ルール検出の遅延について

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

このドキュメントでは、Google Security Operations でのルール検出の遅延について説明します。取り込みパイプラインと処理パイプライン全体で、遅延の原因となる要因を特定し、構造化されたトラブルシューティングのアプローチを概説します。また、検出レイテンシを短縮する手法についても説明します。

検出ルールの概要

検出ルールは、正規化された未加工ログ（通常のイベントとエンティティの統合データモデル（UDM）イベントの両方）を調べて、ルールの仕様に従ってセキュリティ検出を生成します。エンティティ UDM イベントには通常、ユーザーやアセットのメタデータなどのコンテキスト情報が含まれます。検出ルールでは、以前に生成された検出を評価して複合アラートを生成することもできます。

予想される遅延と予想外の遅延

検出レイテンシは、ルールロジック、データの依存関係、システム処理サイクルによって異なります。遅延は次の 2 つのタイプに分類されます。

  • 想定される遅延: 取り込みプロセス、ルールタイプ、実行頻度、検出生成方法、一致ウィンドウの期間、既知のシステム制限などの構造的な要因による遅延。検出ルールの構成とスケジューリング パラメータを調整することで、予想される遅延を最小限に抑えることができます。
  • 予期しない遅延: 外部または動的なパイプライン条件によって発生する遅延。これには、データソースからのログ配信のボトルネック、Google SecOps サービス内の一時的な処理レイテンシ、コンテキストの可用性の遅延、UDM の再拡充サイクルなどがあります。

検出生成方法

Google SecOps は、次の実行パイプラインを介してルール検出を生成します。

  • ストリーミング エンジン: 標準のシングルイベント ルールとウィンドウ化されたシングルイベント ルールを準リアルタイム（通常は取り込みから 5 分以内）で継続的に評価する高速パイプライン。遅れて到着したイベントと遡及的な拡充は、標準実行中に継続的に評価されます。
  • クエリエンジン: 複数のイベントまたは外部データ結合にわたる時間ベースのイベント相関を必要とするルールを評価します。
    • 複雑なシングル イベント ルール: 参照リストまたはデータテーブルをクエリするシングル イベント ルールが含まれます。
    • マルチイベント ルール: 構成されたスケジュールに基づいて、イベント時間のバッチブロック（10 分間隔、1 時間間隔、48 時間を超えるウィンドウの場合は match_window / 10 など）でデータをクエリします。
  • 過去のデータに対して実行されるルール: レトロハントを介して、過去のログに対してルールを遡及的に評価します。過去のスキャンが完了すると、検出結果が表示されます。
  • UDM イベントの再拡充: 過去のイベントに新しいコンテキストまたは更新されたエンティティ データが追加されたときに、以前に処理された時間ブロックを再評価します。

ルール検出の遅延に影響する要因

検出が表示される速度は、ルールの複雑さ、スケジューリング間隔、データの取り込みレイテンシ、コンテキスト拡充パイプラインによって異なります。

ルールのタイプと複雑さ

検出ルールは、レイテンシ プロファイルが異なるいくつかのカテゴリに分類されます。

単一イベントルール

単一イベントルールは、継続的なストリーミング エンジンで準リアルタイムで実行され、検出レイテンシを最小限に抑えます。これらのルールは、外部データセット、データテーブル、マルチイベント一致ウィンドウを結合せずに、個々のイベントを評価します。

複雑な単一イベントルール

これらのルールは単一のイベントを評価しますが、追加のデータの依存関係を組み込みます。

  • ウィンドウ化された単一イベントルール: match セクションを含む単一イベントルール（たとえば、単一イベントが時間枠内で条件に一致するかどうかを評価する）。これらのルールは、データが取り込まれると、継続的なストリーミング エンジンで準リアルタイムで評価されます。
  • 参照単一イベントルール: イベント属性を参照リストまたはデータテーブルと比較する単一イベントルール。

マルチイベント ルール

マルチイベント ルールは、指定された一致ウィンドウで 2 つ以上の UDM イベント条件を関連付け、スケジュールされたバッチ間隔で実行します。

  • 標準のマルチイベント ルール: 複数のイベントを時間枠にわたって集計し、10 分または 1 時間の間隔（48 時間を超える時間枠の場合は match_window / 10）で実行します。
  • コンテキストアウェア ルール: コンテキストアウェア分析を使用して、イベントデータを UDM エンティティ イベント（user_context や asset_context など）に関連付けます。コンテキストアウェア ルールは複数のデータフィードに依存するため、取り込みのタイミングに敏感です。詳しくは、ルールでコンテキストが拡充されたデータを使用するをご覧ください。

ルールの実行頻度

構成された実行頻度によって、クエリエンジンがイベント時間ブロックを評価する頻度が決まります。

  • 準リアルタイム: 単一イベントルール（標準とウィンドウ）の継続評価。
  • 10 分間隔: 一致ウィンドウが 60 分未満のマルチイベント ルールで使用できます。
  • 1 時間の頻度: 一致ウィンドウが 48 時間以下のマルチイベント ルールのデフォルトの間隔。
  • match_window / 10 の頻度: 一致時間枠が 48 時間を超えるマルチイベント ルールに自動的に割り当てられます（たとえば、100 時間の一致時間枠の場合は 10 時間ごと、10 日間の時間枠の場合は 24 時間ごとに実行されます）。

