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

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

このドキュメントでは、Google Security Operations でのルール検出の遅延について説明し、遅延の原因となる要因を特定し、トラブルシューティングのアプローチの概要を示します。また、可能な限り遅延を短縮するための手法を提案します。

検出ルール

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

予測された遅延と予測されなかった遅延

検出時間は処理の遅延の影響を受けます。一部のルールはほぼリアルタイムでトリガーされますが、完了までに数分から数時間かかるルールもあります。ルールの種類、実行頻度、検出生成方法などの要因が、この遅延に影響します。このドキュメントでは、これらの遅延要因について説明します。

遅延は、想定内または想定外のいずれかに分類されます。

  • 想定される遅延: これらの遅延は、取り込みプロセスと、検出ルールの設定時に行った構成の選択によって発生します。たとえば、検出の作成にかかる時間は要因となります。これらの遅延は、ルールタイプ、実行頻度、検出生成方法、既知の制限事項などの既知の構造的要因や、その他の予測可能な要因によって異なります。
    このドキュメントで説明するように、検出ルールの構成を変更または調整することで、これらの遅延を最小限に抑えることができます。
    詳しくは、遅延を短縮するためのヒントをご覧ください。

  • 予測できない遅延: イベントデータが Google SecOps に届くまでの遅延、Google SecOps サービス内の処理パイプラインの一時的な遅延、再エンリッチメント、その他のデータ処理の遅延など、さまざまな要因によって発生するルール固有またはイベント固有の遅延です。

ルール検出の遅延を分析する

ルールの検出遅延を分析するには、ルールとその周辺の要因に関する情報を確認します。

  1. Google SecOps コンソールで、[検出] > [ルールと検出] に移動します。

    ルール ダッシュボードには、Rule name、Rule type、Run frequency などのルール メタデータが表示されます。

    詳しくは、ルール ダッシュボードでルールを表示するをご覧ください。

  2. [ルール ダッシュボード] で、ルール名をクリックして、特定のルールの検出履歴やその他の詳細を表示します。

  3. 特定のルールの実行では、検出レイテンシに影響する要因がいくつかあります。Rule type、Run frequency、Event type、Event time、Ingested time などのディメンションは、特定の検出が遅延した理由を理解するための優れたヒューリスティックです。

[検出タイプ] 列の アイコンは、再処理実行またはレトロハントからの検出を示します。このアイコンは、Google SecOps の [アラート] ページにも表示されます。

  1. 次のトピックをよく読んで、これらの要因がルールの検出遅延にどのように影響するかを理解してください。

検出生成方法

システムがルール検出を作成する方法を学習して、検出生成方法が検出の遅延に与える影響を理解します。

システムは、次の方法でルール検出を生成します。

  1. Streaming Engine

    Streaming Engine は、通常 5 分未満の遅延で動作する高速パイプラインです。一致セクションと外部データセット（参照リストやデータテーブルなど）がない単一イベント ルールを処理します。

  2. クエリエンジン

    クエリエンジンは次のようにルールを処理します。

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

      • ref-list またはデータテーブルを参照する単一イベントルール。
      • 単純な条件で一致ウィンドウを使用するウィンドウ化された単一イベントルール。たとえば、「イベントのカウントが 0 より大きいイベント」などです。これらのルールは、新しいデータが取り込まれてルール処理に使用可能になると、高頻度（準リアルタイム）のクエリレートで実行されます。

    • マルチイベント ルール: これらのルールは、設定したスケジュールに従って、イベント時間（10 分、1 時間、1 日）のブロックでデータをクエリします。
      たとえば、10 分間のスケジュールの場合、ルールはアップストリーム処理のタイムラインに応じて、5 ～ 8 時間後と 24 ～ 48 時間後にイベント時間ブロックを再クエリします。

  3. 過去のデータに対してルールを実行する

    詳細については、遡及的ハンティングをご覧ください。

  4. UDM イベントの再拡充

    詳細については、UDM イベントの再拡充とエンティティ コンテキスト グラフの処理をご覧ください。

既知の制限事項

