クラウド

2021.05.05

Cloud Security Alliance がクラウド利用時のインシデント対応のためのガイドを公表していますね。。。

こんにちは、丸山満彦です。

Cloud Security Alliance がクラウド利用時のインシデント対応のためのガイドを公表していますね。。。

運用における標準約款契約を含む国際的多層委託モデルが複数存在し、かつオンプレ環境もある状況が当たり前になってくる中で、インシデント対応はより複雑になってきますよね。。。これ、日本語化してくれるといいかもですね。。。

● Cloud Security Alliance

・2021.05.04 (press) Cloud Security Alliance’s New Cloud Incident Response Framework Serves as Transparent, Common Blueprint Through Which to Share Best Practices

・2021.05.04 (published) Cloud Incident Response Framewor

Key Takeaways: Key Takeaways
How to effectively manage cloud incidents through the entire lifecycle of a disruptive event, including: 破壊的イベントのライフサイクル全体を通して、クラウド・インシデントをいかに効果的に管理するかについての
・Preparation ・準備
・Detection and analysis ・検知と分析
・Containment, eradication, and recovery ・封じ込め、根絶、回復
・Post-mortem ・事後処理
How to coordinate and share information with stakeholders and other organizations ステークホルダーや他の組織といかに調整や情報共有をするか
Who It’s For: 想定読者
All cloud customers すべてのクラウド利用者
Cloud service providers who need a clear framework for sharing incident response practices with customers インシデント対応方法を利用者と共有するための明確なフレームワークを必要とするクラウドサービスプロバイダー

 

20210505-53437

Table of Contents 目次
1. Introduction  1. 序文
Purpose  目的
Target Audience 想定読者
2. Normative References 2. 規範となる文献
3. Definitions 3. 定義
4. CIR Overview 4. CIRの概要
5. CIR Framework 5. CIRの枠組み
5.1 Phase 1: Preparation and Follow-on Review 5.1 フェーズ1:準備とフォローオンレビュー
5.1.1 Documentation 5.1.1 文書化
5.2 Phase 2: Detection and Analysis 5.2 フェーズ2:検知と分析
5.2.1 Inducement 5.2.1 誘引
5.2.1.1 Cause of Cloud Incident 5.2.1.1 クラウドインシデントの原因
5.2.1.2 Signs of an Incident 5.2.1.2 インシデントの兆候
5.2.1.3 Common Sources of Precursors and Indicators 5.2.1.3 前兆と指標の一般的な情報源
5.2.2 Incident Analysis to Determine Impacts 5.2.2 影響を決めるためのインシデント分析
5.2.2.1 Incident Analysis 5.2.2.1 インシデントの分析
5.2.2.2 Incident Notification 5.2.2.2 インシデントの通知
5.2.2.2.1 Incident Notification Timing 5.2.2.2.1 インシデントの通知タイミング
5.2.2.3 Incident Impacts 5.2.2.3 インシデントの影響
5.2.3 Evidence Gathering and Handling 5.2.3 証拠の収集と処理
5.3 Phase 3: Containment, Eradication, and Recovery 5.3 フェーズ3:封じ込め、根絶、回復
5.3.1 Choosing a Containment Strategy 5.3.1 封じ込め戦略の選択
5.3.2 Eradication and Recovery 5.3.2 封じ込めと回復
5.4 Phase 4: Post-Mortem 5.4 フェーズ4:事後処理
5.4.1 Incident Evaluation 5.4.1 インシデントの評価
5.4.1.1 Incident Evaluation Metrics 5.4.1.1 インシデントの評価指標
5.4.1.2 Incident Classification 5.4.1.2 インシデントの分類
5.4.2 Incident Closing Report 5.4.2 インシデントの終結報告
5.4.2.1 Lessons Learned 5.4.2.1 学んだ教訓
5.4.3 Incident Evidence Retention 5.4.3 インシデントの証拠の保持
6. Coordination and Information Sharing 6. 連携と情報共有
6.1 Coordination 6.1 コーディネーション
6.1.1 Coordination Relationships 6.1.1 協調関係
6.1.2 Sharing Agreements and Reporting Requirements 6.1.2 共有契約及び報告要件
6.2 Information-Sharing Techniques 6.2 情報共有の手法
6.3 Granular Information Sharing 6.3 概要レベルの情報共有
6.3.1 Business Impact Information 6.3.1 ビジネスインパクト情報
6.3.2 Technical Information 6.3.2 技術情報
6.4 Table-Top Exercises and Incident Simulations 6.4 テーブルトップ演習とインシデントシミュレーション
7. Summary 7. まとめ

 

 

| | Comments (0)

2021.05.03

中国 意見募集 顔認識に続けて、歩行認識、音声認識のデータセキュリティ要件の国家標準を発表し、意見募集していますね。。。

こんにちは、丸山満彦です。

中国の情報セキュリティ標準化技術委員会(全国信息安全标准化技术委员会 (National Information Security Standardization Technical Committee) )、いわゆるTC260が、顔認識に続けて、歩行認識、音声認識のデータセキュリティ要件の国家標準を発表し、意見募集していますね。。。

● 全国信息安全标准化技术委员会 (National Information Security Standardization Technical Committee) 情報セキュリティ標準化技術委員会

2021.04.28 国家标准《信息安全技术 声纹识别数据安全要求》 国家標準「情報セキュリティ技術 音声認識データのセキュリティ要件 DOCX
2021.04.28 国家标准《信息安全技术 步态识别数据安全要求》 国家標準「情報セキュリティ技術 歩行認識データセキュリティ要件 PDF
2021.04.23 国家标准《信息安全技术 人脸识别数据安全要求》 国家標準「情報セキュリティ技術 顔認識データセキュリティ要件 DOCX

 

