cybersecurity-analyst

サイバーセキュリティアナリストスキル

目的

サイバーセキュリティの専門的な視点から事象を分析し、厳格なセキュリティフレームワーク（CIA トライアド、多層防御、ゼロトラスト）、脅威モデリング手法（STRIDE、PASTA、VAST）、攻撃対象領域の分析、業界標準（NIST、ISO 27001、MITRE ATT&CK）を適用して、セキュリティリスクを理解し、脆弱性を特定し、脅威アクターと攻撃ベクトルを評価し、防御制御を検証し、リスク軽減策を推奨します。

このスキルを使用する場面

• セキュリティインシデント分析：侵害、データ漏えい、ランサムウェア攻撃、内部脅威を調査します
• 脆弱性評価：システム、アプリケーション、ネットワーク、プロセスの弱点を特定します
• 脅威モデリング：新しいシステムや変更に対する潜在的な攻撃ベクトルと脅威アクターを分析します
• セキュリティアーキテクチャレビュー：設計上の決定がセキュリティに与える影響と、その抜け漏れを評価します
• リスク評価：CVSS、FAIR などのフレームワークを使用してセキュリティリスクを定量化し、優先順位を付けます
• コンプライアンス分析：セキュリティ標準（SOC 2、PCI-DSS、HIPAA、GDPR）への準拠状況を評価します
• インシデント対応計画：検知、封じ込め、根絶、復旧の戦略を策定します
• セキュリティ態勢評価：防御能力全体とその成熟度を評価します
• コードセキュリティレビュー：ソフトウェアの実装におけるセキュリティ上の脆弱性を特定します

中核となる考え方：セキュリティ思考

サイバーセキュリティ分析は、基本原則に基づいています。

多層防御：完璧なセキュリティ制御はありません。複数の独立した制御を重ね、一つが侵害されてもシステム全体が侵害されないようにします。

侵害を前提とする：現代のセキュリティでは、攻撃者が境界防御を突破すると想定します。侵害が発生した場合（発生するかどうかではなく、いつ発生するか）に、被害を最小限に抑え、検知できるようシステムを設計します。

最小権限：正当な機能に必要な最小限のアクセス権を付与します。過剰な権限はすべて、悪用の機会となります。

ゼロトラスト：決して信頼せず、常に検証します。明示的に検証し、最小権限のアクセスを使用し、ネットワーク上の場所にかかわらず侵害を前提とします。

セキュア・バイ・デザイン：セキュリティは後から付け足せるものではありません。初期段階からアーキテクチャと実装の根幹に組み込む必要があります。

CIA トライアド：セキュリティは3つの特性を保護します。機密性（認可されたアクセスのみ）、完全性（認可された変更のみ）、可用性（必要なときにアクセスできること）です。

脅威情報に基づく防御：実際の脅威アクター、その能力、動機、戦術に関する理解（脅威インテリジェンス）をもとに、防御の優先順位を決めます。

リスクベースのアプローチ：完璧なセキュリティは実現できません。リスク（発生可能性 × 影響）に基づいてセキュリティ投資に優先順位を付け、支出あたりのセキュリティ効果を最大化します。

---

理論的基盤（展開可能）

基礎 1：CIA トライアド（従来のセキュリティモデル）

構成要素：

機密性：認可されたエンティティのみが情報にアクセスできます

• 保護メカニズム：暗号化、アクセス制御、認証
• 脅威：盗聴、データ窃取、不正な開示
• 違反の例：データ侵害、パスワード窃取、内部関係者による漏えい

完全性：認可されたエンティティのみが、認可された方法で情報を変更できます

• 保護メカニズム：ハッシュ化、デジタル署名、アクセス制御、バージョン管理
• 脅威：改ざん、不正な変更、マルウェア
• 違反の例：データベースの改ざん、中間者攻撃、ランサムウェアによる暗号化

可用性：認可されたエンティティが必要なときに、情報やシステムにアクセスできます

• 保護メカニズム：冗長化、バックアップ、DDoS 対策、インシデント対応
• 脅威：サービス拒否、ランサムウェア、システムの破壊
• 違反の例：DDoS 攻撃、ランサムウェア、インフラストラクチャの障害

拡張要素：

• 真正性：エンティティの身元と情報の出所が検証されていること
• 否認防止：行為を否定できないこと
• 説明責任：行為をエンティティまで追跡できること

適用：あらゆるセキュリティ分析で、CIA トライアドのどの側面がリスクにさらされているか、また各側面をどのような制御で保護するかを特定する必要があります。

出典：

• CIA Triad - Wikipedia
• NIST Cybersecurity Framework

基礎 2：多層防御（階層型セキュリティ）

原則：複数のセキュリティ制御層を導入し、1 つの層が侵害されてもシステム全体が侵害されないようにします。

歴史的起源：軍事防衛戦略――複数の同心円状の境界防御

セキュリティ層：

1. 物理：施設へのアクセス制御、施錠されたサーバールーム
2. ネットワーク：ファイアウォール、ネットワークのセグメンテーション、IDS/IPS
3. ホスト：エンドポイント保護、ホストファイアウォール、パッチ管理
4. アプリケーション：入力検証、安全なコーディング、認証
5. データ：保存時および転送時の暗号化、DLP、トークン化
6. 人的要素：セキュリティ意識向上トレーニング、フィッシングシミュレーション

重要な洞察：冗長性は無駄ではなく、レジリエンスです。攻撃者がファイアウォールを突破しても、認証、認可、監視、暗号化、検知の各制御に直面します。

適用：セキュリティアーキテクチャでは、重要な資産を保護するために、独立した防御層を複数設ける必要があります。

制限事項：層が維持されていなかったり、相互依存していたりすると、複雑さや誤った安心感を生む可能性があります。

出典：

• Defense in Depth - NSA
• Layered Security - CISA

基盤 3：ゼロトラストアーキテクチャ

中核となる原則：「決して信頼せず、常に検証する」。ネットワーク上の場所に関係なく適用します。

境界モデルとの違い：従来のセキュリティでは、内部ネットワークは信頼できると想定していました（「城壁と堀」）。ゼロトラストでは、どのネットワーク上の場所も信頼できないと想定します。

主要な原則（NIST SP 800-207）：

1. 明示的に検証する：利用可能なすべてのデータポイントに基づいて、常に認証と認可を行います。
2. 最小権限アクセス：ジャストインタイムアクセスと必要最小限のアクセスによって、ユーザーのアクセスを制限します。
3. 侵害を前提とする：影響範囲を最小限に抑え、アクセスを分割します。エンドツーエンド暗号化を検証します。

構成要素：

• アイデンティティ中心のセキュリティ：アイデンティティが新たな境界になります。
• マイクロセグメンテーション：ネットワークを小さなゾーンに分割し、それぞれに個別の制御を適用します。
• 継続的な検証：認証と認可は一度限りではなく、継続的に行われます。
• データ中心：周囲の境界だけでなく、データそのものを保護します。

推進要因：

• クラウドの導入（明確な境界がない）
• リモートワーク（ユーザーが従来の境界の外にいる）
• 高度な攻撃（境界の侵害が頻発）

適用：特にクラウド環境やハイブリッド環境では、ゼロトラストの原則に基づいて最新のセキュリティアーキテクチャを設計する必要があります。

出典：

• NIST SP 800-207：ゼロトラストアーキテクチャ
• ゼロトラスト - Microsoft Security

基盤 4：脅威モデリング

定義：システムに対する潜在的な脅威を特定し、優先順位を付けるための体系的なアプローチです。

目的：修正コストが最も低い設計段階で、セキュリティ上の問題を事前に特定します。

メリット：

• 実装前に脆弱性を発見する
• セキュリティ作業に優先順位を付ける
• ステークホルダーにリスクを伝える
• セキュリティテストの指針とする

一般的な手法：

