ルールにカスタマイズされたスケジュールを構成する
このドキュメントは、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で実行され、カスタマイズできません。- 移行: レガシー スケジュールからカスタマイズ可能なスケジュールへの移行は一方向のプロセスであり、元に戻すことはできません。
マルチイベント ルールのスケジュールを構成する
マルチイベント ルールのスケジュールを構成する手順は次のとおりです。
- Google SecOps で、[検出] > [ルールと検出] に移動します。
- [ルール ダッシュボード] をクリックします。
- ルールテーブルでルールを見つけて、[More] more_vert をクリックし、[Run schedule] を選択します。
- [ルール スケジュール] タブで、[プライマリ実行] セクションを構成します。
- [Set Frequency] リストで、ルールの実行頻度([Every 10 min] や [Every 1 Hour] など)を選択します。
- (省略可)遅延到着データを考慮するには、[Settlement delay] 切り替えをオンにします。
- [Delay] フィールドに遅延値を入力し、[Unit] メニューから時間単位([Minutes] または [Hours])を選択します。
- [True-up run] セクションで、[Ensure enrichment completeness] 切り替えをオンにします(省略可)。
- 想定される障害: 外部コンテキスト ソースの処理に時間がかかると、アラートがイベントのタイムスタンプよりも大幅に遅れて表示されることがあります。
- 修正手順: コンテキストの忠実度が即時アラートの速度よりも優先される、重要度の低いコンプライアンス ルールとフォレンジック ルールにのみ使用してください。
- [プライマリ実行] と [調整実行] の実行タイムラインを確認します。
- プライマリ実行: 遅延到着データに対して指定した決済遅延の後、システムはルールロジックを実行します。
- 調整実行 1: プライマリ実行から 4 時間後に、システムはウィンドウを自動的に再スキャンして、欠落したデータや遅延したデータをキャプチャします。[Ensure enrichment completeness] をオンにすると、この実行では関連する拡充データの処理も待機します。
- 調整実行 2: [Ensure enrichment completeness] をオンにした場合にのみ表示されます。システムはプライマリ実行から 30 時間後に最終スキャンを実行し、データの忠実度を最大限に高めます。
- [保存] をクリックします。
トラブルシューティング
評価タイミングとルール構成を確認して、スケジュールの問題を調査します。プラットフォームはほとんどのスケジューリング タスクを自動化しますが、特定の設定やデータの遅延によって検出のタイミングが影響を受ける可能性があります。
検出は調整実行でのみ表示される
プライマリ実行(T)中に検出が表示されず、調整実行(T + 4 時間またはT + 30 時間)で表示される場合は、次のことを確認してください。
- 取り込みレイテンシ: ログソースに遅延があるかどうかを確認します。イベントの発生から 15 分後にログが到着する場合、10 分の初回実行スケジュールではログが欠落します。調整実行では、これらの遅延到着データがキャプチャされます。
- コンテキストの拡充: ルールがアセットタグやユーザー エイリアスなどの外部メタデータに依存しているかどうかを確認します。拡充プロセスがプライマリ実行ウィンドウよりも時間がかかる場合、検出は、システムが後続の調整実行で拡充を完了した後にのみ表示されます。
カスタマイズ可能なオプションがない
[ルール スケジュール] タブにカスタマイズ オプションが表示されない場合や、メニューがグレー表示になっている場合は、次のことを確認してください。
- ルールタイプを確認する: カスタマイズ可能なスケジュールは、マルチイベント ルールにのみ適用されます。単一イベント ルール(標準ルール、ウィンドウ ルール、参照ベースのルールなど)はほぼリアルタイムで評価され、カスタム スケジュールはサポートされていません。
- ウィンドウを確認する
match:matchウィンドウが 48 時間を超えるマルチイベント ルールは、自動的に割り当てられた頻度match_window / 10で実行され、カスタマイズできません。 - キュレーテッド ルールを特定する: キュレーテッド ルールのスケジュールは変更できません。キュレーテッド ルールを検査すると、UI に「
Multi-event curated rules use a legacy schedule」というメッセージが表示されます。
初回実行アラートの遅延が想定外に発生する
検出がスケジュールされた間隔よりも遅れて到着する場合は、次のことを確認してください。
- 初期化期間: 新しいルールまたは最近変更されたルールには、1 時間の初期化期間が必要です。プラットフォームがこの初期設定を完了し、最初のスケジュールされたサイクルを開始するまで、検出は表示されません。
- 拡充の待機時間: [Ensure enrichment completeness] 切り替えをオンにすると、データ拡充プロセスの完了を待つためにタイミングが動的に調整されることがあります。このプロセスにより検出の欠落を防ぐことができますが、最初の検出が正確な 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 分の場合は、決済遅延を増やします。 |
検証とテスト
スケジュールが意図したとおりに動作していることを確認する手順は次のとおりです。
- Google SecOps で、[検出] > [ルールと検出] に移動し、[ルール ダッシュボード] を選択します。
- ルールを選択し、[検出] タブを表示します。
- [検出タイプ] 列を確認し、 でフィルタして、調整実行でプライマリ実行で欠落したデータがキャッチされているかどうかを確認し、必要に応じて決済遅延を調整します。
次のステップ
関連するスケジューリングのコンセプトと構成ワークフローについては、次のドキュメントをご覧ください。
- ルール実行のスケジューリングについて: Google SecOps がルール構成を継続的なストリーミング エンジンとスケジュールされたバッチクエリ エンジンにマッピングする方法について説明します。
- ルールの再生と MTTD について: 自動調整実行で遅延到着データとコンテキストの更新を処理して、平均検出時間(MTTD)指標に影響を与える方法について説明します。
- ルール検出の遅延について: 取り込みパイプラインと処理パイプラインで発生する予測可能な遅延と予測不可能な遅延を診断して解決します。
- ルールエディタを使用してルールを管理する: Google SecOps でカスタム検出ルールを作成、編集、管理します。
さらにサポートが必要な場合コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。