mcpField
D
defender-xdr

defender-xdr

github.com/vinayaklattheセキュリティ17883 回インストール19 週間前に更新
リポジトリ

defender-xdr について

Microsoft Defender XDR の導入と運用を支援する、セキュリティチーム向けのガイダンススキルです。複数のワークロードにまたがるインシデント調査、対応設定、カバレッジ確認を扱います。

主な機能

  1. 01複数の Defender ワークロードのアラート相関
  2. 02攻撃グラフを使ったインシデント調査
  3. 03統合 RBAC の設定
  4. 04攻撃の中断と AIR の設定
  5. 05KQL とカスタム検出による脅威ハンティング

活用シーン

  1. 01Defender XDR ワークロード導入の計画
  2. 02複数ワークロードにまたがるインシデント調査
  3. 03攻撃の中断機能の安全な設定
  4. 04ハンティングルールとカバレッジの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill defender-xdr

インストール後、Claude Code で/defender-xdrを入力して読み込まれたか確認します。

詳細

Microsoft Defender XDR

Microsoft Defender XDR は、侵害前後を対象とする統合防御スイートです。エンドポイント(MDE)、ID(MDI + Entra ID Protection)、メール/コラボレーション(MDO)、クラウドアプリ(MDA)にまたがるシグナルをネイティブに相関付けし、攻撃の全体像(グラフ、タイムライン、証拠、推奨アクション)を含む、優先順位付けされた単一のインシデントを提供します。

使用する場合

各ワークロードを個別に調査するのではなく、1 つのポータル(security.microsoft.com)から Microsoft 365 環境全体にわたる連携した検出と対応を実行する場合に使用します。また、XDR による相関付けが必要な攻撃の阻止機能を使う場合にも使用します。

次の場合はこのスキルを使用しないでください。 サードパーティのログを取り込む場合や、Microsoft 以外のソースに対するカスタム KQL 検出を作成する場合(sentinel)、Sentinel と Defender を 1 つのポータルに統合する場合(unified-secops-platform)、またはエンドポイントのみのポリシーを調整する場合(defender-for-endpoint)。

シグナルをソースのワークロードに対応付ける

XDR の有効性は、シグナルを供給するワークロードに左右されます。オンボード済みのワークロードと、欠落しているアラートを確認するには、次の表を使用してください。

シグナルソースのワークロード必要なライセンス
デバイス上のプロセスツリー、ネットワーク接続、ファイルハッシュDefender for Endpoint (MDE) P2M365 E5 / MDE P2
Kerberos の異常、DCSync、AD CS の悪用、オンプレミスでのラテラルムーブメントDefender for Identity (MDI)M365 E5 / EMS E5
リスクの高いサインイン、漏えいした認証情報、異常なトークンの使用Entra ID ProtectionEntra ID P2
フィッシング URL のクリック、悪意のある添付ファイルの実行、BECDefender for Office 365 P2M365 E5 / MDO P2
リスクの高い OAuth アプリ、異常な SaaS へのアップロード、MCAS 形式のアラートDefender for Cloud Apps (MDA)MDA 単体または E5
Azure リソースのアラート、AKS ポッドの侵害Defender for Cloudプランベースの DfC

経験則: インシデントに「1 alert, 1 entity」と表示される場合、ワークロードが不足しています。実際の攻撃では、上記のうち少なくとも 2 つに必ず影響が及びます。