STRIDE（Microsoft）：

• S：なりすまし
• T：データの改ざん
• R：否認
• I：情報漏えい
• D：サービス拒否
• E：権限昇格

PASTA（攻撃シミュレーションと脅威分析のプロセス）：

• リスク中心の7段階手法
• ビジネス目標と技術要件を整合させます

VAST（視覚的、アジャイル、シンプルな脅威モデリング）：

• アジャイル開発向けに拡張可能です
• 2種類あります：アプリケーション脅威モデルと運用脅威モデル

適用：新機能、アーキテクチャの変更、またはセキュリティレビューに脅威モデリングを使用します。

出典：

• 脅威モデリング - OWASP
• STRIDE 脅威モデル - Microsoft

基盤 5：MITRE ATT&CK フレームワーク

説明：実環境での観察に基づく、攻撃者の戦術と手法に関するナレッジベースです。

目的：攻撃者の行動を理解し、防御、検知、脅威ハンティングに役立てます。

構造：

• 戦術：大まかな目標（例：初期アクセス、実行、永続化、権限昇格）
• 手法：戦術を達成する方法（例：フィッシング、公開アプリケーションの悪用）
• サブテクニック：具体的な実装方法
• 手順：攻撃者の具体的な行動

14 の戦術（エンタープライズマトリクス）：

1. 偵察
2. リソース開発
3. 初期アクセス
4. 実行
5. 永続化
6. 権限昇格
7. 防御回避
8. 認証情報へのアクセス
9. 探索
10. 横方向の移動
11. 収集
12. コマンド＆コントロール
13. 持ち出し
14. 影響

適用：

• 防御策を ATT&CK の手法にマッピングする
• 検知の不足箇所を特定する
• 脅威インテリジェンスを共有する
• レッドチーム／パープルチーム演習を行う

価値：攻撃者の行動を説明する共通言語となり、脅威情報に基づく防御の基盤となります。

出典：

• MITRE ATT&CK
• ATT&CK Navigator

---

中核となる分析フレームワーク（展開可能）

フレームワーク 1：攻撃対象領域の分析

定義：権限のないユーザーがシステムに侵入したり、システムからデータを持ち出したりできるすべての箇所を特定し、評価することです。

構成要素：

攻撃対象領域の要素：

• ネットワーク攻撃対象領域：外部に公開されているポート、サービス、プロトコル
• ソフトウェア攻撃対象領域：アプリケーション、API、Web インターフェース
• 人的攻撃対象領域：ユーザー、管理者、ソーシャルエンジニアリングの標的
• 物理的攻撃対象領域：施設への立ち入り、ハードウェアへのアクセス

攻撃ベクトル：攻撃者が攻撃対象領域を悪用するために使う手段です。

• ネットワークベース：ポートスキャン、プロトコルの悪用、中間者攻撃
• Web ベース：SQL インジェクション、XSS、CSRF、認証の回避
• メールベース：フィッシング、悪意のある添付ファイル、認証情報の窃取
• 物理的：窃盗、不正アクセス、イービルメイド攻撃
• ソーシャルエンジニアリング：口実を使った誘導、餌付け、後ろからの侵入

分析プロセス：

1. 列挙：すべての侵入口と資産を一覧にします
2. 分類：種類と重要度に基づいて分類します
3. 評価：悪用の可能性と影響を評価します
4. 優先順位付け：リスクに基づいて順位を付けます
5. 縮小：不要な露出を最小限に抑えます

指標：

• 外部に公開されているサービスの数
• インターネットに接続可能なアプリケーションの数
• 特権アカウントの数
• 信頼できない入力にさらされるコード行数

適用：攻撃対象領域を縮小することは、基本的な防御策です。不要な露出をなくしましょう。

出典：

• 攻撃対象領域の分析 - OWASP
• 攻撃対象領域の縮小 - Microsoft

フレームワーク 2：リスク評価フレームワーク

目的：リスクを定量化して優先順位を付け、リソース配分の指針とします。

主なフレームワーク：

CVSS（共通脆弱性評価システム）：

• 脆弱性の深刻度を評価するための標準です
• 悪用可能性、影響、スコープに基づいて 0～10 のスコアを付けます
• 基本スコア（本質的な特性）に時間的評価基準と環境評価基準のスコアを加えます
• 広く使われていますが、特定の状況における実際のリスクを捉えられないと批判されています

FAIR（情報リスクの要因分析）：

• 定量的なリスクフレームワークです
• リスク ＝ 損失イベントの発生頻度 × 損失の大きさ
• セキュリティ投資の費用対効果分析が可能です
• より複雑ですが、金額で表したリスク値を算出できます

NIST リスク管理フレームワーク（RMF）：

• 7 つのステップ：準備、分類、選択、実装、評価、承認、監視
• セキュリティ管理策をリスク管理に結び付けます
• 米国連邦政府機関で使用されています

定性的評価と定量的評価：

• 定性的評価：高／中／低のリスク評価（より簡単で迅速ですが、主観的です）
• 定量的評価：数値によるリスク値（複雑で客観的ですが、データが必要です）

適用：リスク評価は、優先順位付けの指針となります。すべての脆弱性が同じ重要度ではありません。最もリスクの高いものに注力しましょう。

出典：

• CVSS
• FAIR Institute
• NIST RMF

フレームワーク 3：セキュリティ管理策フレームワーク

目的：セキュリティ目標を達成するための、体系化されたセキュリティ管理策のセット

主なフレームワーク：

NIST サイバーセキュリティフレームワーク：

• 5 つの中核機能：識別、防御、検知、対応、復旧
• 規範的ではなく、さまざまな組織に合わせて柔軟に適用できます
• 業界全体および国際的に広く採用されています

NIST SP 800-53（セキュリティおよびプライバシー管理策）：

• 連邦政府システム向けの包括的なセキュリティ管理策カタログ
• 20 の管理策ファミリー（アクセス制御、インシデント対応など）
• 詳細な実装ガイダンス

CIS Controls（Center for Internet Security）：

• 優先順位付けされた 18 のセキュリティ管理策
• 組織の成熟度に基づく実装グループ（IG1、IG2、IG3）
• 実行可能で測定可能

ISO/IEC 27001：

• 情報セキュリティマネジメントシステムに関する国際規格
• 14 の管理策ドメイン、114 の管理策
• 認証を取得できます

適用：フレームワークを使用して、次のことを実現します。

• 包括的な網羅性を確保する
• セキュリティ態勢をベンチマークする
• ステークホルダーとコミュニケーションを取る
• コンプライアンス要件を満たす

出典：

• NIST サイバーセキュリティフレームワーク
• CIS Controls
• ISO 27001

フレームワーク 4：インシデント対応ライフサイクル

定義：セキュリティインシデントに対処するための体系的なアプローチ

標準モデル（NIST SP 800-61）：

フェーズ 1：準備

• IR 機能、ツール、プレイブックを整備する
• トレーニングと演習を行う
• コミュニケーション計画を策定する

フェーズ 2：検知と分析

• 監視とアラート
• インシデントの分類と優先順位付け
• 初期調査
• 範囲の特定

フェーズ 3：封じ込め、根絶、復旧

• 封じ込め：拡散を阻止する（短期および長期）
• 根絶：環境から脅威を除去する
• 復旧：システムを通常運用に戻す

フェーズ 4：インシデント後の活動

• 教訓の整理
• 証拠の保全
• インシデント報告書
• プロセスの改善

主な概念：

• プレイブック：一般的なインシデントの種類に対応する、事前に定義された手順
• 侵害の痕跡（IoC）：悪意のある活動を示す痕跡
• 証拠保全の連鎖：証拠の取り扱い手順
• コミュニケーション：社内外のステークホルダー、法務、広報

指標：

• 平均検知時間（MTTD）
• 平均対応時間（MTTR）
• 平均封じ込め時間（MTTC）

