Microsoft Defender XDR

概要

Microsoft Defender XDR 統合 (INT-021) は、Microsoft Defender for Endpoint (MDE) や Microsoft Defender XDR を含む Microsoft の拡張検出および対応プラットフォームと CaseBender の間で双方向同期を提供します。

インバウンド取り込み

Defender のアラートとインシデントは CaseBender に取り込まれ、正規化され、オブザーバブルと MITRE ATT&CK テクニックで強化され、アラート/ケースに変換されます。

アウトバウンド同期

CaseBender のケースがクローズされると、リンクされた Defender のアラート/インシデントが、 Microsoft Graph 経由でステータス、分類、監査コメントとともに更新されます。

この統合は Microsoft Graph セキュリティ API (https://graph.microsoft.com/v1.0/security) を使用します。OAuth2 クライアント資格情報フローを使用して Azure AD (Entra ID) アプリケーションで認証します。

機能

機能	方向	説明
アラート取り込み	インバウンド	Defender アラートを CaseBender アラートに正規化
インシデント取り込み	インバウンド	Defender インシデント (子アラートを含む) を取り込み
オブザーバブル抽出	インバウンド	エビデンスから IP、URL、ファイルハッシュ、ファイル名、ホスト名、ユーザーアカウントを抽出
アセット抽出	インバウンド	`devices[]` からデバイスのホスト名、IP、OS プラットフォームを取得
MITRE ATT&CK 相関	インバウンド	テクニック ID をタグおよび TTP として追加 (例: `mitre:T1078`)
アラート同期	アウトバウンド	ケースクローズ時に `status`、`classification`、`determination`、コメントを送信
インシデント同期	アウトバウンド	ケースクローズ時に `status`、`classification`、`determination`、コメントを送信
接続テスト	双方向	OAuth2 資格情報と Graph セキュリティ API アクセスを検証

前提条件

Microsoft Defender / Entra ID へのアクセス

Microsoft Defender XDR または Microsoft Defender for Endpoint がライセンスされ、有効化された Microsoft Entra ID (Azure AD) テナント。アプリケーションを登録し、管理者の同意を付与する権限が必要です。

ネットワーク送信

CaseBender のデプロイメントは次に到達できる必要があります:

https://login.microsoftonline.com (OAuth2 トークンエンドポイント)
https://graph.microsoft.com (Graph セキュリティ API)

CaseBender 管理者ロール

設定 → 統合 で統合を作成・管理できる必要があります。

パート A — Azure AD アプリケーションを登録する

アプリ登録を作成する

Microsoft Entra 管理センターで、ID → アプリケーション → アプリの登録 → 新規登録に移動します。名前 (例: CaseBender Defender Integration) を付けて登録します。

識別子を記録する

アプリケーションの概要から、アプリケーション (クライアント) ID と ディレクトリ (テナント) ID をコピーします。これらを CaseBender に入力します。

クライアントシークレットを作成する

証明書とシークレット → 新しいクライアントシークレットで、シークレットを作成し、その値をすぐにコピーします (一度しか表示されません)。

Graph セキュリティ API 権限を付与する

API のアクセス許可 → アクセス許可の追加 → Microsoft Graph → アプリケーションのアクセス許可で、以下を追加してから管理者の同意を与えるをクリックします:

権限	目的
`SecurityAlert.ReadWrite.All`	Defender アラートの読み取りと更新
`SecurityIncident.ReadWrite.All`	Defender インシデントの読み取りと更新

アプリケーション権限 (委任ではない) を使用してください。統合はクライアント資格情報フローでヘッドレス実行され、テナント管理者の同意が必要です。

パート B — CaseBender で統合を構成する

統合カタログを開く

設定 → 統合 → 作成に移動し、EDR/XDR カテゴリから Microsoft Defender XDR を選択します。

Azure AD 資格情報を入力する

パート A で取得した値を入力します:

フィールド	説明
`tenantId`	ディレクトリ (テナント) ID
`clientId`	アプリケーション (クライアント) ID
`clientSecret`	クライアントシークレットの値

同期オプションを構成する

必要な動作を有効にします:

オプション	効果
`syncCaseClose`	ケースのクローズを Defender に送信
`autoCreateCases`	取り込んだ Defender インシデントからケースを自動作成
`closeAlertsOnCaseClose`	ケースクローズ時にリンクされた Defender アラートを解決
`closeIncidentsOnCaseClose`	ケースクローズ時にリンクされた Defender インシデントを解決

接続をテストする

接続テストを使用して検証します。CaseBender は OAuth2 トークンを要求し、 GET /security/alerts_v2?$top=1 を呼び出します。

テスト中の 403 応答は成功として扱われます。アプリがその特定のエンドポイントに読み取りスコープをまだ付与されていない場合でも、認証が機能したことを確認できます。

インバウンド: Defender アラートとインシデントの取り込み

エンドポイント

Defender (または Logic Apps、Sentinel、Webhook フォワーダーなどの仲介) は、アラート/インシデントペイロードを CaseBender の取り込みエンドポイントに送信します:

POST https://<あなたの-casebender-ドメイン>/api/v1/ingest/defender

リクエストは x-api-key ヘッダーの統合 API キーで認証されます (authorization: Bearer <キー> ヘッダーも受け入れられます)。Defender の Webhook API キーには cbr_defender_ プレフィックスが付きます。

ペイロード形式

バッチ形式 (Graph の value[] 配列) と単一アラートオブジェクトの両方がサポートされます。

curl -X POST "https://<あなたの-casebender-ドメイン>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "value": [
      {
        "id": "da637...",
        "incidentId": "12345",
        "title": "不審な PowerShell の実行",
        "severity": "high",
        "status": "new",
        "classification": "unknown",
        "createdDateTime": "2026-07-03T18:20:00Z",
        "mitreTechniques": ["T1059.001"],
        "evidence": [
          { "@odata.type": "#microsoft.graph.security.fileEvidence",
            "sha256": "9f2b...", "fileName": "payload.ps1" }
        ]
      }
    ]
  }'

