9 MITRE ATT&CKにマッピングされたKQL検出ルール（Microsoft Sentinel + Defender XDRのライブ環境：コントロールプレーン、エンドポイント、アイデンティティ）、PRゲート式Detection-as-Codeパイプライン（GitHub Actions、OIDC）、SOARプレイブック、およびSOC 2コントロールマッピング。

クイックスタート

フォーク上で検出単体テストを実行、Azureは不要です。 各ルールの実際のKQLは、ローカルのKustoエミュレータ内の合成フィクスチャに対して実行されるため、テナントなしで検出ロジックを検証できます。

これはCIがすべてのプルリクエストで実行する正確なチェックです（detection-tests）。各ルールが悪意のあるフィクスチャで発火し、良性のフィクスチャでは沈黙することをアサートします。validation/の実際のハーネスはさらに進んで、テナントで実際の良性および攻撃バッチを駆動し、真陽性と誤発火を測定しますが、これには独自のAzureサブスクリプションとaz loginが必要です（validation/READMEを参照）。そのため「ローカル」ではありません。デプロイメントパイプライン：docs/03。ルールの貢献：CONTRIBUTING。

なぜこれが存在するのか

検出は、それが発火することを示せて初めて信頼性があります。このリポジトリは、Azureコントロールプレーン、エンドポイント、IDの3つのプレーンにわたってそのループを閉じます。ルールロジック、制御されたトリガー、生成されたインシデント、調査、MITREマッピング。単一イベントルールを超えて、マルチステージ相関（grant then deploy）と、Azure Resource Graphの姿勢を変更イベントに結合するコンテンツ認識ルールを備えています。合成サンプルではなく、実際のテレメトリに対するSentinel分析ルール、KQL、インシデント対応です。

Detection-as-Code

ルールはポータルでクリックして作成されるわけではありません。これらはバージョン管理されたYAMLであり、PRゲートパイプラインでデプロイされます。検出を編集するにはプルリクエストを開きます。CIが検証し、レビュアーが承認し、mainへのマージがOIDC（保存されたシークレットなし）を使用して、ルールGUID（API 2025-09-01）によって冪等にSentinelにデプロイされます。