適用：効果的なインシデント対応は、被害を最小限に抑え、復旧時間を短縮し、得られた教訓を蓄積します。

出典：

• NIST SP 800-61：コンピューターセキュリティインシデント対応ガイド
• SANS インシデント対応

フレームワーク 5：セキュア開発ライフサイクル（SDL）

目的：ソフトウェア開発プロセスにセキュリティを組み込むこと

Microsoft SDL のフェーズ：

1. トレーニング：開発者向けのセキュリティトレーニング
2. 要件：セキュリティ要件とプライバシー要件を定義する
3. 設計：脅威モデリング、攻撃対象領域の縮小、多層防御
4. 実装：セキュアコーディング標準、コード分析ツール
5. 検証：セキュリティテスト（SAST、DAST、ペネトレーションテスト）
6. リリース：最終的なセキュリティレビュー、インシデント対応計画
7. 対応：脆弱性が発見された場合にインシデント対応計画を実行する

主なプラクティス：

• 静的解析（SAST）：ソースコードを分析して脆弱性を検出する
• 動的解析（DAST）：実行中のアプリケーションをテストする
• 依存関係のスキャン：サードパーティライブラリに既知の脆弱性がないか確認する
• ペネトレーションテスト：実際の攻撃をシミュレーションする
• セキュリティチャンピオン：開発チームにセキュリティの専門知識を組み込む

OWASP SAMM（ソフトウェア保証成熟度モデル）：

• セキュアなソフトウェア開発のための成熟度モデル
• 5 つのビジネス機能：ガバナンス、設計、実装、検証、運用
• 各機能に 3 つの成熟度レベル

適用：セキュリティは開発ライフサイクル全体を通じて組み込む必要があり、最後に追加するだけでは不十分です。

出典：

• Microsoft SDL
• OWASP SAMM

---

方法論的アプローチ（拡張可能）

方法 1：脅威インテリジェンス分析

目的：防御に役立てるため、攻撃者、その能力、戦術、標的を把握すること

脅威インテリジェンスの種類：

戦略的：経営幹部向けの高レベルな傾向

• APT グループの活動と動機
• 地政学的なサイバー脅威
• 業界固有の脅威状況

オペレーショナル：セキュリティ運用向けのキャンペーンレベルの情報

• 現在進行中の攻撃キャンペーン
• 脅威アクターの TTP
• マルウェアファミリー

戦術的：即時の防御に向けた技術的な指標

• IP アドレス、ドメイン、ファイルハッシュ
• YARA ルール、Snort シグネチャ
• 悪用されている CVE

分析プロセス：

1. 収集：内部ソース、脅威フィード、OSINT、ダークウェブからデータを収集する
2. 処理：正規化、相関付け、重複排除を行う
3. 分析：コンテキスト化、帰属の特定、意図と能力の評価を行う
4. 共有：実行可能な形式で関係チームと共有する
5. フィードバック：有効性を評価し、改善する

フレームワーク：

• ダイヤモンドモデル：攻撃者、能力、インフラストラクチャ、被害者
• キルチェーン：偵察 → 武器化 → 配信 → 悪用 → インストール → C2 → 目的達成のための行動
• MITRE ATT&CK：観測された手法を ATT&CK マトリックスにマッピングする

適用：脅威インテリジェンスにより、一般的なセキュリティ対策ではなく、脅威に基づくプロアクティブな防御が可能になります。

出典：

• CISA 脅威インテリジェンス
• 脅威インテリジェンス - SANS

方法 2：侵入テスト

定義：システムのセキュリティを評価するために、許可を得て模擬攻撃を行います。

種類：

ブラックボックス：事前知識なし（外部の攻撃者をシミュレートします）

グレーボックス：部分的な知識あり（内部関係者または侵害されたユーザーをシミュレートします）

ホワイトボックス：完全な知識あり（包括的なセキュリティ評価です）

フェーズ（Penetration Testing Execution Standard）：

1. 事前エンゲージメント：範囲、エンゲージメントルール、法的合意
2. 情報収集：OSINT、ネットワークスキャン、サービス列挙
3. 脅威モデリング：潜在的な攻撃ベクトルを特定します
4. 脆弱性分析：悪用可能な弱点を特定します
5. 脆弱性の悪用：脆弱性の悪用を試みます
6. 侵入後の活動：影響、ラテラルムーブメント、権限昇格を評価します
7. 報告：調査結果を文書化し、影響を示し、修正の指針を提示します

専門的な種類：

• Web アプリケーション侵入テスト：OWASP Top 10 に重点を置きます
• ネットワーク侵入テスト：内部および外部ネットワークを対象とします
• ソーシャルエンジニアリング：フィッシング、ビッシング、物理的侵入
• ワイヤレス侵入テスト：WiFi セキュリティ評価

レッドチームと侵入テストの違い：

• 侵入テスト：できるだけ多くの脆弱性を見つけます
• レッドチーム演習：目標指向（例：特定のデータへのアクセス）で、APT をシミュレートし、検知と対応をテストします

適用：定期的な侵入テストにより、攻撃者に発見される前に、セキュリティ対策の有効性を検証し、ギャップを特定できます。

出典：

• Penetration Testing Execution Standard
• OWASP Testing Guide

方法 3：セキュリティアーキテクチャレビュー

目的：システム設計のセキュリティ特性を評価し、アーキテクチャ上の脆弱性を特定します。

レビューの観点：

構造分析：

• 信頼境界とデータフロー
• 認証および認可のアーキテクチャ
• ネットワークのセグメンテーションと分離
• データの分類と保護

脅威モデリング：

• STRIDE またはその他の手法を適用します
• 攻撃ツリーを特定します
• 特定した脅威に対する緩和策を評価します

対策の評価：

• 対策を CIA トライアドに対応付けます
• 多層防御の各層を評価します
• 単一障害点を特定します

コンプライアンスレビュー：

• セキュリティフレームワーク（NIST、CIS、ISO）への準拠を確認します
• 規制要件（PCI-DSS、HIPAA、SOC 2）を確認します

テクノロジーの評価：

• 暗号技術の実装
• セキュアプロトコル
• パッチ管理のアプローチ
• シークレット管理

分析時の質問：

• 信頼境界はどこですか？
• 機密データはどこを流れますか？
• 認証／認可はどのように適用されますか？
• コンポーネント X が侵害された場合、何が起こりますか？
• セキュリティ上の前提は文書化され、検証されていますか？

成果物：

• セキュリティ注釈付きのアーキテクチャ図
• 脅威モデル
• リスク評価
• 修正の推奨事項

適用：設計フェーズでアーキテクチャレビューを行うことで、本番環境での高コストなセキュリティ問題を防止できます。

方法 4：脆弱性の評価と管理

目的：セキュリティ上の弱点を体系的に特定、分類、優先順位付けし、修正します

プロセス：

フェーズ 1：検出

• 資産のインベントリ作成（何を保有しているか）
• 脆弱性スキャン（自動化ツール）
• 手動でのセキュリティテスト
• コードレビュー（静的解析）

フェーズ 2：評価

• 脆弱性を種類と深刻度で分類する
• 悪用可能性を評価する（エクスプロイトコードがあるか。実際に悪用されているか）
• 影響を特定する（どのデータ／システムがリスクにさらされているか）
• リスクスコアを算出する（CVSS、状況に応じた要因）

フェーズ 3：優先順位付け

• リスク（可能性 × 影響）に基づいて順位付けする
• 脅威インテリジェンスを考慮する（実環境で悪用されているか）
• 影響を受ける資産のビジネス上の重要度
• 修正の複雑さ

フェーズ 4：修正

• パッチ適用（理想的な方法）
• 設定変更
• 代替的な対策（パッチ適用が不可能な場合）
• リスクの受容（文書化して承認する）

フェーズ 5：検証

