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

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

Google SecOps SIEM

このドキュメントは、マルチイベントルールのカスタマイズ可能なスケジュールを構成してトラブルシューティングを行うプラットフォーム管理者と SOC アナリストを対象としています。ここでは、処理スケジュールを設定し、受信遅延データを含めるための追加のチェックを実行する方法について説明します。

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

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

一般的なユースケース

カスタマイズ可能なスケジュールを使用して、検出速度をデータの可用性と完全性と一致させます。

コンプライアンスに基づく非アクティブアカウントのモニタリング

シナリオ: 監査要件を満たすために、30 日間ログインしていないアカウントをモニタリングします。

目的: 拡充の完全性を優先します。
値: [エンリッチメントの完全性を確保する] 切り替えをオンにすることで、最終評価の前にすべてのグローバルログとメタデータが処理されるまで待機し、データの忠実度を最大限に高めます。

マルチテナント MSSP データ分離

シナリオ: マネージドセキュリティサービスプロバイダ（MSSP）として、ログ取り込み速度が異なる複数のお客様のデータを管理します。

目標: 複数の顧客環境でさまざまな取り込み速度を管理します。
値: 「偽陰性」アラートを減らします。初回実行を 1 ～ 2 時間待つことで、システムは真のアップグレード実行中にのみ表示される検出の数を減らし、ダッシュボードをモニタリングする SOC アナリストに一貫性のあるエクスペリエンスを提供します。

主な用語

初回実行（𝑇 + オフセット）: ルールロジックの初回実行。オフセットは、遅延して到着したデータを考慮するために追加された遅延を表します。
調整実行: 最初の実行後に到着したログまたはエンリッチメントデータをキャプチャするために、同じ期間のバックグラウンドで再評価を行います。
拡充: 処理中にログに追加される外部メタデータ（アセットタグやユーザーエイリアスなど）。

始める前に

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

権限

必須: ルールスケジュールを変更するには、次のアクションを付与する IAM ロールが必要です。

detection:ModifyRuleSchedule

事前定義ロール:

roles/detectionEngine.admin
roles/detectionEngine.editor

環境チェック

ルールタイプ: カスタマイズ可能なスケジュールは、マルチイベントルールにのみ適用されます。単一イベントルールとキュレートされたルールは除外されます。
match ウィンドウ: match ウィンドウが 48 時間を超えるルールは、毎日の実行頻度に制限されます。
移行: 以前のスケジュールをカスタマイズ可能なスケジュールに移行するプロセスは一方向であり、元に戻すことはできません。

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

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

Google SecOps で、[検出] > [ルールと検出] に移動します。
[ルールダッシュボード] をクリックします。
ルールを見つけて、[その他] more_vert をクリックし、[スケジュールを実行] を選択します。
[ルールのスケジュール] タブで、[初回実行スケジュール] フィールドの値を選択し、ルールの実行頻度を選択します。
[遅延データに合わせて初回実行を調整する] 切り替えボタンをオンにします。
- 想定される障害: オフセットがソースの実際の取り込みレイテンシよりも短い場合、初回実行でログが欠落する可能性があります。
- 修正手順: オフセットを増やすか、最終検証で True-up 実行に依存します。
[エンリッチメントの完全性を確保する] 切り替えをオンにします。
- 想定される障害: アラートがイベントのタイムスタンプよりも大幅に遅れて表示されることがあります。
- 修正ステップ: 速度よりも精度が重要な重要度の低いコンプライアンスルールにのみ使用します。
ルールスケジュールのプレビューを確認して、実行タイムラインを理解します。
- 初回実行（𝑇 + オフセット）: システムは、遅延して到着したデータに対して指定した遅延の後にルールロジックを実行します。
- 調整実行 1（𝑇 + 4 時間）: システムは、最初の実行から 4 時間後にウィンドウを再スキャンして、欠落したデータや遅延したデータを取得します。[エンリッチメントの完全性を確保する] 切り替えをオンにすると、この実行では、関連するすべてのエンリッチメントデータが処理されるまで待機します。
- 調整実行 2（𝑇 + 30 時間）: この実行は、[エンリッチメントの完全性を確保する] 切り替えをオンにした場合にのみ表示されます。システムは、最初の実行から 30 時間後に最終スキャンを実行し、データの忠実度を最大限に高めます。
[保存] をクリックします。

