Azure の「View MITRE ATT&CK coverage in Microsoft Sentinel」は、Microsoft Sentinel 上で自組織の検知ルールが MITRE ATT&CK のどの戦術・技術をカバーしているかを確認するための機能です。結論から言うと、これは新しい防御製品を追加する機能ではなく、既存の分析ルール、NRT ルール、利用可能な検知テンプレートを MITRE ATT&CK の観点で棚卸しし、検知の穴を見つけるための確認画面です。
2026年6月30日に更新された Microsoft Learn の公式情報では、この MITRE ATT&CK 画面は Microsoft Defender ポータルと Azure ポータルの Microsoft Sentinel の両方に適用される一方、機能自体は Preview とされています。Microsoft Sentinel は現在 MITRE ATT&CK framework version 18 に対応しており、管理者はアクティブな検知だけでなく、未構成だが利用可能な検知ルールも見ながら、セキュリティカバレッジを強化できます。(Microsoft Learn)
Azure の「View MITRE ATT&CK coverage in Microsoft Sentinel」とは
「View MITRE ATT&CK coverage in Microsoft Sentinel」は、Microsoft Sentinel の MITRE ATT&CK 画面で、自社環境における検知カバレッジを ATT&CK の戦術・技術単位で可視化する機能です。
Microsoft Sentinel は、取り込んだログやセキュリティデータをもとに脅威検知や調査を支援します。この画面では、単に「ルールが何件あるか」ではなく、攻撃者の行動モデルである MITRE ATT&CK に照らして、どの攻撃技術に対する検知が有効になっているかを確認できます。(Microsoft Learn)
たとえば、以下のような確認に使えます。
- 認証情報窃取に関する検知ルールが有効か
- 永続化や権限昇格に関する検知が不足していないか
- 既存の分析ルールが MITRE ATT&CK の技術に正しく紐づいているか
- 有効化できるルールテンプレートが残っていないか
- SOC やセキュリティ運用チームが優先して強化すべき領域はどこか
重要なのは、この画面が「完全に守れているか」を保証するものではない点です。MITRE ATT&CK カバレッジは、あくまで Microsoft Sentinel 上で構成済みの検知ルールや利用可能な検知候補を、攻撃手法の観点で見える化するものです。データコネクタが未設定だったり、ルールが無効だったり、環境に合わないクエリのままだったりすると、カバレッジが表示されていても実効性は限定的になります。
2026年6月30日更新情報で確認すべきポイント
今回の公式情報で管理者が押さえるべきポイントは、画面の場所、対象ルール、シミュレーション機能、Preview 扱い、MITRE ATT&CK バージョンの5つです。
| 確認項目 | 内容 | 管理者が取るべき行動 |
|---|---|---|
| 対象ポータル | Microsoft Defender ポータルと Azure ポータルの Microsoft Sentinel に適用 | 自社がどちらのポータルで運用しているか確認する |
| 機能状態 | MITRE 画面は Preview | 本番運用の判断資料に使う場合は Preview 機能であることを明記する |
| ATT&CK バージョン | Microsoft Sentinel は MITRE ATT&CK framework version 18 に対応 | 自社のリスク評価や監査資料とバージョン差がないか確認する |
| 現在のカバレッジ | アクティブな Scheduled query rules と Near-real-time rules が既定で表示される | 有効なルールだけでなく、無効化されたルールや未設定領域も確認する |
| シミュレーション | 利用可能だが未構成の検知を含めた想定カバレッジを確認可能 | 追加すべきルール候補を洗い出し、優先順位を付ける |
Microsoft Defender ポータルでは、Microsoft Sentinel > Threat management > MITRE ATT&CK から確認します。Azure ポータルでは、Microsoft Sentinel の Threat management > MITRE ATT&CK (Preview) から確認できます。公式情報では、技術名や技術 ID で検索したり、特定の技術を選択して詳細ペインから関連するアクティブ項目やハンティングクエリへ移動したりできると説明されています。(Microsoft Learn)
影響範囲：誰に関係する変更か
この更新は、Microsoft Sentinel を使っているすべての組織に関係しますが、特に影響が大きいのは次の担当者です。
| 担当者 | 影響 | 確認すべきこと |
|---|---|---|
| SOC アナリスト | 攻撃手法ごとの検知状況を把握しやすくなる | 調査頻度の高い攻撃シナリオに対する検知の有無 |
| Sentinel 管理者 | ルール、データコネクタ、テンプレートの不足を見つけやすくなる | データソース、分析ルール、NRT ルールの有効化状況 |
| セキュリティアーキテクト | ATT&CK ベースでセキュリティ投資の優先順位を整理できる | 事業リスクと検知カバレッジの対応関係 |
| MSSP・グローバル運用担当 | 複数ワークスペースや複数地域の検知水準を比較しやすくなる | ワークスペース間でルール設計や命名規則が揃っているか |
| 監査・リスク管理担当 | セキュリティ対策の説明材料として使える | 「表示されているカバレッジ」と「実効的な検知能力」を区別して説明できるか |
特にグローバル企業では、地域ごとにログ収集範囲、ライセンス、データ保持ポリシー、運用チームの成熟度が異なります。そのため、MITRE ATT&CK カバレッジを見るときは、単純に「カバー率が高い国・低い国」を比較するだけでは不十分です。
たとえば、あるリージョンでは Microsoft Defender for Endpoint のデータが十分に取り込まれている一方、別リージョンでは ID 系ログやクラウド監査ログが不足している場合があります。この状態で同じ分析ルールを有効化しても、検知結果の品質は揃いません。カバレッジ画面は、ルール数の比較ではなく、データ収集、ルール有効化、インシデント運用までを含めた検知体制の点検表として使うのが実務的です。
前提条件：表示されない場合に確認すること
MITRE ATT&CK カバレッジを確認するには、Microsoft Sentinel インスタンス、必要な閲覧権限、関連データを取り込むデータコネクタ、アクティブな Scheduled query rules や NRT rules が必要です。公式情報でも、これらが前提条件として示されています。(Microsoft Learn)
表示が期待どおりにならない場合は、次の順で確認すると原因を切り分けやすくなります。
| 症状 | 主な原因 | 確認ポイント |
|---|---|---|
| MITRE ATT&CK 画面が見つからない | ポータルの違い、権限不足、ワークスペース未選択 | Defender ポータルと Azure ポータルのどちらで操作しているか確認する |
| カバレッジが少ない | 分析ルールが無効、NRT ルール未設定 | Analytics の Active rules を確認する |
| 特定の技術が空白 | 対応するルールがない、または MITRE マッピングが未設定 | ルール作成画面で MITRE tactics / techniques が設定されているか確認する |
| ルールを有効化しても検知されない | データコネクタ未設定、ログ不足、KQL 条件が環境に合っていない | コネクタ、Log Analytics テーブル、クエリ結果を確認する |
| シミュレーションで候補が出るが本番化できない | ソリューション未導入、権限不足、運用負荷の未評価 | Content hub、必要ロール、インシデント増加の影響を確認する |
Microsoft Sentinel の分析ルールは、Configuration メニューの Analytics ページで確認できます。アクティブなルール、テンプレート、Anomalies などのタブが用意されており、追加のルールテンプレートは Content hub から関連ソリューションを導入することで利用できる場合があります。(Microsoft Learn)
設定変更：カバレッジを高めるための実務手順
MITRE ATT&CK カバレッジを高める作業は、単にルールを大量に有効化することではありません。誤検知が増えれば SOC の負荷が上がり、重要なアラートを見落とす原因になります。以下の流れで、実効性のある検知強化を進めるのが安全です。
現在のカバレッジを確認する
まず、Microsoft Sentinel の MITRE ATT&CK 画面を開き、現在アクティブな Scheduled query rules と NRT rules がどの技術に対応しているか確認します。画面の凡例を使うと、特定の技術に対して有効な検知がいくつあるかを把握できます。(Microsoft Learn)
ここで見るべきなのは、単なる数ではありません。次のように、攻撃シナリオと業務リスクを結び付けて確認します。
- 管理者権限を持つアカウントへの攻撃を検知できるか
- VPN、ID、エンドポイント、クラウド管理操作のログがつながっているか
- ランサムウェア初期侵入、横展開、データ持ち出しに関係する技術が空白になっていないか
- 自社で過去に発生したインシデントやヒヤリハットに近い技術がカバーされているか
- 重要システムに関係するログソースが Sentinel に取り込まれているか
Simulated coverage で追加候補を洗い出す
次に、Simulated rules を使って、利用可能だが未構成の検知を含めた場合の想定カバレッジを確認します。公式情報では、シミュレーションカバレッジは「利用可能だが、現在の Microsoft Sentinel ワークスペースでは構成されていない検知」を示すものと説明されています。(Microsoft Learn)
この機能は、次のような判断に役立ちます。
| 判断したいこと | 見るべきポイント |
|---|---|
| どのルールを追加すべきか | 空白または薄い技術に対応する利用可能ルール |
| 優先度をどう決めるか | 自社の重要資産、攻撃リスク、過去インシデントとの関係 |
| すぐ有効化してよいか | 必要ログ、誤検知リスク、運用担当者の対応余力 |
| 追加効果をどう説明するか | 有効化前後の MITRE ATT&CK カバレッジ差分 |
シミュレーションで候補が見つかった場合でも、いきなり本番環境で有効化するのは避けた方が安全です。まずはクエリの対象テーブル、必要なデータコネクタ、アラート件数の見込み、インシデント化の条件を確認します。
分析ルールに MITRE ATT&CK を正しく紐づける
カスタムの Scheduled analytics rule を作成する場合、ルール作成画面で MITRE ATT&CK の tactics と techniques を選択できます。複数選択も可能です。公式ドキュメントでは、ルールの一般情報として Severity や MITRE ATT&CK を設定する手順が説明されています。(Microsoft Learn)
実務では、次のような運用ルールを決めておくと、後からカバレッジを分析しやすくなります。
- ルール名に検知対象を具体的に入れる
- Description に想定する攻撃シナリオを書く
- MITRE tactics / techniques を必ず設定する
- Severity は「検知したイベントの危険度」ではなく「真陽性だった場合の影響度」で決める
- カスタムルールを作る前に Content hub のテンプレートで代替できないか確認する
- 誤検知が多いルールは無効化ではなく、条件調整や除外条件で改善する
Scheduled analytics rule では KQL クエリの設計も重要です。公式情報では、スケジュール分析ルールのクエリは TimeGenerated 列を返す必要があるとされています。これはルールが lookback period を評価する基準になるためです。(Microsoft Learn)
移行期限：この機能自体よりも Defender ポータル移行に注意
「View MITRE ATT&CK coverage in Microsoft Sentinel」自体に、個別の移行期限が示されているわけではありません。ただし、Microsoft Sentinel 全体としては Azure ポータルから Microsoft Defender ポータルへの移行計画が重要です。
Microsoft の公式情報では、Microsoft Sentinel は Microsoft Defender ポータルで一般提供されており、Microsoft Defender XDR や E5 ライセンスを持たない顧客でも利用できるとされています。また、2027年3月31日以降、Microsoft Sentinel は Azure ポータルでサポートされず、Microsoft Defender ポータルのみで利用される予定です。Azure ポータルで Microsoft Sentinel を使っている顧客は Defender ポータルへリダイレクトされます。(Microsoft Learn)
つまり、管理者が今やるべきことは、MITRE ATT&CK カバレッジ画面の確認だけではありません。以下の移行準備も同時に進める必要があります。
| 確認項目 | 理由 | 対応 |
|---|---|---|
| Defender ポータルで MITRE ATT&CK 画面を開けるか | 今後の主な操作場所になるため | セキュリティ担当者のアクセス権を確認する |
| 既存ワークスペースが Defender ポータルにオンボード済みか | 未移行だと運用変更時に混乱しやすい | Sentinel 管理者と Azure 管理者で状態を確認する |
| 権限モデルに差分がないか | Defender ポータル移行で RBAC や URBAC の確認が必要になるため | 最小権限の設計を見直す |
| インシデント運用が変わらないか | Defender 側の相関やインシデント統合の影響を受ける場合があるため | SOC の手順書、通知、チケット連携を確認する |
| 自動化ルールや Playbook が期待どおり動くか | ポータル移行で一部の挙動や制限を意識する必要があるため | 検証用インシデントで動作確認する |
Microsoft の移行ドキュメントでは、Defender ポータルへの移行自体に追加コストはなく、Sentinel の利用量に応じた従来の課金が継続されると説明されています。一方で、データ保存・プライバシー、インシデント、アラート、自動化、Playbook には運用上の差分があるため、事前確認が必要です。(Microsoft Learn)
管理者が確認すべきチェックリスト
MITRE ATT&CK カバレッジ画面を開いたら、次の順番で確認すると実務に落とし込みやすくなります。
| 順番 | チェック項目 | 合格ライン |
|---|---|---|
| 1 | Sentinel ワークスペースを選択できる | 対象ワークスペースにアクセスできる |
| 2 | MITRE ATT&CK 画面を開ける | Defender ポータルまたは Azure ポータルで表示できる |
| 3 | アクティブな Scheduled / NRT ルールが表示される | 主要な検知ルールが有効化されている |
| 4 | データコネクタが有効 | ID、エンドポイント、クラウド、ネットワークなど必要ログが入っている |
| 5 | 重要な ATT&CK 技術に空白がない | 自社リスクに関係する技術に検知がある |
| 6 | Simulated coverage を確認した | 追加できるルール候補を把握している |
| 7 | ルールの MITRE マッピングが適切 | カスタムルールにも tactics / techniques が設定されている |
| 8 | 誤検知対応の方針がある | 除外条件、Severity、インシデント作成条件を調整している |
| 9 | Defender ポータル移行を見越している | 2027年3月31日以降の運用場所を前提に手順化している |
| 10 | 変更履歴を残している | どのルールをなぜ有効化したか説明できる |
特に重要なのは、5番目の「重要な ATT&CK 技術に空白がない」ことです。全技術を均等に埋める必要はありません。自社にとって重要な業務システム、管理者アカウント、クラウド管理操作、機密データへのアクセスに関係する技術から優先して確認します。
失敗しやすいポイント
MITRE ATT&CK カバレッジは便利ですが、使い方を誤ると「見た目のカバレッジ」だけが改善し、実際の防御力が上がらないことがあります。
| よくある失敗 | なぜ問題か | 回避策 |
|---|---|---|
| カバレッジを埋めるためだけにルールを大量有効化する | 誤検知が増え、SOC が疲弊する | 重要資産と攻撃シナリオから優先順位を決める |
| データコネクタを確認しない | ルールがあっても対象ログがなければ検知できない | ルール有効化前に必要テーブルへデータが入っているか確認する |
| MITRE マッピングを設定しない | カスタムルールがカバレッジに反映されにくい | ルール作成・変更時の必須項目にする |
| Preview 機能であることを忘れる | 画面仕様や表示内容が変わる可能性がある | 監査資料では取得日と前提条件を残す |
| Azure ポータル前提の手順書を放置する | Defender ポータル移行時に運用が止まる | 2027年3月31日を見据えて手順書を更新する |
| カバレッジを「防御保証」と説明する | 経営層や監査部門に誤解を与える | 「検知ルールの対応状況」として説明する |
実務では、MITRE ATT&CK カバレッジを月次レビューや四半期ごとのセキュリティ改善会議に組み込むと効果的です。たとえば、前月から増えた検知、無効化したルール、誤検知が多かった技術、次に有効化するテンプレートを一覧化すれば、SOC の改善活動を説明しやすくなります。
活用シーン別の使い方
SOC の検知改善に使う
SOC では、インシデント件数だけでなく「どの攻撃手法を検知できているか」を確認するために使います。たとえば、Credential Access や Lateral Movement に関係する技術でカバレッジが薄い場合、ID ログ、エンドポイントログ、クラウド監査ログの取り込み状況を見直します。
このとき、すぐにルールを追加するのではなく、過去30日や90日のログ量、既存アラートの真陽性率、対応時間を確認してから有効化すると、運用負荷を抑えながら改善できます。
監査・リスク説明に使う
監査やリスク管理では、「Microsoft Sentinel を導入している」だけでは説明として不十分です。MITRE ATT&CK カバレッジを使えば、どの攻撃手法に対して検知ルールが有効かを説明しやすくなります。
ただし、監査資料では次のように表現するのが適切です。
Microsoft Sentinel の MITRE ATT&CK 画面により、ATT&CK framework version 18 に基づく検知ルールの対応状況を確認している。ただし、これは検知ルールの構成状況を示すものであり、すべての攻撃を防止・検知できることを保証するものではない。
この一文を入れるだけで、過度な断定を避けながら、管理状況を具体的に説明できます。
グローバル環境の標準化に使う
複数国・複数リージョンで Microsoft Sentinel を使っている場合、MITRE ATT&CK カバレッジは標準化の出発点になります。
たとえば、本社 SOC が「最低限カバーすべき ATT&CK 技術」を定義し、各地域の Sentinel ワークスペースで以下を確認します。
- 同じデータコネクタが有効か
- 同じ分析ルールテンプレートが使えるか
- ローカル要件に合わせて除外条件が調整されているか
- 検知後のインシデント対応フローが統一されているか
- Defender ポータル移行後も同じ手順で確認できるか
この使い方をすると、単なるルール管理ではなく、グローバル SOC の運用品質をそろえるための共通言語として MITRE ATT&CK を活用できます。
まず実施すべきこと
Azure の「View MITRE ATT&CK coverage in Microsoft Sentinel」を確認する目的は、検知ルールの数を増やすことではなく、自社に必要な攻撃手法を見落としていないかを確認し、優先順位を付けて改善することです。
まずは Microsoft Sentinel の MITRE ATT&CK 画面を開き、現在のアクティブな Scheduled query rules と NRT rules を確認します。次に Simulated coverage で追加候補を洗い出し、重要資産や過去インシデントに関係する技術からルールの有効化・調整を進めます。
同時に、Microsoft Sentinel の Azure ポータル利用は 2027年3月31日以降サポートされなくなる予定であるため、Defender ポータルで同じ確認・調査・自動化運用ができるかを今のうちに検証しておくべきです。MITRE ATT&CK カバレッジを「見える化」で終わらせず、データ収集、分析ルール、インシデント対応、移行計画までつなげて見直すことが、今回の更新を実務で活かす最も重要なポイントです。
コメント