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

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

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

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

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

検出生成方法

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

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

  1. Streaming Engine

    Streaming Engine は、低レイテンシ（通常は 5 分未満の遅延）で動作する専用のストリーミング パイプラインです。一致なしセクション、外部データセットなし（参照リストやデータテーブルなど）、UEBA 関数を含まない標準の単一イベント ルールを評価します。

  2. クエリエンジン

    クエリエンジンは、複雑な単一イベント ルールとマルチイベント ルールを評価します。

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

      • 参照リストまたはデータテーブルを含む単一イベントルール: 単一のイベントを評価し、参照リストまたはデータテーブルに対してルックアップを実行するルール。
      • ウィンドウ化された単一イベント ルール: 一致ウィンドウと単純な存在条件（$e、#e > 0、#e >= 1 など）で単一のイベントを評価するルール。
      • 複雑な単一イベントルールは、ストリーミング エンジンではなくクエリ エンジンを使用しますが、新しいデータが取り込まれると、高頻度の準リアルタイム スケジュールで実行されます。これにより、ストリーミング エンジンの一般的なレイテンシに近い低レイテンシが実現します。遅れて到着したデータや拡充されたデータは、標準クエリの実行中に再評価されます。マルチイベントの調整間隔は必要ありません。

    • マルチイベント ルール: これらのルールは、設定したスケジュールに従って、イベント時間（10 分、1 時間、1 日）のブロックでデータをクエリします。遅延して到着したデータの再クエリのタイミングは、スケジュール タイプによって異なります。

      • デフォルトのスケジュールでは、イベント時刻の約 5 時間後と 24 時間後に再クエリが行われます。
      • カスタマイズ可能なスケジュールでは、さまざまな調整タイミングが用意されています。詳細については、ルールの再生と MTTD についてをご覧ください。

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

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

  4. UDM イベントの再拡充

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

既知の制限事項

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

  • エンリッチメントの遅延は、想定よりも時間がかかることがあります。拡充の再処理により、後続のルール実行でデータが再評価されます。システムは複数のエンリッチメント実行を実行します。エンリッチメントは、イベントが取り込まれてから最大 24 時間後に UDM イベントを更新できます。

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

    • デフォルトのスケジュールのマルチイベント ルールの場合、システムはイベント時刻の約 5 時間後と 24 時間後にルールを再実行します。

    • カスタマイズ可能なスケジュールを含むマルチイベント ルールでは、調整時間が異なります。

    これらのルール再生は、遅延データを処理するためにトリガーされます。

  • コンテキストアウェア ルールは、アセットと ID のエイリアスやエンティティ コンテキスト グラフなどの拡充ソースに依存するルールです。これらのルールは複数のイベントソースに依存するため、レイテンシが高くなる可能性があります。

  • システムは、最初のルールの実行から 5 ～ 8 時間後と 24 ～ 48 時間後にルールを再実行します。これら 2 つの個別のルール再生は、再処理パイプラインの実行時間に基づいてトリガーされます。

  • その他の検出上限については、検出上限についてをご覧ください。

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

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

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

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

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

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

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

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

      たとえば、特定ルールの検出で Event time と Ingested time の間に大きな差がある場合は、検出の遅延を予想される遅延に起因する可能性が高いです。Ingestion time が Event time より 30 分以上経過している場合、[検出タイプ] 列に アイコンが表示されます。

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

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

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

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

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

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

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

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

    • 頻度: ルールの実行頻度を確認します。実行頻度が低く設定されているルールでは、検出の遅延が長くなります。
    • 一致ウィンドウ: ルールに一致ウィンドウがある場合、最小遅延はそのウィンドウの期間になります。
    • 実行頻度と照合期間の関係: 実行頻度が照合期間と互換性があることを確認します。たとえば、60 分未満のマッチ ウィンドウの場合、10 分（準リアルタイム）の実行頻度がサポートされています。60 分以上のマッチ ウィンドウ（最大 48 時間）の場合は、1 時間を使用します。マッチウィンドウが 48 時間を超える場合は、[Daily] を使用します。

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

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

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

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

可能な限り遅延を減らすには、次の方法を使用します。

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

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

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

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

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

    • 照合期間を短縮する:

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

  • 遅延データの回避:

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

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

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

ルール検出の遅延には、次の要因が影響します。

ルールの種類

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

単一イベントのルール

標準の単一イベントルールは、外部データ ルックアップ、一致ウィンドウ、ユーザーとエンティティの行動分析（UEBA）なしで個々のイベントを検出します。これらのルールは、専用のストリーミング エンジンを使用して準リアルタイムで実行され、検出レイテンシが最小限に抑えられます（通常は 5 分未満）。

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

複雑なシングル イベント ルールは、個々のイベントを評価しますが、参照リスト、データテーブル、単純な一致ウィンドウを組み込みます。ストリーミング エンジンではなくクエリ エンジンを使用して実行されますが、ストリーミング エンジンに近い低レイテンシのほぼリアルタイムのスケジュールでスケジュールされます。

  • 参照リストとデータテーブルの単一イベント ルール:

    これらの単一イベントルールは、マルチイベント一致ウィンドウを必要とせずに、参照リストまたはデータテーブルに対してルックアップを実行します。

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

    これらの単一イベント ルールには、単純なイベント数条件（$e、#e > 0、#e >= 1 など）を含む一致ウィンドウが含まれます。

マルチイベントのルール

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

  • マルチイベント ルール

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

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

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

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

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

ルールの実行頻度

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

  • 準リアルタイム: イベントが取り込まれると、最小限のレイテンシでルールが実行されます。これは、以下に適用されます。
    • すべての単一イベントルール（標準の単一イベント、参照リストまたはデータテーブルを含むルール、ウィンドウ化された単一イベントルール）。
    • 一致ウィンドウが 60 分未満のマルチイベント ルール。
  • その他の頻度: その他のルール構成では、次の頻度を設定できます。
    • 10 分間のフリークエンシーは、60 分未満のマッチ ウィンドウで有効です。
    • 1 時間と 1 日のフリークエンシーは、最長 48 時間のマッチ ウィンドウで有効です。
    • 1 日あたりのフリークエンシーは、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）が確認され、以前は見逃されていた検出がトリガーされる可能性があります。

リファレンス リスト

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

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

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

非存在ルール

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

データ処理の遅延

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

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