• 再スキャンして修正を確認する
• 脆弱性データベースを更新する
• 指標を追跡する（修正までの時間、脆弱性密度）

課題：

• アラート疲れ（検出結果が多すぎる）
• 誤検知
• パッチ適用による業務中断
• レガシーシステム

ベストプラクティス：

• リスクベースの優先順位付け（CVSS だけに頼らない）
• SLA に基づく修正（Critical：7 日、High：30 日など）
• 可能な限り自動化する
• 傾向と指標を追跡する

適用：継続的な脆弱性管理は、不可欠な基本対策です。把握していない問題は修正できません。

出典：

• NIST SP 800-40：パッチと脆弱性の管理

方法 5：セキュリティ監視と検知エンジニアリング

目的：悪意のある活動を検知する機能を設計し、運用します

構成要素：

データソース：

• ネットワークトラフィック（NetFlow、全パケットキャプチャ）
• エンドポイントログ（プロセスの作成、ファイルアクセス、レジストリの変更）
• 認証ログ（ログイン、権限昇格）
• アプリケーションログ（エラー、トランザクション）
• クラウド API と監査ログ

検知の仕組み：

シグネチャベース：既知の悪意あるパターン（ウイルス対策、IDS シグネチャ）

• 長所：誤検知が少なく、高速
• 短所：既知の脅威しか検知できない

異常ベース：ベースラインの動作からの逸脱

• 長所：新種の攻撃を検知できる
• 短所：誤検知が多く、調整が必要

ヒューリスティックベース：攻撃者の行動パターンに基づくルール

• 長所：既知の攻撃の亜種を検知できる
• 短所：ルールの作成にはセキュリティの専門知識が必要

脅威インテリジェンスベース：既知の IoC と照合する

• 長所：集合知を活用できる
• 短所：事後対応となる（侵害後に指標が発見される）

検知の開発：

1. 攻撃者の手法を理解する（MITRE ATT&CK）
2. その手法を記録しているデータソースを特定する
3. 検知ロジックを開発する
4. 真陽性と誤検知を使ってテストする
5. しきい値とロジックを調整する
6. 検知と対応の手順を文書化する
7. 有効性を監視し、反復的に改善する

SIEM と SOC：

• SIEM：セキュリティログを集約、相関分析、分析する
• SOC：セキュリティオペレーションセンター。アラートを監視し、インシデントに対応するチーム

指標：

• 検知範囲（カバーしている ATT&CK 手法の割合）
• アラートの量と品質
• 誤検知率
• 平均検知時間（MTTD）

適用：検知できないものには対応できません。直面する脅威に沿った検知機能に投資してください。

出典：

• 検知エンジニアリング - Splunk
• Sigma ルール

---

分析評価基準

調査する項目

資産とデータ：

• どのような機密データが存在しますか？（PII、認証情報、企業秘密、財務データ）
• それらはどこに保存、処理、送信されますか？
• 誰がアクセスできますか？
• 侵害された場合のビジネスへの影響は何ですか？（機密性、完全性、可用性）

攻撃対象領域：

• どのシステムがインターネットに公開されていますか？
• 攻撃者の侵入経路は何ですか？
• どのような認証が必要ですか？
• どのようなサードパーティ依存関係がありますか？

脅威アクター：

• 誰がこれを標的にする可能性がありますか？（国家、サイバー犯罪者、ハクティビスト、内部関係者）
• 彼らの能力と動機は何ですか？
• 通常どのようなTTPを使用しますか？
• 利用できる脅威インテリジェンスはありますか？

脆弱性：

• 既知のソフトウェア脆弱性（CVE）はありますか？
• 設定上の弱点はありますか？
• アーキテクチャ上のセキュリティ上の欠陥はありますか？
• コードレベルの脆弱性はありますか？
• 人的要因による脆弱性（フィッシングへの脆弱性）はありますか？

既存の対策：

• どのようなセキュリティ対策が導入されていますか？
• 多層防御の原則に従っていますか？
• 適切に設定され、維持されていますか？
• どのような検知・対応能力がありますか？

確認すべき質問

脅威に関する質問：

• 何が問題になり得ますか？
• 最も可能性の高い攻撃経路は何ですか？
• どのような脅威アクターがこれを標的にする可能性がありますか？
• 彼らの目標と能力は何ですか？
• 関連する過去のインシデントはありますか？

脆弱性に関する質問：

• どのような弱点がありますか？
• どの程度悪用されやすいですか？
• 悪用された場合の影響は何ですか？
• 既知のエクスプロイトや、現在進行中の悪用はありますか？
• 脆弱性をどの程度迅速に修正できますか？

対策に関する質問：

• どのような保護策が導入されていますか？
• その有効性はどの程度ですか？
• 防御範囲にどのようなギャップがありますか？
• 対策を回避できますか？
• 悪意のある活動をどのように検知しますか？

リスクに関する質問：

• 侵害が発生する可能性はどの程度ですか？
• 想定される影響は何ですか？
• 全体的なリスクレベルはどの程度ですか？
• 組織のリスク許容度と比べて、リスクはどの程度ですか？
• どのようなリスク対応の選択肢がありますか？（軽減、受容、移転、回避）

コンプライアンスに関する質問：

• どのような規制や基準が適用されますか？
• セキュリティ要件を満たしていますか？
• コンプライアンスを示す証拠は何ですか？
• どのようなギャップがありますか？

考慮すべき要因

技術的要因：

• システムのアーキテクチャと設計
• 技術スタックとバージョン
• 設定とセキュリティ強化
• 暗号の実装
• ネットワークトポロジとセグメンテーション

組織的要因：

• セキュリティの成熟度と文化
• 利用可能なリソースと予算
• リスク許容度
• 規制環境
• ビジネス上の重要性

脅威の状況：

• 現在の脅威アクターの活動
• 新たに出現している攻撃手法
• 業界固有の脅威
• 地政学的要因

運用上の要因：

• パッチ管理プロセス
• インシデント対応能力
• セキュリティの監視と検知
• セキュリティ意識向上とトレーニング
• サードパーティリスク管理

考慮すべき過去の類似事例

• 類似のセキュリティインシデント
• 比較可能な脆弱性の悪用
• 業界固有の攻撃パターン
• 大規模な情報漏えいから得られた教訓
• 脅威アクターのTTPの変化

検討すべき影響

直近のセキュリティ上の影響：

• 機密性：データ侵害のリスク
• 完全性：データ改ざんまたは破損のリスク
• 可用性：サービス停止のリスク
• 財務：身代金、復旧費用、罰金

より広範な影響：

• 評判の毀損
• 法的・規制上の影響
• 顧客の信頼の低下
• 競争上の不利益
• システミックリスク（重要インフラに関わる場合）

戦略上の影響：

• 必要となるセキュリティアーキテクチャの変更
• セキュリティプログラムの成熟度に関するギャップ
• リソースの配分と優先順位付け
• リスク管理のアプローチ

---

ステップごとの分析プロセス

ステップ 1：範囲とコンテキストを定義する

アクション：

• 分析対象のシステム、アプリケーション、またはイベントを明確に特定します
• 境界とインターフェースを決定します
• ステークホルダーとそのセキュリティ要件を特定します
• ビジネスコンテキストと重要度を理解します
• 関連ドキュメント（アーキテクチャ図、データフロー、ポリシー）を収集します

成果物：

• スコープ記述書
• 資産インベントリ
• ステークホルダーリスト
• ビジネスコンテキストの理解

ステップ 2：資産とデータを特定する

アクション：

• 重要な資産（システム、データ、サービス）を列挙します
• 機密性に応じてデータを分類します（公開、内部、機密、制限付き）
• データフローをマッピングします（データが作成、保存、処理、送信、破棄される場所）
• 最重要資産（最も価値の高い資産）を特定します

成果物：

• 重要度評価付きの資産インベントリ
• データ分類マトリックス
• データフロー図
• 最重要資産リスト

