Microsoft Defenderで脅威インテリジェンスを運用している管理者がまず確認すべき点は、Revokeされたインジケーターが確実に反映されるか、そしてAND条件を含むパターン定義が期待どおり解釈されるかです。
2026年5月13日に公開または更新された公式情報「Generally Available: Sentinel TI – improved pattern parsing & revoke reliability」は、Microsoft Defenderポータル上の脅威インテリジェンス運用、特にMicrosoft Sentinel TIを使ったIOC管理・検知・自動化に関わる改善です。公式更新では、Revokeアクションの信頼性修正と、パターン解析におけるAND条件のサポートが示されています。(Microsoft Azure)
今回の変更は、エンドユーザー端末のMicrosoft Defender設定を直接変えるものではありません。影響が出やすいのは、SOC運用、Microsoft Sentinelの脅威インテリジェンス管理、STIX/TAXII連携、カスタムTIP連携、KQLクエリ、分析ルール、Logic Appsなどの自動化です。
Microsoft DefenderのSentinel TI更新で何が変わるのか
今回の更新は、Microsoft Defenderポータルで扱う脅威インテリジェンスの「正確性」と「制御性」を高める内容です。Azure Updates上ではLaunched、つまり本番利用可能な状態として扱われる更新です。Azure Updatesのステータス定義では、Launchedは完全にリリースされ、本番環境で利用可能な製品・機能を指します。(Microsoft Azure)
主な変更点は次の2つです。
| 変更点 | 内容 | 実務上の意味 |
|---|---|---|
| Revoke fix | Revokeアクションが一貫して適用されない問題を修正 | 無効化したIOCが残り続け、不要な検知や誤検知につながるリスクを下げられる |
| AND in pattern parsing | パターン解析でAND条件を組み合わせられるように改善 | より細かい条件を持つインジケーターや検知パターンを扱いやすくなる |
たとえば、単に「このIPアドレスは危険」というだけでなく、「特定のファイルハッシュかつ特定の名前」「特定の条件を同時に満たす通信」など、複数条件を前提にしたパターンを扱う場面で効果が出ます。
AI/Copilotの画面追加ではなく、脅威インテリジェンス運用の基盤改善
見出しだけを見ると、Microsoft DefenderのAI機能やCopilot機能の追加と誤解しやすいですが、今回の主役はSentinel TI、つまりThreat Intelligenceの処理改善です。
Microsoft DefenderポータルのIntel ManagementはMicrosoft Sentinelを利用し、脅威インテリジェンスの更新、検索、作成、大規模な管理を行う仕組みです。Microsoft Learnでは、Intel ManagementがSTIXを使った脅威インテリジェンス管理をサポートし、Microsoft Sentinelをソースとして運用されることが説明されています。(Microsoft Learn)
そのため、影響範囲は次のように整理できます。
| 対象 | 影響 |
|---|---|
| SOCアナリスト | 無効化したIOCの扱い、検索結果、調査時のノイズに影響する可能性がある |
| Microsoft Sentinel管理者 | インジェストルール、Threat Intelligence管理画面、ワークスペース設計の確認が必要 |
| 検知エンジニア | AND条件を含むパターン、KQLクエリ、分析ルールの検証が必要 |
| TIP/API連携の開発者 | STIXパターン、Revoke状態、API連携後のデータ反映確認が必要 |
| 一般利用者 | 通常のPC操作やDefenderクライアント設定への直接影響は基本的に小さい |
ポイントは、今回の更新を「新しい画面が増えた」と見るのではなく、脅威インテリジェンスの品質管理がより正確になったと捉えることです。
変更点1：Revoke fixで無効化したインジケーターの扱いが安定する
Revokeは、脅威インジケーターを「取り消し済み」「無効化済み」として扱うための状態です。Microsoft Sentinelのインジケーター作成画面では、Revokedのチェックを入れるとインジケーターをRevokeし、チェックを外すとアクティブに戻せると説明されています。(Microsoft Learn)
これまでは、Revokeアクションが常に意図どおり反映されないケースがあったとされます。今回の修正により、Revokeしたインジケーターが確実に反映されることが期待できます。
Revoke fixが重要な理由
脅威インテリジェンスでは、IOCの鮮度が非常に重要です。古いIPアドレス、誤って登録されたドメイン、調査後に無害と判断されたファイルハッシュが残り続けると、次のような問題が起こります。
- 無効なIOCに基づく不要なアラートが発生する
- SOCアナリストが古い情報を調査してしまう
- 自動化されたブロックや通知が誤って動く
- 外部TIPからの訂正情報が運用に反映されにくい
- 脅威インテリジェンスの信頼度が下がる
特に、外部TIP、Microsoft Defender Threat Intelligence、TAXIIフィード、独自API連携を組み合わせている環境では、Revokeの反映漏れが「なぜこのIOCがまだ検知されるのか」という調査負荷につながります。
管理者が確認すべきKQL例
ThreatIntelIndicatorsテーブルには、STIXインジケーターの情報が格納され、Revoked、IsActive、Pattern、ValidFrom、ValidUntilなどの列が用意されています。Revokedはインジケーターが取り消されたかどうか、IsActiveは検知に対して有効かどうかを示す列です。(Microsoft Learn)
Revoke状態を確認するには、次のようなKQLで直近の状態を確認できます。
ThreatIntelIndicators
| summarize arg_max(TimeGenerated, *) by Id
| where Revoked == true or IsActive == false
| project TimeGenerated, Id, ObservableKey, ObservableValue, Pattern, Revoked, IsActive, Confidence, ValidUntil, SourceSystem, Modified
| order by TimeGenerated descこのクエリで確認したいのは、単にRevoke済みの件数ではありません。重要なのは、Revoke済みのIOCが後続の検知ルールや自動化でまだ使われていないかです。
たとえば、分析ルール側でRevoked == falseやIsActive == trueを考慮していない場合、古いインジケーターを拾い続ける可能性があります。今回の更新でRevokeの反映が安定しても、クエリやルール側がRevoke状態を見ていなければ運用上の問題は残ります。
変更点2：AND条件のパターン解析で、より精密な定義が可能になる
もう一つの変更は、パターン解析でAND条件をサポートした点です。公式更新では、ANDを使って条件を組み合わせられるようになり、より精密で表現力のあるパターン定義が可能になると説明されています。(Microsoft Azure)
これにより、単一条件では広すぎるIOCを、より現実的な条件に絞り込めます。
| 使いどころ | AND条件が役立つ理由 |
|---|---|
| ファイル系IOC | ハッシュ値だけでなく、ファイル名や関連属性も合わせて扱える |
| 通信系IOC | IPアドレスだけでなく、ポートやプロトコルなどの条件を組み合わせやすい |
| キャンペーン調査 | 複数の観測条件を満たすものだけを対象にし、ノイズを減らせる |
| 外部TIP連携 | ベンダーが提供する複合条件付きパターンを扱いやすくなる |
概念的には、次のような考え方です。
条件A AND 条件Bたとえば、STIXパターンを扱う環境では、単に「特定の値に一致する」だけでなく、「複数の属性が同時に一致する」条件を使うことがあります。実際のSTIX構文は利用しているTIP、データコネクタ、オブジェクト形式に合わせて確認する必要がありますが、AND対応によって、従来よりも細かいパターン定義を運用に取り込みやすくなります。
AND条件を使うときの注意点
AND条件は便利ですが、条件を厳しくしすぎると検知漏れにつながります。たとえば、攻撃者がファイル名だけを変えた場合、ハッシュとファイル名のAND条件では検知できない可能性があります。
実務では、次のように使い分けるのが現実的です。
| 判断基準 | 推奨される使い方 |
|---|---|
| 誤検知を減らしたい | AND条件で対象を絞る |
| 初期調査で広く拾いたい | 単一条件またはOR条件も残す |
| 高信頼度のIOCだけ使いたい | ConfidenceやSourceと組み合わせる |
| 攻撃キャンペーンを追跡したい | STIXオブジェクトやリレーションシップも活用する |
AND条件に対応したからといって、すべての既存パターンを複合条件に変更する必要はありません。まずは、誤検知が多いパターン、外部TIPで複合条件が多いフィード、SOCで調査負荷が高いIOCから見直すのが安全です。
管理者が確認すべき設定と運用ポイント
Microsoft Sentinelの脅威インテリジェンスは、DefenderポータルまたはAzure portalから管理できます。Microsoft Learnでは、Defenderポータルでは「脅威インテリジェンス > Intel 管理」、Azure portalではMicrosoft Sentinelの「脅威の管理 > 脅威インテリジェンス」から管理インターフェイスにアクセスすると説明されています。(Microsoft Learn)
今回の更新後、管理者は次の順に確認すると効率的です。
| 確認項目 | 見るべきポイント |
|---|---|
| 脅威インテリジェンスのソース | Defender TI、TAXII、TIP、Upload API、手動登録のどれを使っているか |
| Revoke済みIOC | Revoke後もアラートや自動化に使われていないか |
| パターン定義 | AND条件を含むパターンが期待どおり取り込まれているか |
| インジェストルール | Source、Confidence、ValidUntil、Tagsなどの条件が適切か |
| 分析ルール | RevokedやIsActiveを考慮しているか |
| 自動化 | Logic Appsやプレイブックが古いIOCを処理していないか |
| 監査・運用手順 | SOCがRevokeと削除を混同していないか |
脅威インテリジェンスを管理するには、ユーザーアカウントにMicrosoft Sentinel共同作成者以上のロールが必要です。また、脅威インテリジェンスのインポートやエクスポートでは、Threat Intelligenceソリューションのインストールや関連コネクタの有効化が必要になる場合があります。(Microsoft Learn)
インジェストルールの見直しが重要
Microsoft Sentinelでは、取り込まれる脅威インテリジェンスに対してインジェストルールを使い、ノイズ削減、ValidUntilの延長、タグ付けなどを行えます。Microsoft Learnでは、SourceやConfidenceなどを条件にし、取り込まれたオブジェクトに対して編集アクションを適用する例が示されています。(Microsoft Learn)
今回の更新後は、特に次のルールを見直してください。
- 低Confidenceのインジケーターを除外・タグ付けしているルール
- 特定SourceのIOCだけValidUntilを延長しているルール
- 調査用タグを自動付与しているルール
- RevokeされたIOCを後続処理から外す前提のルール
- AND条件を含むパターンを持つフィードに対するルール
Revokeが安定して適用されるようになると、これまで曖昧に処理されていたIOCの状態がはっきりします。その結果、過去に作った例外ルールや一時的なワークアラウンドが不要になる場合があります。
開発者・自動化担当者が確認すべき移行と実装
外部TIPやカスタムアプリから脅威インテリジェンスを取り込んでいる場合、開発者はデータの投入後だけでなく、Revoke後の状態変化とAND条件を含むパターンの保存・検索・検知まで確認する必要があります。
Microsoft Sentinelでは、TAXII 2.0または2.1サーバーから脅威インジケーターをワークスペースにインポートでき、TAXII Exportコネクタを使うとTAXII 2.1プラットフォームへのエクスポートも構成できます。(Microsoft Learn)
また、Upload APIを使う場合は注意が必要です。Microsoft Learnでは、Threat Intelligence Upload APIはプレビューとして説明され、STIXオブジェクトをアップロードする仕組みであること、利用にはMicrosoft Entra IDのアクセストークンやMicrosoft Sentinel contributorロールが必要であることが示されています。(Microsoft Learn)
開発者向けチェックリスト
| 確認項目 | 具体的な作業 |
|---|---|
| STIXパターン | ANDを含むパターンをテストデータで投入し、Pattern列に期待どおり保存されるか確認する |
| Revoke反映 | APIやTIP側でRevokeしたIOCがThreatIntelIndicatorsでRevokedとして確認できるか検証する |
| 重複処理 | 同じIOCを複数ソースから取り込んだ場合の優先順位やタグ付けを確認する |
| 自動化 | Logic Apps、Functions、SIEM連携がRevokedを無視していないか確認する |
| テスト | 正常系だけでなく、Revoke後、ValidUntil切れ、Confidence低下時もテストする |
AND条件を使う場合は、単に「取り込めたか」だけで合格にしないでください。検索、分析ルール、アラート、プレイブックまで通して検証することが重要です。
古いThreatIntelligenceIndicatorテーブルを使っていないか確認する
Microsoft Sentinelでは、STIXインジケーターとオブジェクトの新しいスキーマとしてThreatIntelIndicatorsとThreatIntelObjectsが使われています。Microsoft Learnでは、2025年7月31日までにカスタムクエリ、分析・検出ルール、ブック、自動化を新しいテーブルへ更新するよう案内されていました。(Microsoft Learn)
2026年時点でまだ古いThreatIntelligenceIndicatorを参照するKQLやワークブックが残っている場合、今回の改善を正しく評価できない可能性があります。
古いクエリが残っていないか、次の観点で棚卸ししてください。
- 分析ルール
- ハンティングクエリ
- ワークブック
- Logic Apps
- Azure Functions
- Power BIや外部SIEM連携
- SOC向けの手順書
展開後に行う検証手順
本番環境でいきなり全ルールを変更するのではなく、小さく検証してから展開するのが安全です。
推奨される検証フロー
| 手順 | 作業 | 成功条件 |
|---|---|---|
| 1 | 利用中のTIソースを棚卸しする | Defender TI、TAXII、TIP、API、手動登録の一覧がある |
| 2 | テスト用インジケーターを用意する | 本番検知に影響しない安全なIOCで検証できる |
| 3 | Revokeを実行する | ThreatIntelIndicatorsでRevokedが反映される |
| 4 | AND条件のパターンを投入する | Pattern列と管理画面で期待どおり確認できる |
| 5 | 分析ルールを確認する | Revoke済みIOCで不要なアラートが出ない |
| 6 | 自動化を確認する | Logic Appsや通知処理が状態を正しく扱う |
| 7 | SOC手順書を更新する | Revoke、削除、期限切れの違いが説明されている |
AND条件を含むパターンの確認には、次のようなKQLを使えます。
ThreatIntelIndicators
| where TimeGenerated > ago(14d)
| where tostring(Pattern) contains " AND "
| summarize arg_max(TimeGenerated, *) by Id
| project TimeGenerated, Id, Pattern, Revoked, IsActive, Confidence, ValidUntil, SourceSystem
| order by TimeGenerated descこの結果を見て、AND条件を含むインジケーターが想定したソースから取り込まれているか、Revokeや有効期限と矛盾していないかを確認します。
失敗しやすいポイント
Revokeを削除と同じ意味で扱ってしまう
Revokeは「取り消し済み」という状態であり、必ずしもデータの物理削除ではありません。監査や過去調査のためにレコードが残ることがあります。
そのため、KQLや自動化で「存在するかどうか」だけを見ていると、Revoke済みのIOCも処理してしまいます。検知やブロックに使う場合は、RevokedやIsActiveを明示的に見る設計にしてください。
AND条件を増やしすぎて検知漏れを起こす
AND条件はノイズ削減に有効ですが、条件を増やすほど一致対象は狭くなります。重要度の高い脅威キャンペーンでは、広く拾うルールと精密に絞るルールを分ける方が安全です。
たとえば、初期検知ではIPアドレス単体で広く拾い、優先度付けや調査画面ではAND条件を持つ高信頼度インジケーターを使う、といった使い分けが現実的です。
ポータル移行を後回しにする
Microsoft Sentinelは、2027年3月31日以降Azure portalではサポートされず、Microsoft Defenderポータルでのみ利用される予定です。Microsoft Learnでは、Azure portalを使っている場合はDefenderポータルへの移行計画を開始することが推奨されています。(Microsoft Learn)
今回のSentinel TI更新をきっかけに、脅威インテリジェンス管理の画面、権限、運用手順をDefenderポータル前提で整理しておくと、後の移行負荷を下げられます。
複数ワークスペースに同じIOCを重複投入する
複数のMicrosoft Sentinelワークスペースを使っている場合、同じ脅威インジケーターをすべてのワークスペースに取り込むと、管理やコストの面で非効率になることがあります。Microsoft Learnでは、同一テナントに複数ワークスペースがある場合、脅威インジケーターを中央のワークスペースにのみ接続する方がコスト効率が高い場合があると説明されています。(Microsoft Learn)
MSSPや大規模組織では、どのワークスペースにTIを持たせるかを再確認してください。
TAXII Exportの設定変更を軽く見る
TAXII Exportを使っている場合、既存コネクタの編集がサポートされていない点にも注意が必要です。Microsoft Learnでは、TAXIIサーバーや規則の構成を変更するにはコネクタの再インストールが必要と説明されています。(Microsoft Learn)
外部共有先にRevoke済みIOCをどう渡すか、AND条件付きのパターンが共有先でどう解釈されるかも含めて確認しましょう。
まず実施すべきこと
今回のMicrosoft Defender関連のSentinel TI更新は、派手なUI追加ではありません。しかし、脅威インテリジェンスを使った検知・調査・自動化の品質に直結します。
特に優先すべき作業は次の5つです。
- Revoke済みIOCが分析ルールや自動化で使われ続けていないか確認する
- AND条件を含むパターンをテストデータで検証する
ThreatIntelIndicatorsとThreatIntelObjectsを前提にKQLや自動化を見直す- インジェストルールでSource、Confidence、ValidUntil、Tagsの扱いを再確認する
- Defenderポータル前提の権限・手順・SOC運用に更新する
Sentinel TIを日常的に使っていない環境でも、Defender TI、TAXII、外部TIP、手動登録IOCのいずれかを使っているなら、今回の更新は確認対象です。まずは直近14日分のThreatIntelIndicatorsを確認し、Revoke状態とAND条件を含むパターンの扱いから点検してください。
コメント