• ソースオブトゥルース：detections/rules/*.yaml · パイプライン：.github/workflows/deploy-detections.yml · デプロイヤー/バリデーター：cicd/ · 詳細：docs/03-cicd.md

実際の変更がこれを通過しました：PR #1 はDET-001のしきい値（10から8に）を厳格化しました。CIが検証し、マージが実際のsc200-wsルールにデプロイされました。ルールがレビューされたPRによってgitから自動的にデプロイされるこのステップが、検出エンジニアとコースを修了したアナリストを区別します。

アーキテクチャ

検出カタログ

結果

各検出は、制御された自己元に戻す管理アクションでトリガーされ、実際のインシデントを生成しました。

ワークスペースの現在の運用状態：10の分析ルールが有効、4つのアクティブなデータコネクタ、1つの自動化ルール、ライブデータフロー。有効な10ルールは、このカタログの9つのカスタム[DET]スケジュールルールと、Microsoftの組み込みFusionルール（Advanced Multistage Attack Detection、デフォルトでオン、ここでは作成されていません）です。このREADMEの他の場所にある9つの数字はカスタムルールのみをカウントしています。

5つのインシデントが完全な調査として文書化されています。

• INV-01, 大量リソース削除 (High)
• INV-02, RBAC特権昇格
• INV-03, LSASS資格情報アクセス (High)、エンドポイント、インシデント #65
• INV-04, NSGがAnyからのインバウンドを開放 (High)、ARGコンテンツ相関 (DET-009)
• INV-05, 特権付与後のデプロイメント (High)、マルチステージ相関 (DET-007)

1回限りのトリガーを超えて、検証ハーネスがテナントで実際の良性 + 攻撃バッチを駆動し、各ルールのKQLをそれに対して実行するため、誤検知は仮定ではなく測定されます。最新の実行（結果）：5/5の攻撃シナリオが発火（DET-002/003/004/007/009）、良性ストリームでは0の誤発火（許可リスト所有者のデプロイ、しきい値未満の削除、grantなしのデプロイ）。本番ボリュームを偽装するのではなく、「N=1で0% FP」を測定された「実際の良性バッチでの0誤発火」に変換します。

ATT&CKカバレッジ

明示的なギャップがあるカバレッジマップは、ルールのリストよりも正直です。ATT&CK Navigatorレイヤー（読み込み方）は両方を示しています。

ギャップは静的なテキストではありません。それぞれが実際のdetection-gap issueであるため、ロードマップはクリック可能なバックログです。

なぜこれらのルールであり、他ではないのか： docs/08、検出戦略と脅威モデルは、カタログをクラウドキルチェーンにマッピングし、ギャップをリスクランク付けします。ルールの調整方法： docs/09、測定されたDET-005調整ループは、ルールを「すべての書き込みで発火」から、検証ハーネスで測定された誤検知ゼロに導きます。

自動応答（SOAR）

最も重大度の高い検出は、検出から応答までのループを閉じます。Sentinel自動化ルールは、DET-004（大量削除）インシデントごとにLogic Appプレイブックを実行します。推奨される封じ込め（呼び出し元の無効化、リソースグループのロック、復元、ハンティング）を含む強化コメントを投稿します。プレイブックは、独自のマネージドIDを使用してARM APIに対して直接認証し、シークレットや外部コネクタは不要です。

2番目のプレイブックは、Microsoft Security Copilotを使用して検出→応答→AI調査のループを拡張します。同じDET-004インシデントで、プロンプトブック + Logic AppがCopilotプロンプトブックを呼び出し、AI調査サマリーをコメントとして投稿します。これはコンピューティングユニットなしで構築およびデプロイされます。実際のAIサマリーキャプチャは単一のコスト制限（約$4）の有料ウィンドウで実行され、キャプチャされるまで請求されません。コストと破棄のランブック：docs/06。

エンドポイントと脆弱性管理

検出はAzureコントロールプレーンから始まります。このフェーズではエンドポイントプレーンを追加します。Windowsホスト上のDefender for Endpointセンサーが同じワークスペースにフィードするため、Detection-as-Codeパイプラインはコントロールプレーンルールと並んでエンドポイントルールDET-006 LSASS資格情報アクセスをデプロイします。DET-006はマルチソースで証拠があります。3つの資格情報ダンプ手法がセンサーに対して実行され、強化されたホスト（LSASS RunAsPPL、AMSI、動作保護）がそれぞれを防止し、結果としてDefenderアラートでルールが発火してインシデントが発生しました（INV-03）。Defender Vulnerability Managementは2番目の入力を追加します。露出したソフトウェア、失敗したセキュリティ構成基準、アクティブなアラート下の脆弱な資産によって重要なCVEを表面化するハンティングライブラリです。DeviceTvm*テーブルはDefenderの高度なハンティングにのみ存在するため、それらの相関はハンツであり、デプロイされたルールではありません。リポジトリは各クエリが実際にどこで実行されるかを示します。アーキテクチャとデータフロー：docs/07。

ポスチャー修復

検出は攻撃を監視します。このフェーズでは、テナント自身のポスチャースコアを読み取り、それがフラグを立てたものを修正し、数値が動いたことを証明します。Defender for Cloudのセキュアスコアベースラインは、collect-posture.ps1によって機械可読スナップショットとして取得されます。そのため、before/afterはスクリーンショット比較ではなく、ファイル差分です。ベースラインでのスコアは68.81%（21.33 / 31）であり、コントロール別の内訳は、9.67ポイントのギャップ全体が4つのコントロール（保存時の暗号化、アクセスと権限、ネットワークアクセス、監査）にあることを示しています。修復は爆風半径順に並べられ、最初に追加的な修正が行われ、各項目はその回帰を捕捉するカタログルールにマッピングされています（ストレージ露出→DET-002 / DET-009、RBAC拡散→DET-003 / DET-007、ログ損失→カタログ全体）。このパスでは3つの修正が適用され、リソースレベルで検証されました。セキュリティ連絡先とアラート通知、両方のSOARプレイブックの診断ログ（+1監査）、センサーVMのホストでの暗号化（+4保存時の暗号化）。Defender for Cloudは次の24〜72時間で再評価してスコアを再計算するため、アフタースコアは今すぐ主張するのではなく、フォローアップとして文書化されます。完全な方法、順序付けられた計画、検出リンクテーブル：docs/10、ポスチャー修復。

SOC 2コントロールマッピング

この作業は認識されたコントロールフレームワークをサポートするため、リポジトリはその場所を示します。カタログの各部分はSOC 2 Trust Services Criterionにマッピングされます。9ルールカタログとインシデントは監視および対応シリーズ（CC7.2〜CC7.4）に、SOARプレイブックはインシデント対応（CC7.4）に、PRゲートのDetection-as-Codeパイプラインは変更管理（CC8.1）に、検証ハーネスとポスチャーのbefore/afterはコントロール運用効果（CC4.1）にマッピングされます。これはコンプライアンス主張ではなくマッピングとして構成されています。これは私が運用する1つのテナントであり、監査された組織ではないため、ドキュメントは技術的コントロール活動をマッピングし、実際のSOC 2レポートに必要なガバナンスラッパー（検出リポジトリは持たない）について明示します。基準ごとの完全なテーブルと「監査でどう読まれるか」の注記：docs/11、SOC 2コントロールマッピング。

リポジトリレイアウト

実証されたスキル

KQL · Microsoft Sentinelスケジュール分析ルール · マルチステージ相関ルール · Entra ID ID検出（SigninLogs） · 許可リストウォッチリスト（_GetWatchlist） · Azure Resource Graphポスチャー・アズ・コンテンツ（スケジュールアクション） · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · 高度なハンティング（Device / DeviceTvmテーブル） · Microsoft Secure Score · Defender for Cloudポスチャー修復（CSPM, MCSB） · SOC 2共通基準コントロールマッピング · Detection-as-Code (GitHub Actions, OIDC) · SOAR (Logic Apps自動化ルール) · Sigma (ベンダーニュートラル) · Atomic Red Team検証 · インシデントトリアージと調査 · MITRE ATT&CKマッピング · Azureコントロールプレーン（アクティビティログ）監視。

貢献

これは個人のポートフォリオですが、検出の変更がポータルクリックではなくレビュー可能なプルリクエストになるように構造化されています。フォークするかルールを提案したい場合、CONTRIBUTING.mdがワークフローをカバーしています。ルールYAMLを編集し、KQLミラーを再生成し、テストフィクスチャを拡張し、ローカルで単体テストを実行し、同じCIゲートがチェックするPRを開きます。

資格

Microsoft認定: Security Operations Analyst Associate (SC-200)。

免責事項

私が運用する環境であり、雇用主やサードパーティの本番テナントではありません。検出は、自分のリソースに対する制御された自己元に戻す管理アクションで検証されています。本番システムやサードパーティは関与していません。すべてのスクリーンショットで、テナントID、サブスクリプションID、PIIは編集されています。

ライセンス

MIT