ルール検出の遅延の原因となる標準的な制限は次のとおりです。

  • エンリッチメントの遅延は、想定よりも時間がかかることがあります。拡充の再処理により、後続のルール実行でデータが再評価されます。システムは複数のエンリッチメント実行を行い、エンリッチメントはイベントが取り込まれてから最大 24 時間後に UDM イベントを更新できます。
  • 複数イベント ルールでは、プライマリ イベントのイベント時刻から数時間後に到着するコンテキスト データが結合されることがよくあります。このコンテキスト データのレイテンシが高いと、再エンリッチメント処理とルール再生が相互に作用し、検出が遅れる可能性があります。Google SecOps はこの機能を使用して非常に遅れて到着したデータを処理しますが、検出ウィンドウ（イベント時間ブロック）とアラートの作成時間の間に大きな時間差が生じます。
  • コンテキストアウェア ルールは、アセットと ID のエイリアスやエンティティ コンテキスト グラフなどのエンリッチメント ソースに依存するルールです。これらのルールは複数のイベントソースに依存するため、レイテンシが高くなる可能性があります。
  • システムは、最初のルール実行から 5 ～ 8 時間後と 24 ～ 48 時間後にルールを再実行します。これら 2 つの個別のルール再生は、再処理パイプラインの実行時間に基づいてトリガーされます。
  • その他の検出上限については、検出上限についてをご覧ください。

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

消去法でルールの検出遅延のトラブルシューティングを行います。

ルール検出の遅延を調査してトラブルシューティングするには、次のアプローチをおすすめします。

  1. 明らかな遅延がないか確認します。

    取り込みの遅延があるかどうかを判断します。

    1. Google SecOps コンソールで、[検出] > [ルールと検出] に移動します。

    2. ルール ダッシュボードで、分析するルールを検索します。

    3. Event time と Ingested time を比較します。

      たとえば、特定ルールの検出で Event time と Ingested time の間に大きなギャップがある場合は、検出の遅延を予想される遅延に起因する可能性が高いです。

  2. コンテキスト ソースの収集時間を確認します。

    コンテキスト ソースの収集時間を確認します。

    コンテキストアウェア ルールには、次のコンテキスト ソースを含めることができます。収集時間を確認します。

    • UDM 拡充から派生したフィールド。
    • principal フィールドを含むイベント。

    • graph.entity フィールドを参照するルール。

      graph.entity 構文でエンティティ コンテキスト グラフ（ECG）を参照するルールは、特にレイテンシが高くなる可能性があります。たとえば、心電図パイプラインはコンテキスト データを生成します。このプロセスは、データタイプに応じて 30 時間、場合によっては最大 8 日かかることがあります。

    詳細については、データ処理の遅延をご覧ください。

  3. ルールの実行頻度と照合期間の構成を確認します。

    • 頻度: ルールの実行頻度を確認します。実行頻度が低くなるように構成されたルールでは、検出の遅延が長くなります。
    • 一致ウィンドウ: ルールに一致ウィンドウがある場合、最小遅延はそのウィンドウの期間になります。
    • 実行頻度と照合期間の関係: 実行頻度が照合期間と互換性があることを確認します。たとえば、一致ウィンドウが 5 分の場合、実行頻度が 10 分でも問題ありません。ただし、一致ウィンドウが 10 分を超える場合は、次に使用可能な実行頻度である 1 時間を使用します。

  4. 最近のインシデントを確認します。

    データフィードの遅延や問題の原因となった可能性がある最近のインシデントがないか確認します。

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

検出ルールの構成を更新するには、ルールエディタを使用してルールを管理するをご覧ください。

可能な場合は、次の方法で遅延を減らします。

  • レイテンシの影響を受けやすいルールには、最も頻繁に実行されるオプションを使用します。

    • ルールの頻度を増やす:

      遅延を減らすには、ルールタイプと一致ウィンドウに基づいて、可能な限り高い頻度を構成します。

      • 単一イベントルールの場合: [準リアルタイム] を使用します。
      • 一致ウィンドウが 60 分未満のマルチイベント ルールの場合: 10 分を使用します。
      • 一致ウィンドウが 60 分以上のルールの場合: 必要に応じて、1 時間または 24 時間を使用します。

      詳細については、実行頻度を設定するをご覧ください。

    • 照合期間を短縮する:

      一致ウィンドウを短縮してもレイテンシに直接影響することはありませんが、最小遅延を設定することで効率を高めることができます。

  • 遅延データの回避:

    遅延したデータは最初のクエリで検出されず、5 ～ 8 時間後にイベント時間ブロックを再クエリしたときにのみ処理されるため、大幅な遅延が発生します。通常、遅延時間は 20 分程度です。