アプローチ

  1. まず主要なワークロードをオンボーディングします — 次の順に進めます。MDE(エンドポイントのシグナルが最も多い)、MDI(ラテラルムーブメント)、Entra ID Protection、MDO。SaaS アプリが対象範囲に含まれる場合は、MDA も追加します。各ワークロードをそれぞれのポータルにオンボーディングしても、統合 Defender ポータルに表示されます。 確認方法:24 時間後に Incidents ビューを開き、少なくとも 3 種類の異なる ServiceSource の値からアラートが表示されることを確認します。

  2. 広範に有効化する前に統合 RBAC を設定します — ワークロードごとのロールから Microsoft Defender XDR Unified RBAC(security.microsoft.com → Permissions)に移行します。データソースとアクセス許可レベルに応じて、カスタムロールを作成します。適用する前に、active-directory モードで 30 日間パイロット運用します。 確認方法:Tier-1 アナリストがトリアージと封じ込めを実行できる一方で、ポリシーは変更できないこと、また Tier-3 が検出を調整できる一方で、RBAC は変更できないことを確認します。

  3. アラートではなく、インシデントを調査します — インシデントでは、関連するアラート、資産、証拠が攻撃グラフとともにグループ化されます。必ず Incidents キューから調査を始めます。攻撃グラフには、ワークロードを横断するキルチェーンが 1 つのビューに表示されます。 確認方法:複数のアラートを含むインシデントを開き、ユーザー、デバイス、メールボックス、IP などのエンティティがワークロードをまたいで関連付けられてグラフに表示されることを確認します。

  4. 攻撃の自動的な阻止を有効にします — Defender XDR は、複数のシグナルをまたぐ信頼度が 99% 以上の場合、信頼度の高い進行中の攻撃に対処できます(ユーザーの無効化、デバイスの分離、メールボックスの封じ込め)。14 日間は レポートのみ で運用し、アクションを確認してから適用します。 確認方法:過去 14 日間の Action center を確認し、阻止アクションに誤検知がないことを確認します。

  5. 高度なハンティング — KQL の共有スキーマ(DeviceEvents、IdentityLogonEvents、EmailEvents、CloudAppEvents)に対してクエリを実行します。有用なハンティングは、インシデントのグループ化と影響を受けたエンティティのマッピングを設定して、カスタム検出ルール に昇格させます。 確認方法:各カスタムルールにエンティティのマッピングがあることを確認します。マッピングがない場合、アラートはインシデントに結合されません。

  6. 自動調査と修復(AIR) — デバイスグループごとに修復レベル(No remediation → Semi → Full)を設定します。多くの環境では、ワークステーションに Full、サーバーに Semi を適用します。

  7. 毎月、カバレッジを確認します — MITRE ATT&CK coverage ビューを使って、検出の空白を特定します。XDR の ROI に関わる SOC 指標として重要なのは、確認までの時間と封じ込めまでの時間の中央値の 2 つだけです。

ガードレール

  • 4 つすべてのワークロードがなければ、XDR とは言えません。「MDE のみの Defender XDR」環境は、見栄えのよいポータルを備えた EDR にすぎません。相関には、少なくとも MDE、MDI、Entra ID Protection が必要です。
  • **まず統合 RBAC を設定し、その後で広範に有効化します。**設定しない場合、アナリストはワークロードごとのロールグループを通じて、テナント全体の権限を取得します。アクセスを許可する前に、RBAC を制限してください。
  • **攻撃の阻止は、まずレポートのみで実行します。**デバイスが分離され、ユーザーが無効化されます。14 日間アクションをパイロット運用し、Action Center を確認してから適用してください。
  • **カスタム検出ルールにはエンティティのマッピングが必要です。**マッピングがないと、アラートはインシデントに相関されず、攻撃グラフが正しく機能しません。
  • **キューのレベルでインシデントを抑制しないでください。**アラートのソース(MDE/MDI/MDO)で抑制し、基盤となる検出を引き続き調整できるようにします。キューでの抑制は、原因ではなく症状を隠します。
  • **Defender ポータルは SOC の作業画面です。**アナリストが MDE、MDI、MDO の各ポータルを行き来する運用は避けてください。それこそが、XDR で解決しようとしている問題です。

よくあるアンチパターン

  • 「MDE だけをオンボードして、これを XDR と呼ぶ」 - キルチェーンの半分が見えなくなります。XDR のカバレッジを主張する前に、MDI と Entra ID Protection をオンボードしてください。
  • 「各 Defender ワークロードに専任の分析チームがある」 - 統合調査モデルが損なわれます。1 つのインシデントに、1 人のアナリストが、すべてのワークロードを担当します。
  • 「初日からテナント全体で攻撃の阻止を有効にする」 - 正当なアクティビティ(ランサムウェアに見える侵入テストなど)まで中断してしまいます。まず 14 日間、レポート専用モードで運用してください。
  • 「エンティティのマッピングなしでカスタムルールを使う」 - アラートがインシデントに集約されません。必ず少なくとも 1 つのエンティティ(ユーザー/デバイス/IP)をマッピングしてください。
  • 「一部のワークロードでは統合 RBAC を、他のワークロードでは従来の RBAC を使う」 - 権限の重複によって過剰な権限が付与されます。すべてのワークロードを移行するか、どれも移行しないでください。
  • 「自動化を信用できないので、すべての場所で AIR を No remediation に設定する」 - 定型作業にアナリストの時間が浪費されます。ワークステーションでは Semi から始め、確認してください。

プロンプトの例

  • 新しい Microsoft 365 テナントで、最初に有効にすべき Defender XDR のコントロールは何ですか?
  • 攻撃グラフを使って、Defender XDR で複数段階のインシデントを調査する方法を順を追って説明してください。
  • デバイス全体で不審な PowerShell の実行を検出するための、高度なハンティング KQL クエリを作成してください。
  • 自動攻撃阻止の仕組みと、最初に設定すべき項目を教えてください。
  • 同じインシデント内で、ID アラートとデバイスアラートを関連付けるにはどうすればよいですか?
  • 3 層の SOC 向けに統合 RBAC ロールを設計してください。
  • このハンティングクエリを、エンティティのマッピングを含むカスタム検出ルールに変換してください。

Microsoft Learn

コメント