ルールのカスタム スケジュールを構成する

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

Google SecOps SIEM

このドキュメントは、Google Security Operations がルールの実行をスケジュールする方法を構成して管理するセキュリティ アナリスト、エンジニア、プラットフォーム管理者を対象としています。カスタム マルチイベント ルールの実行頻度の調整、決済遅延の構成、調整タイムラインの管理について説明します。

このドキュメントで説明するプロセスに沿って操作すると、検出レイテンシとデータの完全性を正確に制御できます。正常に完了すると、検出がタイムリーかつ正確になり、取り込みの遅延による偽陰性が減少し、一貫したセキュリティ運用が保証されます。

カスタマイズ可能なスケジュールにより、Google Security Operations でマルチイベント ルールがどのように実行されるかを把握し、制御できます。一部のマルチイベント ルールでは、データを正確に集計するためにバッファ期間が必要になることがあります。この方法を使用すると、システム デフォルトに依存するのではなく、その期間を定義できます。

注意: この機能を有効にすると、既存のすべてのマルチイベント ルール スケジュールに「以前のバージョン」というラベルが付けられます。カスタムルールの以前のスケジュールを新しいカスタマイズ可能なシステムに移行できます。ルールのスケジュールを新しいシステムに移行すると、以前のスケジュールに戻すことはできません。

一般的なユースケース

カスタマイズ可能なスケジュールを使用すると、特定の運用目標に合わせて実行パラメータを調整できます。

• 短期間の関連付け: 一致ウィンドウが 60 分未満のマルチイベント ルールを 10 分の頻度で実行し（デフォルトの 1 時間間隔を待つのではなく）、ブルート フォース攻撃などの時間依存型の脅威をより迅速に検出します。
• 取り込みレイテンシの補正: 配信の遅延がわかっているログソースに対して、決済遅延（T + オフセット）を構成し、プライマリ実行に想定されるすべてのイベントが含まれるようにします。
• コンテキストの完全性の確保: 最終評価の前にエンティティとアセットのメタデータの完全な解決を必要とする、重要度の低いコンプライアンス ルールとフォレンジック ルールに対して、[Ensure enrichment completeness] 切り替えを有効にします。

主な用語

• プライマリ実行（T + オフセット）: 受信データに対するルールロジックの初期実行。決済遅延は、遅れて到着するデータを考慮するために追加されるオフセットを表します。
• 決済の遅延: ルール評価が開始される前に遅延到着ログを処理できるように、プライマリ実行に追加されるバッファ期間。
• 調整実行: 同じ期間のバックグラウンド再評価。プライマリ実行後に到着したログデータまたは拡充データを取り込みます。
• 拡充: 処理中にログに追加される外部メタデータ（アセットタグやユーザー エイリアスなど）。

始める前に

ルール スケジュールを変更または自動化する前に、環境とアカウントがセキュリティとシステムに関する必要な要件を満たしていることを確認してください。これらの前提条件を検証すると、デプロイエラーを防ぎ、検出ロジックが組織の Identity and Access Management ポリシーに沿っていることを確認できます。

• 権限: ルール スケジュールを変更するには、次の IAM 権限が必要です。

  • 個々のスケジュール更新の API 使用状況の chronicle.ruleDeployments.update。

  • バッチ API の更新と UI の使用状況については、chronicle.rules.modifyRules をご覧ください。

  Chronicle API 管理者（roles/chronicle.admin）や Chronicle API 編集者（roles/chronicle.editor）などの事前定義 IAM ロールを使用する場合、これらの権限は自動的に含まれます。

• 環境チェック:

  • ルールの種類: カスタマイズ可能なスケジュールは、マルチイベント ルールにのみ適用されます。シングル イベントルール（標準ルール、ウィンドウ ルール、参照ベースのルールを含む）は、ほぼリアルタイムで評価され、カスタマイズできません。キュレートされたルールは固定システム スケジュールを使用するため、除外されます。
  • match ウィンドウ: match ウィンドウが 48 時間を超えるマルチイベント ルールは、自動的に割り当てられた match_window / 10 の頻度で実行され、カスタマイズできません。
  • 移行: 以前のスケジュールをカスタマイズ可能なスケジュールに移行するプロセスは一方向であり、元に戻すことはできません。