ステップ 3：攻撃対象領域を分析する

アクション：

• すべての侵入口（API、Web インターフェース、ネットワークサービス、物理アクセス）を列挙します
• 信頼境界（信頼されていない入力が信頼されたゾーンに入る場所）を特定します
• 認証および認可のポイントをマッピングします
• 依存関係（サードパーティサービス、ライブラリ、サプライヤー）を特定します

成果物：

• 攻撃対象領域マップ
• 信頼境界図
• 侵入口インベントリ
• 依存関係リスト

ステップ 4：脅威モデリングを実施する

アクション：

• 脅威モデリング手法（STRIDE、PASTA など）を選択します
• 潜在的な脅威アクターとその目標を特定します
• 各資産に対する潜在的な攻撃ベクトルを列挙します
• 攻撃経路を示す攻撃ツリーを作成します
• MITRE ATT&CK の手法に対応付けます

成果物：

• 脅威モデル文書
• 脅威アクターのプロファイル
• 攻撃ツリー図
• ATT&CK 手法の対応付け

ステップ 5：脆弱性を特定する

アクション：

• 使用中のテクノロジーに関する既知の CVE を確認します
• セキュリティベンチマーク（CIS、STIG など）に照らして設定を分析します
• アーキテクチャにセキュリティ設計上の欠陥がないか確認します
• 該当する場合は、コードレベルの脆弱性を検討します
• 人的な脆弱性（フィッシングへの脆弱性、権限の不正使用）を評価します

成果物：

• 脆弱性インベントリ
• CVSS スコアまたはリスク評価
• 設定ギャップ分析
• アーキテクチャ上のセキュリティ課題

ステップ 6：既存の管理策を評価する

アクション：

• すべてのレイヤー（ネットワーク、ホスト、アプリケーション、データ）にわたるセキュリティ管理策を一覧にします
• 管理策を脅威に対応付けます（どの脅威を管理策で軽減できるか）
• 管理策の有効性を評価します（適切に設定されているか、維持されているか、監視されているか）
• 管理策のギャップ（十分な軽減策がない脅威）を特定します
• 検知および対応能力を評価します

成果物：

• 管理策インベントリ
• 脅威と管理策の対応付けマトリックス
• 管理策の有効性評価
• 検知範囲のギャップ

ステップ 7：リスクを分析する

アクション：

• 脅威と脆弱性の各組み合わせについて、発生可能性と影響を推定します
• リスクスコア（定性的または定量的）を算出します
• リスクに優先順位を付けます
• 組織のリスク許容度と比較します
• リスク間の相互依存関係や連鎖的な影響を考慮します

成果物：

• リスク登録簿
• リスクヒートマップ
• 優先順位付けされたリスト
• リスク受容に関する推奨事項

ステップ 8：検知と対応を評価する

アクション：

• どのような悪意ある活動が検知されるかを評価します
• さまざまな攻撃シナリオについて、MTTD（平均検知時間）を評価します
• インシデント対応計画とプレイブックを確認します
• インシデント対応チームの能力を評価します
• 検知または対応におけるギャップを特定します

成果物：

• 検知範囲の評価
• MTTD の推定値
• IR 能力の評価
• 検知と対応のギャップ

ステップ 9：修正策を策定する

アクション：

• 特定したリスクに対する緩和策を提案します（予防、検知、是正）。
• リスク低減効果と実施に必要な労力に基づいて優先順位を付けます。
• 直接的な緩和が現実的でない場合は、代替統制策を検討します。
• コストと実施期間を見積もります。
• 緩和しないリスクについて、リスク受容を文書化します。

成果物：

• 修正ロードマップ
• 優先順位付けされた推奨事項の一覧
• 費用対効果分析
• リスク受容に関する文書

ステップ 10：コンプライアンス要件を検討する

アクション：

• 適用される規制や標準を特定します。
• 統制をコンプライアンス要件に対応付けます。
• コンプライアンスの証拠を文書化します。
• コンプライアンス上のギャップを特定します。
• コンプライアンスの達成または維持に必要な対応を提案します。

成果物：

• コンプライアンスマトリックス
• ギャップ分析
• 証拠に関する文書
• コンプライアンス修正計画

ステップ 11：結果を統合して報告する

アクション：

• 対象者（経営幹部、技術チーム、コンプライアンス担当者）ごとに主要な調査結果を要約します。
• 明確なリスク評価と推奨事項を提示します。
• 指標と KPI を含めます。
• 前提条件と制約事項を文書化します。
• 担当者と期限を設定したアクションプランを作成します。

成果物：

• エグゼクティブサマリー
• 技術的な調査結果レポート
• 修正ロードマップ
• コンプライアンスの概要

---

使用例

例1：セキュリティインシデント - ランサムウェア攻撃

イベント：組織がランサムウェア攻撃を受け、ファイルが暗号化され、身代金の支払いを要求するメモが残されました

分析：

ステップ1 - 範囲とコンテキスト：

• 影響を受けたシステム：ファイルサーバー、ワークステーション、バックアップ
• ビジネスへの影響：業務が停止し、データを利用できない
• 重要事項：ランサムウェアの亜種、暗号化の範囲、攻撃者のアクセス状況を把握する

ステップ2 - 資産：

• 最重要資産：顧客データベース、財務記録、知的財産
• 状況：ファイルが暗号化され、可用性が損なわれている

ステップ3 - 攻撃対象領域の分析：

• 初期アクセスベクトル：フィッシングメール、または脆弱な RDP エンドポイントの可能性が高い
• 横方向の移動：SMB、認証情報の窃取

ステップ4 - 脅威モデリング（インシデント発生後）：

• 脅威アクター：金銭目的のサイバー犯罪グループの可能性が高い
• ATT&CK のマッピング：
  • 初期アクセス：フィッシング、またはインターネットに公開されたアプリケーションの悪用
  • 実行：ユーザーによる実行、またはクライアント実行を目的とした悪用
  • 永続化：レジストリの Run キー、スケジュールされたタスク
  • 権限昇格：権限昇格を目的とした悪用
  • 認証情報アクセス：認証情報のダンプ
  • 横方向の移動：SMB／Windows 管理共有
  • 影響：影響を与えるためのデータ暗号化

ステップ5 - 脆弱性：

• フィッシングに対する脆弱性（メールフィルタリングがなく、ユーザートレーニングも不十分）
• パッチが適用されていない RDP の脆弱性
• 弱いパスワード、または認証情報の使い回し
• 不十分なネットワークセグメンテーション（ランサムウェアが容易に拡散）
• バックアップの脆弱性（バックアップも暗号化）

ステップ6 - 対策の評価：

• 欠如：メールセキュリティゲートウェイ、EDR、MFA
• 不十分：ネットワークセグメンテーション、バックアップの隔離、パッチ管理
• 失敗：ウイルス対策ソフトがランサムウェアを検知できなかった

ステップ7 - リスク分析：

• 影響度：高（業務の中断、データ損失、身代金要求、評判の毀損）
• 発生可能性：高（実証済み—インシデントが発生）
• 残存リスク：重大（改善しなければ、再発する可能性が高い）

ステップ8 - 検知と対応：

• 検知：暗号化が始まるまで失敗（EDR がなく、ログも限定的）
• MTTD：数時間から数日（遅すぎる）
• 対応：プレイブックがなく、対応の連携も不十分
• 不足点：IR チームがなく、コミュニケーション計画も法務／広報との連携もない

ステップ9 - 推奨事項（優先順位順）：

直ちに（数時間から数日）：

1. 影響を受けたシステムを隔離する（拡散を封じ込める）
2. ランサムウェアの亜種を特定し、復号ツールがないか確認する
3. 社内に対応能力がない場合は、インシデント対応企業に依頼する
4. 直ちに身代金を支払わない（まず代替策を評価する）
5. 法務、保険会社、必要に応じて法執行機関に通知する

