ルールのカスタマイズされたスケジュールを構成する

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

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

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

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

このドキュメントと併せて、ルール実行スケジュールを管理する方法についてもご覧ください。

主な用語

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

始める前に

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

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

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

    • バッチ API の更新と UI の使用状況の chronicle.rules.modifyRules。

  • 環境チェック:

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

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

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

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

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

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

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

  • True-up runs: 時間枠を事前に再評価します。これらの実行により、プラットフォームは次の情報を取得できます。

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

検出元を特定する

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

検出インジケーター

[検出タイプ] 列の は、調整実行、再処理実行、または RetroHunt からの検出を識別します。

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

アラート ページでアラートの完全性を確認する

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

トラブルシューティング

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

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

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

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

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

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

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

初回実行アラートの遅延

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

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

MTTD の測定値が高い

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

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

制限事項

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

エラーの修復

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

検証とテスト

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

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

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