mcpField
S
sentinel-detection-engineering

sentinel-detection-engineering

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

sentinel-detection-engineering について

Microsoft Sentinel の検出、ハンティングクエリ、対応自動化の構築と保守を支援するスキルです。KQL の作成と検証、MITRE マッピング、検出のコード管理を扱います。

主な機能

  1. 01KQL 検出ルールの作成
  2. 02分析ルールの選択
  3. 03バックテストと調整
  4. 04MITRE ATT&CK マッピング
  5. 05自動化とプレイブック
  6. 06検出のコード管理

活用シーン

  1. 01エンティティを割り当てた Sentinel ルールの作成
  2. 02過剰な通知とインシデント集約の調整
  3. 03GitHub リポジトリ経由のルール展開
  4. 04未発報の検出ルールの見直しと廃止

インストール

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

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill sentinel-detection-engineering

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

詳細

Sentinel の検出エンジニアリング

Sentinel の検出エンジニアリングとは、高精度で適切に調整され、保守可能な検出と対応の自動化を構築する分野です。このスキルでは、検出のライフサイクル、すなわちコンテンツの取得、作成、検証、自動化、バージョン管理を扱います。より広範な SIEM アーキテクチャは対象外です。

使用する場面

Microsoft Sentinel で分析ルール、ハンティングクエリ、自動化ルール、プレイブックを作成または成熟させる場合に使用します。KQL の検出パターン、MITRE との整合性、コンテンツハブとカスタムコンテンツの選択、検出のコード化の展開に使用します。

このスキルは使用しないでください。Sentinel のオンボーディング／アーキテクチャ（sentinel）、Defender XDR のカスタム検出のみを扱う場合（defender-xdr）、検出に関係のない一般的な KQL の学習には使用しないでください。

コンテンツのソース（次の順に使用）

  1. コンテンツハブのソリューション — Microsoft およびパートナーが公開する、データコネクタ、分析ルール、ハンティングクエリ、ブック、プレイブックをまとめたバージョン管理済みのバンドルです。必ずここから始めてください。ソリューションをインストールし、ルールを Active で有効にします。

  2. Microsoft Sentinel GitHub — まだソリューションに含まれていない、コミュニティ提供のクエリです。精査してから、リポジトリに取り込みます。

  3. カスタム検出 — 独自のデータソースや特定のビジネスロジックに基づいて作成する、ドメイン固有の検出です。

経験則： Microsoft のソリューションでユースケースの 80% をカバーできる場合は、そのソリューションをインストールし、残りの 20% をリポジトリでオーバーライドしてください。ゼロからフォークしないでください。

分析ルールの種類を選択する

ルールの種類使用する場面遅延
スケジュール済みほとんどの場合。KQL の時間枠ベースのルール5 分～24 時間
ニアリアルタイム（NRT）優先度の高い、単一イベントの検出（例：特権ロールの割り当て）1 分未満
Microsoft Security（レガシ）Defender のアラートを Sentinel インシデントとして転送する場合即時
Fusion複数段階の攻撃の相関分析（組み込みの ML）可変
異常行動ベースライン（組み込みの ML）1 時間ごと
脅威インテリジェンスTI インジケーターとログの照合スケジュール

NRT には制約があります（単一のテーブルのみ。ほとんどの参照テーブルとの結合は不可）。選択する前に確認してください。

アプローチ

  1. クエリではなく、ユースケースから始めます。 検出内容を次のように表現します。「<攻撃者の行動>をで<期待する忠実度>で検出する。」 KQL エディターを開く前に、MITRE ATT&CK の手法 ID に対応付けます。

  2. データのカバレッジを確認します。 コネクタは必要なフィールドを出力していますか？ まず take 100 を実行してスキーマを確認し、そのテーブルの取り込み遅延もチェックします。

  3. 検出パターンを使って KQL を作成します。

    • 早い段階でフィルターし、投影は後にします。
    • レートベースの検出には summarize と bin(TimeGenerated, 5m) を使います。
    • 結合した中間結果には materialize() を一度だけ使います。
    • 参照データの多いルール（許可リスト、資産の重要度）には、_GetWatchlist("name") を使ってウォッチリストを利用します。
    • 巨大なテーブルでは * 結合を避け、両側を事前にフィルターします。

  4. エンティティをマッピングします。 ルールの UI で User、Host、IP、FileHash、Url のエンティティを設定し、インシデントグラフと調査機能が使えるようにします。エンティティをマッピングしないと、Sentinel のインシデントは平坦なデータの塊になります。

  5. インシデントの作成方法を慎重に設定します。 バースト的な挙動を伴う高ボリュームのルールでは、Group all alerts triggered by this rule into a single incident を使ってアラートを単一のインシデントにグループ化します。「ユーザーごとに 1 インシデント」にする場合は、エンティティごとにグループ化します。

  6. 検証します。 ルールの KQL を過去 7 日間の期間に対して実行します。次の点を確認します。

    • 1 日あたりの平均アラート数 → トリアージ可能である必要があります（重大度が高い場合の目標は <10）。
    • 誤検知のサンプル — 50% が FP なら、調整してから公開します。
    • カバレッジ — 既知の攻撃シナリオで実際に検出されますか？ Attack Simulation Training のログを使うか、エクスポート済みのレッドチームイベントを再生します。

  7. 自動化を接続します。

    • Automation rule（ノーコード）で、割り当て、重大度の調整、抑制期間、一括クローズを行います。
    • Playbook (Logic App) でアクションを実行します。ユーザーの無効化、（Defender for Endpoint を介した）デバイスの隔離、MDTI からの情報補完、Teams/Slack への投稿、ITSM チケットの作成などです。
    • 共有コンテキストを伴う処理には、alert-trigger よりもincident-triggerのプレイブック（インシデントごとに 1 回実行）を使います。

  8. 検出をコードとして管理します。 Repositories 機能を使って、Sentinel を GitHub または Azure DevOps のリポジトリに接続します。信頼できる情報源はリポジトリであり、デプロイはパイプラインで行います。ブランチ保護と PR レビューにより、「誰かがポータルでルールを調整していた」という事態がなくなります。

  9. ライフサイクルを管理します。

    • ルールにバージョン（メタデータ内）と所有者のタグを付けます。
    • 四半期ごとに再検証します。データソースのスキーマ変更により、検出が気づかないうちに機能しなくなることがあります。
    • アラートが継続的にゼロで、FN のカバレッジもないルールは廃止します。