curl -X POST "https://<あなたの-casebender-ドメイン>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "da637...",
    "title": "エンドポイントでマルウェアを検出",
    "severity": "medium",
    "status": "new",
    "createdDateTime": "2026-07-03T18:20:00Z"
  }'

成功したリクエストは HTTP 202 Accepted を返します:

{ "success": true, "processed": 1, "failed": 0 }

処理パイプライン

取り込みプロキシ

/api/v1/ingest/defender はソースを検証し、リクエストを取り込みサービス (POST /v1/sources/defender) に転送します。

キューへの発行

取り込みサービスは API キーを認証し、ペイロードを検証して、各アラートを処理キューに発行します。

正規化

Defender プロセッサは各レコードを CaseBender アラートに正規化します。重大度のマッピング、タイトル/説明の構築、オブザーバブルとデバイスアセットの抽出、MITRE TTP の生成を行います。

データマッピングリファレンス

重大度マッピング (Defender → CaseBender 1–4):

Defender の重大度	CaseBender の重大度
`high`	1
`medium`	2
`low`	3
`informational`	4
`unknown`	3

オブザーバブル抽出 (evidence[] から):

エビデンスフィールド	オブザーバブルタイプ
`ipAddress`	`ip`
`url`	`url`
`sha256`	`hash`
`fileName`	`filename`
`deviceDnsName`	`hostname`
`userAccount`	`user` (`DOMAIN\account`)

取り込み時に適用されるタグには、defender、xdr、service:<serviceSource>、 category:<category>、incident (インシデントの場合)、および MITRE テクニックごとに 1 つの mitre:<technique> タグが含まれます。取り込まれたレコードはデフォルトで TLP:2 と PAP:2 になります。

アウトバウンド: ケースのディスポジションを Defender に同期

CaseBender でケースがクローズされると、case_closed イベントが Defender ハンドラーにディスパッチされます。ケースが Defender のアラートまたはインシデントにリンクされている場合、 CaseBender は Graph セキュリティ API を通じて解決を送信します。

