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

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

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

検出ルールの概要

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

予測される遅延と予測できない遅延

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

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

検出生成方法

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

  • ストリーミング エンジン: 標準の単一イベント ルールとウィンドウ化された単一イベント ルールを準リアルタイム（通常は取り込み後 5 分以内）で継続的に評価する高速パイプライン。遅れて到着したイベントと遡及的な拡充は、標準実行中に継続的に評価されます。
  • クエリエンジン: 複数のイベントまたは外部データ結合にわたる時間ベースのイベント相関を必要とするルールを評価します:
    • 複雑な単一イベント ルール: 参照リストまたはデータテーブルをクエリする単一イベント ルールが含まれます。
    • マルチイベント ルール: 構成されたスケジュールに基づいて、イベント時間のバッチ処理ブロック（10 分間隔、1 時間間隔、48 時間を超えるウィンドウの場合は match_window / 10 など）でデータをクエリします。
  • 過去のデータに対して実行されるルール: Retrohunt を使用して、過去のログに対してルールを遡及的に評価します。過去のスキャンが完了すると、検出結果が表示されます。
  • 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）とイベント B（イベント時刻 9:05）を関連付けます。イベント 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. イベントが午後 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 分以上遅れて到着したイベントデータ、自動調整実行、再処理パイプライン、Retrohunt から生成された検出結果には、 アイコンが [Detection Type] 列に表示されます。
  • コンテキスト ソースの依存関係を確認する: ルールが principal の拡充、UDM エイリアス、または graph.entity フィールドを参照しているかどうかを確認します。コンテキスト パイプラインは非同期で処理され、後続の調整実行中に検出結果が表示されることがあります。
  • 頻度と一致ウィンドウの互換性を確認する: 構成された実行頻度が一致ウィンドウのサイズと一致していることを確認します（たとえば、15 分の一致ウィンドウを持つルールが 10 分または 1 時間にスケジュールされていることを確認します）。
  • データフィードの中断を確認する: 取り込みログとフィード管理ダッシュボードで、取り込みの遅延や一時的なソースの停止を確認します。

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

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

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

次のステップ

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

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