短期（数日から数週間）：

1. 利用可能で、侵害されていないバックアップから復元する
2. すべてのエンドポイントに EDR を導入する
3. すべてのリモートアクセスに MFA を実装する
4. 根本原因と範囲を特定するため、フォレンジック調査を実施する
5. IR プレイブックを作成してテストする

中期（数週間から数か月）：

1. ネットワークセグメンテーション（横方向の移動を防止）
2. メールセキュリティゲートウェイ（フィッシングを阻止）
3. 特権アクセス管理（認証情報の窃取を制限）
4. セキュリティ意識向上トレーニング（フィッシングの成功率を低減）
5. バックアップの強化（エアギャップ化、またはイミュータブルバックアップ）

長期（数か月から1年）：

1. セキュリティ成熟度の評価とロードマップ
2. 24時間365日の SOC、または MDR サービス
3. ペネトレーションテストとレッドチーム演習
4. 包括的な脆弱性管理プログラム

ステップ10 - コンプライアンス：

• 規制上の通知要件（GDPR、州のデータ侵害関連法など）
• サイバー保険の保険金請求
• 監査人向けにインシデントを記録する

ステップ11 - 総括：

• 根本原因：フィッシング／RDP の悪用、不十分な検知、弱いセグメンテーション、バックアップの脆弱性が複合
• 主な教訓：多層防御の失敗—複数の対策の不備が攻撃の成功を許した
• 優先事項：直ちに封じ込めと復旧を行い、その後、検知と予防の対策を整備する
• コスト：身代金要求額＋ダウンタイム＋復旧＋修復＋評判の毀損（数百万に上る可能性）

例2：脆弱性評価 - 新しい Web アプリケーションのリリース

イベント：組織が顧客向け Web アプリケーションのリリースを計画しており、リリース前のセキュリティレビューが依頼されました

分析：

ステップ 1 - スコープ：

• アプリケーション：E コマース Web アプリケーション
• ユーザー：外部顧客
• データ：個人情報、決済情報、注文履歴
• 重要度：高（収益を生み出し、顧客の信頼に関わる）

ステップ 2 - 資産：

• 顧客の個人情報と決済データ（機密性と完全性が重要）
• 在庫と価格のデータ（完全性と可用性が重要）
• アプリケーションの可用性（収益への影響）

ステップ 3 - 攻撃対象領域：

• Web インターフェース（一般公開）
• API（モバイルアプリ、サードパーティとの連携）
• 管理ポータル（内部ユーザー）
• 決済プロセッサとの連携
• サードパーティのライブラリと依存関係

ステップ 4 - 脅威モデリング（STRIDE）：

なりすまし：

• 脅威：攻撃者がユーザーまたは管理者になりすまします
• 緩和策：強力な認証、多要素認証、セッション管理

改ざん：

• 脅威：攻撃者が価格、注文、またはユーザーデータを改ざんします
• 緩和策：入力検証、認可チェック、完全性制御

否認：

• 脅威：ユーザーが注文したことを否認します
• 緩和策：監査ログ、トランザクション署名

情報漏えい：

• 脅威：攻撃者が他のユーザーの個人情報や決済情報にアクセスします
• 緩和策：認可チェック、暗号化、安全なセッション管理

サービス拒否：

• 脅威：攻撃者がアプリケーションに過剰な負荷をかけます
• 緩和策：レート制限、DDoS 対策、スケーラブルなインフラストラクチャ

権限昇格：

• 脅威：ユーザーが管理者アクセス権を取得します
• 緩和策：最小権限、安全な認可、権限の分離

ステップ 5 - 脆弱性（OWASP Top 10 分析）：

1. アクセス制御の不備：IDOR 脆弱性、水平方向／垂直方向の権限昇格を確認します
2. 暗号化の失敗：保存中および転送中の暗号化、鍵管理を検証します
3. インジェクション：SQL インジェクション、XSS、コマンドインジェクションをテストします
4. 安全でない設計：セキュリティ設計上の欠陥、脅威モデルの不足を確認します
5. セキュリティ設定のミス：デフォルトの認証情報、不要な機能、詳細すぎるエラーメッセージを確認します
6. 脆弱なコンポーネント：依存関係をスキャンして、既知の CVE を確認します
7. 認証の失敗：パスワードポリシー、セッション管理、多要素認証をテストします
8. ソフトウェア／データの完全性：サプライチェーンのセキュリティ、署名されていない更新を検証します
9. ログ記録の失敗：セキュリティイベントが記録されていること、ログの改ざんが防止されていることを確認します
10. SSRF：サーバーサイドリクエストフォージェリの脆弱性をテストします

ステップ 6 - 対策の評価：

良好な所見：

• すべての接続で TLS 1.3 を使用
• パスワードは bcrypt でハッシュ化
• 入力検証フレームワークを使用
• CI/CD で依存関係をスキャン

特定されたギャップ：

• 顧客アカウントで多要素認証を使用していない
• 管理ポータルが別のドメイン／ネットワークに分離されていない
• 詳細すぎるエラーメッセージによってスタックトレースが露出する
• API エンドポイントにレート制限がない
• 一部のサードパーティ依存関係に既知の CVE がある
• 認可チェックが不十分（IDOR 脆弱性）
• Web アプリケーションファイアウォール（WAF）がない

ステップ 7 - リスク分析：

重大なリスク：

• IDOR 脆弱性：発生可能性：高、影響：大（データ侵害）
• 脆弱な依存関係：発生可能性：中、影響：大（RCE の可能性）

高リスク：

• レート制限なし：発生可能性：高、影響：中（スクレイピング、ブルートフォース）
• 管理ポータルが同じドメイン上にある：発生可能性：低、影響：大（認証情報の窃取）

中リスク：

• 詳細すぎるエラー：発生可能性：中、影響：中（情報漏えい）
• 多要素認証なし：発生可能性：低（現時点）、影響：大（アカウント乗っ取り）

ステップ 8 - 検知と対応：

• ログ記録：認証とトランザクションについては十分
• SIEM 連携：未設定
• インシデント対応プレイブック：汎用的であり、アプリケーション固有のシナリオが必要です
• 推奨事項：SIEM を設定し、アプリケーション固有のインシデント対応プレイブックを作成し、不審なパターンに対するアラートを実装します

ステップ 9 - 推奨事項（リスク順）：

リリース前に必ず修正（重大）：

1. IDOR 脆弱性を修正します（認可チェックを実装）
2. 脆弱な依存関係を更新します
3. 本番環境で詳細なエラーメッセージを削除します
4. すべてのエンドポイントにレート制限を実装します

リリース前に修正すべき項目（高）：

1. OWASP Core Rule Set を導入した WAF をデプロイします
2. 管理ポータルを分離します（別ドメイン、VPN／IP 制限）
3. SIEM 連携とアラートを設定します

リリース後（中）：

1. 顧客アカウントに MFA を実装します
2. ログを強化します（より多くのセキュリティイベントを記録）
3. ペネトレーションテストを実施します
4. バグ報奨金プログラムを設立します

ステップ 10 - コンプライアンス：

• PCI-DSS：決済カードデータを扱う場合に必須です（トークン化を使用し、カード会員データ環境を最小限にします）
• GDPR/CCPA：顧客データのプライバシー要件です（同意、データ最小化、侵害通知）
• SOC 2：B2B 顧客から保証を求められる場合

ステップ 11 - 総合評価：

• アプリケーションの基盤は堅牢です（最新の暗号技術、入力検証、依存関係スキャン）
• リリース前に重大な問題を修正する必要があります（IDOR、脆弱な依存関係）
• WAF により、Web の脅威に対する多層防御を実現できます
• リリース後：テスト、バグ報奨金、セキュリティ監視を継続します
• リリース可否：重大な問題が解決するまでリリース不可です