マルチイベント ルールのスケジュールを構成する

複数イベント ルールのスケジュールを構成する手順は次のとおりです。

1. Google SecOps で、[検出] > [ルールと検出] に移動します。
2. [ルール ダッシュボード] をクリックします。
3. ルールテーブルでルールを見つけて、その他アイコン more_vert をクリックし、[スケジュールを実行] を選択します。
4. [ルールのスケジュール] タブで、[プライマリ実行] セクションを構成します。
   1. [Set Frequency] リストで、ルールの実行頻度（[Every 10 min] や [Every 1 Hour] など）を選択します。
   2. （省略可）遅れて到着するデータを考慮するには、[決済の遅延] 切り替えをオンにします。
   3. [遅延] フィールドに遅延値を入力し、[単位] メニューから時間単位（分または時間）を選択します。
5. [True-up run] セクションで、[Ensure enrichment completeness] 切り替えをオンにします（省略可）。
   • 予測される障害: 外部コンテキスト ソースの処理に時間がかかると、イベントのタイムスタンプよりも大幅に遅れてアラートが表示されることがあります。
   • 修正ステップ: コンテキストの忠実度が即時アラートの速度よりも優先される、重要度の低いコンプライアンス ルールとフォレンジック ルールにのみ使用します。
6. [プライマリ実行] と [調整実行] で実行タイムラインを確認します。
   • 初回実行: システムは、遅れて到着したデータに対して指定した決済遅延の後にルールロジックを実行します。
   • 調整実行 1: システムは、プライマリ実行の 4 時間後にウィンドウを自動的に再スキャンして、見逃したデータや遅延したデータを取り込みます。[エンリッチメントの完全性を確保する] をオンにすると、この実行では関連するエンリッチメント データが処理されるまで待機します。
   • 調整実行 2: [エンリッチメントの完全性を確保する] をオンにした場合にのみ表示されます。システムは、プライマリ実行の 30 時間後に最終スキャンを実行して、データの忠実度を最大限に高めます。
7. [保存] をクリックします。

トラブルシューティング

評価のタイミングとルール構成を確認して、スケジューリングの問題を調査します。プラットフォームではほとんどのスケジューリング タスクが自動化されていますが、特定の設定やデータの遅延によって、検出が表示されるタイミングに影響が生じることがあります。

検出は調整実行でのみ表示される

プライマリ実行（T）で検出が表示されず、調整実行（T + 4 時間または T + 30 時間）で検出が表示される場合は、次のことを確認します。

• 取り込みレイテンシ: ログソースに遅延があるかどうかを確認します。イベントの発生から 15 分後にログが到着した場合、10 分間の初回実行スケジュールではログが検出されません。調整実行では、これらの遅延到着データを取り込みます。
• コンテキストの拡充: ルールがアセットタグやユーザー エイリアスなどの外部メタデータに依存しているかどうかを確認します。エンリッチメント プロセスがプライマリ実行ウィンドウよりも長くかかると、検出は、システムが後続の調整実行でエンリッチメントを完了した後にのみ表示されます。

カスタマイズ可能なオプションが見つからない

[ルールのスケジュール] タブにカスタマイズ オプションが表示されない場合や、メニューがグレー表示になっている場合:

• ルールのタイプを確認する: カスタマイズ可能なスケジュールは、マルチイベント ルールにのみ適用されます。単一イベントルール（標準ルール、ウィンドウ ルール、参照ベースのルールを含む）は準リアルタイムで評価され、カスタム スケジュールはサポートされていません。
• match ウィンドウを確認する: match ウィンドウが 48 時間を超えるマルチイベント ルールは、自動的に割り当てられた match_window / 10 の頻度で実行され、カスタマイズできません。
• キュレートされたルールを特定する: キュレートされたルールのスケジュールは変更できません。キュレートされたルールを検査すると、UI に Multi-event curated rules use a legacy schedule というメッセージが表示されます。

