ルールの有効性と効率性を分析する

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

Google SecOps SIEM

このガイドは、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 に変換するプロセス。
ルール再生: 関連するコンテキストデータが最初のイベントデータよりも遅れて到着した場合や、最初のイベントデータよりも遅れて処理された場合に、既存のデータに対してルールを自動的に再実行します。
遡及検索: 新しいルールを既存のデータに適用して、これまで検出されなかった脅威を特定します。

ルールを分析する方法

以降のセクションでは、ルールのパフォーマンスを分析する方法について説明します。

デプロイ後にルールをテストして評価する

ルールを初めて本番環境にデプロイする場合は、Rule Observability ダッシュボードで 24 ～ 48 時間モニタリングします。

[ダッシュボード] に移動します。
Rule Observability を検索します。
[ルール] 列で新しいルールを検索します。[Rule Observability] ダッシュボードには、検出数、取り込みレイテンシ、取り込みから検出までの時間などの統計情報が表示されます。

ルールロジックによって優先度の高いアラートの生成が開始される前に、人工的な遅延が発生しないようにするには、検出のスキーマリファレンスを使用します。このスキーマは、セキュリティアラートのモニタリングに使用される構造化された形式を定義します。検出頻度、リスク分布、ルールパフォーマンスの追跡に最適化されています。クエリの例を詳しく確認すると、スキーマの使用方法をより深く理解できます。

ルール結果の遅延の理由を特定する

ルール結果が遅延しているかどうか、遅延している場合はその理由を特定するには、次の手順を完了します。

[検出] > [アラートと IOC] に移動します。
[アラート] タブで、[検出タイプ] 列を見つけます。
黄色の電球アイコンのアラートを検索します。
アイコンにカーソルを合わせると、検出が次のいずれかによってトリガーされたかどうかを確認できます。
- ルールの再処理: ユーザーが手動でトリガーしました。
- 遡及検索: ユーザーが手動でトリガーしました。
- 遅延したイベントデータ: 検出の遅延が予想されるかどうかを示します。

検出時間に基づいてアラートをフィルタする

[検出] > [アラートと IOC] に移動します。
[アラート] タブで、[検出時間] 列のフィルタ要素を使用して、到着時間に基づいて検出を並べ替えます。
表の上部にある更新アイコンをクリックし、 [今すぐ更新] をクリックします。Google SecOps アカウントに到着した最新のアラートと、各アラートに関連付けられたルールを確認できます（[ルール名] 列を確認してください）。

メタデータを調べる

ルールのパフォーマンスに関する詳細な分析を行うには、未加工の検出 JSON を latencyMetrics を使用して検査し、oldestEventTime とoldestIngestionTime の差を確認します。

検出タイミングの値

次の表に、 DetectionTimingDetails に関連付けられた列挙値を示します。

値	説明	MTTD への影響
`UNSPECIFIED`	標準の予約受付期間内に作成された検出。	MTTD のグラウンドトゥルース。
`REPROCESSING`	ルール再生（遅れて到着したデータなど）によって生成されました。	運用上のリスクを表します。レポートで考慮する必要があります。
`RETROHUNT`	過去の遡及検索の実行によって生成されました。	通常、標準の 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 のプロフェッショナルから回答を得ることができます。