スケジュールのプレビューについて

スケジュールプレビューでは、検出ロジックの特定のマイルストーンが特定されます。これらのバックグラウンド実行を使用して、検出までの平均時間（MTTD）を正確に測定し、アラートの完全性を検証します。

初回実行（𝑇 + オフセット）

初回実行では、できるだけ早く脅威を特定します。一部のデータは転送中またはエンリッチメント中である可能性があるため、初回実行時の検出が予想よりも遅れることがあります。

True-up 実行

True-up の実行では、時間枠が自動的に再評価されます。これらの実行により、プラットフォームは次の情報を取得できます。

遅延ログ: 最初の実行が完了した後にプラットフォームに到達したデータ。
拡充コンテキスト: 追加のバックグラウンド処理が必要なメタデータ（アセット ID やユーザーエイリアスなど）。

トラブルシューティング

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

制限事項

マルチイベントルールのみ: この機能は単一イベントルールでは使用できません。
カスタムルールのみ: キュレートされたルールでは、変更できない固定スケジュールが使用されます。キュレートされたルールを表示すると、Curated rules use a legacy schedule というメッセージが表示されます。

エラーの修復

エラー	問題	修正
オプションが表示されない	[ルールのスケジュール] タブがグレー表示されているか、オプションが表示されない。	ルールがマルチイベントカスタムルールであり、一致ウィンドウが 48 時間以内であることを確認します。
アラートの遅延	検出がスケジュールされた間隔よりも遅れて到着する。	[Ensure enrichment completeness] 切り替えがオンになっているかどうかを確認します。システムがメタデータの処理を待機している可能性があります。
調整アラートのみ	検出は初回実行（`𝑇`）では表示されません。	[取り込みレイテンシ] をクリックして確認します。ログの到着が 15 分遅れていて、オフセットが 10 分の場合は、初回実行のオフセットを増やします。

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

初回実行（𝑇）で検出されず、調整実行（𝑇+4$ または 𝑇+30$）で検出された場合は、次の点を確認します。

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

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

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

ルールタイプを確認する: カスタマイズ可能なスケジュールは、マルチイベントルールにのみ適用されます。単一イベントルールは継続的（リアルタイム）エンジンを使用し、カスタムスケジュールをサポートしていません。
match ウィンドウを確認する: match ウィンドウが 48 時間を超えるルールは、毎日の実行頻度に制限され、カスタマイズできません。
キュレートされたルールを特定する: キュレートされたルールのスケジュールは変更できません。Curated rules uses a legacy schedule メッセージを探して、ルールが保護されたシステムルールかどうかを確認します。

初回実行アラートの遅延

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

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

MTTD の測定値が高い

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

バッファを確認する: 1 時間のスケジュールの場合、システムはイベントが到着してから 1 ～ 2 時間後にイベントを評価します。
速度を最適化する: レイテンシを短縮する必要がある場合は、ルールをリアルタイム スケジュールに移行します。注: これにより、完全な精度を確保するために調整実行に依存する検出の数が増える可能性があります。

検出元を特定する

Google SecOps では、初期検出とバックグラウンドの再実行中に検出されたものを区別するために、視覚的なインジケーターが使用されます。

検出インジケーター

[検出タイプ] 列のは、調整実行、再処理実行、遡及的ハンティングによる検出を識別します。

このアイコンが表示されている場合、検出は初回実行（𝑇）ではなく、調整実行（𝑇+4$ または 𝑇+30$）中に行われました。
このアイコンが表示された検出は、通常、ログの遅延やエンリッチメントの遅延により、プラットフォームが最初の取り込み後に脅威をキャプチャしたことを示しています。

アラートページでアラートの整合性を確認する

[アラート] ページのは、アラートのソースを示します。タイムラインを調査するときに、このインジケーターを使用してアラートのソースを確認します。

アイコンのないアラートは、初回実行（𝑇）または継続的エンジンから発生します。
のアラートは、システムが後でデータスキャンを実行して脅威を特定し、精度を最大限に高めたことを示します。

検証とテスト

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

ルールダッシュボードに移動します。
ルールを選択し、[検出] タブを表示します。
でフィルタして、True-up 実行で最初の実行で取得できなかったデータが取得されているかどうかを確認し、それに応じてオフセットを調整します。

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