ルール検出の遅延につながる要因

ルールの検出遅延の主な要因は、ルールタイプ、実行頻度、Google SecOps の取り込みの速度です。

ルール検出の遅延に影響する要因は次のとおりです。

ルールの種類

ルールは、主に次の 2 つのカテゴリに分類されます。

単一イベントのルール

単一イベントルールはストリーミング アプローチを使用して準リアルタイムで実行されるため、可能な場合は遅延を最小限に抑えるために使用します。

これらのルールは単一のイベントを検出し、参照リスト、データテーブル、一致ウィンドウ、ユーザーとエンティティの行動分析（UEBA）を使用しません。これらのルールは、準リアルタイムのストリーミング方式で実行され、検出遅延が最も短くなります。

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

これらのルールには、一致ウィンドウまたはリファレンス リストが含まれているため、検出の遅延が発生しやすくなります。

  • ウィンドウ化された単一イベントのルール

    これらは、一致ウィンドウを含む単一イベントルールであり、通常、他の単一イベントルールよりも遅延がわずかに長くなります。通常、一致ウィンドウは、ルールが 1 つ以上のイベントを検査する期間です。

  • 単一イベントのルールを参照する

    これらは、参照リストまたはデータテーブルを含む単一イベントルールです。

マルチイベントのルール

マルチイベント ルールはスケジュールに基づいて実行されるため、スケジュールされた実行間の時間により遅延が長くなります。

  • マルチイベント ルール

    これらのルールは、2 つ以上の UDM イベント条件を調べます。通常、一致ウィンドウと複数の条件があります。

  • コンテキストアウェア ルール

    コンテキストアウェア ルールを使用すると、追加のエンティティと検出コンテキスト データをイベントに結合できます。

    • これらのルールは 2 つ以上のデータソースで構成され、少なくとも 1 つの条件が UDM エンティティ イベント（UDM イベントが user_context などのコンテキスト タイプの場合）です。
    • コンテキストアウェア ルールは、遅延したデータに最も影響を受けます。
    • コンテキストアウェア ルールは、システムがまず Entity Context Graph のデータなどの必要なコンテキスト データを生成する必要があるため、通常、遅延が最も長くなります。
    • 詳しくは、ルールでコンテキストが拡充されたデータを使用するをご覧ください。

単一イベントルールとマルチイベントルールの違いについて詳しくは、こちらをご覧ください。

ルールの実行頻度

ルールの実行頻度は、検出遅延に直接影響します。

  • 準リアルタイム: リアルタイム データに対してルールがより頻繁に実行されます。これは、単一イベント ルールにのみ適用されます。
  • その他の頻度: 他のルールタイプでは、次の頻度を設定できます。
    • 10 分間のフリークエンシーは、60 分未満のマッチ ウィンドウで有効です。
    • 1 時間と 24 時間の頻度は、一致ウィンドウが 48 時間未満の場合に有効です。
    • 24 時間の頻度は、48 時間以上のすべての照合期間で有効です。

考えられる回避策: 検出を高速化するには、実行頻度を短くします。一致ウィンドウを短縮してもレイテンシに直接影響することはありませんが、最小遅延を設定することで効率を高めることができます。

一致ウィンドウ

ルールに一致ウィンドウがある場合、ウィンドウの期間によって最小検出遅延が決まります。これは、システムがウィンドウ全体が発生するまで待機する必要があるためです。

取り込みの遅延

取り込み遅延とは、イベントの発生後に Google SecOps がデータを取り込むのにかかる時間のことです。

データが遅れて到着すると、最初のクエリ ウィンドウに間に合いません。後続の履歴処理クエリで取得されますが、5 ～ 8 時間の遅延が発生する可能性があります。

たとえば、イベント A（イベント時刻 9:03）とイベント B（イベント時刻 9:05）は、30 分以内に 2 つのイベントを探すルールの対象です。イベント A が午前 10 時 5 分に到着した場合（1 時間遅延）、午前 9 時～ 9 時 30 分のブロックの最初のクエリは実行されません。午後 2 時から午後 5 時の間にそのブロックのフォローアップ クエリが実行され、検出が生成されるため、5 ～ 8 時間の遅延が発生します。