リンクされた Defender エンティティの解決方法

ハンドラーは次の順序で Defender 識別子を検索します:

extraData.defenderAlertId / extraData.defenderIncidentId
extraData.source === "defender" の場合の sourceRef
Defender アラート参照のように見える場合の sourceRef (プレフィックス da)

アラートまたはインシデント ID が見つからない場合、この統合ではケースクローズがスキップされます。

解決 → 分類のマッピング

CaseBender の解決	Defender の分類
`TruePositive`	`truePositive`
`FalsePositive`	`falsePositive`
`Duplicate`	`informationalExpectedActivity`
`NoImpact`	`informationalExpectedActivity`
(その他 / なし)	`truePositive` (デフォルト)

クローズ時、CaseBender はアラート/インシデントの status を resolved に設定し、マッピングされた classification を適用して、次のようなコメントを追加します:

Case <ケース ID> closed in CaseBender with resolution: <解決>

アウトバウンドのアラート更新には closeAlertsOnCaseClose の有効化が必要です。インシデント更新には closeIncidentsOnCaseClose が必要です。どちらも有効になっていない場合、アウトバウンド同期は行われません。

セキュリティに関する考慮事項

シークレットの取り扱い — クライアントシークレットは統合設定に保存されます。組織が要求するスケジュールでローテーションし、その際に統合を更新してください。
最小権限 — SecurityAlert.ReadWrite.All と SecurityIncident.ReadWrite.All のみを付与します。より広範な Graph スコープを追加しないでください。
トークンキャッシュ — アクセストークンは統合ごとにメモリ内にキャッシュされ、有効期限の 1 分前に更新されます。トークンはディスクに永続化されません。
Webhook キー — cbr_defender_ API キーはシークレットとして扱ってください。公開された場合はローテーションし、送信者の構成を更新します。
ネットワーク — 送信を login.microsoftonline.com と graph.microsoft.com に制限します。

トラブルシューティング

接続テストが OAuth2 エラーで失敗する

tenantId、clientId、clientSecret を確認します。クライアントシークレットが期限切れでなく、Graph アプリケーション権限に対して管理者の同意が付与されていることを確認します。

取り込みが 401 Unauthorized を返す

x-api-key ヘッダーが欠落しているか無効です。統合の構成済み Webhook API キーと一致する cbr_defender_ キーを送信していることを確認します。

取り込みが 400 'No alerts in payload' を返す

ペイロードに value[] 配列もトップレベルの id もありませんでした。Graph バッチオブジェクトまたは単一アラートオブジェクトを送信します。

ケースのクローズが Defender を更新しない

closeAlertsOnCaseClose / closeIncidentsOnCaseClose が有効で、ケースに Defender のアラート/インシデント ID (extraData または sourceRef 経由) があることを確認します。

アウトバウンド更新が 403 を返す

Azure AD アプリに書き込み権限がありません。SecurityAlert.ReadWrite.All と SecurityIncident.ReadWrite.All が管理者の同意とともに付与されていることを確認します。

​概要

インバウンド取り込み

アウトバウンド同期

​機能

​前提条件

​パート A — Azure AD アプリケーションを登録する

​パート B — CaseBender で統合を構成する

​インバウンド: Defender アラートとインシデントの取り込み

​エンドポイント

​ペイロード形式

​処理パイプライン

​データマッピングリファレンス

​アウトバウンド: ケースのディスポジションを Defender に同期

​リンクされた Defender エンティティの解決方法

​解決 → 分類のマッピング

​セキュリティに関する考慮事項

​トラブルシューティング

​関連ドキュメント

概要

機能

前提条件

パート A — Azure AD アプリケーションを登録する

パート B — CaseBender で統合を構成する

インバウンド: Defender アラートとインシデントの取り込み

エンドポイント

ペイロード形式

処理パイプライン

データマッピングリファレンス

アウトバウンド: ケースのディスポジションを Defender に同期

リンクされた Defender エンティティの解決方法

解決 → 分類のマッピング

セキュリティに関する考慮事項

トラブルシューティング

関連ドキュメント