国家标准《信息安全技术 声纹识别数据安全要求》 国家標準「情報セキュリティ技術 音声認識データのセキュリティ要件
前言  序文
1 范围  1 範囲
2 规范性引用文件  2 規範となる引用文書
3 术语和定义  3 用語と定義 
4 概述  4 概要 
4.1 声纹识别数据活动典型场景  4.1 音声認識データ活動の典型的なシナリオ 
4.2 声纹识别应用场景  4.2 声紋認証の利用シーン 
4.3 科学实验场景  4.3 科学実験のシナリオ 
4.4 非声纹识别的语音应用场景  4.4 非音声認識音声アプリケーションのシナリオ 
5 基本安全要求  5 基本的なセキュリティ要件 
6 安全处理要求  6 安全な処理の要件 
6.1 通用安全处理要求  6.1 一般的なセキュリティ処理の要件 
6.2 声纹识别应用场景安全处理要求  6.2 音声認識アプリケーションシナリオのセキュリティ処理要件 
6.3 科学实验场景安全处理要求  6.3 科学実験シナリオにおけるセキュリティ処理の要件 
6.4 非声纹识别的语音应用场景安全处理要求  6.4 音声認識以外の音声アプリケーションシナリオのセキュリティ処理要件 
7 安全管理要求 7 セキュリティ管理の要件
附录A (资料性) 声纹识别数据活动的典型场景 附属書A(参考)音声認識データ活動の典型的なシナリオ
A.1 声纹识别应用场景 A.1 音声認識アプリケーションのシナリオ
A.2 科学实验场景 A.2 科学実験のシナリオ
A.3 非声纹识别的语音应用场景 A.3 非音声認識音声アプリケーションのシナリオ
附录B (资料性) 声纹识别数据安全风险分析  附属書B (参考) 音声認識データのセキュリティリスク分析 
B.1 共性风险  B.1 一般的なリスク 
B.2 特性风险  B.2 特徴的なリスク 
附录C (资料性) 科学实验场景知情同意书示例  附属書C(参考) 科学実験シナリオのためのインフォームド・コンセント・フォームの例 
参考文献  参考文献 
   
国家标准《信息安全技术 步态识别数据安全要求》 国家標準「情報セキュリティ技術 歩行認識データセキュリティ要件
前言  序文
1 范围 1 範囲
2 规范性引用文件 2 規範となる引用文書
3 术语和定义 3 用語と定義
4 概述 4 概要
4.1 步态识别数据活动典型场景 4.1 歩行認識データ活動の典型的なシナリオ
4.2 场景分类  4.2 シナリオ分類 
4.3 数据控制者  4.3 データコントローラ 
5 基本安全要求  5 基本的なセキュリティ要件 
6 步态识别数据安全处理要求  6 歩行認識データの安全な処理条件 
6.1 通用安全处理要求  6.1 一般的なセキュリティ処理の要件 
6.2 身份识别应用场景  6.2 識別アプリケーションのシナリオ 
6.3 非身份识别场景  6.3 非識別化シナリオ 
6.4 科研场景  6.4 科学研究のシナリオ 
7 步态识别数据安全管理要求  7 歩行認識データのセキュリティ管理要件 
附录 A (资料性) 步态识别数据活动的典型场景  附属書A(参考) 歩行認識データの活動に関する典型的なシナリオ 
A.1 身份识别应用场景  A.1 識別アプリケーションのシナリオ 
A.2 非身份识别应用场景  A.2 非識別アプリケーションのシナリオ 
A.3 科研场景  A.3 科学研究のシナリオ 
附录 B (资料性) 步态识别数据常见安全风险  附属書B(参考) 歩行認識データに共通するセキュリティリスク 
B.1 常见安全风险  B.1 一般的なセキュリティリスク 
B.2 常见安全风险与条款对照表  B.2 一般的なセキュリティリスクと用語の比較表 
附录 C (资料性) 科学实验场景知情同意书示例  附属書C(参考) 科学実験シナリオのためのインフォームド・コンセント・フォームの例
参考文献  参考文献
   
国家标准《信息安全技术 人脸识别数据安全要求》 国家標準「情報セキュリティ技術 顔認識データセキュリティ要件
前言 序文
1 范围 1 スコープ
2 规范性引用文件 2 基準となる文献
3 术语和定义 3 用語と定義
4 概述 4 概要
5 基本安全要求 5 基本的な安全要件
6 安全处理要求 6 安全な取り扱いの要件
7 安全管理要求 7 安全管理の要件
参考文献 参考文献

20210502-234126


■ 参考

● まるちゃんの情報セキュリティ気まぐれ日記

・2021.04.28 中国 意見募集 スマホアプリによる個人情報保護管理に関する暫定規定

・2020.11.12 中国 TC260 パブコメ オンライン車予約サービスのデータセキュリティに関するガイド案

・2020.11.10 中国 TC260 パブコメ AI倫理に関するガイドライン案

・2020.11.10 中国 TC260 ネットワークセキュリティ状況認識技術の標準化に関する白書

・2020.10.29 中国が情報セキュリティに関連の国家標準のパブコメ (2020.03.20期日以降2020.11.29まで分)

・2020.10.21 中国電子標準化研究所が国家標準GB/T 37988-2019「情報セキュリティ技術 データセキュリティ能力成熟度モデル」に準拠した成熟度評価ツールをリリースしましたね

