Configure customized schedules for rules

Supported in:

Google secops SIEM

This document is for Platform Admins and SOC Analysts who want to configure and troubleshoot customizable schedules for multi-event rules. It explains how to set processing schedules and run extra checks to include late-arriving data.

By following the process described in this document, you gain precise control over detection latency and data integrity. Successful completion ensures that your detections are both timely and accurate, reducing false negatives caused by ingestion delays and ensuring consistent security operations.

Customizable schedules provide transparency and control over how multi-event rules run in Google Security Operations. Multi-event rules require a buffer period to aggregate data accurately; this method lets you define that period rather than relying on system defaults.

Note: When this feature is enabled, the system labels all existing multi-event rule schedules as "legacy". You can migrate your custom rules legacy schedules for custom rules to the new customizable system. Once you migrate the rule schedule to the new system, you can't revert it to a legacy schedule.

Common use cases

Use customizable schedules to align your detection speed with data availability and completeness.

Compliance-based inactive account monitoring

Scenario: You monitor for accounts that have not logged in for 30 days to satisfy an audit requirement.

• Objective: Prioritize enrichment completeness.
• Value: Ensures maximum data fidelity by turning on the Ensure enrichment completeness toggle, which waits for all global logs and metadata to process before the final evaluation.

Multi-tenant MSSP data segregation

Scenario: As a Managed Security Service Provider (MSSP), you manage data for multiple customers with varying log ingestion speeds.

• Objective: Manage varying ingestion speeds across multiple customer environments.
• Value: Reduce "false negative" alerts. By waiting 1 to 2 hours for the first run, the system reduces the number of detections that only appear during true-up runs, providing a more consistent experience for the SOC analysts monitoring the dashboard.

Key terminology

• First run (𝑇 + offset): The initial execution of the rule logic. The offset represents the delay added to account for late-arriving data.
• True-up run: A background re-evaluation of the same time window to capture logs or enrichment data that arrived after the first run.
• Enrichment: External metadata (like asset tags or user aliases) added to logs during processing.

Before you begin

Before you attempt to modify or automate your rule schedules, make sure that your environment and account meet the necessary security and system requirements. When you validate these prerequisites, it helps prevent deployment errors and makes sure that your detection logic aligns with your organization's Identity and Access Management policies.

Permissions

Required: To modify rule schedules, you must have an IAM role that grants the following action:

detection:ModifyRuleSchedule

Predefined roles:

• roles/detectionEngine.admin

• roles/detectionEngine.editor

Environment check

• Rule type: Customizable schedules apply only to multi-event rules. Single-event and curated rules are excluded.
• match window: Rules with a match window greater than 48 hours are restricted to a Daily run frequency.
• Migration: Migrating a legacy schedule to a customizable schedule is a one-way process and cannot be reverted.

Configure the schedule for a multi-event rule

To configure the schedule for a multi-event rule, follow these steps:

1. In Google SecOps, go to Detection > Rules & Detections.
2. Click Rules Dashboard.
3. Locate your rule and click More more_vert and select Run schedule.
4. On the Rule schedule tab, select a value for the First run schedule field, and select how often the rule runs.
5. Turn on the Adjust first run for late-arriving data toggle.
   • Anticipated failure: The first run might still miss logs if the offset is shorter than your source's actual ingestion latency.
   • Corrective step: Increase the offset or rely on the True-up runs for final validation.
6. Turn on the Ensure enrichment completeness toggle.
   • Anticipated failure: Alerts may appear significantly later than the event timestamp.
   • Corrective step: Only use this for non-critical compliance rules where accuracy is more important than speed.
7. Review the Rule schedule preview to understand the run timeline:
   • First run (𝑇 + offset): The system executes the rule logic after the delay you specify for late-arriving data.
   • True-up run 1 (𝑇 + 4 hours): The system re-scans the window 4 hours after the first run to capture missed or late data. If you turn on the Ensure enrichment completeness toggle, this run also waits for all associated enrichment data to process.
   • True-up run 2 (𝑇 + 30 hours): This run only appears if you turn on the Ensure enrichment completeness toggle. The system performs a final scan 30 hours after the first run to provide maximum data fidelity.
8. Click Save.

Understand the schedule preview

The schedule preview identifies the specific milestones for your detection logic. Use these background runs to accurately measure Mean Time to Detection (MTTD) and verify alert integrity.