ガードレール

  • 7 日間のバックテストをせずにルールを公開しないでください。 「エディターでは正しく見える」ルールが、本番環境でノイズの嵐を引き起こします。
  • 高ボリュームのテーブル（SecurityEvent、Syslog、CommonSecurityLog）では、早い段階でフィルターします。 テーブル全体のスキャンは LA のコストがかかり、実行も遅くなります。
  • NRT には制限があります。 5 テーブル結合の検出を NRT に無理に適用せず、スケジュール実行を使います。
  • 必ずエンティティをマッピングします。 エンティティがないと、調査グラフもなくなり、アナリストの負担になります。
  • 信頼度の低いルールでユーザーを自動的に無効化しないでください。 SOAR の強力さ × 低い忠実度は、障害につながります。忠実度の高いルールと組み合わせる場合に限ります。
  • ウォッチリストは追記専用のログではありません。 行数に上限があります（条件によって約 10 MB／100 万行）。大規模な参照データには Log Analytics テーブルを使います。
  • Microsoft が公開するルールはソリューションを介して更新されます。 その場で編集してフォークすると、更新を受け取れなくなります。複製して名前を変更するか、リポジトリでオーバーライドします。
  • Defender XDR のカスタム検出と Sentinel のルール — データが存在する場所で作成します。データが XDR にしかなく、トリアージも XDR で行うなら、カスタム検出は XDR で作成し、重複させないでください。

よくあるアンチパターン

  • 「重大度がすべて P2 のルールを 200 個作成した」 — 優先順位付けとして意味がありません。重大度は件数ではなく、ビジネスへの影響と検出精度を反映します。
  • 「5 分間隔のスケジュールルールで where TimeGenerated > ago(90d) を使った」 — コストが膨大になります。ルールの実行間隔に合わせて検索期間を設定してください。
  • 「ポータルだけで検出ルールを作成し、ソース管理を使わなかった」 — 変更履歴、ロールバック、レビューが失われます。
  • 「ノイズの多いルールでアラートをすべてグループ化した」 — 数千件のアラートを含む巨大なインシデントが 1 件作られ、トリアージが不可能になります。
  • 「初日から検出ルールにデバイス隔離プレイブックを設定した」 — 誤検知による障害が発生します。まず SOAR の監査モードを使ってください。
  • 「すべての IOC に対して脅威インテリジェンス照合ルールを実行した」 — 数百万行のログに対して数テラバイト分のインジケーターを照合することになります。インジケーターの種類や信頼度で絞り込み、対象テーブルを限定してください。
  • 「何をするか分かっているから」という理由で MITRE マッピングを省略した」 — カバレッジ分析と関係者への報告が妨げられます。

プロンプトの例

  • 適切なエンティティマッピングを使用して、SigninLogs による不可能な移動を検出する Sentinel のスケジュールルールを作成してください。
  • チューニングとグループ化によって、ノイズの多い検出ルール（1 日平均 800 件のアラート）を実用的な形に変換してください。
  • Teams での承認ステップを含め、Sentinel インシデントに対応して Defender for Endpoint デバイスを隔離するプレイブックを作成してください。
  • PR 経由で GitHub から分析ルールをデプロイするために、Sentinel Repositories を設定してください。
  • 新しく追加された Global Administrator を 1 分以内に検出する NRT ルールを作成してください。
  • カスタム検出ルールを MITRE ATT&CK の手法にマッピングし、カバレッジのギャップを検証してください。
  • エンドポイント全体での環境寄生型バイナリの使用状況を調査するためのハンティング用ワークブックを作成してください。
  • 四半期ごとのコンテンツレビュー：アラートが一度もないルールを特定し、ひそかに機能不全に陥っていないことを検証してから、廃止またはリファクタリングしてください。

Microsoft Learn

コメント

Markdown 対応