一致ウィンドウの期間

マルチイベント ルールの場合、一致ウィンドウの期間は、イベントの集計に必要なモニタリング期間を定義します。検出は、期間全体が経過するまで表示されません。

ログの取り込み遅延

取り込み遅延とは、ソースでイベントが発生してから Google SecOps がログを受信して解析するまでの経過時間です。

イベントがその時間ブロックの最初のスケジュールされた評価の後に到着した場合、最初の実行には間に合いません。システムは、後続の自動バックグラウンド実行（トゥルーアップ実行）で遅れて到着したデータをキャプチャします。これは、プライマリ実行の約 4 時間後（オプションでエンリッチメントの完了から 30 時間後）に発生します。

  • 例: ルールは、30 分のウィンドウ内でイベント A（イベント時刻 9:03 AM）とイベント B（イベント時刻 9:05 AM）を関連付けます。イベント A が午前 10 時 5 分（1 時間遅れ）に到着した場合、午前 9 時～午前 9 時 30 分のブロックの最初の実行には間に合いません。システムは、プライマリ実行の約 4 時間後（午後 2 時頃）に、その後のトゥルーアップ実行中にブロックを再評価し、イベント発生から約 5 時間後に検出を生成します。

サードパーティ API ポーリング フィードにおけるアップストリームのインデックス登録のレイテンシについては、ポーリング フィードで遅れて到着するイベントをご覧ください。

タイムゾーンの不一致

Google SecOps は、デフォルトでログのタイムスタンプを UTC として解釈します。ログソースで明示的なタイムゾーン オフセットが省略されている場合、システムはタイムスタンプを UTC として扱います。これにより、ログがすぐに受信された場合でも、ログが遅れて到着したように見えることがあります。

  • 例: イベントが東部時間の午前 10 時（15:00 UTC）に発生し、15:05 UTC に Google SecOps に到着します。タイムゾーン メタデータはありません。システムはタイムスタンプを 10:00 UTC と解釈し、5 時間の取り込み遅延が発生したと認識して、ルールの評価をバックグラウンドのトゥルーアップ実行に延期します。

回避策: タイムゾーンの不一致を解決するには、次の手順を行います。

  • イベント タイムスタンプに明示的な UTC タイムゾーン オフセットが含まれるようにログソースを構成します。
  • 特定の取り込みフィードにタイムゾーンのオーバーライドを設定するには、サポートにお問い合わせください。
  • BindPlane プロセッサを使用して、取り込み前にログ本文のタイムスタンプを UTC に正規化する。詳細については、BindPlane を使用してログ本文のタイムスタンプを変更するをご覧ください。

コンテキスト結合とデータの拡充

Google SecOps は、セカンダリ ソースから ID、アセット、脅威のメタデータを追加して UDM イベントを拡充します。コンテキストの可用性が遅れると、検出のタイミングが遅れる可能性があります。

エイリアスとエンリッチメントのメカニズム

エイリアスとエンリッチメントにより、未加工のインジケーターを組織のコンテキストに関連付けます。

  • エイリアス: データソース間で同じエンティティの異なる識別子を識別してリンクします（DHCP ログの IP アドレスを MAC アドレスとホスト名（alex-macbook など）にマッピングしたり、ユーザー ID を従業員の役職にマッピングしたりします）。
  • 拡充: 正規化された UDM イベント フィールドにエイリアス コンテキストを入力します（未加工イベントに IP アドレスのみが存在する場合に $udm.event.principal.hostname を入力するなど）。

サポートされているエンリッチメント タイプには、アセット、ユーザー、プロセス、ファイル ハッシュ メタデータ、地理的位置、クラウド リソースなどがあります。詳細については、UDM の拡充とエイリアスの概要をご覧ください。

UDM イベントの再拡充

コンテキスト ソースの進化に伴い、システムは過去のイベントを継続的に更新します。

  • 基盤となるデータの変更: 過去のイベントは、新しいコンテキスト データが取り込まれてから最大 24 時間更新できます。
  • エンリッチメント システムの更新: エンティティ メタデータ、IP 位置情報、VirusTotal 脅威インテリジェンスが更新されると、ルールエンジンは過去のブロックを再評価し（通常はスケジュールされたトゥルーアップ実行または再処理中）、更新されたコンテキストで検出を生成します。
  • コンテキスト データの遅延: コンテキスト データ（ホスト名など）がイベントログの 1 日後に到着した場合、システムは UDM イベントを再拡充し、後続のトゥルーアップ実行で拡充されたレコードを評価します。
  • コンテキストの変更: エンリッチメントの更新によってイベント属性が変更された場合（IP 位置情報を USA から Canada に更新するなど）、更新された値に一致するルールが、その後の再評価中に検出をトリガーします。

エンティティ コンテキスト グラフ（ECG）の処理

