ルールの再生と MTTD について

以下でサポートされています。

このドキュメントでは、ルール再生（クリーンアップ実行または調整実行とも呼ばれます）で遅延して到着したデータとコンテキストの更新を処理する方法と、これらの再生が検出までの平均時間（MTTD）指標に与える影響について説明します。

ルールの再生

Google Security Operations は、大量のセキュリティ データを処理します。コンテキスト データまたは相関データに依存するルールの検出を正確に行うため、ルールエンジンはルール再生プロセスを自動的に実行します。

ルール再生プロセスは、次のカテゴリのルールを処理します。

  • 単一イベントルール: これらのルールは、UDM 拡充プロセスで以前に評価されたイベントが更新されると再生されます。データテーブルを含むルールに関する例外については、このドキュメントの後半のデータが遅れて到着するシナリオをご覧ください。

  • ウィンドウ化された単一イベント（WSE）ルールとデータテーブルを含む単一イベント ルール: これらのルールには、標準の単一イベント ルールとマルチイベント ルールとは異なる、遅延到着データを処理するための独自のスケジューリング メカニズムがあります。

  • マルチイベント ルール: これらのルールはスケジュールに従って実行され、イベント時間のブロックを処理します。同じ時間ブロックを異なる間隔で繰り返し再評価し、ユーザーまたはアセットのコンテキスト データやセキュリティ侵害インジケーター（IOC）のマッチングなど、遅延したエンリッチメントの更新をキャプチャします。正確なタイミングは、スケジュール構成によって異なります。

ルールの再生トリガー

システムは、初期ルールの実行後にデータが到着または更新された場合でも、検出を確実にキャッチできるように、ルールを再評価（再実行）します。この遅延データには、次のカテゴリが含まれます。

  • 遅延して到着したソースイベント: 生ログまたは UDM イベント自体が、イベントの実際のタイムスタンプよりも大幅に遅れて Google SecOps に到着します。
  • 遅延して到着したエンリッチメント データ: イベントに関連するコンテキスト データ（ユーザー、アセット、脅威インテリジェンスなど）が利用可能になるか、システムがイベントを最初に処理した後に更新されます。これは、エンティティ コンテキスト グラフ（ECG）などのエンリッチメント パイプラインがデータをバッチで処理したり、外部データソースに依存したりすることが原因で発生することがよくあります。
  • 遡及的な UDM 拡充の更新: 遅れて到着したソースデータ（DHCP レコードのホスト名の更新など）により、UDM イベント フィールドが変更されます。$udm.event.principal.hostname などの検出ロジックでエイリアス フィールド（拡充されたフィールド）を使用するルールは、ソースデータが遅延した場合に再生をトリガーできます。この遅延到着により、これらのフィールド値が遡及的に更新されます。

システムは、ルールの種類と遅延データの性質に応じて、ルールの再生を異なる方法でトリガーします。目標は、検出の適時性とデータの完全性のバランスをとることです。

ルールタイプ別の遅延データの処理方法

