Microsoft SentinelのThreat intelligence（脅威インテリジェンス）機能を使っているチームが、2026年4月時点で最初に確認すべきことは明確です。Azure portal前提の運用を続けず、Microsoft Defender portal前提の運用設計へ寄せること。あわせて、脅威インテリジェンスの取り込み・検索・検知ルール・ワークブックを、新しいSTIX中心の管理とテーブル構成に合わせて点検することです。
Microsoft公式の「Threat intelligence in Microsoft Sentinel」は2026年4月22日に更新されており、Microsoft SentinelのThreat intelligenceを、単なるIOCの一覧管理ではなく、STIXオブジェクト、関係性、取り込みルール、分析ルール、ハンティング、可視化まで含む運用基盤として整理しています。特にsecurity admins、identity teams、compliance teamsは、ポータル移行、データ保持・共有、検知ロジック、TLPによる共有範囲の管理まで含めて見直す必要があります。(Microsoft Learn)
2026年4月更新でまず確認すべきポイント
2026年4月22日更新の公式情報で重要なのは、「Threat intelligenceの画面やコネクタを知る」だけではありません。実務上は、次の4点を優先して確認します。
| 確認ポイント | 実務上の影響 | 今すぐやること |
|---|---|---|
| Defender portalへの移行 | 2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Defender portalでの利用が前提になる | SOC運用手順、権限、インシデント対応、教育資料をDefender portal基準で更新する |
| STIX中心の管理 | IOCだけでなく、攻撃者、攻撃手法、Identity、Relationshipを関連付けて扱える | タグだけで管理している情報を、Relationshipに置き換えられないか確認する |
| 取り込み経路の整理 | Defender Threat Intelligence、TAXII、upload API、従来のTIPコネクタで役割が異なる | 既存のTI連携が非推奨コネクタに依存していないか棚卸しする |
| 新テーブルへの対応 | ThreatIntelIndicatorsとThreatIntelObjectsを前提に、KQL、分析ルール、Workbook、Automationを見直す必要がある | 旧ThreatIntelligenceIndicator依存のクエリを洗い出す |
Microsoftは、2027年3月31日以降にMicrosoft SentinelがAzure portalではサポートされず、Microsoft Defender portalでのみ利用可能になると案内しています。現在Azure portalで運用している組織は、Threat intelligenceだけでなく、インシデント管理、分析ルール、Automation、Playbook、権限設計まで含めた移行計画を立てるべきです。(Microsoft Learn)
Threat intelligenceは「IOCリスト」ではなく文脈管理に近づいている
Threat intelligenceというと、IPアドレス、ドメイン、URL、ファイルハッシュなどのIOCを取り込んで、ログと照合する機能を想像しがちです。Microsoft SentinelでもIOCは重要ですが、2026年時点の整理では、STIXオブジェクトを使って脅威の文脈を管理する方向が強くなっています。
Microsoft Sentinelでは、脅威インテリジェンスをSTIX形式で扱い、攻撃者、攻撃パターン、インジケーター、Identity、Relationshipなどを管理できます。これにより、「この不審ドメインがどの攻撃者に関連しているか」「その攻撃者はどのTTPを使うか」「どの組織や業種が狙われているか」といった文脈を調査に使いやすくなります。(Microsoft Learn)
STIXオブジェクトの使い分け
| STIXオブジェクト | 使いどころ | 実務例 |
|---|---|---|
| Indicator | IP、ドメイン、URL、ファイルハッシュなどの観測可能な値を管理する | 不審IPとプロキシログを照合する |
| Threat actor | 攻撃グループや攻撃主体の情報を整理する | 特定グループに関連するIOCをまとめる |
| Attack pattern | TTPやMITRE ATT&CKの段階に紐づく攻撃手法を管理する | フィッシング、資格情報窃取、横展開などを分類する |
| Identity | 被害組織、業種、関係者などを表す | 自社グループ会社や重要部門への影響を整理する |
| Relationship | オブジェクト同士の関係を表す | 「攻撃者AがドメインBを使用」「攻撃パターンCがIdentity Dを標的」などを表現する |
タグで何でも分類すると、後から検索はできても関係性が曖昧になります。たとえば、APT29、phishing、finance-sectorのようなタグを同じIndicatorに付けるだけでは、「誰が」「何を使い」「誰を狙ったのか」が読み取りにくくなります。攻撃者、攻撃手法、標的が明確な場合は、タグではなくRelationshipを使うほうが調査・ハンティング・説明責任に向いています。
取り込み経路は「何を、どこから、どの粒度で入れるか」で選ぶ
Microsoft SentinelのThreat intelligenceでは、主にデータコネクタまたはAPIで脅威情報を取り込みます。公式ドキュメントでは、Microsoft Defender Threat Intelligence data connector、Threat Intelligence – TAXII data connector、Threat Intelligence upload API、Threat Intelligence Platform data connectorが整理されています。なお、Threat Intelligence Platform data connectorは非推奨化の方向にあるため、既存連携の見直しが必要です。(Microsoft Learn)
| 取り込み方法 | 向いているケース | 注意点 |
|---|---|---|
| Microsoft Defender Threat Intelligence data connector | Microsoft由来の脅威インテリジェンスをSentinelで活用したい場合 | 標準版とプレミアム版で利用できる情報が異なる |
| Threat Intelligence – TAXII data connector | STIX/TAXII 2.0または2.1に対応したフィードを取り込みたい場合 | TAXIIサーバーのAPI rootとcollection IDなどの設定が必要 |
| Threat Intelligence upload API | TIPや独自アプリからSTIXオブジェクトを取り込みたい場合 | Preview機能であり、Microsoft EntraアプリとMicrosoft Sentinel Contributor権限が必要 |
| Threat Intelligence Platform data connector | 既存TIP連携で従来APIを利用している場合 | 非推奨化の方向にあるため、upload APIへの移行検討が必要 |
特にupload APIは、データコネクタを必要とせず、ワークスペースレベルでSTIXオブジェクトをMicrosoft Sentinelへ取り込める点が重要です。利用にはMicrosoft Entraアプリの登録、クライアントシークレット、Microsoft Sentinel Contributorロールの割り当てなどが必要です。ただし、このupload APIはPreviewとして案内されているため、本番採用時は変更可能性を前提に運用設計へ組み込むべきです。(Microsoft Learn)
Ingestion rulesでノイズを減らし、使える脅威情報だけを残す
Threat intelligence運用で失敗しやすいのは、「フィードをたくさん入れれば検知力が上がる」と考えることです。実際には、古いIOC、信頼度の低いIOC、重複したIndicatorが増えると、アラートの質が下がり、SOCの調査負荷が増えます。
Microsoft Sentinelでは、データコネクタから取り込むThreat intelligenceに対してIngestion rulesを使い、取り込み前にフィルタリングや属性の更新ができます。たとえば、6か月更新されていない低信頼度のIOCを除外する、高信頼度のIndicatorの有効期限を延長する、旧名称や社内分類用のタグを付ける、といった使い方ができます。(Microsoft Learn)
Ingestion rulesの設計例
| 目的 | ルール例 | 期待できる効果 |
|---|---|---|
| 古いIOCを減らす | 最終更新が古く、Confidenceが低いIndicatorをDeleteする | 誤検知や無駄な照合を減らす |
| 重要フィードを優先する | 信頼できるSourceかつConfidenceが高いIndicatorのValid untilを延長する | 有用なIOCを検知対象に残しやすくする |
| 調査対象を分類する | 特定キャンペーンや地域に関するタグを自動付与する | ハンティングやレポート作成がしやすくなる |
注意点は、Ingestion rulesがデータコネクタ経由のThreat intelligenceに適用される機能であり、upload APIで追加したThreat intelligenceや手動作成したオブジェクトには影響しないことです。また、ルールは順番に処理され、Deleteアクションが実行されるとそのオブジェクトは取り込みパイプラインから除外されます。新規作成または編集したルールは、反映まで最大15分程度かかると案内されています。(Microsoft Learn)
新テーブルThreatIntelIndicatorsとThreatIntelObjectsへの対応は必須
2026年時点で最も見落としやすいのが、Threat intelligenceのテーブル変更です。Microsoftは2025年4月3日に、STIX indicatorおよびobjectスキーマをサポートする新しいThreatIntelIndicatorsとThreatIntelObjectsをPublic Previewとして案内しました。公式情報では、旧ThreatIntelligenceIndicatorテーブルへの同一データ取り込みは2025年7月31日まで継続され、その後は旧テーブルへの取り込みが停止されると説明されています。(Microsoft Learn)
つまり、2026年4月時点で旧テーブル前提のクエリ、分析ルール、Workbook、Automationが残っている場合、すでに期待どおり動いていない可能性があります。特に以下は優先して確認してください。
| 対象 | 確認内容 |
|---|---|
| Analytics rules | ThreatIntelligenceIndicatorを参照しているKQLがないか |
| Hunting queries | IOC照合や攻撃者関連付けのクエリが新テーブル対応になっているか |
| Workbooks | Threat Intelligence Workbookや独自ダッシュボードが旧テーブル依存でないか |
| Automation / Playbooks | 旧スキーマの列名を前提に条件分岐していないか |
| 外部連携 | SIEM連携、チケット連携、レポート出力で旧列名を使っていないか |
まずは、以下のようなKQLで新テーブルにデータが入っているか確認します。
ThreatIntelIndicators
| summarize arg_max(TimeGenerated, *) by Id
| where IsDeleted == false
| summarize Count = count() by ObservableKey
| order by Count desc攻撃者や攻撃パターンなど、Indicator以外のSTIXオブジェクトを確認する場合は、ThreatIntelObjectsを使います。
ThreatIntelObjects
| summarize arg_max(TimeGenerated, *) by Id
| where IsDeleted == false
| summarize Count = count() by StixType
| order by Count descMicrosoftのドキュメントでは、旧ThreatIntelligenceIndicatorから新ThreatIntelIndicatorsスキーマへ移行する例も示されています。新テーブルではObservableKeyとObservableValueを使って、IP、ドメイン、URL、ファイルハッシュなどを扱う考え方になります。既存KQLを単純にテーブル名だけ置換すると動かないケースがあるため、列名とデータ構造の確認が必要です。(Microsoft Learn)
Defender portal移行でsecurity adminsが見るべきこと
Threat intelligenceの更新ポイントは、Sentinel単体の話に見えますが、実際にはDefender portal移行の影響を強く受けます。Microsoft SentinelをDefender portalに統合すると、SIEMとXDRをまたいだ統合セキュリティ運用に近づきます。一方で、インシデントの相関、アラート表示、Automation、APIの扱いが変わる部分があります。(Microsoft Learn)
security adminsは、特に次の点を確認します。
| 項目 | 確認する理由 |
|---|---|
| 権限 | Defender portalではSentinel、Defender XDR、Advanced huntingの操作権限が運用に影響する |
| データコネクタ | 一部コネクタの表示場所や扱いがAzure portal時代と異なる |
| Analytics rules | ルール自体は利用できるが、インシデント相関やアラートの見え方が変わる可能性がある |
| Automation rules | インシデント名やProviderNameを条件にしたルールは見直しが必要 |
| API連携 | 統合インシデントやアラートはMicrosoft Graph REST APIを使う設計が推奨される場面がある |
失敗しやすいのは、ポータルだけを切り替えて、SOC手順書や検知後の運用を更新しないことです。たとえば、Azure portalで「Microsoft Sentinelのインシデント」として扱っていたものが、Defender portalではMicrosoft XDRの相関ロジックにより、複数のアラートを含む統合インシデントとして表示される場合があります。調査担当者がこの違いを理解していないと、重複対応や見落としが起きます。
identity teamsはIdentityとRelationshipを調査に活かす
identity teamsにとって、Threat intelligenceの価値は「不審なIPを検知すること」だけではありません。Microsoft Sentinelでは、STIXのIdentityオブジェクトやRelationshipを使って、脅威情報と被害対象、攻撃手法、攻撃者の関係を整理できます。
たとえば、以下のような調査シナリオで役立ちます。
| シナリオ | Threat intelligenceの使い方 |
|---|---|
| 特定ユーザーへの標的型攻撃 | 攻撃パターン、送信元ドメイン、標的Identityを関連付ける |
| Entra IDサインイン異常 | 不審IPやドメインIndicatorをサインインログと照合する |
| 重要部門への攻撃傾向 | Identityオブジェクトで部門や組織を整理し、関連Indicatorを追跡する |
| フィッシング後の横展開調査 | 攻撃パターンと関連Indicatorをまとめてハンティングする |
タグだけでは、「これは経理部門関連」「これはフィッシング関連」という分類はできますが、攻撃の流れを説明しにくくなります。Relationshipを使えば、攻撃者、Indicator、攻撃手法、Identityをつなげられるため、インシデントレビューや経営層向け報告でも説明しやすくなります。
compliance teamsはTLP、データ所在地、エクスポートを確認する
compliance teamsが見るべきポイントは、検知精度よりも「どの脅威情報を、誰と、どの範囲で共有できるか」です。Microsoft Sentinelでは、Threat intelligenceオブジェクトにTraffic Light Protocol（TLP）を設定し、共有範囲の目安を管理できます。TLPにはWhite、Green、Amber、Redの区分があり、公開可能な情報から限定共有すべき情報までを分類します。(Microsoft Learn)
特にグローバル組織では、次の観点を運用ルールに含めるべきです。
| 観点 | 確認内容 |
|---|---|
| TLP | 外部共有できる情報と、社内限定にすべき情報を分類しているか |
| データ所在地 | Defender portal移行に伴い、適用されるデータ保管・処理・共有ポリシーを確認しているか |
| エクスポート | TAXII経由で外部へThreat intelligenceを共有する際、地域・契約・権限を確認しているか |
| 監査証跡 | 誰がThreat intelligenceを作成、編集、共有したかを説明できるか |
| 命名規則 | タグやSource名が属人的でなく、監査時に意味が分かる形になっているか |
Microsoft SentinelではThreat intelligenceを他の宛先へエクスポートできますが、公式ドキュメントでは、データのエクスポート先が異なる地理的または規制上のリージョンに存在する可能性があるため、共有権限やデータ所有権を慎重に確認するよう注意しています。また、Threat intelligenceのエクスポートはTAXII 2.1ベースのプラットフォームを対象とする説明になっています。(Microsoft Learn)
検知とハンティングでは「一致したか」より「なぜ重要か」を見る
Threat intelligenceを検知に使う場合、基本はログ内のイベントとIndicatorを照合し、アラートやインシデントを生成することです。Microsoft Sentinelには、ドメイン、メール、ファイルハッシュ、IPアドレス、URLなどのIndicator種別とデータソースイベントを照合する組み込み分析ルールテンプレートがあります。(Microsoft Learn)
ただし、実務で重要なのは「IOCに一致した」という事実だけではありません。次の3点をセットで確認すると、アラートの質が上がります。
| 見るべき点 | 例 |
|---|---|
| Confidence | 信頼度が低いIndicatorに一致しただけで重大インシデントにしていないか |
| Valid until | 期限切れに近い、または古いIndicatorを過剰に重視していないか |
| Relationship | 一致したIndicatorが既知の攻撃者や攻撃手法に関連しているか |
IPアドレスやドメインIndicatorには、GeoLocationやWhoIsの付加情報を利用できるPublic Previewの機能もあります。調査時には、国や地域、組織、レジストラ、ドメイン作成日などを手がかりに、単なる一致判定から「調査すべき理由」の説明へつなげられます。(Microsoft Learn)
Workbookは「取り込み量」ではなく「使えるTIか」を可視化する
Threat intelligenceのWorkbookを作るときは、取り込み件数だけを見ても不十分です。件数が多いほど良いのではなく、SOCが使える情報になっているかを可視化する必要があります。
おすすめは、次のような観点です。
| 可視化項目 | 目的 |
|---|---|
| Source別のIndicator数 | 特定フィードに偏りすぎていないか確認する |
| Confidence分布 | 低信頼度データが多すぎないか確認する |
| Valid untilの期限切れ予備軍 | 期限切れ前に更新・削除判断をする |
| ObservableKey別の件数 | IP、ドメイン、URL、ハッシュなどの偏りを把握する |
| アラート化されたIndicator | 実際に検知に貢献しているTIを把握する |
Microsoft SentinelにはThreat Intelligence Workbookが用意されており、取り込んだThreat intelligenceの主要情報を可視化できます。自社の運用では、標準テンプレートに加えて、フィード品質、期限、信頼度、検知貢献度を見られるダッシュボードへ拡張すると実務に役立ちます。(Microsoft Learn)
2026年4月版を踏まえた実務チェックリスト
最後に、Microsoft SentinelのThreat intelligence運用で、今すぐ確認すべき項目を整理します。
| 優先度 | チェック項目 | 対象チーム |
|---|---|---|
| 高 | Azure portal前提の手順をDefender portal前提に更新する | security admins |
| 高 | ThreatIntelligenceIndicator依存のKQL、Analytics rules、Workbooks、Automationを洗い出す | security admins |
| 高 | 既存TIP連携が非推奨化方向のThreat Intelligence Platform data connectorに依存していないか確認する | security admins |
| 中 | Ingestion rulesで古い低信頼度IOCを除外する | SOC / security admins |
| 中 | タグ運用とRelationship運用を分ける基準を決める | SOC / identity teams |
| 中 | Identityオブジェクトを使い、標的部門や重要アカウントに関する脅威文脈を整理する | identity teams |
| 中 | TLP、エクスポート、共有先リージョン、データ所有権を確認する | compliance teams |
| 低 | Workbookで件数だけでなく、信頼度、期限、検知貢献度を可視化する | SOC / management |
2026年4月更新のMicrosoft Sentinel Threat intelligenceで押さえるべき本質は、IOCを大量に入れる運用から、文脈を持った脅威インテリジェンスを管理し、検知・調査・共有・監査に使う運用へ移ることです。
まずは、Defender portal移行、旧テーブル依存、非推奨コネクタ依存の3点を棚卸ししてください。そのうえで、STIXオブジェクト、Relationship、Ingestion rules、Workbookを使い、SOCが実際に判断しやすいThreat intelligence運用へ整えるのが、2026年時点の現実的な対応です。
コメント