変更要約: SC-100 第2章を新規作成（ドメイン2 前半「セキュリティ運用」: Defender XDR/Sentinel(SIEM)/XDR＋SIEM 統合/Defender for Endpoint・Identity・Office 365・Cloud Apps、SOAR/オートメーションルール/プレイブック(Logic Apps)/脅威ハンティング(KQL)/UEBA、集中ログ/Microsoft Purview Audit(Standard・Premium)/マルチクラウド監視/保持と分離、MITRE ATT&CK(Enterprise/Mobile/ICS)/検知カバレッジ/インシデント対応ワークフロー）。
2.4MITRE ATT&CK と検知カバレッジ
MITRE ATT&CK マトリクス（Enterprise・Mobile・ICS）を用いた脅威検知カバレッジの評価、インシデント対応・脅威ハンティング・インシデント管理のワークフローの設計と評価を理解します。
「うちの検知は十分か」を主観でなく共通言語で示すために、業界標準の MITRE ATT&CK を使います。アーキテクトは検知カバレッジを ATT&CK の戦術/技術にマッピングし、穴を可視化して優先的に塞ぎます。
2.4.1ATT&CK でカバレッジを評価
MITRE ATT&CK は、攻撃者の戦術（目的：初期アクセス・永続化・横移動・持ち出し等）と技術（手口）を体系化した知識ベースです。対象環境に応じて Enterprise（IT）・Mobile（モバイル）・ICS（産業制御システム）のマトリクスを使い分けます。Microsoft Sentinel は分析ルールを ATT&CK の技術にマッピングし、検知カバレッジ をマトリクス上で可視化できます。アーキテクトは「どの戦術段階の検知が薄いか」を評価し、ルールやデータソースを補強します。
2.4.2インシデント対応ワークフローの設計
検知の先に、インシデント対応（検知→トリアージ→封じ込め→根絶→復旧→教訓）、脅威ハンティング、インシデント管理 の一連のワークフローを設計します。アーキテクトは役割と手順（誰が・いつ・何を）、自動化（SOAR）と人の判断の境界、ATT&CK に基づく検知の継続改善を定義します。これにより SOC は属人化を避け、再現性のある運用になります。
決め手：「検知の網羅性を共通言語で評価し穴を可視化」＝MITRE ATT&CK（Sentinel のマッピング）。環境で使い分け＝IT は Enterprise、産業制御は ICS、モバイルは Mobile。「対応の手順・役割・自動化境界を定義」＝インシデント対応ワークフローの設計。
混同に注意：
①ATT&CK は「検知の評価フレームワーク」＝検知製品そのものではない。
②ICS/OT 環境に Enterprise マトリクスだけを当てない（ICS マトリクス＋Defender for IoT）。
③ワークフロー設計は自動化（SOAR）と人の判断を切り分ける＝全自動でも全手動でもない。
2.4.3この節のまとめ
- MITRE ATT&CK＝戦術/技術の共通言語で検知カバレッジを評価。Enterprise/Mobile/ICS を環境で使い分け
- Sentinel は分析ルールを ATT&CK にマッピングし、薄い段階を可視化して補強
- インシデント対応/ハンティング/管理のワークフローを役割・手順・自動化境界とともに設計
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 検知ルールの網羅性を業界共通の戦術/技術に対して評価し、カバレッジの穴を可視化したい。最適なのはどれですか？
Q2. 産業制御システム（OT/ICS）環境の脅威検知カバレッジを評価する際に最も適切なのはどれですか？
Q3. SOC の属人化を避け、再現性のある運用にするために設計すべきものはどれですか？
Q4. MITRE ATT&CK の位置づけとして正しいのはどれですか？
Q5. ATT&CK マトリクス上で「横移動」の段階の検知が薄いと判明した。アーキテクトの最適な次の一手はどれですか？