エンティティ コンテキスト グラフ（ECG）は、セキュリティ侵害インジケーター（IOC）とエンタープライズ アセット グラフデータを関連付けます。ECG パイプラインはバッチ処理（データ量に応じて 30 時間から数日かかる場合があります）に依存しているため、graph.entity フィールドを参照するルールは、グラフの関係が完全に計算された後に検出を生成します。

過去のルール実行と Retrohunt

過去のデータに対してルールを実行すると、選択した期間全体で Retrohunt スキャンが完了した後にのみ検出が生成されます。

  • 遡及的な拡充ワークフロー:
    1. 午後 1 時にイベントが ip_address = 10.0.0.5（ホスト名が不明）で到着します。
    2. 午後 2 時 30 分に、10.0.0.5 を workstation-123 にリンクする DHCP ログが到着します。
    3. エイリアス パイプラインは、過去の午後 1 時のイベントを principal.hostname = workstation-123 で更新します。
    4. その後のルールリプレイでは、拡充されたホスト名が評価され、最初の実行時にトリガーされなかった検出が表面化します。

リファレンス リスト

参照リストをクエリするルールは、実行時に最新のリスト バージョンに対して評価されます。参照リストを更新すると、スケジュールされたルールが、以前に取り込まれたログに対して遡及的に検出を生成する可能性があります。

非存在ルール

誤検知を防ぐため、システムは存在しない条件（!$e や #e=0 など）をチェックするルールを評価する前に、少なくとも 1 時間のバッファを導入し、関連するすべてのログが到着する時間を確保します。

データ処理とトゥルーアップの制限事項

検出レイテンシを評価する際は、次のシステム動作に注意してください。

  • 拡充処理: コンテキスト拡充では、最初の取り込みから最大 24 時間後に過去の UDM イベントを更新できます。
  • トゥルーアップ サイクル: マルチイベント ルールは、遅れて到着したデータをキャプチャするために、プライマリ実行の約 4 時間後（オプションで 30 時間後）に自動的に再実行されます。詳細については、ルールリプレイと MTTD についてをご覧ください。
  • 検出の上限: プラットフォームの容量とスロットリングの境界については、検出の上限についてをご覧ください。

ルールの検出遅延のトラブルシューティング

ルールで遅延検出が生成された理由を診断するには、Google SecOps コンソールで次のヒューリスティックとパイプライン ステージを調べます。

  • ルールのメタデータとスケジュールを確認する: ルール ダッシュボードで、[ルール名]、[ルールタイプ]、[ルール スケジュール] の列を確認して、ルールの実行エンジンとベースライン評価の頻度を特定します。
  • イベント時間と取り込み時間を比較する: [検出] タブで検出結果を見つけ、イベントのタイムスタンプと取り込みのタイムスタンプを比較します。イベント時刻と取り込み時刻の差が 30 分を超える場合、レイテンシはソースまたは収集中のログ配信の遅延が原因です。30 分以上遅れて到着したイベントデータ、自動トゥルーアップ実行、再処理パイプライン、レトロハントから生成された検出には、[検出タイプ] 列に アイコンが表示されます。
  • コンテキスト ソースの依存関係を確認する: ルールが principal エンリッチメント、UDM エイリアス、graph.entity フィールドを参照しているかどうかを確認します。コンテキスト パイプラインは非同期で処理され、後続のトゥルーアップ実行中に検出結果が表示されることがあります。
  • 頻度と一致ウィンドウの互換性を確認する: 構成された実行頻度が一致ウィンドウのサイズと一致していることを確認します（たとえば、15 分の一致ウィンドウを持つルールが 10 分または 1 時間にスケジュールされていることを確認します）。
  • データフィードの中断を確認する: 取り込みログとフィード管理ダッシュボードを確認して、取り込みの遅延や一時的なソースの停止がないか確認します。

検出の遅延を短縮するためのヒント

環境全体で検出の遅延を最小限に抑えるには、次の最適化手法を適用します。

  • ルールの実行頻度を最適化する:
    • シングル イベント ルール（標準とウィンドウ）には準リアルタイムを使用します。
    • 一致ウィンドウが 60 分未満のマルチイベント ルールに 10 分のスケジュールを構成します。
    • 迅速なアラートが必要な、一致ウィンドウが 1 ～ 48 時間のルールには、1 時間を使用します。
  • 一致ウィンドウの期間を調整する: 関連する脅威の動作をキャプチャするために必要な最小期間に一致ウィンドウを設定します。
  • ログ配信のボトルネックを解消する: フォワーダーとコレクタがイベントデータをすぐに送信して、ログが最初の実行ウィンドウを逃さないようにします。
  • タイムゾーン構成を検証する: ログソースが明示的な UTC オフセットを提供していることを確認し、5 時間以上の取り込み遅延が発生しないようにします。
  • 監査コンテキストと存在しない条件: コンテキストが拡充されたフィールドと存在しない条件（!$e）は、検出ロジックで必要な場合にのみ使用します。これらは意図的なバッファリング期間を導入するためです。

次のステップ

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

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