トラブルシューティング: イベントが発生したらすぐに Google SecOps にデータを送信することを確認します。検出を確認する際は、UDM イベントと取り込みのタイムスタンプを慎重に確認してください。

タイムゾーンに関する問題

Google SecOps SIEM のデフォルトのタイムゾーンは UTC です。ログに明示的なタイムゾーン定義が含まれていない場合、システムはログを UTC として解釈します。解釈が正しくないと、ログが遅延データとして扱われ、システムがリアルタイムで受信しても検出が遅延する可能性があります。

たとえば、イベント時刻が午前 10 時（東部時間）（15:00 UTC）のログが 15:05 UTC に到着したが、タイムゾーンがないとします。ログにタイムゾーンがない場合、システムはイベント時間を 10:00 UTC と解釈します。システムは、解釈されたイベント時間（10:00 UTC）と実際の取り込み時間（15:05 UTC）の間に 5 時間の遅延があると計算します。この遅延が計算されると、ルールがリアルタイムの取り込みに基づいて処理を優先するため、検出遅延がトリガーされます。

回避策: 元のデータのイベント タイムスタンプが UTC 以外のタイムゾーンにある場合は、次のいずれかを試してください。

  • 元のデータのイベント タイムゾーンを更新します。
  • ログソースでタイムゾーンを更新できない場合は、サポートに連絡してタイムゾーンをオーバーライドしてください。
  • または、BindPlane プロセッサを使用してタイムスタンプを修正し、UTC としてフォーマットするか、適切なタイムゾーン インジケーターを追加します。詳細については、BindPlane を使用してログ本文のタイムスタンプを変更するをご覧ください。

コンテキスト結合

UEBA やエンティティ コンテキスト グラフ フィールドなどのコンテキスト データを使用する複数イベント ルールでは、遅延が長くなる可能性があります。Google SecOps は、まずコンテキスト データを生成する必要があります。

拡充システム

Google SecOps は、他のソースからコンテキスト データを追加して UDM イベントを拡充します。通常、このプロセスは 30 分以内に完了します。この拡充されたデータを UDM イベントに追加する際に遅延が発生すると、検出時間が長くなる可能性があります。

ルールが拡充されたフィールドを評価しているかどうかを確認するには、Event Viewer を確認します。ルールが拡充されたフィールドを評価している場合は、検出が遅延する可能性があります。

詳細については、データ拡充をご覧ください。

エイリアシングと拡充

エイリアス設定と拡充は、Google SecOps のセキュリティ データ拡充プロセスの 2 つのステップで、イベント レコードにコンテキスト データを関連付けて追加します。エイリアスは接続を検出し、拡充はその接続されたデータで UDM フィールドに入力します。このプロセスで入力されるフィールドは、エイリアス フィールドまたは拡充フィールドと呼ばれます。

  • エイリアス設定: 同じエンティティの異なる名前や識別子を特定してリンクするプロセスです。インジケーターを説明する追加のコンテキスト データを見つけます。たとえば、エイリアスを使用すると、単一の hostname（alex-macbook など）を、関連する他のインジケーター（IP addresses や MAC addresses（DHCP ログから取得）など）に接続できます。エイリアスは、user ID（alex など）をユーザーの job title と employment status（ユーザー コンテキスト データから）に接続することもできます。
  • 拡充: エイリアスから収集した情報を使用して、UDM イベントにコンテキストを追加するプロセスです。たとえば、IP address のみを含む新しいイベントが到着すると、エンリッチメント プロセスはエイリアス データを使用して関連する hostname（alex-macbook など）を見つけ、$udm.event.principal.hostname フィールドに入力します。

Google SecOps は、アセット（ホスト名、IP アドレス、MAC など）、ユーザー、プロセス、ファイルハッシュ メタデータ、地理的位置、クラウド リソースなど、複数のエンティティ タイプのエイリアスとエンリッチメントをサポートしています。詳細については、UDM の拡充とエイリアスの概要をご覧ください。

