ルール実行のスケジュール設定について
このドキュメントは、Google Security Operations がルールの実行をスケジュールする方法を理解して管理したいセキュリティ アナリスト、エンジニア、プラットフォーム管理者を対象としています。ルールの構成によって処理頻度がどのように決定されるか、システムが準リアルタイム ストリーミングとスケジュールされたバッチ処理のバランスをどのように取るか、バックグラウンド実行で遅れて到着したログとコンテキストの拡充がどのように処理されるかについて説明します。
一般的なユースケース
適切なスケジュールを選択または理解するには、脅威の重大度とロジックの複雑さを考慮する必要があります。
- 優先度の高いアラート: 追加のイベント相関関係を必要としない単一イベントの一致について、重大な脅威をほぼリアルタイムで検出し、攻撃者の滞留時間を短縮します。
- 複雑な関連付けとレポート: カウント、合計、スライディング一致ウィンドウを計算するマルチイベント ルールに、スケジュールされた間隔(10 分や 1 時間など)を使用します。スケジュールされた間隔により、システムは実行前に関連するログを取り込んで拡充し、コンプライアンスと傾向分析のアラートの精度を高めます。
主な用語
- 決定論的頻度: ルールの照合期間とルールタイプに基づいてシステムが自動的に割り当てるベースライン実行間隔。
- プライマリ実行(T + オフセット): イベント時間ブロックに対する検出ロジックの最初の実行。決済遅延は、遅延して到着したデータを考慮するために追加されたオフセットを表します。
- 決済の遅延: ルール評価が開始する前に遅延到着ログを処理できるように、プライマリ実行に追加されるバッファ期間。
- 調整実行(ルール再生): 以前に処理された時間枠を再評価して、プライマリ実行後に到着したログまたは拡充データをキャプチャする自動バックグラウンド実行。
- エンリッチメント: パイプライン処理中にログにコンテキスト(アセットのメタデータ、ユーザー ID、脅威インテリジェンス指標など)を追加するプロセス。
- 検出の遅延: イベントのタイムスタンプと検出の作成までの合計経過時間。
始める前に
環境が次の要件を満たしていることを確認します。
- 権限: ルール スケジュールを変更するには、Chronicle API 管理者(
roles/chronicle.admin)または Chronicle API 編集者(roles/chronicle.editor)の IAM ロールが必要です。ルール ダッシュボードでスケジュールを検査するには、Chronicle API 閲覧者(roles/chronicle.viewer)ロールが必要です。 - 環境チェック: スケジュールされた間隔集計をサポートするために、ログが Unified Data Model(UDM)にマッピングされていることを確認します。
ルール スケジューリングの仕組み
Google SecOps は、数千ものルールにわたって、ほぼリアルタイムの検出レイテンシとプラットフォームの安定性のバランスを取ります。このプラットフォームでは、主に次の 2 つの実行モデルを使用します。
- ストリーミング エンジン: 標準の単一イベント ルールとウィンドウ化された単一イベント ルール(一致ウィンドウが 48 時間を超える場合でも)を準リアルタイムで継続的に評価します(通常は取り込みから 5 分以内)。遅延イベントと遡及的エンリッチメントは、標準実行中に継続的に評価されます。
- スケジュール設定されたクエリ エンジン: 複雑な単一イベント ルール(参照リストまたはデータテーブルを含む)をほぼリアルタイムで評価し、マルチイベント ルールをイベント時間のバッチ処理ブロック(10 分または 1 時間の間隔、または 48 時間を超えるウィンドウの
match_window / 10など)で評価します。マルチイベント ルールでは、ソース間でイベントを集計して関連付けるための時間枠が必要です。
デフォルトのスケジュール構成
ルールを有効にすると、Google SecOps はルールのロジックと一致ウィンドウに基づいて、デフォルトの実行頻度を自動的に決定します。
| ルールのタイプとウィンドウ サイズ | 実行頻度 | 評価のタイミング | 調整実行 |
|---|---|---|---|
| 単一イベントルール(標準またはウィンドウ) | リアルタイム | 到着後まもなく(5 分以内) | いいえ。 標準実行で遅延データとエンリッチ化されたデータを継続的に評価します。 |
| 単一イベント ルール(参照リストまたはデータテーブルを使用) | ほぼリアルタイム | 到着後まもなく(5 分以内) | いいえ。 標準クエリの実行中に、遅延データとエンリッチ化されたデータを継続的に評価します。 |
マルチイベント ルール(window <= 48h) |
1 時間ごと(または 10 分ごと。ウィンドウ < 1 時間の場合はカスタマイズ可能) | 到着後 1 ~ 2 時間 | はい。自動の 4 時間の調整実行と、オプションの 30 時間の調整実行が含まれます。 |
マルチイベント ルール(window > 48h) |
match_window / 10(例: 10 日間の照合期間の場合、1 日ごと) |
照合期間によって異なる(match_window / 10) |
いいえ。後続の重複実行中に、遅延データと拡充データを評価します。 |
自動調整実行
取り込みレイテンシや、遅れて到着するエンリッチメント メタデータ(アセットタグやユーザー エイリアスなど)が原因で検出漏れが発生しないように、システムはマルチイベント ルール(window <= 48h)のバックグラウンドで自動的に調整実行を行います。
- 初回実行: スケジュールされた間隔に基づいて可能な限り早く実行され、直近の脅威を検出します。
- 最初の調整実行(4 時間): 最初の実行から約 4 時間後に時間ブロックを再評価し、遅れて到着したログを取得します。このステージでは、データが完全に拡充されるまで待機しません。
- 2 回目の調整実行(30 時間):(省略可)すべての追加のコンテキストとデータ拡充パイプラインが完了してから約 30 時間後に実行されます。
調整の動作とシナリオの詳細については、ルールの再生と MTTD についてをご覧ください。
カスタマイズ可能なスケジュール
一致ウィンドウが 48 時間以下のカスタム マルチイベント ルールの場合、Google SecOps では、システム デフォルトに完全に依存するのではなく、スケジュール パラメータをカスタマイズできます。
- 頻度の選択: [10 分ごと](一致ウィンドウが 60 分未満の場合)や [1 時間ごと] などの実行頻度を選択します。
- 決済の遅延: 既知のログソース取り込みレイテンシに対応するために、バッファ遅延(T + オフセット)を追加します。
- 拡充の完全性: 最終評価の前にすべての外部メタデータの結合が完了するように、調整処理を 30 時間に延長します。
構成手順の詳細については、ルールのカスタム スケジュールを構成するをご覧ください。
ルール ダッシュボードでのスケジュールの可視性
[ルール ダッシュボード] の [ルール スケジュール] 列には、アクティブな各ルールに割り当てられた実行スケジュールが表示されます。無効なルールでは、有効になるまで有効なスケジュールは表示されません。
カスタム マルチイベント ルールの実行頻度を変更したり、決済遅延を追加したり、エンリッチメントの待機時間を調整したりするには、ルールのカスタム スケジュールを構成するをご覧ください。
検出元のインジケーター
[アラート] ページと [ルール ダッシュボード] の [検出タイプ] 列には、検出が最初の実行に起因するものか、自動バックグラウンド実行に起因するものかが示されます。
- アイコンなし: 検出は、プライマリ実行(T)中または継続的ストリーミング エンジンを使用して生成されました。
- 電球アイコン : 検出は、30 分以上遅れて到着したイベントデータ、自動化された調整実行、再処理パイプライン、またはレトロハントから発生しました。
レイテンシとトラブルシューティングに関する考慮事項
ルールの実行頻度は、検出の速度に直接影響します。ルールを設計してモニタリングする際は、次の動作に注意してください。
- 1 時間ごとのスケジュール: 利用可能な最新のデータを使用して 1 時間ごとに実行されます。デフォルトでは追加のバッファは適用されません。
- 一致期間が 48 時間を超える: システムはこれらのルールを
match_window / 10のレートで実行し、調整実行は行いません。 - 実行間の不一致: ログの取り込みが遅延した場合や、コンテキストの拡充(エンティティ グラフの解決など)が最初の評価後に完了した場合、最初の実行でトリガーされなかった検出が、調整実行でトリガーされることがあります。
- カスタマイズ オプションがない: 単一イベントルールは準リアルタイムで評価され、間隔のカスタマイズはサポートされていません。キュレーションされたルールは、固定のシステム スケジュールに従います。一致ウィンドウが 48 時間を超えるカスタム マルチイベント ルールは、
match_window / 10の頻度で実行され、カスタマイズできません。 - サポートされていない間隔: ほぼリアルタイムの実行を選択できない場合、ルールは時間経過に伴うイベントの関連付けを必要とするマルチイベント ルールであるか、スケジュール設定されたバッチクエリ エンジンを必要とする集計(
countやsumなど)が含まれています。
詳細なトラブルシューティングの手順については、ルールの検出遅延についてをご覧ください。
次のステップ
関連するスケジューリングのコンセプトと構成ワークフローについては、次のドキュメントをご覧ください。
- ルールのカスタム スケジュールを構成する: マルチイベント ルールの実行頻度、決済の遅延、調整の充実度をカスタマイズします。
- ルールの再生と MTTD について: 自動化された調整実行で、遅れて到着したデータとコンテキストの更新が処理され、検出までの平均時間(MTTD)指標に影響する仕組みについて説明します。
- ルールの検出遅延を理解する: 取り込みパイプラインと処理パイプライン全体で、予測された遅延と予測されなかった遅延を診断して解決します。
- ルール エディタを使用してルールを管理する: Google SecOps でカスタム検出ルールを作成、編集、管理します。
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。