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

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

Google SecOps SIEM

このドキュメントでは、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 などのディメンションは、特定の検出が遅延した理由を理解するための優れたヒューリスティックです。

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

   • 検出生成方法
   • 既知の制限事項
   • ルールの検出遅延の原因となる要因

検出生成方法

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

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

1. Streaming Engine

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

2. クエリエンジン

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

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

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

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

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

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

4. UDM イベントの再拡充

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

既知の制限事項

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

• エンリッチメントの遅延は、想定よりも時間がかかることがあります。エンリッチメントの再処理により、後続のルール実行でデータが再評価されます。システムは複数のエンリッチメント実行を行い、最後の実行はイベント時刻の 3 日後に行われます。
• 複数イベント ルールでは、プライマリ イベントのイベント時刻から数時間後に到着するコンテキスト データが結合されることがよくあります。このコンテキスト データのレイテンシが高いと、再エンリッチメント処理とルール再生が相互に作用し、検出が遅れる可能性があります。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 時間を使用します。

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

  • 照合期間を短縮する:

    一致ウィンドウが小さいほど効率的です。60 分間の照合ウィンドウを 59 分間に変更して、10 分間の処理を有効にします。

• 遅延データの回避:

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

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

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

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

ルールの種類

• 単一イベントのルール:

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

  • シンプルな単一イベントのルール

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

    注: suppression_window オプションを使用すると、単一イベント ルールにアラート抑制を適用できます。

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

    • ウィンドウの単一イベント ルール

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

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

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

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

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

  • マルチイベント ルール

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

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

    コンテキスト認識ルールを使用すると、テレメトリーの動作パターンと、これらのパターンから影響を受けるエンティティのコンテキストを理解できます。

    • これらのルールは 2 つ以上の条件で構成されますが、少なくとも 1 つの条件は UDM エンティティ イベントです（UDM イベントのタイプは context（user_context など）です）。
    • このタイプのルールでは遅延が長くなるため、検出に数日かかることも珍しくありません。
    • コンテキストアウェア ルールは、システムがまず必要なコンテキスト データを生成する必要があるため、通常、遅延が最も長くなります。

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

ルールの実行頻度

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

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

考えられる回避策: 検出を高速化するには、実行頻度を短くし、一致ウィンドウを小さくします。一致ウィンドウを短く（1 時間未満）すると、実行頻度を上げることができます。

一致ウィンドウ

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

取り込み遅延

取り込み遅延とは、イベントの発生後に 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 や Entity Graph などのコンテキスト データを使用する Multiple Event ルールでは、遅延が長くなる可能性があります。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 イベントを更新します。ルールが一致し、システムが検出を作成します。

• 遅延コンテキスト データ: 最初のログから 3 日後に 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）が認識されるようになり、以前は見逃されていた検出をトリガーできるようになりました。

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

リファレンス リスト

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

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

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

非存在ルール

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

データ処理の遅延

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

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