・2020.02.22 中国サイバーセキュリティ関連組織・・・

・2020.02.04 中国が情報セキュリティに関連の国家標準のパブコメを18件出していました・・・

| | Comments (0)

2021.05.01

Cloud Security Alliance APIを提供・利用するためのセキュリティガイドライン

こんにちは、丸山満彦です。

Cloud Security Allianceが、「APIを提供・利用するためのセキュリティガイドライン」を公表していますね。。。

そういえば、本日のお昼ごろは暗号資産関係の方と少し話をしておりました。。。

Cloud Security Alliance: CSA

・2021.04.30 Security Guidelines for Providing and Consuming APIs

・[PDF]は簡単な質問に答えると入手できます。

20210501-90842

Introduction はじめに
Purpose of This Document この文書の目的
 Document Terminology  用語
 Document Scope  文書の範囲
 Target Audience  想定読者
 Overview  概要
Part 1: Risk Evaluation Part 1: リスク評価
Part 2: Security Checklist Part 2: セキュリティチェックリスト
 API Security Guidelines  APIセキュリティガイドライン
 Section 1: Design for Ingress API Connectivity   セクション1:Ingress API接続の設計 
 Section 2: Design for Egress API Connectivity  セクション2:Egress API接続の設計
Final Thoughts 最終的な考え
Appendix A: Mapping OWASP API Top Ten to Section 1 Controls 附属書A:OWASP API Top Tenとセクション1のコントロールのマッピング
Appendix B: Third-Party Integration – Non-API Access Security Guidelines 附属書B:サードパーティとの統合 - 非 API アクセスセキュリティガイドライン
Appendix C: SaaS Marketplace Integration 附属書C:SaaS マーケットプレイスの統合
Appendix D: Mapping to Other CSA Resources 附属書D:CSA の他のリソースへのマッピング
Further Reading 参考文献

| | Comments (0)

U.K. 王立監査院 (National Audit Office: NAO) がクラウドサービスに関する監査委員会のガイダンスを更新しましたね。。。

こんにちは、丸山満彦です。

英国の王立監査院 (National Audit Office: NAO) がクラウドサービスに関する監査委員会のガイダンスを更新しましたね。。。前のバージョンは2019年に4月でしたから2年ぶりの更新です。記述が増えましたね(^^)

U.K. National Audit Office: NAO

・2021.04.30 Guidance for audit committees on cloud services


このガイダンスでは、クラウドサービスの概要と、その利用に関する政府の方針を説明しています。その上で、監査委員会が経営陣と関わる際に、3つの段階で質問することを検討するための具体的な質問を示しています。

  • クラウドサービスの評価:組織戦略やデジタル戦略、ビジネスケースプロセス、デューデリジェンスの一環としてクラウドサービスを検討する。
  • クラウドサービスの導入:システム構成、データ移行、サービスのリスクとセキュリティを考慮する。
  • クラウドサービスの管理と最適化:運用上の考慮点、第三者による保証の必要性、本番稼動を管理するために必要な能力を説明する。

本ガイダンスは、他で配布されている詳細なクラウド・ガイダンスを参照・補完するものです。


ということのようです。。。

・[PDF] Guidance for audit committees on cloud services

20210430-235829

目次

Foreword 序文
Introduction はじめに
 Why this requires attention  なぜこれが必要なのか
 What is government policy on cloud services?  クラウドサービスに関する政府の政策とは?
 Other guidance available  その他のガイダンス
An overview of cloud services クラウドサービスの概要
 Pricing of cloud services  クラウドサービスの価格
 Legacy systems  従来のシステム
 Lock-in and exit strategy  ロックインと出口戦略
Part One: Assessment of cloud services 第1部:クラウドサービスの評価
 Digital strategy  デジタル戦略
 Business case  ビジネスケース
 Due diligence  デューディリジェンス
Part Two: Implementation of cloud services 第2部:クラウドサービスの導入
 System configuration  システム構成
 Risk and security  リスクとセキュリティ
 Implementation  実装
Part Three: Management and optimisation of cloud services  第3部:クラウドサービスの管理と最適化 
 Operations  運用
 Assurance  保証
 Capability  キャパシティ
Appendix One: National Cyber Security Centre guidance 附属書1:王立サイバーセキュリティセンターのガイダンス
Appendix Two: Assurance arrangements: Service Organisation Controls(SOC) reports, Cyber Essentials and ISO 27001 附属書2:保証体制:Service Organisation Controls(SOC)レポート、Cyber Essentials、ISO 27001

 

2019年4月に初版が公表された時のページです。

・2019.04.24 Guidance for audit committees on cloud services

20210501-00430

 

2018年5月に監査委員会向けの啓発をした時のページです。

・2018.05.24 Transformation guidance for audit committees


このガイダンスは、監査委員会が、経営陣が変革によって何を意図しているのか、サービスはどのように変化するのか、そして目的を達成するための戦略を明確にすることを促すためのものです。本ガイダンスでは、3つの段階での質問と、注目すべき証拠や指標を示しています。

  • セットアップ:ビジョン、戦略、ガバナンス、アーキテクチャ、および変革の進化する性質を含みます。
  • 提供:変更と実装、およびサービスとパフォーマンスの管理をカバーします。
  • 実運用と便益の実現:人、プロセス、技術を対象とします。

変革においてデータが中心的な役割を果たすことを踏まえ、本ガイダンスでは、監査委員会がデータの役割と管理について質問できる項目も用意されています。


20210501-60920

 

2017年に監査委員会向けにサイバーセキュリティについて発表した資料

・2017.09.13 Cyber security and information risk guidance for Audit Committees


