ルールのリプレイと 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 時間後に到着します。
    • システムは、2 回目のトゥルーアップ実行（T + 31 時間）で、この遅延拡充を使用してルールを再評価します。

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

    • マルチイベント ルールには、48 時間の match ウィンドウと、[拡充の完全性を確保する] が有効になっているスケジュール（最後のトゥルーアップは 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 のプロフェッショナルから回答を得ることができます。