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

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

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

ルールの再生

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

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

  • 単一イベントルール: 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 日間の期間内のイベントに対して拡充データが到着すると、ルールが再評価されます。

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

    • マルチイベント ルールはスケジュールに従って実行され、遅延したデータを考慮して時間ブロックを再評価します。ルールのスケジュールをどのように構成するかによって、有効なカットオフ ウィンドウが決まります。
      • デフォルトのスケジュール: 通常、システムはイベント時刻の約 5 時間後と 24 時間後に自動調整を実行します。24 時間の実行が完了した後にデータが到着した場合、その時間枠ではこのルールで評価されません。
      • カスタマイズ可能なスケジュールが有効: この機能を使用すると、[実行頻度] の設定で実行タイミングをより詳細に制御できます。ルールのカスタム スケジュールを構成するをご覧ください。主なタイミングは次のとおりです。
        • 初回実行: システムは、イベント時刻に構成されたオフセット（たとえば、T + 1 時間）を加えた時刻に初回実行を行います。
        • True-up 実行 1: システムは、初回実行から約 4 時間後に最初の True-up 実行を行います。つまり、システムには T + 4 ～ 5 時間程度までのイベントを含めることができます。
        • 調整実行 2（条件付き）: [エンリッチメントの完全性を確保する] をオンにすると、初回実行から約 30 時間後に最終調整実行が実行されます。これにより、システムが遅延データを処理するウィンドウが T + 30 ～ 31 時間程度に延長されます。
      • カットオフの影響: スケジュールをカスタマイズすると、最後の調整実行によって、遅延データを含める有効なカットオフが決定されます。通常、初回実行から約 4 時間後、または [エンリッチメントの完全性を確保する] を有効にした場合は初回実行から約 30 時間後に発生します。特定の時間枠の最終調整実行後に到着したイベントまたはエンリッチメントは、その時間枠のこのルールによって処理されません。

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

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

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

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

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

  • シナリオ 3: 遅延したソースイベント - 複数イベント ルール（デフォルトのスケジュール）

    • イベントがイベント タイムスタンプの 10 時間後に到着した場合、システムは 5 時間の調整実行中にイベントを見逃しますが、24 時間の調整実行中にイベントを処理します。25 時間遅れて到着したイベントは処理されません。

  • シナリオ 4: 遅延したソースイベント - 複数イベント ルール（カスタマイズ可能なスケジュール）

    • 初回実行オフセットが 1 時間のマルチイベント ルールを構成します。イベントはタイムスタンプの 6 時間後に到着します。
    • このイベントでは、初回実行（T + 1 時間）と最初の調整実行（T + 4 時間）が欠落しています。[拡充の完全性を確保する] を有効にしない限り、システムはこのルールでこのイベントを処理しません。

  • シナリオ 5: 遅延エンリッチメント - 複数イベント ルール（エンリッチメントの完全性でカスタマイズ可能）

    • マルチイベント ルールのオフセットが 1 時間で、[Ensure enrichment completeness] を有効にしている。イベントのエンリッチメント データは、イベントのタイムスタンプから 28 時間後に到着します。
    • この遅延したエンリッチメント データの一部は、T + 30 時間前後に行われる 2 回目の「調整実行」で使用できる可能性があります（エンリッチメントの完全性を確保するを有効にしているため）。エンリッチメント データが利用可能な場合、システムはこの遅延エンリッチメントを使用してルールを再評価します。

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

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

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

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

タイミング指標への影響

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

  • アラートの [検出ウィンドウ] または [イベントのタイムスタンプ] は、元の悪意のあるアクティビティの時刻を示します。
  • 作成日時は、システムが検出結果を作成した日時です。これは、数時間または数日遅れることがあります。
  • 検出レイテンシは、イベントのタイムスタンプと検出の作成時間の差です。

通常、検出の遅延が大きくなるのは、データの遅延による再エンリッチメントや、エンティティ コンテキスト グラフ（ECG）などのコンテキスト ソースの更新によるレイテンシが原因です。

この時間差により、検出が「遅い」または「遅延している」ように見えることがあります。これにより、アナリストが混乱し、MTTD などのパフォーマンス指標が歪められる可能性があります。

指標コンポーネント 時間のソース リプレイが MTTD に与える影響
検出ウィンドウ / イベントのタイムスタンプ 元のセキュリティ イベントが発生した時刻。 リプレイでは、イベント時間に合わせて正確に再生されます。
検出日時 / 作成日時 エンジンが実際に検出を出力した時刻。 遅延エンリッチメント データを取り込んだセカンダリ（再生）実行により、この時間がイベントのタイムスタンプよりも遅れて表示されます。この差分は MTTD の計算に悪影響を及ぼします。

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

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

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

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

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

検出を高速化するには、単一イベント ルールを使用します。これらのルールはほぼリアルタイムで実行され、通常は 5 分未満の遅延で実行されます。

これにより、複合検出の包括的な使用もサポートされます。

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

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

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

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

ルールを最適化して、遅延エンリッチメントへの依存度を下げる

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

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