ルールの種類とその構成によって、遅延データがルールの再評価をトリガーできる時間枠が決まります。

  • 単一イベントルール（一致ウィンドウまたはデータテーブルなし）:

    • 遅延ソースイベント: 通常、これらのルールは、システムに到着したときのタイムスタンプの古さに関係なく、イベントを処理します。システムは、遅延したソースイベントの初期処理に厳格なカットオフ ウィンドウを適用しません。
    • 遅延拡充: 以前に評価されたイベントの拡充データが到着した場合、または更新が発生した場合、システムは新しいコンテキストでイベントに対してこれらのシングル イベント ルールを再評価します。これは、最初のイベントから数時間後、または数日後に発生することがあります。

  • ウィンドウ化された単一イベント（WSE）ルールとデータテーブルを含む単一イベントルール:

    • これらのルールは、他のシングル イベント ルールやマルチイベント ルールの調整スケジュールと同じ遅延データ処理に従いません。
    • 次のような動作をします。
      • カットオフ: これらのルールでは、イベントのタイムスタンプから 7 日以上経過してから取り込まれたイベントは処理されません。
      • 遅延データ（7 日未満）: システムは、7 日未満の遅延で到着したイベントを処理しますが、レイテンシが高くなる可能性があります。
      • 受信遅延のソースイベント: イベントのタイムスタンプから 7 日以上経過してからデータが Google SecOps に届いた場合、WSE ルールはイベントを処理しません。
      • コンテキストの更新: イベントのコンテキストが遅れて到着した場合や、イベントが遡及的に拡充された場合、システムは拡充されたイベントに対してルールを自動的に再評価します。このルールの再生により、最初の評価で検出されなかった場合でも、新しい検出がトリガーされる可能性があります。
      • 遅延エンリッチメント: エンリッチメントによって UDM イベントが更新された場合（取り込み後 7 日以内）、システムは更新されたイベントに対してこれらのルールを再評価します。ただし、他のルールタイプとは異なり、データテーブルのコンテンツを更新しても、これらのルールで過去のイベントが自動的に再評価されることはありません。
      • ルックバック ウィンドウ: これらのルールでは、約 7 日間のルックバック ウィンドウを使用してイベントを再評価します。この 7 日間の期間内に発生したイベントの拡充データが到着すると、ルールが再評価されます。

  • マルチイベント ルール:

    • マルチイベント ルールはスケジュールに従って実行され、遅延データを考慮して時間ブロックを再評価します。ルールのスケジュールによって、有効なカットオフ ウィンドウが決まります。
      • プライマリ実行: システムは、イベント時刻に設定された決済遅延（T + 1 時間など）を加えて最初の評価を実行します。
      • 調整実行 1: システムは、プライマリ実行の約 4 時間後に最初の調整実行を行います。これにより、システムで遅れて到着したイベントを含めることができます。
      • 調整実行 2（条件付き）: [エンリッチメントの完全性を確保する] をオンにすると、プライマリ実行から約 30 時間後に最終調整実行が実行されます。これにより、システムが遅れて到着したデータとコンテキストの拡充を処理するウィンドウが約 30 時間延長されます。
      • カットオフの影響: 最終的な調整実行によって、遅延データを含めるための有効なカットオフが決定されます。通常、プライマリ実行の約 4 時間後（エンリッチメントの完全性を確保するを有効にしている場合はプライマリ実行の約 30 時間後）に発生します。特定の期間の最終調整実行後に到着したイベントまたはエンリッチメントは、その期間のこのルールによって処理されません。

受信遅延データのシナリオの例

  • シナリオ 1: 遅延したソースイベント - 単一イベントルール

    • Google SecOps は、3 日前のタイムスタンプを含むイベントを取り込みます。標準のシングル イベント ルールは、このイベントを新しいデータとして処理します。

  • シナリオ 2: 遅延エンリッチメント - 単一イベント ルール

    • システムは昨日ログイン イベントを処理しました。現在、この機能は、関連するユーザーの新しい情報（部署の変更など）を取り込んで拡充します。システムは、更新されたユーザー コンテキストを使用してログイン イベントに対して単一イベント ルールを再評価します。

  • シナリオ 3: 遅延したソースイベント - マルチイベント ルール（デフォルトの 4 時間の調整）

    • デフォルト設定でスケジュール設定されたマルチイベント ルールの場合、イベントはイベント タイムスタンプの 3 時間後に到着します。イベントは最初のプライマリ実行（T + 1 時間）を逃しましたが、システムは 4 時間の調整実行中にイベントを処理します。

  • シナリオ 4: 遅延したソースイベント - マルチイベント ルール（エンリッチメントの完全性なし）

    • エンリッチメントの完全性を確保するを有効にせずに、プライマリ実行オフセットが 1 時間のマルチイベント ルールを構成します。イベントはタイムスタンプの 6 時間後に到着します。
    • このイベントでは、プライマリ実行（T + 1 時間）と最初の調整実行（T + 4 時間）が欠落しています。このイベントは、最終的な調整実行後に到着したため、その時間枠では処理されません。

  • シナリオ 5: 遅延エンリッチメント - マルチイベント ルール（エンリッチメントの完全性あり）

    • マルチイベント ルールのオフセットが 1 時間で、[拡充の完全性を確保する] を有効にしている。イベントのエンリッチメント データは、イベントのタイムスタンプから 28 時間後に到着します。
    • システムは、約 T + 31 時間の 2 回目の調整実行時に、この遅延エンリッチメントを使用してルールを再評価します。

  • シナリオ 6: 遅延したソースイベント - 一致ウィンドウを含むマルチイベント ルール

    • マルチイベント ルールには、48 時間の match ウィンドウと、[Ensure enrichment completeness] が有効になっているスケジュールがあります（最終的な調整は T + 30 時間前後）。イベントはタイムスタンプの 36 時間後に到着します。このイベントは、イベント時刻が他のイベントに対するルールの照合期間内であっても、最終的な調整実行後に到着したため、処理されません。カットオフは、照合期間だけでなく、調整スケジュールに対する到着時間に基づいています。

  • シナリオ 7: 遅延したソースイベント - ウィンドウ化された単一イベントルール

    • 8 日前のタイムスタンプを持つソースイベントが遅れて到着した場合、WSE ルールの 7 日間のルックバック ウィンドウの範囲外になる可能性があり、処理されないことがあります。

