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

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

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

検出ルールの概要

検出ルールは、正規化された生ログ（通常のユニバーサル データモデル（UDM）イベントとエンティティ 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 時 3 分）とイベント B（イベント時刻 9 時 5 分）を関連付けます。イベント A が午前 10 時 5 分に到着した場合（1 時間遅延）、午前 9 時～午前 9 時 30 分のブロックの初回実行はスキップされます。システムは、プライマリ実行の約 4 時間後（午後 2 時頃）に後続の調整実行中にブロックを再評価し、イベント発生から約 5 時間後に検出を生成します。

タイムゾーンの不一致

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. ip_address = 10.0.0.5（ホスト名不明）のイベントが午後 1 時に到着します。
    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 のプロフェッショナルから回答を得ることができます。