Microsoft SentinelのMITRE coverageは、MITRE ATT&CKの戦術・手法ごとに「自社で有効化済みの検出」と「構成すれば使える検出候補」を可視化する機能です。2026年4月22日に更新されたMicrosoft公式ドキュメントでは、カバレッジマトリックスの見方に加え、Defenderポータルでの推奨カバレッジ確認、シミュレーション、分析ルール・インシデント・ハンティングとの連携が重要な確認ポイントになっています。(Microsoft Learn)
セキュリティ管理者、ID管理チーム、コンプライアンス担当者がまず行うべきことは、単に「MITREのマスが埋まっているか」を見ることではありません。重要な攻撃手法に対して、必要なデータが取り込まれ、検出ルールが有効で、運用チームが対応できる状態かを確認することです。
Microsoft SentinelのMITRE coverageとは
Microsoft SentinelのMITRE coverageは、MITRE ATT&CKフレームワークを基準に、自社の検出態勢を確認するためのビューです。
Microsoft Sentinelは、取り込まれたセキュリティデータを使って脅威検出や調査を支援するだけでなく、組織のセキュリティ状態とカバレッジを可視化します。公式ドキュメントでは、Microsoft SentinelのMITREページを使って、ワークスペースで有効な分析ルールと、構成可能な検出を確認できると説明されています。(Microsoft Learn)
この機能で確認できる主な内容は次のとおりです。
| 確認できる内容 | 実務での意味 |
|---|---|
| 有効化済みの検出 | 現在のワークスペースで稼働している検出ルールが、どのMITRE手法をカバーしているか分かる |
| 構成可能な検出 | まだ有効化していないが、追加すればカバレッジを広げられる検出候補を把握できる |
| 手法単位の詳細 | 特定の攻撃手法に関連する分析ルール、ハンティングクエリ、説明へ移動できる |
| 推奨カバレッジ | Defenderポータルでは、選択した手法について推奨される検出やセキュリティサービスに対する有効化状況を確認できる |
つまり、MITRE coverageは「ダッシュボードを見る機能」ではなく、検出ギャップを見つけ、ルール・データコネクタ・ハンティング運用を改善するための起点です。
2026年4月更新で押さえるべきポイント
2026年4月22日更新の公式ページで、実務上特に押さえたいポイントは次の5つです。
| 更新ポイント | 何を確認すべきか | 主な担当 |
|---|---|---|
| MITREページはプレビュー扱い | 社内レポートや監査資料では、補助的な可視化機能として扱う | セキュリティ管理者、コンプライアンス担当 |
| 現在のカバレッジとシミュレーションを分けて確認 | 有効な検出と、構成すれば使える検出候補を混同しない | SOC、セキュリティ管理者 |
| Defenderポータルで推奨カバレッジを確認 | Active detectionsとMicrosoftセキュリティサービスの有効化状況を合わせて見る | セキュリティ管理者 |
| MITRE ATT&CK version 18に整合 | Sentinel上の表示がどのATT&CKバージョンに基づくか確認する | SOC、検出エンジニア |
| 分析ルール・インシデント・ハンティングとの連携を重視 | ルールにMITRE手法が正しく紐づいているか確認する | SOC、脅威ハンティング担当 |
公式ドキュメントでは、Microsoft SentinelのMITREページは現在プレビュー段階と明記されています。プレビュー機能は便利ですが、本番運用では「最終的な統制証跡」ではなく、検出改善のための運用ビューとして使うのが現実的です。(Microsoft Learn)
Microsoft SentinelでMITRE coverageを確認する前提条件
MITRE coverageを見る前に、次の条件が満たされているか確認します。
| 前提条件 | 確認ポイント |
|---|---|
| Microsoft Sentinelインスタンスが有効 | 対象ワークスペースでSentinelが利用可能か |
| 必要な権限がある | Sentinelのコンテンツや脅威管理画面を表示できるロールがあるか |
| データコネクタが構成済み | Entra ID、エンドポイント、クラウド、ネットワークなど必要なログが取り込まれているか |
| スケジュール済みクエリルールとNRTルールが有効 | 検出ルールが実際に稼働しているか |
| MITRE ATT&CKの基礎理解がある | 戦術、手法、サブ手法の意味をチームで共有しているか |
公式ページでも、MITRE coverageを表示する前提として、アクティブなSentinelインスタンス、必要な権限、関連するデータコネクタ、スケジュール済みクエリルールとNRTルール、MITRE ATT&CKへの理解が挙げられています。(Microsoft Learn)
ここで重要なのは、カバレッジはデータ取り込みと検出ルールに依存するという点です。ルールを有効化していても、必要なログが入っていなければ検出は機能しません。逆にログが豊富でも、MITRE手法に紐づくルールが無効なら、マトリックス上ではカバレッジが低く見えます。
DefenderポータルとAzure portalでの見方
Microsoft SentinelのMITRE coverageは、Microsoft DefenderポータルとAzure portalの両方で確認できます。
Defenderポータルでは、Microsoft Sentinel > Threat management > MITRE ATT&CK からアクセスします。Azure portalでは、Threat management > MITRE ATT&CK (Preview) から確認できます。公式ドキュメントでは、現在アクティブなスケジュール済みクエリルールとNRTルールが、既定でカバレッジマトリックスに表示されると説明されています。(Microsoft Learn)
ただし、これから運用設計を見直すなら、Defenderポータルを前提に考えるべきです。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzure portalではサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内しています。(Microsoft Learn)
| 利用ポータル | 向いている場面 | 注意点 |
|---|---|---|
| Microsoft Defenderポータル | 今後の統合セキュリティ運用、推奨カバレッジ確認、XDR連携 | 移行済みワークスペースを前提に運用設計する |
| Azure portal | 既存環境での確認、移行前の暫定運用 | 将来的にはDefenderポータル前提の運用へ移行が必要 |
グローバル組織では、地域ごとにAzure portalとDefenderポータルの利用状況が混在しがちです。日本、米国、欧州などでSOC運用を分けている場合は、「どちらのポータルでMITRE coverageを正式確認するか」を運用手順書に明記しておくと混乱を防げます。
現在のMITRE coverageで見るべき項目
MITRE coverageを開いたら、まず全体の色や数だけを眺めるのではなく、次の順序で確認します。
| 確認順 | 見る項目 | 判断のポイント |
|---|---|---|
| 1 | 重要な戦術の空白 | Initial Access、Credential Access、Lateral Movementなど、自社リスクが高い領域に空白がないか |
| 2 | 手法単位の検出数 | 重要手法に対して有効な検出が1つだけに偏っていないか |
| 3 | 詳細ウィンドウ | 関連する分析ルールやハンティングクエリへ移動できるか |
| 4 | 推奨カバレッジ | 推奨される検出やMicrosoftセキュリティサービスに対して、何が有効化済みか |
| 5 | 未構成の検出候補 | すぐ有効化できる候補と、ログ不足で有効化しても効果が薄い候補を分ける |
公式ドキュメントでは、凡例で特定手法に対する有効な検出数を把握でき、検索バーで手法名またはIDを検索でき、マトリックス上の手法を選択すると詳細ウィンドウから関連項目へ移動できると説明されています。Defenderポータルでは、推奨される検出やセキュリティサービスに対するアクティブな検出・製品の比率も表示されます。(Microsoft Learn)
ここでの実務的な見方は、検出数の多さより、リスクに対する妥当性です。たとえば、ID侵害が主要リスクである組織では、Credential AccessやValid Accountsに関連する検出が薄い状態は優先的に改善すべきです。一方、業務環境に存在しない技術領域のカバレッジを無理に埋めても、ノイズが増えるだけの可能性があります。
Simulated coverageは「伸びしろ」を見る機能
Microsoft SentinelのMITRE coverageでは、現在のカバレッジだけでなく、利用可能だが未構成の検出を使った場合のカバレッジも確認できます。
公式ドキュメントでは、シミュレートされたカバレッジは「ワークスペースで利用可能だが、現在は構成されていない検出」を指すと説明されています。Simulated rulesメニューを使うことで、すべての利用可能な検出を構成した場合のセキュリティ状態を把握できます。(Microsoft Learn)
ただし、Simulated coverageをそのまま「導入すべきルール一覧」と考えるのは危険です。実際には、次の観点で優先順位を付けます。
| 判断基準 | 確認する内容 | 例 |
|---|---|---|
| ログの有無 | ルールが参照するデータが取り込まれているか | Entra IDサインインログ、エンドポイントログ、クラウド監査ログ |
| 誤検知の許容度 | 有効化後にアラート過多にならないか | 管理者操作が多い環境で権限昇格系ルールを有効化する場合 |
| 対応手順 | アラート発生時に誰が何をするか決まっているか | IDチームへのエスカレーション、端末隔離、パスワードリセット |
| 業務影響 | 検出後の封じ込めが業務停止につながらないか | 共有アカウント、レガシーアプリ、海外拠点アクセス |
| 監査価値 | 統制やリスク説明に使えるか | 検出ギャップ、改善計画、残存リスクの説明 |
おすすめは、Simulated coverageで候補を洗い出した後、すぐ有効化するルール、検証環境で試すルール、ログ整備後に検討するルールの3つに分類することです。
MITRE ATT&CK version 18対応で注意すべきこと
2026年4月22日更新の公式ページでは、Microsoft SentinelはMITRE ATT&CK framework version 18に合わせて調整されていると記載されています。(Microsoft Learn)
一方で、MITRE公式のバージョン履歴では、ATT&CK v19.0が2026年4月28日からCurrent Versionになっています。(MITRE ATT&CK)
この点は、運用上かなり重要です。Microsoft SentinelのMITRE coverage画面がversion 18ベースで表示されている場合、MITRE公式サイトの最新バージョンに追加・変更された内容が、すぐにSentinel上のマトリックスへ反映されるとは限りません。
そのため、次のように整理しておくと安全です。
| 観点 | 実務での扱い |
|---|---|
| Sentinel上のカバレッジ | Microsoft Sentinelが表示しているATT&CKバージョンを基準に評価する |
| 脅威インテリジェンス | MITRE公式の最新バージョンや脅威レポートも併せて確認する |
| 監査・報告 | 「Microsoft Sentinel上ではversion 18基準」と明記する |
| 検出エンジニアリング | v19で追加・変更された手法が自社リスクに関係する場合、Sentinel外でも暫定的に確認する |
カバレッジ評価では、「最新のMITREに完全追従しているか」よりも、自社が評価に使っている基準バージョンを明確にすることが大切です。特にグローバル企業では、リージョンやSOCごとに資料作成時点が異なるため、レポートには確認日とATT&CKバージョンを残しておくべきです。
分析ルール・インシデント・ハンティングとの連携が重要
MITRE coverageは、分析ルールだけを眺める機能ではありません。Microsoft Sentinelでは、分析ルール、インシデント、脅威ハンティングの各運用にMITRE ATT&CKの戦術・手法を活用できます。
公式ドキュメントでは、MITRE手法が適用されたスケジュール済みルールが定期的に実行されることで、MITREカバレッジマトリックス上のセキュリティ状態が強化されると説明されています。また、MITRE手法が設定されたルールからアラートが生成されると、その手法はインシデントにも追加されます。脅威ハンティングでは、クエリ作成時やブックマーク作成時に戦術・手法をマッピングできます。(Microsoft Learn)
実務では、次の3点を確認してください。
分析ルールにMITRE手法が設定されているか
カスタム分析ルールを作成している場合、検出ロジックだけで満足してはいけません。該当するMITRE戦術・手法を設定していないと、カバレッジの可視化やルール検索で不利になります。
たとえば、疑わしいサインインや異常な管理者操作を検出するルールを作っているのに、Credential AccessやPrivilege Escalationに相当するマッピングを付けていなければ、レポート上は検出態勢が弱く見える可能性があります。
インシデントに手法情報が残るか
インシデント対応では、「どのアラートが出たか」だけでなく、「攻撃ライフサイクルのどの段階に相当するか」を説明できることが重要です。
MITRE手法がインシデントに付与されていれば、対応後の振り返りで次のような分析がしやすくなります。
- 初期侵入の検出が遅れていないか
- ID侵害の兆候が複数のインシデントで繰り返されていないか
- 横展開の検出がエンドポイント側に偏っていないか
- 特定のクラウド操作に対する検出が不足していないか
ハンティングクエリにもMITREを紐づける
定期的な脅威ハンティングを行っている組織では、ハンティングクエリにもMITRE戦術・手法を設定しておくと、検出ギャップの説明がしやすくなります。
特に有効なのは、アラート化する前の仮説検証です。たとえば、まだ誤検知が多くて分析ルール化できないクエリでも、MITRE手法を紐づけておけば、将来的な検出改善候補として管理できます。
チーム別に見るべきポイント
Microsoft SentinelのMITRE coverageは、SOCだけの機能ではありません。security admins、identity teams、compliance teamsがそれぞれ別の観点で使うと、実用性が高まります。
| チーム | 見るべきポイント | 具体的な行動 |
|---|---|---|
| Security admins | ルールの有効化状況、NRTルール、データコネクタ、ポータル移行 | 空白の多い戦術を洗い出し、必要なデータとルールを整備する |
| Identity teams | 認証、権限、アカウント悪用に関する検出 | Entra IDやID関連ログが必要な検出に反映されているか確認する |
| Compliance teams | カバレッジの根拠、確認日、MITREバージョン、改善計画 | 監査資料に「対象範囲」「未対応リスク」「次回見直し」を記載する |
| SOC analysts | アラート、インシデント、ハンティングのつながり | よく発生するインシデントをMITRE戦術別に分類し、対応手順を整える |
| Detection engineers | カスタムルールのMITREマッピング | 新規ルール作成時に戦術・手法の設定を標準手順に入れる |
特にID管理チームは、MITRE coverageを「セキュリティ部門の可視化画面」としてではなく、認証ログや特権操作ログの重要性を説明する材料として使えます。検出ギャップの多くは、ルール不足ではなく、必要なデータが入っていないことから発生します。
すぐに実施できる確認手順
Microsoft Sentinel環境がある場合は、次の手順で棚卸しを始めると効果的です。
| 手順 | 作業内容 | 完了の目安 |
|---|---|---|
| 1 | DefenderポータルでMITRE ATT&CKページを開く | 対象ワークスペースのマトリックスが表示される |
| 2 | 重要な戦術を3〜5個選ぶ | 自社の脅威モデルや過去インシデントに基づいて選定する |
| 3 | 空白または検出数が少ない手法を確認する | 重要資産やIDリスクに関係する手法を優先する |
| 4 | 詳細ウィンドウから関連ルール・ハンティングクエリを確認する | 有効な項目と未構成の項目を分ける |
| 5 | Simulated rulesで追加候補を確認する | 有効化候補を「即時」「検証後」「保留」に分類する |
| 6 | データコネクタとログ量を確認する | ルールが参照するテーブルに必要なデータがある |
| 7 | 改善計画を記録する | 担当者、期限、期待効果、残存リスクを残す |
この手順で重要なのは、最初から全マトリックスを完璧に埋めようとしないことです。MITRE ATT&CKは非常に広いフレームワークです。自社にとって重要な脅威シナリオから始め、月次または四半期で見直す運用にしたほうが継続しやすくなります。
よくある失敗と対策
カバレッジの数だけをKPIにする
「MITREの検出数を増やす」だけを目標にすると、ノイズの多いルールを有効化してSOCの負荷を増やすことがあります。
対策は、検出数ではなく、次のような実効性のある指標を併用することです。
| 指標 | 見る理由 |
|---|---|
| 重要手法の検出有無 | リスクの高い攻撃に備えられているか確認する |
| 誤検知率 | SOCが処理できる品質か確認する |
| 対応時間 | 検出後に実際に封じ込められるか確認する |
| ログ欠損 | ルール以前にデータが足りているか確認する |
| 改善完了率 | 検出ギャップが放置されていないか確認する |
Simulated coverageを実カバレッジと誤解する
Simulated coverageは、あくまで「構成すれば使える可能性がある検出」です。現在稼働している検出ではありません。
レポートでは、次のように分けて記載すると誤解を防げます。
| 区分 | 表現例 |
|---|---|
| Current coverage | 現在有効化済みの検出 |
| Simulated coverage | 追加構成により拡張可能な検出候補 |
| Gap | ログ不足、ルール未構成、製品未導入などにより未対応の領域 |
データコネクタの状態を見ない
MITRE coverage上で候補ルールが見えても、必要なログが取り込まれていなければ意味がありません。
たとえば、ID関連の検出を強化したい場合は、認証ログ、監査ログ、条件付きアクセス関連の情報、ID保護関連のシグナルなど、自社で必要なデータがSentinelに入っているかを確認する必要があります。
カスタムルールにMITREマッピングを付け忘れる
検出エンジニアがKQLで優れたカスタムルールを作っても、MITRE戦術・手法を設定していなければ、カバレッジ管理では活用しづらくなります。
ルール作成の標準手順に、次の項目を入れておくとよいでしょう。
| ルール作成時の確認項目 | 理由 |
|---|---|
| 対応するMITRE戦術 | 攻撃フェーズを説明しやすくする |
| 対応するMITRE手法 | カバレッジマトリックスに反映しやすくする |
| 必要なデータソース | ログ欠損による検出漏れを防ぐ |
| 想定される誤検知 | チューニング計画を立てる |
| 対応手順 | アラート発生後の運用品質を高める |
コンプライアンス対応での使い方
コンプライアンス担当者にとって、Microsoft SentinelのMITRE coverageは「統制がある」と言い切るための証拠ではなく、リスクベースで検出態勢を説明するための補助資料として有効です。
監査資料や内部統制レポートに使う場合は、次の項目をセットで記録します。
| 記録項目 | 記載例 |
|---|---|
| 確認日 | 2026年4月30日 |
| 対象環境 | Production Sentinel workspace |
| 参照ポータル | Microsoft Defenderポータル |
| ATT&CKバージョン | Sentinel表示上はversion 18 |
| 対象範囲 | ID、エンドポイント、クラウド操作ログ |
| 未対応領域 | 一部の横展開手法で検出候補はあるが未構成 |
| 改善計画 | ルール検証、ログ追加、対応手順整備 |
| 残存リスク | 誤検知調整中のため一部アラート化は保留 |
このように記録しておくと、「マトリックスがどれだけ埋まっているか」ではなく、「どのリスクを把握し、どのように改善しているか」を説明できます。
Microsoft SentinelのMITRE coverageで次に取るべき行動
2026年4月更新のポイントを踏まえると、Microsoft SentinelのMITRE coverageは、単なる可視化機能ではなく、検出エンジニアリング、SOC運用、ID管理、コンプライアンスをつなぐ共通言語として使うべきです。
まずは次の3つを実施してください。
1つ目は、DefenderポータルでMITRE coverageを開き、重要な戦術・手法の空白を確認することです。2つ目は、Simulated coverageを使って追加候補を洗い出し、すぐ有効化できるものと検証が必要なものを分けることです。3つ目は、カスタム分析ルール、インシデント、ハンティングクエリにMITREマッピングを付ける運用を標準化することです。
特に、Azure portal中心でSentinelを運用している組織は、2027年3月31日以降のDefenderポータル移行も見据えて、MITRE coverageの確認手順をDefenderポータル前提で整備しておくとよいでしょう。(Microsoft Learn)
Microsoft SentinelのMITRE coverageは、すべての攻撃を防ぐ魔法のスコアではありません。しかし、検出の抜け、データ不足、ルール未構成、対応手順の弱さを見つけるには非常に有効です。まずは重要な脅威シナリオを3つ選び、現在のカバレッジと改善候補を棚卸しするところから始めましょう。
コメント