初回実行アラートの遅延

検出がスケジュールされた間隔よりも遅れて到着した場合:

• 初期化期間: 新しいルールや最近変更されたルールには、1 時間の初期化期間が必要です。プラットフォームがこの初期設定を完了し、最初のスケジュールされたサイクルを開始するまで、検出は表示されません。
• エンリッチメントの待機時間: [エンリッチメントの完全性を確保する] 切り替えをオンにすると、データ拡充プロセスが完了するまで待機するように、タイミングが動的に調整されることがあります。このプロセスにより検出漏れを防ぐことができますが、最初の検出が正確な T タイムスタンプよりも遅れて到着する可能性があります。

MTTD の測定値が高い

MTTD の測定には、データの完全性に必要なバッファリング期間が含まれます。

• バッファを確認する: 1 時間のスケジュールの場合、システムはイベントが到着してから 1 ～ 2 時間後にイベントを評価します。
• 速度を最適化する: レイテンシを短縮する必要がある場合は、ルールを 10 分のスケジュール（60 分未満の一致ウィンドウの場合）に構成するか、イベント集計が不要な場合は、検出ロジックをほぼリアルタイムで実行される単一イベント ルールに変換します。

制限事項

• マルチイベント ルールのみ: この機能は、単一イベント ルールでは使用できません。シングル イベント ルール（標準ルール、ウィンドウ ルール、参照ベースのルールを含む）は、ほぼリアルタイムで評価されます。
• カスタムルールのみ: キュレーション ルールでは、変更できない固定スケジュールが使用されます。キュレートされたルールを表示すると、Multi-event curated rules use a legacy schedule というメッセージが表示されます。以前のカスタムルールを表示すると、Your Multi-Event rule uses a legacy schedule が表示されます。

エラーの修復

エラー	問題	修正
オプションが表示されない	ルール スケジュール タブがグレー表示されているか、オプションが表示されない。	ルールがマルチイベント カスタムルールであり、一致ウィンドウが 48 時間以下であることを確認します。キュレートされたルールと単一イベントルールはカスタマイズできません。
サポートされていない間隔	ほぼリアルタイムのストリーミングを選択できない。	イベント間の相関関係を必要とするマルチイベント ルールや、集計（count や sum など）を使用するルールには、スケジュール設定されたバッチクエリ エンジンが必要です。
アラートの遅延	検出がスケジュールされた間隔よりも遅れて到着する。	[Ensure enrichment completeness] 切り替えがオンになっているかどうかを確認します。システムがメタデータの処理を待機している可能性があります。
調整アラートのみ	検出はプライマリ実行（T）には表示されません。	ログ取り込みのレイテンシを確認します。ログの到着が 15 分遅れているが、決済遅延が 10 分の場合は、決済遅延を増やします。

検証とテスト

スケジュールが意図したとおりに動作していることを確認する手順は次のとおりです。

1. Google SecOps で、[検出] > [ルールと検出] に移動し、[ルール ダッシュボード] を選択します。
2. ルールを選択し、[検出] タブを表示します。
3. [検出タイプ] 列を確認し、 でフィルタして、調整実行でメイン実行で検出されなかったデータが検出されているかどうかを確認し、それに応じて決済遅延を調整します。

次のステップ

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

• ルール実行のスケジューリングについて理解する: Google SecOps がルール構成を継続的なストリーミングとスケジュールされたバッチクエリ エンジンにマッピングする方法について説明します。
• ルールの再生と MTTD について: 自動化された調整実行で、遅れて到着したデータとコンテキストの更新が処理され、検出までの平均時間（MTTD）指標に影響する仕組みについて説明します。
• ルールの検出遅延を理解する: 取り込みパイプラインと処理パイプライン全体で、予測された遅延と予測されなかった遅延を診断して解決します。
• ルール エディタを使用してルールを管理する: Google SecOps でカスタム検出ルールを作成、編集、管理します。

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