タイミング指標への影響

ルール再生の結果として検出が行われた場合、システムでは次の用語が使用されます。

  • アラートの [検出ウィンドウ] または [イベントのタイムスタンプ] は、元の悪意のあるアクティビティの時刻を示します。
  • [作成日時] は、システムが検出を作成した時刻です。これは、検出が実際に発生した時刻よりも大幅に遅れることがあります（数時間または数日後になることもあります）。
  • 検出レイテンシは、イベントのタイムスタンプと検出の作成時間の差です。

タイムラインの差分と MTTD

最初のイベントのタイムスタンプと検出の作成の間の経過時間は、MTTD の計算に直接影響します。

パイプライン / スケジュールのステージ 評価のタイミング MTTD 測定への影響
単一イベントルール（ストリーミング） 継続的（到着後 5 分以内） リアルタイム検出は、MTTD への影響を最小限に抑えながら、プラットフォームの真の速度を表します。
マルチイベント ルール（プライマリ実行） 到着後 1 ～ 2 時間（+ 構成された決済遅延） マルチイベントの関連付け状態を集計するために必要な、回避できないバッチ バッファリング ウィンドウが含まれます。
マルチイベント ルール（調整実行） プライマリ実行の 4 時間後または 30 時間後 遅延した拡充データを取り込んだセカンダリ（再生）実行により、この時間がイベントのタイムスタンプよりも遅れて表示されます。この差分は MTTD の計算に悪影響を及ぼします。

MTTD の測定に関するベスト プラクティス

MTTD は、最初の侵害から脅威の効果的な検出までの時間を定量化します。ルールの再生によってトリガーされた検出を分析する場合は、次のベスト プラクティスを適用して、正確な MTTD 指標を維持します。

Google SecOps には、MTTD を正確に測定するためにユーザーがクエリできる指標がいくつか用意されています。これらの指標の詳細については、ダッシュボード ページの YARA-L 2.0 クエリの例をご覧ください。

[検出タイプ] 列の アイコンは、30 分以上遅れて到着したイベントデータ、自動化された調整実行、再処理パイプライン、レトロハントから生成された検出を示します。このアイコンは、Google SecOps の [アラート] ページにも表示されます。

リアルタイム検出システムの優先順位付け

検出を高速化するには、単一イベント ルールを使用します。これらのルールは準リアルタイムで実行され、通常は 5 分未満の遅延で実行されます。これにより、複合検出のより包括的な使用もサポートされます。

マルチイベント ルールでルールの再生を考慮する

マルチイベント ルールは、スケジュールされた実行頻度により、本質的にレイテンシが高くなります。マルチイベント ルールからの検出の MTTD を測定する場合は、自動化ルール再生によってカバレッジと精度が向上することを認識してください。これらの再生では、遅延コンテキストを必要とする脅威が検出されることが多く、これらの検出の報告されたレイテンシが増加します。

  • クリティカルで時間的制約のあるアラートの場合: 実行頻度を可能な限り短くした単一イベントルールまたはマルチイベントルールを使用します。一致ウィンドウを短縮しても、レイテンシに直接影響することはありませんが、最小遅延を設定することで効率を高めることができます。

  • 複雑で長時間の関連付け（UEBA、マルチステージ攻撃）の場合: これらのルールは、広範なコンテキスト結合または参照リストに依存しており、非同期で更新される可能性があります。コンテキスト データやイベントデータの到着が遅れると、レイテンシが高くなる可能性がありますが、絶対的な速度よりも再現性優先の検出というメリットがあります。

ルールを最適化して、遅延エンリッチメントへの依存を減らす

検出速度を最適化し、遡及的エンリッチメント実行の影響を最小限に抑えるには、可能な限り、ルールロジックでエイリアスなしのフィールド（ダウンストリーム エンリッチメント パイプラインで処理されないフィールド）の使用を検討してください。

次のステップ

関連するスケジューリングのコンセプトと構成ワークフローについては、次のドキュメントをご覧ください。

さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。