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

Microsoft Sentinel ではさまざまなソースからデータを取り込む場合ができますが、状況によって各データ ソースのインジェスト時間が異なる可能性があります。

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

遅延が重大な理由

たとえば、カスタム検出ルールを作成し、 [クエリの実行間隔] および [Lookup data from last](データを最後から検索) フィールドを、ルールが 5 分ごとに実行され、その最後の 5 分間からデータを検索するように設定できます。

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

[Lookup data from last](データを最後から検索) フィールドには、"ルックバック" 期間と呼ばれる設定を定義します。 遅延がない場合は、次の図に示すように、この検出で見逃されるイベントがないことが理想的です。

5 分間のルックバック枠が表示されている図。

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

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

5 分間のルックバック枠と 2 分の遅延が示されている図。

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

遅延を処理する方法

注意

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

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

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

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

  • ルックバック期間を長くする。 基本的な直感では、ルックバック期間のサイズを大きくすればよさそうです。 ルックバック期間は 5 分、遅延は 2 分なので、ルックバック期間を 7 分に設定すると、この問題に対処できるようになります。 たとえば、ルール設定で、次のように設定します。

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

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

    7 分間のルックバック枠と 2 分の遅延が示されている図。

  • 重複を処理する。 ルックバック期間を単に長くするだけでは、ルックバック枠が重なることになるため、重複が生じる可能性があります。 たとえば、次の図に示すように、別のイベントが表示される可能性があります。

    ルックバック枠が重なっているために重複が作成されている図。

    イベント TimeGenerated 値が両方のルックバック期間で見つかるため、このイベントから 2 つのアラートが発生します。 この重複を解決する方法を見つける必要があります。

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

    これを行うには、元のルール look-back = 5m の代わりに、ingestion_time() > ago(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)

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

既定では、Microsoft Sentinel のスケジュールされたアラート ルールには、5 分間のルックバック期間が構成されています。 しかしながら、各データ ソースで、独自の個別のインジェストの遅延が発生する場合があります。 複数のデータ型を結合する場合、ルックバック期間を正しく構成するには、データ型ごとに異なる遅延を把握する必要があります。

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

次に例を示します。

ワークスペース使用状況レポートにテーブル別のエンドツーエンドの待機時間が示されているスクリーンショット

次のステップ

詳細については、次を参照してください。