例 3：セキュリティアーキテクチャレビュー - クラウド移行

イベント：組織がオンプレミスアプリケーションを AWS に移行することを計画しており、セキュリティアーキテクチャレビューが依頼されました

分析：

ステップ 1 - 範囲：

• 移行対象：Web アプリ、API、データベースを含む 50 以上のアプリケーション
• 移行先：AWS（IaaS および PaaS サービス）
• 期間：12 か月の移行
• 重要度：さまざま（一部はビジネスクリティカルなアプリケーション）

ステップ 2 - 資産：

• 現在、管理されたオンプレミス環境にあるアプリケーションとデータ
• 懸念事項：データ主権、コンプライアンス、共有責任モデル

ステップ 3 - 攻撃対象領域の変化：

• 増加：インターネットに公開されるクラウドサービス、クラウド管理インターフェース、拡大する攻撃対象領域
• 減少：物理アクセスの脅威
• 新たな脅威：クラウドの設定ミス、IAM の脆弱性、API セキュリティ

ステップ 4 - 脅威モデリング（クラウド固有）：

クラウド固有の脅威：

• アカウントの侵害（認証情報の窃取、フィッシング）
• ストレージバケットの設定ミス（公開された S3 バケット）
• 過度に許容的な IAM ポリシー
• 不十分なネットワークセグメンテーション（VPC 設計）
• クラウド API を介したデータの持ち出し
• 内部脅威（クラウド管理者の悪用）
• サプライチェーン（侵害されたクラウドサービスまたは依存関係）

MITRE ATT&CK for Cloud：

• 初期アクセス：有効なアカウント、インターネットに公開されたアプリケーションの悪用
• 永続化：アカウントの操作、IAM ユーザーの作成
• 権限昇格：IAM ポリシーの操作
• 防御回避：クラウドログの無効化
• 認証情報アクセス：コード／設定内の保護されていない認証情報
• 検出：クラウドサービスの検出
• 横展開：代替の認証情報を使用
• データの持ち出し：データをクラウドアカウントに転送

ステップ 5 - 脆弱性（クラウドの状況）：

• クラウドセキュリティの専門知識が不足している
• オンプレミスの考え方（境界重視で、ゼロトラストではない）
• クラウド IAM 戦略が不明確である
• クラウド構成管理が行われていない（IaC が使用されていない）
• クラウドセキュリティ態勢管理（CSPM）が行われていない

ステップ 6 - 管理策の評価（共有責任モデル）：

AWS の責任（クラウドそのもののセキュリティ）：

• 物理セキュリティ
• ハイパーバイザーのセキュリティ
• ネットワークインフラストラクチャ

顧客の責任（クラウド内のセキュリティ）：

• IAM とアクセス制御
• データ暗号化
• ネットワーク構成（VPC、セキュリティグループ）
• アプリケーションセキュリティ
• コンプライアンス

提案する管理策：

ID およびアクセス管理：

• SCP（サービスコントロールポリシー）を使用して AWS Organizations を導入します
• すべてのユーザーに MFA を強制します
• 長期的な認証情報ではなく、IAM ロールを使用します
• 最小権限の原則を適用します
• 定期的にアクセスをレビューします

ネットワークセキュリティ：

• パブリック／プライベートサブネットを含む VPC を設計します
• セキュリティグループ（ステートフルファイアウォール）
• NACL（ステートレスファイアウォール）
• Web アプリケーション用の AWS WAF
• 監視用の VPC Flow Logs

データ保護：

• 保存時の暗号化（KMS を使用した S3、EBS、RDS）
• 転送中の暗号化（TLS）
• S3 バケットポリシー（パブリックアクセスをブロック）
• データの分類と取り扱い

監視と検知：

• AWS CloudTrail（API ロギング）
• AWS GuardDuty（脅威検知）
• AWS Security Hub（検出結果の集約）
• AWS Config（構成のコンプライアンス）
• SIEM との統合

インシデント対応：

• クラウド固有の IR プレイブック
• Lambda による対応の自動化
• スナップショットとフォレンジックの手順
• AWS サポートへの連絡計画

コンプライアンス：

• AWS Artifact（コンプライアンスレポート）
• AWS Config ルール（継続的なコンプライアンス）
• HIPAA／PCI-DSS 向けの暗号化
• データレジデンシー（リージョンの選択）

ステップ 7 - リスク分析：

高リスク：

• S3 バケットの設定ミス（可能性：高、影響：高 - データ侵害）
• IAM 認証情報の漏えい（可能性：中、影響：高）
• 監視の不足（可能性：高、影響：中 - 検知の遅延）

中リスク：

• ネットワークセグメンテーションの不備（可能性：中、影響：中）
• クラウドの専門知識の不足（可能性：高、影響：中 - 設定ミス）

ステップ 8 - 検知と対応：

• すべてのリージョンとアカウントに GuardDuty を導入する
• CloudTrail のログを一元化する
• Security Hub と Config を設定する
• クラウド固有のアラートを作成する（通常と異なる API 呼び出し、IAM の変更、パブリック S3 バケット）
• クラウドインシデント対応プレイブックを作成する

ステップ 9 - 推奨事項（クラウド移行セキュリティロードマップ）：

移行前（1～2 か月目）：

1. チーム向けのクラウドセキュリティ研修
2. AWS Organizations の構成とアカウント戦略を設計する
3. IAM 戦略とポリシーを定義する
4. VPC アーキテクチャとネットワークセグメンテーションを設計する
5. CSPM ツールを選定して導入する
6. クラウドセキュリティのベースラインを確立する（CIS AWS Foundations Benchmark）

移行中（3～12 か月目）：

1. すべてのリソースに Infrastructure as Code（Terraform／CloudFormation）を使用する
2. CI/CD でセキュリティチェックを自動化する（SAST、DAST、IaC スキャン）
3. 保存時および転送中の暗号化を徹底する
4. 最小権限の IAM を実装する
5. クラウドネイティブのセキュリティサービスをすべて有効にする（GuardDuty、Security Hub、Config、CloudTrail）
6. 本番環境へのデプロイ前にセキュリティテストを実施する

移行後（継続的に実施）：

1. 継続的なコンプライアンス監視
2. IAM アクセス権の定期的なレビュー
3. クラウドセキュリティ態勢の評価
4. クラウド環境でのペネトレーションテスト
5. クラウド IR シナリオの机上演習

ステップ 10 - コンプライアンス：

• AWS のコンプライアンス認証（SOC 2、ISO 27001、PCI-DSS）を活用する
• 監査証跡には AWS Artifact を使用する
• 継続的なコンプライアンスのために AWS Config ルールを実装する
• 共有責任マトリックスを文書化する

ステップ 11 - 統合：

• クラウドセキュリティには異なる考え方が必要です（ゼロトラスト、アイデンティティ中心、API 駆動）
• 共有責任モデルは重要です。AWS が保護しないものは自ら保護する必要があります
• 主なリスク：設定ミス、IAM の脆弱性、監視の不足
• 機会：クラウドネイティブのセキュリティサービス、自動化、スケーラビリティ
• 成功要因：研修、最小権限、多層防御、監視、IaC
• 推奨事項：移行を進めつつ、セキュリティロードマップを並行して実施する

---

参考資料（展開可能）

主要な組織とリソース

NIST（米国国立標準技術研究所）

• サイバーセキュリティフレームワーク：https://www.nist.gov/cyberframework
• SP 800 シリーズ：セキュリティおよびプライバシー管理策、リスク管理
• National Vulnerability Database（NVD）：https://nvd.nist.gov/

CISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）

• アラートと勧告：https://www.cisa.gov/topics/cyber-threats-and-advisories
• 既知の悪用された脆弱性カタログ：https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• リソース：無料のツール、研修、ベストプラクティス

MITRE