以下をカバーする質問と問題のチェックリストを提供します。

  • サイバーセキュリティとリスク管理についての全体的なアプローチ
  • サイバーセキュリティを管理するために必要な機能
  • 情報リスク管理、ネットワークセキュリティ、ユーザー教育、インシデント管理、マルウェア保護、監視、在宅およびモバイル作業などの特定の側面
  • クラウドサービスの利用や新しいサービス・テクノロジーの開発などの関連分野

20210501-61608

 

| | Comments (0)

2021.04.30

MITRE ATT&CKのVer 9.0がリリースされましたね。。。

こんにちは、丸山満彦です。

MITRE ATT&CKのVer 9.0がリリースされましたね。。。

主な変更点はブログを見ればわかりやすいと思います。。。、まだ追いきれていませんが...(^^;;

MITRE ATT&CK

概要はBlogがわかりやすいです。

・2021.04.29 Data Sources, Containers, Cloud, and More: What’s New in ATT&CK v9? by Jamie Williams

Updated: A revamp of data sources (Episode 1 of 2) 更新:データソースの刷新(第1話/第2話)
Updated: Some refreshes to macOS techniques 更新:macOSの操作方法を一部変更しました。
New: Consolidation of IaaS platforms 新規: IaaSプラットフォームの統合
New: The Google Workspace platform 新規:Google Workspaceプラットフォーム
New: ATT&CK for Containers (and not the kind on boats) 新規:コンテナ(船の上にあるものではありません)のためののATT&CK

 

詳細はこちら。。。

Updates - April 2021

 

Twitter (MITRE ATT&CK) でも告知されています...

2021.04.29 

 


 

■ 関連

● まるちゃんの情報セキュリティきまぐれ日記

・2021.02.28 MITRE "Intelligence After Next"

・2020.11.18 MITRE : INTELLIGENCE AFTER NEXT: THE FUTURE OF THE IC WORKPLACE (自宅でインテリジェンス?)

・2020.10.28 MITRE ATT&CKのVer 8.0がリリースされましたね。。。

・2020.10.24 敵対的機械学習に対する脅威マトリックス (Adversarial ML Threat Matrix)

・2020.08.27 MITRE Shield vs MITRE ATT&CK

・2020.07.08 MITRE ATT&CKのVer 7.0がリリースされましたね。。。

| | Comments (0)

2021.04.28

中国 意見募集 スマホアプリによる個人情報保護管理に関する暫定規定

こんにちは、丸山満彦です。

中国の個人情報関係の規則や基準ってどうも全体像がよくわかりません。。。どこかでじっくり学ばないとですね。。。

 

中共中央网络安全和信息化委员会办公室中国共産党中央委員会ネットワークセキュリティ・情報化対策室

・2021.04.26 移动互联网应用程序个人信息保护管理暂行规定 - 公开征求意见(モバイル・インターネット・アプリケーションの個人情報保護管理に関する暫定規定 - 意見募集)

 

北大法宝

・2021.04.25 将出台App个人信息保护管理暂行规定(アプリ個人情報保護管理規定が導入されます)

 

● 全国信息安全标准化技术委员会 (National Information Security Standardization Technical Committee)

(いわゆるTC260)がセキュリティについて以下の意見募集をおこなっています。。。関係する標準もありますね。。。

国家标准《信息安全技术 人脸识别数据安全要求》 国家標準「情報セキュリティ技術 顔認識データセキュリティ要件」
国家标准《信息安全技术 移动互联网应用程序(APP)个人信息安全测评规范》  国家標準「情報セキュリティ技術 モバイルインターネットアプリケーション(APP)個人情報セキュリティ測定仕様」
国家标准《信息安全技术 移动互联网应用程序(APP)SDK安全指南》 国家標準「情報セキュリティ技術 モバイルインターネットアプリケーション(APP)SDKセキュリティガイド」
国家标准《信息安全技术 政务网络安全监测平台技术规范》  国家標準「政府機関ネットワークのセキュリティ監視プラットフォームの情報セキュリティ技術技術仕様」 
国家标准《信息安全技术 信息系统密码应用测评要求》  国家標準「情報セキュリティ技術 情報システムパスワードアプリケーション測定要件」
国家标准《信息安全技术 个人信息去标识化效果分级评估规范》 国家標準「情報セキュリティ技術 個人情報匿名化効果採点評価仕様書」
国家标准《信息安全技术 边缘计算安全技术要求》  国家標準「情報セキュリティ技術 エッジコンピューティング セキュリティ技術の要件」
国家标准《信息安全技术 IPSec VPN安全接入基本要求与实施指南》 国家標準「情報セキュリティ技術 IPSec VPN セキュリティアクセス基本要件および実装ガイド」

 

Photo_20210427233701

 


まるちゃんの情報セキュリティきまぐれ日記

・2021.02.09 中国 国務院独占禁止委員会がプラットフォーム経済に関する独占禁止ガイドラインを発表していますね。。。

・2021.01.27 中国 TC260 パブコメ ブロックチェーン情報サービスのセキュリティ仕様他

・2021.01.09 中国 互联网信息服务管理办法(インターネット情報サービスの運営に関する措置)の改訂案について意見募集中

・2020.12.17 中国 セキュリティ評価に合格したクラウドプラットフォーム

・2020.11.12 中国 TC260 パブコメ オンライン車予約サービスのデータセキュリティに関するガイド案

・2020.11.10 中国 TC260 パブコメ AI倫理に関するガイドライン案

・2020.11.10 中国 TC260 ネットワークセキュリティ状況認識技術の標準化に関する白書

・2020.10.29 中国が情報セキュリティに関連の国家標準のパブコメ (2020.03.20期日以降2020.11.29まで分)

・2020.10.21 中国電子標準化研究所が国家標準GB/T 37988-2019「情報セキュリティ技術 データセキュリティ能力成熟度モデル」に準拠した成熟度評価ツールをリリースしましたね

・2020.05.02 中国 サイバースペース管理局、他11局が共同で、サイバーセキュリティレビューのための措置を発行しましたね。。。

・2020.02.22 中国サイバーセキュリティ関連組織・・・

・2020.02.04 中国が情報セキュリティに関連の国家標準のパブコメを18件出していました・・・

 


↓↓↓↓ パブコメの対象 ↓↓↓↓

Continue reading "中国 意見募集 スマホアプリによる個人情報保護管理に関する暫定規定"

| | Comments (0)

2021.04.26

NISC 意見募集「政府機関等のサイバーセキュリティ対策のための統一基準群」の改定(案)

こんにちは、丸山満彦です。

内閣官房サイバーセキュリティセンター (NISC) が、政府機関等のサイバーセキュリティ対策のための統一基準群」の改定(案)について意見募集をしていますね。

思い返せば、NISCが「内閣官房 情報セキュリティ対策推進室」(多分)といわれていた頃に内閣官房に参加し、まずは情報セキュリティセンターの立ち上げと同時に、政府統一基準の策定を進めておりましたね。当時は、内閣府の新しいビルが立つ前で、そこに3階建のプレハブがあり、そこで色々としておりましたね。。。もう、16年以上も前の話ですね。。。

作成当時の重要なルールとして、「主語」を明確にするというのがありましたね。XXXをする責任を持ってするのは誰か?を明確にするということですね。これは、セキュリティの役割の「椅子」を用意することができないので、担当という「帽子」を被せるということにしたのですが、どの帽子の人が何をしなければならないかを明確にしないといけないですよね。。。ということから来ています。。。

なので遵守事項は、「最高情報セキュリティ責任者は」とか、「職員等(当時は、「行政事務従事者」でしたね。。。)は」とか、になっているんですよね。。。

今回は、「ISMAPの制度」もできたし、「常時アクセス判断・許可アーキテクチャ」(きっとゼロトラスト的なものなんでしょう。。。)も海外政府では取り組んでいるし、「コロナで在宅やし」という感じですかね。。

● NISC

・2021.04.26「政府機関等のサイバーセキュリティ対策のための統一基準群」の改定(案)に関する意見の募集

意見募集は...

20210426-143641

20210426-143744 

20210426-143804

ここからは、参考資料...

見直しの概要


1.クラウドサービスの利用拡大を見据えた記載の充実
■ 政府情報システムのためのセキュリティ評価制度(ISMAP)の管理基準も踏まえ、クラウドサービス利用者側として実施すべき対策や考え方に係る記載を追加。
⇒外部サービスを安全に利用するために、業務内容や取り扱う情報の格付や取扱制限に応じた情報セキュリティ対策を自ら講じられることが重要。

2.情報セキュリティ対策の動向を踏まえた記載の充実
■ 政府機関等を標的とした主要なサイバー攻撃や近年の情報セキュリティインシデント事例、最新のセキュリティ対策などを踏まえた記載、また今後取り組むべき情報セキュリティ対策の将来像について記載。
⇒従来からの境界型防御を補完するものとして「常時アクセス判断・許可アーキテクチャ」にも目を向ける。また、情報システム「常時システム診断・対処」を引き続き推進するなど、情報セキュリティ対策基盤を着実に進化させることが重要。

3.多様な働き方を前提とした情報セキュリティ対策の整理
■ 新型コロナウイルス感染症対策として政府機関等においても急速に広まったテレワークや遠隔会議の経験も踏まえ、係る多様な働き方を前提とする場合に必要な情報セキュリティ対策について、参照すべき統一基準上の規定や解説を整理することで、政府機関等が実施すべき対策の水準を明確にする。
⇒危機管理や働き方改革への対応として、通常とは異なる環境下においても必要な情報セキュリティ水準を確保した上で業務の円滑な継続を図ることが重要。


新旧対照表

です。。。

 

| | Comments (0)

2021.04.20

気になった記事2つ(大変革期に突入した自動車産業とサイバーセキュリティ、クラウドネイティブセキュリティ101)

こんにちは、丸山満彦です。

今日は、気になった記事を2つ紹介したいと思います。

最初は、JNSAの自動車セキュリティに関連する記事で、J-Auto-ISACの中島さんの記事です...

● JNSA - リレーコラム

・2021.04.16 第209号:大変革期に突入した自動車産業とサイバーセキュリティ

印象に残ったのが、


すでにクルマの制御プログラムに使用するソースコードの総行数はスマホOSの1,200万行、戦闘機の2,400万行を大きく上回り、2億行に迫っています。今後の自動運転技術の進展を踏まえて6億行に達するという予測も出ています。


という話です。自動車のコードって戦闘機よりのコードよりも多いんですね。プロが乗る戦闘機と違い、一般大衆が乗る自動車だからこそ、エラー処理も含めて丁寧に対応する必要もあってコードが増えているという面もあるのですかね。。。

まぁ、いずれにしても2億行もコードがあれば、どこかに脆弱性はあるでしょうし、いろいろな利害関係者のネットワークと思うと対応が難しいかもしれませんね。。。そして、


今、自動車業界は「ソフトウェアのサプライチェインマネジメント」という課題に直面しています。しかし何層もの裾野産業に支えられた巨大なピラミッド構造を考えると解決は容易ではありません。


という話です。

ソフトウェアというかプログラムの資産管理が必要かもしれませんね。。。ソフトウェアBOMのような仕組みです。オープンソフトも含めて考えなければならないのですが、何かアイデアを絞って考える必要がありますね。。。

 

 

もう一つは、「クラウドネイティブセキュリティ101」です。

● Cloud Seucurity Alliance

・2021.04.19 Cloud-Native Security 101

これは、Intezerブログ2021.04.01に掲載されていたものを再掲載したものです。これからクラウドネイティブに変わるとセキュリティについての考え方を変えて行かないといけないのでは、という話です。

Traditional perimeter-based security approaches fall short for cloud-native applications. The deployment and delivery processes have become more decentralized and agile, but security strategies need to be revamped to keep up with development. As those strategies change and enterprises shift to cloud-native applications, what are the do’s and don’ts of security? 従来の境界線を利用したセキュリティアプローチでは、クラウド・ネイティブ・アプリケーションには対応できません。デプロイメントとデリバリーのプロセスはより分散化され、アジャイルになっていますが、開発に追いつくためにはセキュリティ戦略を見直す必要があります。このような戦略の変化と企業のクラウドネイティブアプリケーションへの移行に伴い、セキュリティの「やるべきこと」と「やってはいけないこと」はどのようになっているのでしょうか。

という話です。

deployment と delivery の違いとか、整理しないといけないなぁと思ったりしました。。。

次のポイントが指摘されていました。参考まで...

The “Cattle, Not Pets” Approach 「ペットではなく牛」というアプローチ
Dynamically scalable environments drive agility in the cloud, where environments are created and destroyed as needed. This means that security should be integrated with the deployment process through security as code to keep up with the speed of development. In short, security should be integrated into design from day one, not as an afterthought. 動的に拡張可能な環境は、必要に応じて環境を作成したり破壊したりするクラウドのアジリティを促進します。つまり、開発のスピードに追いつくためには、セキュリティをコードとして統合し、デプロイメント・プロセスに組み込む必要があります。つまり、セキュリティは後付けではなく、初日から設計に組み込まれるべきなのです。
As workloads move to the cloud, deployments get automated through infrastructure as code (IaC). If you integrate security best practices into IaC, the resources will be protected when you deploy for the first time, reducing the attack surface. Deploying resources first and securing them later leaves your application vulnerable to attack. ワークロードがクラウドに移行すると、Infrastructure as Code(IaC)によってデプロイメントが自動化されます。IaCにセキュリティのベストプラクティスを統合すれば、最初にデプロイする際にリソースが保護され、攻撃対象が減少します。リソースを先にデプロイし、後からセキュリティを確保すると、アプリケーションは攻撃されやすい状態になります。
... ...
Focus on Runtime Protection ランタイム保護の重視
When compared to cloud non-native deployments, the focus shifts from perimeter security to runtime security in the cloud. While minimizing attack surface is important, it is also crucial to ensure comprehensive runtime security. クラウドの非ネイティブなデプロイメントと比較すると、クラウドでは境界線のセキュリティからランタイムのセキュリティに焦点が移ります。攻撃対象を最小限に抑えることは重要ですが、包括的なランタイム・セキュリティを確保することも重要です。
... ...
Undetected Threats in Linux Linuxに潜む脅威
... ...
Linux is traditionally considered secure, as it has features like SELinux and restricted user access, which is reinforced with cloud firewalls and access control mechanisms. However, recent trends show that Linux is increasingly becoming a preferred target for attackers. Linuxは、SELinuxのような機能を持ち、ユーザーのアクセスが制限されており、クラウドのファイアウォールやアクセス制御機構で強化されているため、伝統的に安全だと考えられています。しかし、最近の傾向では、Linuxが攻撃者の好ましい標的となるケースが増えています。
... ...
Cloud-Native Microservices クラウドネイティブなマイクロサービス
... ...
However, keep in mind that the cloud follows a shared responsibility model, where ownership of workload security is still with the customer. Defense-in-depth security practices for cloud-native microservices should include guardrails at all layers, such as the cluster, containers and code security. しかし、クラウドは責任共有モデルを採用しており、ワークロードのセキュリティの所有権は依然として顧客にあることに留意してください。 クラウドネイティブなマイクロサービスのための徹底したセキュリティ対策には、クラスター、コンテナ、コードセキュリティなど、すべての層でガードレールを設ける必要があります。
... ...
Moving one layer deeper to containers, where the workloads are deployed, it is recommended to implement image scanning to identify compromised images. Enabling the principle of least privilege (PoLP) for users will help to protect against unauthorized access to containers. You should also avoid security anti-patterns, such as disabling SELinux, host root access, and privilege elevation. Any configuration change should be enabled only through CI/CD pipelines, and deviations should be strictly monitored and reported. また、ワークロードが配置されているコンテナについては、イメージスキャンを実施して危険なイメージを特定することが推奨されます。ユーザーにPoLP(Principle of least privilege)を有効にすることで、コンテナへの不正なアクセスから保護することができます。また、SELinuxの無効化、ホストのルートアクセス、特権昇格など、セキュリティのアンチパターンを避ける必要があります。構成の変更は、CI/CDパイプラインを通じてのみ有効にし、逸脱は厳密に監視して報告する必要があります。
In addition to cluster and container security, you should also ensure code security through static code analysis, third-party library scanning for vulnerabilities, use of automated tools to protect from known attacks, port restriction, and other means. クラスタやコンテナのセキュリティに加えて、静的なコード解析、サードパーティのライブラリによる脆弱性のスキャン、既知の攻撃から保護するための自動化ツールの使用、ポートの制限などにより、コードのセキュリティを確保する必要があります。
... ...

セキュリティ対策の根本は変わらないと思いますが、重点を当てる部分や手段は環境に合わせて考える必要がありますね。。。

 

2021.04.20 13:12 追記

「“Cattle, Not Pets”って何?」と質問がきたのですが、これはパブリッククラウドを説明する際に、過去から時々出てくる言い回しのようなもので、要は、「あなたにとってかけがえのないたった一つのペット(従来のオンプレミスの比喩)ではなくて、広大な牧場にいる番号で管理されている牛の群れ(クラウドの比喩)を扱っているという感覚ですよ。。。ということだと思います。。。多分。。。」

1_20210420085201

| | Comments (0)

2021.04.16

FedRAMP インシデント・コミュニケーション手順4.0の公表

こんにちは、丸山満彦です。

これも、2021.04.15の一連の措置の一環として、CISA緊急指令への対応が含まれていますね。。。

FedRAMP

・2021.04.15 (blog) Release of FedRAMP Incident Communications Procedures

・[PDF] FedRAMP Incident Communications Procedures Version 4.0

20210416-105829

Introduction and Purpose 序文・目的
Applicability 適用
Compliance コンプライアンス
Applicable Laws and Regulations 適用法と規制
Applicable Standards and Guidance 適用される基準とガイダンス
Assumptions 前提条件
Roles and Responsibilities 役割と責任
CSP General Reporting Process クラウド・サービス・プロバイダーの一般的な報告プロセス
JAB Reviewers’ Responsibilities 共同承認ボードのレビュアーの責任
Appendix A: CSP General Reporting Process Graphic 附属書A:クラウド・サービス・プロバイダーの一般的な報告プロセスのグラフィック

 

■ 参考

● まるちゃんの情報セキュリティ気まぐれ日記

・2021.04.16 White HouseはSolarWindsの不正アクセスに関連する行動がロシアによるものと正式に認め制裁を課す大統領令を発出していますね。。。 U.S. サイバー軍と国土安全保障省-CISAはSolarWindsの不正アクセスに関連するロシア製マルウェアのサンプルを公開

2021.03.27 上院軍事委員会公聴会特殊作戦コマンドとサイバーコマンド

・2021.03.19 米国 下院エネルギー・商業委員会は、SolarWindsサイバー攻撃に関する情報を要求する超党派議員に関する声明を発表し、関係省庁に質問状を送付していますね。。。

・2021.01.07 米国 FBI,、CISA,、国家情報長官室(ODNI)、国家安全保障局(NSA)がSolar Winds関連事案に関して共同声明を公表していますね。

・2021.01.01 U.S. CISAが、攻撃者がSolarWinds Orionのソフトウェアのサプライチェーンを侵害し一般的に使用されている認証メカニズムを広範囲に悪用しているとして、ウェブサイトを立ち上げ、無料の検証ツールを提供していますね。。。

2020.12.21 U.S. NSA 認証メカニズムを悪用してクラウド上のリソースに攻撃者がアクセスすることについての注意喚起

・2020.12.19 米国国土安全保障省 緊急指令21-01 関連。。。SolarWinds Orion Code Compromise

 

 

| | Comments (0)

2021.04.14

Cloud Security Alliance 暗号資産交換セキュリティガイドライン

こんにちは、丸山満彦です。

Cloud Security Allianceが、「CSAが暗号資産交換セキュリティガイドライン」を公表していますね。。。

そういえば、本日のお昼ごろは暗号資産関係の方と少し話をしておりました。。。

Cloud Security Alliance: CSA

・2021.04.13 CSA Crypto-Asset Exchange Security Guidelines Abstract

・[PDF]は簡単な質問に答えると入手できます。

20210413-234458

 

Key Takeaways: 要点
The types of attacks that threaten crypto-asset exchanges 暗号資産取引所を脅かす攻撃の種類
The details of a centralized exchange reference architecture that applies to a broad spectrum of crypto-asset exchanges 広範な暗号資産取引所に適用される集中型取引所リファレンスアーキテクチャの詳細
Crypto-asset exchange security best practices for end-users, exchange operators, and auditors エンドユーザ、取引所運営者、監査人向け暗号資産取引所セキュリティのベストプラクティス
Crypto-asset exchange administrative and physical security control measures including: legal considerations, risk management, information access management, security awareness and training, workstation security, and more 法的考察、リスク管理、情報アクセス管理、セキュリティ意識とトレーニング、ワークステーションのセキュリティを含む、暗号アセット取引所の管理および物理的なセキュリティ管理対策

 

目次は、

1. Crypto-Asset Exchange Threat Modeling 1. 暗号資産取引所の脅威モデル
Threat Models Against Exchanges 取引所に対する脅威モデル
2. Crypto-assets Exchange Security Reference Architecture 2. 暗号資産取引所のセキュリティ参照アーキテクチャ
3. Crypto-Asset Exchange Security Best Practices 3. 暗号資産取引所のセキュリティのベストプラクティス
3.1 Security Best Practices from End-User Perspective 3.1 エンドユーザから見たセキュリティのベストプラクティス
3.2 Security best practices from Exchange Operator’s perspective 3.2 取引所運営者から見たセキュリティのベストプラクティス
3.3 Security Best Practices from Auditor’s Perspective 3.3 監査人から見たセキュリティのベストプラクティス
4. Crypto-asset Exchange Administrative and Physical Security 4. 暗号資産取引所の管理的・物理的セキュリティ
4.1 Administrative Controls 4.1 管理的コントロール
4.2 Crypto-asset Exchange Legal Aspects 4.2 暗号資産取引所の法的側面
4.3 Insurance for Exchanges: Internal and External 4.3 取引所の保険:内部・外部
4.4 Exchange Alliance for Security Incidents 4.4 セキュリティインシデントに対する取引所の提携
4.5 Risk Management Process 4.5 リスク管理プロセス
4.6 Assigned Security Responsibility 4.6 割り当てられたセキュリティ責任
4.7 Policies and Procedures 4.7 方針と手続き
4.8 Information Access Management 4.8 情報アクセス管理
4.9 Security Awareness and Training 4.9 セキュリティに関する意識向上とトレーニング
4.10 Security Incident Management Procedures 4.10 セキュリティインシデント管理手順
4.11 Contingency Plan 4.11 コンティンジェンシー計画
4.12 Evaluation 4.12 評価
4.13 Physical Controls 4.13 物理的コントロール

 

3.1 エンドユーザから見たセキュリティのベストプラクティス3.2 取引所運営者から見たセキュリティのベストプラクティス

3.1 Security Best Practices from End-User Perspective 3.1 エンドユーザから見たセキュリティのベストプラクティス
1. Use reputable and safe exchanges 1. 信頼できる安全な取引所の利用
2. Password management and Two-Factor or Multi-Factor Authentication 2. パスワード管理と2要素または多要素認証
3. Use a separate device 3. 別デバイスの使用
4. Understand the key concepts associated with wallet application 4. 財布アプリケーションに関する重要なコンセプトの理解
 Public Key and Address  公開鍵とアドレス
 Private Key  秘密鍵
 Keystore File  鍵保管ファイル
 Mnemonic Phrase (Recovery Phrase)  ニーモニックフレーズ(リカバリーフレーズ)
5. Be careful what you install or click 5. インストール、クリック時の注意
6. Protect sensitive data 6. 大切なデータの保護
7. Keep your device secure 7. デバイスの安全保持
8. Always use secure network connection 8. 安全なネットワーク接続
9. Know different types of wallets and how to use them 9. 財布の種類と使い方の理解
 Paper Wallets  ペーパーウォレット
 Software Wallets  ソフトウェアウォレット
 Hardware Wallets  ハードウェアウォレット
10. Use Multisig for large amount of funds 10. 多額の資金についてのマルチシグの利用
   
3.2 Security best practices from Exchange Operator’s perspective 3.2 取引所運営者から見たセキュリティのベストプラクティス
1. Distributed Denial of Service Attack (DDoS) protection 1. 分散型サービス拒否攻撃(DDoS)対策
 Increase Network Bandwidth  ネットワーク帯域幅の拡大
 Use Early Detection and Packet Monitoring DDoS Attack Mitigation  早期発見とパケット監視による DDoS 攻撃の緩和
 Manage and Block Malicious Traffic  悪質なトラフィックの管理とブロック
 Build Infrastructure Redundancy  インフラの冗長化
 Incorporate ISP Redundancy  ISPの冗長性の確保
 Blocking DDoS Attacks With a Cloud Solution  クラウドソリューションによるDDoS攻撃の遮断
2. Cross-Site Scripting (XSS-Protection) 2. クロスサイトスクリプティング(XSS-Protection)
3. Do Not Expose Server Information 3. サーバ情報の不開示
4. Web Application Firewall 4. ウェブアプリケーションファイアウォール
5. Database Firewall 5. データベースファイアーウォール
6. Third-Party Components and Patch 6. サードパーティ製コンポーネントとパッチ
7. Clickjacking Attack and X-Frame-Options 7. クリックジャッキング攻撃とX-Frame-Options
8. HSTS (HTTP Strict-Transport-Security) and Secure Socket Layer (SSL) 8. HSTS(HTTP Strict-Transport-Security)とSSL(Secure Socket Layer)
9. Applying Machine Learning for Better Protection 9. 機械学習を利用した保護機能の強化
 Flow Analysis  フロー解析
 Address Classification  アドレスの分類
 Analyzing Trading Behaviors  取引行動の分析
 Fraud Detection  不正行為の検知
10. HTTP Public Key Pinning (HPKP) 10. HTTP Public Key Pinning (HPKP)
11. Use Hardware Security Module (HSM) Enabled Wallet 11. ハードウェア・セキュリティ・モジュール(HSM)対応財布の使用
12. Deploy a Zero Trust Architecture 12. ゼロトラストアーキテクチャの導入
13. Error Handling 13. エラー処理
14. 2FA 14. 2要素認証
15. 51% attack 15. 51%攻撃
16. Cloud Service Security Protection 16. クラウドサービスのセキュリティ保護

 

■ 関連

ブロックチェーンのユースケース

・2019.07.31 Documentation of Relevant Distributed Ledger Technology and Blockchain Use Cases v2

・[PDF]は簡単な質問に答えると入手できます。

  • 国際決済
  • 投票
  • 土地登記所
  • 食品サプライチェーン
  • メディアとエンターテインメント
  • 身元
  • 使用料
  • 保険

 

・2018.11.27 Blockchain DLT Use Cases

・[PDF]は簡単な質問に答えると入手できます。

  • 運送
  • 航空券販売
  • 自動再保険
  • Nostro銀行口座の調整
  • 医薬品サプライチェーンのセキュリティ
  • 食品安全
  • 教育
  • サプライチェーン
  • 不動産 

| | Comments (0)

より以前の記事一覧