First run (𝑇 + offset)

The first run identifies threats as quickly as possible. Because some data may still be in transit or undergoing enrichment, detections in the first run might arrive later than expected.

True-up runs

True-up runs proactively re-evaluate the time window. These runs let the platform capture the following:

• Late-arriving logs: Data that reached the platform after the first run completed.
• Enrichment context: Metadata, such as asset identities or user aliases, that required additional background processing.

Troubleshooting

Investigate scheduling issues by reviewing the evaluation timing and rule configuration. While the platform automates most scheduling tasks, certain settings or data delays can impact when detections appear.

Limitations

• Multi-event rules only: This feature is unavailable for single-event rules.
• Custom rules only: Curated rules use fixed schedules that you can't modify. If you view a curated rule, the system displays the message: Curated rules use a legacy schedule.

Error remediation

Error	Issue	Fix
Missing options	Rule schedule tab is grayed out or options are missing.	Verify the rule is a multi-event custom rule and the match window is under 48 hours.
Delayed alerts	Detections arrive later than the scheduled interval.	Check if the Ensure enrichment completeness toggle is on; the system may be waiting for metadata processing.
Only true-up alerts	Detections never appear in the first run (𝑇).	Click Ingestion Latency to verify. If logs arrive 15 mins late but your offset is 10 mins, increase the first-run offset.

Detections only appear in true-up runs

If a detection doesn't appear during the first run (𝑇), but appears in a true-up run (𝑇+4$ or 𝑇+30$), check the following:

• Ingestion latency: Check if the log source has a delay. If logs arrive 15 minutes after the event occurs, a 10-minute first-run schedule will miss them. The true-up runs capture these late arrivals.
• Context enrichment: Confirm if the rule relies on external metadata, such as asset tags or user aliases. If the enrichment process takes longer than the first-run window, the detection only surfaces after the system completes the enrichment in a later run.

Customizable options are missing

If the Rule schedule tab doesn't show customization options or the menu is grayed out:

• Check the rule type: Customizable schedules apply only to multi-event rules. Single-event rules use the continuous (real-time) engine and don't support custom schedules.
• Verify the match window: Rules with a match window greater than 48 hours are restricted to a Daily run frequency and can't be customized.
• Identify curated rules: You can't modify the schedule for curated rules. Look for the Curated rules uses a legacy schedule message to confirm if the rule is a protected system rule.

Unexpected delay in first-run alerts

If a detection arrives later than the scheduled interval:

• Initialization period: New or recently modified rules require a one-hour initialization period. Detections don't surface until the platform completes this initial setup and begins the first scheduled cycle.
• Enrichment wait times: If you turn on the Ensure enrichment completeness toggle, the system may dynamically adjust timing to wait for data enrichment processes to finish. While this process prevents missed detections, it can cause the initial detection to arrive later than the exact 𝑇 timestamp.

MTTD measurements seem high

The MTTD measurements include the settling period required for data completeness.

• Review the buffer: For a one-hour schedule, the system evaluates events one to two hours after they arrive.
• Optimize for speed: If you require lower latency, transition the rule to a realtime schedule. Note: This can increase the number of detections that rely on true-up runs for full accuracy.

Identify detection sources

Google SecOps uses visual indicators to help you distinguish between initial detections and those surfaced during background re-runs.

Detection indicators

In the Detection type column, the identifies detections from true-up runs, reprocessing runs, or retrohunts.

• If you see this icon, the detection occurred during a true-up run (𝑇+4$ or 𝑇+30$) rather than the initial run (𝑇).
• Detections with this icon often indicate that the platform captured the threat after initial ingestion, usually because of late-arriving logs or enrichment delays.

Verify alert integrity in the alerts page

The on the Alerts page indicates the source of an alert. Use this indicator to verify the source of an alert when investigating a timeline.

• Alerts without an icon originate from the first run (𝑇) or the continuous engine.
• Alerts with signal that the system identified the threat during a later data scan to provide maximum accuracy.

Validation and testing

To verify your schedule is working as intended, follow these steps:

1. Go to the Rules Dashboard.
2. Select your rule and view the Detections tab.
3. Filter by to see if your True-up runs are catching data that the first run missed, then adjust your offsets accordingly.

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