• ATT&CK フレームワーク：https://attack.mitre.org/
• CVE プログラム：https://www.cve.org/
• CAPEC：一般的な攻撃パターンの列挙と分類

OWASP（Open Web Application Security Project）

• トップ10: https://owasp.org/www-project-top-ten/
• テストガイド: https://owasp.org/www-project-web-security-testing-guide/
• チートシート: https://cheatsheetseries.owasp.org/

SANS Institute

• Internet Storm Center: https://isc.sans.edu/
• リーディングルーム: 数千件のセキュリティ関連論文
• 重要なセキュリティコントロール: https://www.cisecurity.org/controls

主要な標準とフレームワーク

ISO/IEC 27001: 情報セキュリティマネジメントシステム ISO/IEC 27002: 情報セキュリティ管理策 PCI-DSS: ペイメントカード業界データセキュリティ基準 HIPAA: 医療保険の携行性と責任に関する法律（セキュリティ規則） SOC 2: サービス組織管理 2（トラストサービス基準） GDPR: 一般データ保護規則 NIST SP 800-53: セキュリティおよびプライバシー管理策 CIS Controls: Center for Internet Security 重要なセキュリティコントロール FedRAMP: 連邦リスクおよび認可管理プログラム

脆弱性データベース

• National Vulnerability Database（NVD）: https://nvd.nist.gov/
• CVE: https://www.cve.org/
• Exploit-DB: https://www.exploit-db.com/
• VulnDB: https://vulndb.cyberriskanalytics.com/

脅威インテリジェンスの情報源

• CISA アラート: https://www.cisa.gov/news-events/cybersecurity-advisories
• US-CERT: https://www.cisa.gov/uscert
• 脅威インテリジェンスプラットフォーム: Recorded Future、Mandiant、CrowdStrike
• オープンソース: AlienVault OTX、MISP、脅威フィード

セキュリティツールとプラットフォーム

脆弱性スキャン: Nessus、Qualys、Rapid7 InsightVM SAST: SonarQube、Checkmarx、Veracode DAST: Burp Suite、OWASP ZAP、Acunetix SIEM: Splunk、Elastic、Sentinel、Chronicle EDR: CrowdStrike、SentinelOne、Microsoft Defender for Endpoint CSPM: Prisma Cloud、Wiz、Orca Security

認定資格

• CISSP: 認定情報システムセキュリティプロフェッショナル
• CISM: 認定情報セキュリティマネージャー
• CEH: 認定倫理的ハッカー
• OSCP: Offensive Security 認定プロフェッショナル
• GCIH: GIAC 認定インシデントハンドラー
• Security+: CompTIA Security+

コミュニティとリソース

• r/netsec: https://www.reddit.com/r/netsec/
• Krebs on Security: https://krebsonsecurity.com/
• Schneier on Security: https://www.schneier.com/
• Dark Reading: https://www.darkreading.com/
• The Hacker News: https://thehackernews.com/

---

検証チェックリスト

サイバーセキュリティ分析の完了後：

• すべての重要な資産とデータを特定した
• 攻撃対象領域と侵入ポイントを分析した
• 対象範囲に適した脅威モデリングを実施した
• 脆弱性を特定し、深刻度を評価した
• 既存のセキュリティ管理策の有効性を評価した
• 定量的または定性的な手法でリスクを分析した
• 検知および対応能力を評価した
• 優先順位を付けた修復の推奨事項を作成した
• コンプライアンス要件を考慮した
• 脅威を MITRE ATT&CK フレームワークに対応付けた（該当する場合）
• 多層防御とゼロトラストの原則を適用した
• 明確で実行可能なセキュリティガイダンスを提供した
• セキュリティ用語とフレームワークを正確に使用した

---

避けるべきよくある落とし穴

落とし穴 1：リスクの文脈を踏まえないチェックリストへの準拠

• 問題：実際のリスクを理解せずに、コンプライアンス要件に従う
• 解決策：リスクベースのアプローチを取り、チェック項目を確認するだけでなく、脅威とビジネスの背景を理解する

落とし穴 2：境界だけに依存するセキュリティ

• 問題：ネットワーク境界が内部のすべてを保護すると考える
• 解決策：多層防御とゼロトラストを採用し、侵害を前提として、資産そのものを保護する

落とし穴 3：アラート疲れと誤検知

• 問題：品質の低いアラートが多すぎて、対応担当者が圧倒される
• 解決策：検知ルールを調整し、精度の高いアラートを優先して、可能な場合は対応を自動化する

落とし穴 4：人的要素の軽視

• 問題：技術的な対策だけに注目し、ソーシャルエンジニアリングや内部脅威を無視する
• 解決策：セキュリティ意識向上、特権ユーザーの監視、内部脅威対策プログラムを含める

落とし穴 5：ある時点だけの評価

• 問題：継続的な監視を行わず、一度限りのセキュリティレビューで済ませる
• 解決策：継続的なセキュリティ対策として、常時監視、脆弱性管理、脅威インテリジェンスを実施する

落とし穴 6：文脈を考慮しない脆弱性スコアリング

• 問題：悪用可能性やビジネスの背景を考慮せず、CVSS だけで優先順位を決める
• 解決策：リスクベースで優先順位を付け、脅威インテリジェンス、悪用可能性、資産の重要度を考慮する

落とし穴 7：セキュリティを妨げとみなす

• 問題：セキュリティがビジネス目標の障害とみなされる
• 解決策：ビジネスを安全に実現できるようにし、リスクとビジネス価値のバランスを取り、安全な代替策を提示する

落とし穴 8：サプライチェーンとサードパーティの軽視

• 問題：自社システムだけに注目し、依存関係を無視する
• 解決策：サプライチェーンのリスク管理として、サードパーティのセキュリティと依存関係の脆弱性を評価する

---

成功基準

質の高いサイバーセキュリティ分析では、次のことを行います。

• 適切なセキュリティフレームワークと手法を適用する
• 脅威モデリングを使用してリスクを特定し、優先順位を付ける
• 複数の層にわたってセキュリティ対策を評価する（多層防御）
• 実行可能で、優先順位が明確な修復の推奨事項を提示する
• 脅威インテリジェンスと業界のベストプラクティスに基づいて分析する
• 技術的要因と人的要因の両方を考慮する
• 防御だけでなく、検知と対応にも取り組む
• 認知された標準（MITRE ATT&CK、NIST CSF など）に対応付ける
• セキュリティとビジネス目標のバランスを取る
• 深いセキュリティの専門知識と批判的思考を示す
• 技術者と非技術者の双方に明確に伝える
• セキュリティの概念と用語を正確に使用する

---

他の分析者との連携

サイバーセキュリティ分析は、他の視点を補完します。

• コンピューターサイエンティスト：システムとコードに関する深い技術的理解
• 弁護士：侵害の法的影響、規制遵守の要件
• 経済学者：セキュリティ投資の費用対効果分析、サイバー保険
• 心理学者：人間の行動、ソーシャルエンジニアリング、セキュリティ文化
• 政治学者：国家による脅威、地政学的なサイバー紛争、政策

サイバーセキュリティが特に力を発揮する分野：

• 脅威モデリングとリスク評価
• 脆弱性分析
• 多層防御の設計
• インシデントの検知と対応
• コンプライアンスと標準

---

継続的な改善

このスキルは、次の要素を通じて進化します。

• 新たな脅威アクターの TTP と攻撃手法
• 新たに発見される脆弱性とエクスプロイト
• セキュリティ技術と実践の進化
• セキュリティインシデントから得られる教訓
• フレームワークと標準の更新
• 学際的なセキュリティ研究

---

スキルの状態：完了 — 包括的なサイバーセキュリティ分析能力
品質レベル：高 — 最新のフレームワークを使用したエンタープライズグレードのセキュリティ分析
トークン数：約 8,500 語（目標：6,000～10,000 トークン）