スケジュールされた分析ルールでのインジェストの遅延を処理する

重要

カスタム検出は、SIEM Microsoft Defender XDR全体で新しいルールMicrosoft Sentinel作成するための最良の方法になりました。 カスタム検出を使用すると、インジェスト コストを削減し、無制限のリアルタイム検出を取得し、自動エンティティ マッピングを使用してDefender XDRデータ、関数、修復アクションとシームレスに統合できます。 詳細については、カスタム検出が Microsoft Defender XDR で検出を作成するための統合エクスペリエンスになりましたを参照してください。

Microsoft Sentinelは接続されたデータソースからデータを取り込むことができますが、各データソースの取り込み時間は状況によって異なる場合があります。

この記事では、インジェストの遅延がスケジュールされた分析ルールに与える影響と、これらのギャップをカバーするためにそれらを修正する方法について説明します。

遅延が重要な理由

たとえば、カスタム検出ルールを作成し、[ クエリの実行間隔][最後のフィールドのデータの参照 ] を設定して、ルールを 5 分ごとに実行し、過去 5 分間のデータを検索します。

[分析ルール ウィザード - 新しいルールの作成] ウィンドウを示すスクリーンショット。

最後のフィールドのルックアップ データは、ルックバック期間と呼ばれる設定を定義します。 理想的には、遅延がない場合、次の図に示すように、この検出はイベントを見逃しません。

5 分間のルックバック ウィンドウを示す図。

イベントは生成されると到着し、 ルックバック 期間に含まれます。

次に、データ ソースに若干の遅延があるとします。 この例では、イベントが生成されてから 2 分後に取り込まれたとします。 遅延は 2 分です。

5 分間のルックバック ウィンドウを示す図。遅延は 2 分です。

イベントは最初のルックバック期間内に生成されますが、初回実行時にMicrosoft Sentinel ワークスペースに取り込まれません。 次にスケジュールされたクエリを実行すると、イベントが取り込まれますが、5 分以上前に発生したため、時間生成フィルターによってイベントが削除されます。 この場合、 ルールはアラートを生成しません

遅延を処理する方法

スケジュールされた分析ルールのインジェストの遅延を考慮するには、次の方法を使用します。

注:

以下で説明するプロセスを使用して問題を解決するか、Microsoft Sentinelのほぼリアルタイム検出 (NRT) ルールを実装できます。 詳細については、「Microsoft Sentinelでほぼリアルタイム (NRT) 分析ルールを使用して脅威をすばやく検出する」を参照してください。

この問題を解決するには、データ型の遅延を把握する必要があります。 この例では、遅延が 2 分であることが既にわかっています。

独自のデータについては、Kusto ingestion_time() 関数を使用して遅延を理解し、 TimeGenerated とインジェスト時間の差を計算できます。 詳細については、「 インジェスト遅延の計算」を参照してください。

遅延を判断した後、次のように問題に対処できます。

  • ックバック期間を長くする:直感的に、ルックバック期間を長くすると効果的だと感じます。 ルックバック期間は 5 分、遅延は 2 分であるため、ルックバック期間を 7 分に設定すると、この問題に対処するのに役立ちます。 たとえば、ルール設定では次のようになります。

    ルックバック ウィンドウを 7 分に設定しているスクリーンショット。

    次の図は、ルックパック期間に見逃されたイベントがどのように含まれるかを示しています。

    2 分の遅延で 7 分間のルックバック ウィンドウを示す図。

  • * 重複処理: ルックバック期間を増やすと、ルックバック ウィンドウが重複するため、重複が発生する可能性があります。 たとえば、次の図に示すように、別のイベントが表示される場合があります。

    ルックバック ウィンドウが重複して重複を作成する方法を示す図。

    イベント TimeGend 値が両方のルックバック期間で検出されるため、イベントは2つのアラートを発生させます。 重複を解決する方法を見つける必要があります。

  • イベントを特定のルックバック期間に関連付ける:最初の例では、スケジュールされたクエリが実行された時点でデータが取り込まれていなかったためにイベントを見逃しました。 ルックバックを拡張してイベントを含めますが、これにより重複が発生しました。 イベントを含めるために拡張したウィンドウにイベントを関連付ける必要があります。

    これを行うには、元のルールingestion_time() > ago(5m)ではなく、look-back = 5mを設定します。 この設定は、イベントを最初のルックバック ウィンドウに関連付けます。 例:

    ago 制限を設定することで重複を回避する方法を示す図

    インジェスト時間の制限によって、ルックバック期間に追加した余分な 2 分がトリミングされるようになりました。 最初の例では、2 回目の実行のルックバック期間にイベントがキャプチャされるようになります。

    ago 制限を設定することでイベントがキャプチャされる仕組みを示す図。

次のサンプル クエリは、インジェスト遅延の問題を解決するためのソリューションをまとめたものです。

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Kustoのドキュメントで前述の例で使用された以下の項目の詳細をご覧ください:

インジェストの遅延を計算する

デフォルトでは、Microsoft Sentinelのスケジュールされたアラートルールは5分間のリックバック期間に設定されています。 しかし、各データソースには独自のインデンス遅延がある場合があります。 複数のデータ型を結合するときは、ルックバック期間を正しく構成するために、データ型ごとに異なる遅延を理解する必要があります。

すぐに使用できるワークスペース使用状況レポートMicrosoft Sentinel、ワークスペースに流れ込むさまざまなデータ型の待機時間と遅延を示すダッシュボードが含まれています。

例:

テーブル別のエンド ツー エンド待機時間を示すワークスペース使用状況レポートのスクリーンショット