UDM イベントの再エンリッチメント

  • 基になるデータの変更: イベントの取り込み後に基になるデータが変更された場合、システムは過去のデータを再処理し、取り込み後 24 時間以内にイベントを更新します。

  • エンリッチメント システムの更新: エンリッチメント システムがエンティティまたはプロセスのメタデータ、IP ジオロケーション、VirusTotal インジケーターを更新すると、ルールエンジンは 24 ～ 48 時間後にこれらのブロックを再評価して、更新をキャプチャします。
    たとえば、午前 9 時 3 分のイベントには entity.asset.hostname = hostnameA がありますが、IP はありません。午前 8 時 55 分の DHCP ログには hostnameA = IP 1.2.3.4 が表示されます。ルールエンジンは午前 9 時 10 分に実行されますが、ルールは一致しません。エンリッチメント処理パイプラインは、その期間の hostnameA と 1.2.3.4 を関連付け、UDM イベントを更新します。ルールが一致し、システムが検出を作成します。

  • 遅延コンテキスト データ: 最初のログの 1 日後に hostname などのコンテキスト データを送信すると、システムは UDM イベントを再エンリッチします。この再エンリッチされたデータを検索するルールが再度実行され、検出が作成されます。この機能により、コンテキストが遅延した場合でもシステムで検出が作成されます。

  • 拡充データの変更: 拡充データが変更されると、最初は一致しなかったルールが後で一致する可能性があります。
    たとえば、午前 9 時 3 分のイベントには entity.ip_geo_artifact.country_or_region = USA があります。ルールエンジンは午前 9 時 10 分に実行され、午前 9 時から午前 10 時までのクエリを実行しますが、ルールは一致しません。その後、拡充の再処理によって、位置情報がカナダに更新されます。ルールが再度実行されると、一致するようになり、システムが検出を作成します。

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

システムは、エンティティ コンテキスト グラフ（ECG）情報を生成してログデータに追加し、コンテキスト（セキュリティ侵害インジケーター（IOC）やアセット コンテキスト データなど）を提供します。ECG パイプラインは主にバッチ処理に依存しているため、エンティティ コンテキスト情報は、ルール実行で検出が作成された後にのみ更新されることがよくあります。

レトロ ハンティング

RetroHunt を使用して過去のデータに対してルールを実行すると、RetroHunt プロセスが完了した後にのみ検出が作成されます。このプロセスには時間がかかるため、検出が遅れる可能性があります。

遡及的更新プロセスの例:

  1. 最初のイベント: ip_address = 10.0.0.5 を含むイベントが午後 1 時に到着します。現時点では、hostname は不明です。
  2. エイリアス ソースが到着: 午後 2 時 30 分（1 時間以上後）に、午後 1 時の DHCP ログが到着し、10.0.0.5 が workstation-123 にリンクされます。
  3. 遡及的エンリッチメント: エイリアス システムがこの新しいリンクを処理します。これにより、午後 1 時から UDM イベントが遡及的に更新され、以前は空だった $udm.event.principal.hostname フィールドに値 workstation-123 が設定されます。
  4. 検出: 後続のルール再生では、強化された値（workstation-123）が確認され、以前に検出されなかった検出をトリガーできます。

注: ライブ検出ルールのレイテンシ モニタリング指標とレトロハント検出ルールのレイテンシ モニタリング指標を区別することはできません。検出レイテンシ モニタリング指標の歪みを避けるため、ライブルールを使用して RetroHunt ルールをシミュレートしないでください。ベスト プラクティスとして、専用の検出ルールを作成し、遡及検索ルールとして実行します。

リファレンス リスト

ルールの実行では、常に最新バージョンのリファレンス リストが使用されます。スケジュールされたルールが再度実行されると、システムは更新されたリファレンス リストの内容に基づいて新しい検出を作成できます。これらの検出は、リファレンス リストの更新前に取り込まれたデータに基づいて行われるため、遅れて表示されることがあります。

検出の遅延を短縮するには、次の操作を行います。

  • イベントが発生したらすぐに Google SecOps にログデータを送信します。
  • 監査ルールを確認して、存在しないデータまたはコンテキストが拡充されたデータを使用するかどうかを判断します。
  • 実行頻度を低くする。

非存在ルール

システムは、存在しないことを確認するルール（!$e または #e=0 を含むルールなど）を実行する前に少なくとも 1 時間待機し、データの受信時間を確保します。

データ処理の遅延

システムは、最初の検出を作成した後もデータの処理を継続し、新しい検出や更新された検出につながる可能性があります。詳細については、ルール再生がトリガーされる場合をご覧ください。

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