Analyze rule effectiveness and efficiency

Supported in:

This guide is for security engineers who create, deploy, and monitor rules in Google Security Operations. It explains how to monitor rules to ensure they are working as intended and aren't consuming resources excessively using the data available in your Google SecOps instance. This data helps you debug delayed detections, understand the impact of late-arriving enrichment data on rules, and identify which rules have the highest mean time to detect (MTTD).

This guide provides documentation on the following tasks:

  • How to evaluate a rule during its initial release, receive alerts, and check the Rules Dashboard to monitor its health.

  • How to identify the cause of any detection delays (for example, whether it was due to late ingestion or inefficient logic) and either adjusting Mean Time to Detect (MTTD) reporting or tuning the rule with additional Rule exclusions.

Before you begin

To view and modify rules as described in this document, you need to be a Chronicle API Editor. For more information, see Google Security Operations roles and permissions.

Prior to analyzing the effectiveness of rules in Google SecOps, you should develop a good understanding of the YARA-L language, YARA-L queries, how to create and manage rules, and how to create dashboards:

Key terminology

  • Rules: Identify threats automatically as log data is ingested into your Google SecOps account.
  • Quotas: Limits on your data ingestion volume, the number and complexity of queries you can run against your data, and the number and complexity of the rules you have active in your Google SecOps account.
  • Alerts and detections: Security issues identified by Google SecOps and your own security infrastructure that require your attention.
  • Ingestion: Process of importing your security data to Google SecOps and converting it to UDM.
  • Rule replays: Automatic reruns of rules against existing data in the event that relevant context data arrives or is processed later than the initial event data.
  • Retrohunt: Apply new rules to existing data to identify previously undiscovered threats.

How to analyze rules

The following sections describe how to analyze the performance of your rules.

Test and evaluate rules after deployment

When you first deploy a rule to production, monitor it in the Rule Observability dashboard for 24 to 48 hours:

  1. Navigate to Dashboards

  2. Search for Rule Observability.

  3. Search for the new rule in the Rule column. The Rule Observability dashboard includes statistics like the detection count, ingestion latency, and the time from ingestion to detection.

To ensure the rule logic isn't introducing artificial delays before it begins to generate high-priority alerts, you can use the schema reference for detections. The schema defines the structured format used to monitor security alerts. It's optimized for tracking detection frequency, risk distribution, and rule performance. You can get a better sense of how to use the schema by taking a close look at the Query examples.

Identify reason for rule result delay

Complete the following steps to determine whether rule results are delayed and, if so, why:

  1. Navigate to Detections > Alerts & IOCs.
  2. On the Alerts tab, find the Detection Type column.
  3. Search for alerts with a yellow light bulb icon.
  4. Hover over the icon to see if the detection was triggered by any of the following:
    • Rule reprocessing: Triggered manually by a user.
    • Retrohunt: Triggered manually by a user.
    • Delayed event data: Indicates if a detection delay is expected.

Filter alerts based on detection time

  1. Navigate to Detections > Alerts & IOCs.

  2. On the Alerts tab, use the filter element for the Detection time column to sort detections based on their arrival time.

  3. Click the refresh icon at the top of the table and click Refresh Now. You can see the latest alerts arriving in your Google SecOps account and the rule associated with each alert (check the Rule name column).

Examine metadata

For additional insight into how your rules are performing, you can inspect the raw detection JSON using latencyMetrics to find the difference between the oldestEventTime and theoldestIngestionTime.

Detection timing values

The following table lists the enumerated values associated with DetectionTimingDetails:


Value
Description
MTTD impact

UNSPECIFIED


Detection created within the standard scheduling window.
Ground truth for MTTD.

REPROCESSING


Generated due to a rule replay (for example, late-arriving data).
Represents operational risk; should be accounted for in reports.

RETROHUNT


Generated through a historical retrohunt run.
Typically filtered out of standard MTTD reporting.

Example: latencyMetrics metadata

The following latencyMetrics example shows the time difference between when an event occurred (oldestEventTime versus newestEventTime) and when the event was ingested (oldestIngestionTime versus newestIngestionTime). The latency between the event and the ingestion into the Google SecOps account is about 53 minutes.

"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"
}

Troubleshooting

The following table lists some of the issues you might have with your rules and how to resolve them:


Issue
Resolution

Lightbulb icon appears, but the enumeration is UNSPECIFIED.
This is normal behavior when the delta between event time and ingestion time exceeds 30 minutes. Use the Data Health Hub metrics to investigate the source of the ingestion delay.

Detection appears late relative to the time of the event.
Check the detectionTimingDetails. If the enumeration value is REPROCESSING, the delay is likely due to late-arriving enrichment data rather than rule execution latency. If UNSPECIFIED, investigate the efficiency of the rule logic.

Excess compute.
The rule is likely scanning too much data or has inefficient logic. Navigate to Rule Exclusions or use Filter Offloading to tune the rule to narrow its data search.

Known limitations

  • Threshold rigidity: The visual cue for late data is fixed at a 30-minute threshold and doesn't account for user-defined latency windows.
  • Data health: Rule observability informs rule health, but data health monitoring (closer to ingestion) is more effective for catching general late-arriving data issues.
  • Quota enforcement: While the dashboard shows resource usage, it doesn't provide real-time notifications when rules are nearing a quota limit.

What's next

For information on rule replays and rule detection delays, see the following:

Need more help? Get answers from Community members and Google SecOps professionals.