ルールのパフォーマンスをモニタリングする
このガイドは、Google Security Operations でルールを作成、デプロイ、モニタリングするセキュリティ エンジニアを対象としています。このドキュメントでは、Google SecOps インスタンスで使用可能なデータを使用して、ルールが意図したとおりに機能し、リソースを過剰に消費していないことを確認するためにルールをモニタリングする方法について説明します。このデータは、検出の遅延をデバッグしたり、遅延して到着したエンリッチメント データがルールに与える影響を把握したり、平均検出時間（MTTD）が最も長いルールを特定したりするのに役立ちます。
このガイドでは、次のタスクに関するドキュメントを提供します。
ルールの初回リリース時にルールを評価し、アラートを受信して、ルール ダッシュボードでルールの健全性をモニタリングする方法。
検出の遅延の原因（取り込みの遅延や非効率的なロジックなど）を特定し、検出までの平均時間（MTTD）のレポートを調整するか、追加のルール除外を使用してルールを調整する方法。
始める前に
このドキュメントで説明するルールを表示して変更するには、Chronicle API 編集者である必要があります。詳細については、Google Security Operations のロールと権限をご覧ください。
Google SecOps でルールの有効性を分析する前に、YARA-L 言語、YARA-L クエリ、ルールの作成と管理の方法、ダッシュボードの作成方法について十分に理解しておく必要があります。
主な用語
- ルール: ログデータが Google SecOps アカウントに取り込まれると、脅威が自動的に特定されます。
- 割り当て: データ取り込み量、データに対して実行できるクエリの数と複雑さ、Google SecOps アカウントで有効になっているルールの数と複雑さの上限。
- アラートと検出: Google SecOps と独自のセキュリティ インフラストラクチャによって特定された、対応が必要なセキュリティの問題。
- 取り込み: セキュリティ データを Google SecOps にインポートして UDM に変換するプロセス。
- ルールの再生: 関連するコンテキスト データが最初のイベント データよりも遅れて到着または処理された場合に、既存のデータに対してルールを自動的に再実行します。
- Retrohunt: 新しいルールを既存のデータに適用して、以前に検出されなかった脅威を特定します。
ルールの分析方法
以降のセクションでは、ルールのパフォーマンスを分析する方法について説明します。
デプロイ後にルールをテストして評価する
ルールを初めて本番環境にデプロイする場合は、Rule Observability ダッシュボードで 24 ～ 48 時間モニタリングします。
[ダッシュボード] に移動します。
Rule Observabilityを検索します。[ルール] 列で新しいルールを検索します。[Rule Observability] ダッシュボードには、検出数、取り込みレイテンシ、取り込みから検出までの時間などの統計情報が表示されます。
ルールロジックが優先度の高いアラートの生成を開始する前に、人工的な遅延が発生しないようにするには、検出のスキーマ リファレンスを使用します。スキーマは、セキュリティ アラートのモニタリングに使用される構造化形式を定義します。検出頻度、リスク分布、ルールのパフォーマンスの追跡に最適化されています。クエリの例をよく見ると、スキーマの使用方法をより深く理解できます。
ルール結果の遅延の理由を特定する
次の手順に沿って、ルールの結果が遅延しているかどうか、遅延している場合はその理由を特定します。
- [検出] > [アラートと IOC] に移動します。
- [アラート] タブで、[検出タイプ] 列を見つけます。
- 黄色の電球アイコンの付いたアラートを探します。
- アイコンにカーソルを合わせると、次のいずれかによって検出がトリガーされたかどうかが表示されます。
- ルールの再処理: ルールの再生によって生成されます
- Retrohunt: ユーザーが手動でトリガーします。
- 遅延イベントデータ: 遅延到着データが原因でルールが再生された場合に生成されます。
ルールの再処理によって作成された検出の詳細については、ルールの再生をご覧ください。
検出時間に基づいてアラートをフィルタする
[検出] > [アラートと IOC] に移動します。
[アラート] タブで、[検出時間] 列のフィルタ要素を使用して、検出を到着時間に基づいて並べ替えます。
表の上部にある更新アイコン をクリックし、[今すぐ更新] をクリックします。Google SecOps アカウントに届いた最新のアラートと、各アラートに関連付けられているルールを確認できます（[ルール名] 列を確認してください）。
メタデータを調べる
ルールのパフォーマンスに関する詳細な分析情報を得るには、latencyMetrics を使用して未加工の検出 JSON を検査し、oldestEventTime と oldestIngestionTime の違いを確認します。
検出タイミングの値
次の表に、DetectionTimingDetails に関連付けられている列挙値を示します。
値 |
説明 |
MTTD の影響 |
|---|---|---|
|
標準のスケジュール設定ウィンドウ内で作成された検出。 |
MTTD のグラウンド トゥルース。 |
|
ルール再生（遅延データなど）により生成されます。 |
運用リスクを表します。レポートで考慮する必要があります。 |
|
過去のレトロハントの実行で生成されました。 |
通常、標準の MTTD レポートから除外されます。 |
例: latencyMetrics メタデータ
次の latencyMetrics の例は、イベントが発生した時刻（oldestEventTime と newestEventTime）とイベントが取り込まれた時刻（oldestIngestionTime と newestIngestionTime）の差を示しています。イベントと Google SecOps アカウントへの取り込みの間のレイテンシは約 53 分です。
"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
"oldestIngestionTime": "2025-12-09T16:54:14Z",
"newestIngestionTime": "2025-12-09T16:54:14Z",
"oldestEventTime": "2025-12-09T16:01:06Z",
"newestEventTime": "2025-12-09T16:01:06Z"
}
|
|---|
トラブルシューティング
次の表に、ルールで発生する可能性のある問題とその解決方法を示します。
問題 |
解決策 |
|---|---|
電球アイコンが表示されるが、列挙が UNSPECIFIED. |
イベント時刻と取り込み時刻の差が 30 分を超えると、この動作は正常です。データ ヘルスハブの指標を使用して、取り込みの遅延の原因を調査します。 |
イベントの時刻に対して検出が遅れて表示される。 |
detectionTimingDetails を確認します。列挙値が REPROCESSING の場合、遅延はルール実行のレイテンシではなく、エンリッチメント データの遅延が原因である可能性があります。UNSPECIFIED の場合は、ルールロジックの効率性を調査します。 |
過剰なコンピューティング。 |
ルールがスキャンするデータが多すぎるか、ロジックが非効率的である可能性があります。[ルールの除外] に移動するか、フィルタ オフロードを使用して、ルールのデータ検索を絞り込むように調整します。 |
既知の制限事項
- しきい値の厳密さ: 遅延データの視覚的な合図は 30 分のしきい値で固定されており、ユーザー定義のレイテンシ ウィンドウは考慮されません。
- データの健全性: ルールのオブザーバビリティはルールの健全性を示しますが、データ健全性モニタリング（取り込みに近い）は、一般的な遅延データの問題を検出するのに効果的です。
- 割り当ての適用: ダッシュボードにはリソース使用量が表示されますが、ルールが割り当て上限に近づいたときにリアルタイムで通知されることはありません。
次のステップ
ルールの再生とルールの検出の遅延については、以下をご覧ください。
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。