DE1.3 Scheduled Rules — Frequency and Trigger Logic

Detection latency explained

Detection latency — the time between a technique executing and the alert firing — has two components: ingestion latency (how long between the event occurring and it appearing in the workspace) and rule latency (how long between the event appearing in the workspace and the next rule execution).

Ingestion latency varies by data source. Microsoft first-party connectors (SigninLogs, DeviceProcessEvents, EmailEvents) typically ingest within 1-5 minutes. Third-party connectors via CEF/Syslog vary from 1-15 minutes depending on the forwarder configuration and batching interval. Custom tables via Data Collection Rules vary widely — some near real-time, some batched hourly.

Rule latency equals the query frequency. A rule that runs every 5 minutes has a maximum rule latency of 5 minutes (the event arrives just after the last execution) and an average rule latency of 2.5 minutes. A rule that runs every hour has an average rule latency of 30 minutes.

Total detection latency = ingestion latency + rule latency. For a SigninLogs query running every 5 minutes: approximately 3 minutes ingestion + 2.5 minutes average rule latency = approximately 5.5 minutes average total detection latency. For the same query running every hour: 3 minutes + 30 minutes = 33 minutes.

Figure DE1.3 — Detection latency by frequency with NE-specific examples. Higher frequency = faster detection = more compute. The NE allocation distributes compute budget across severity tiers.

Frequency selection by severity

Not every rule needs to run every 5 minutes. The frequency should match the severity and urgency of the detection — and the available compute budget.

Critical severity → NRT or 5-minute frequency. Detections where delayed detection leads to irreversible damage. Ransomware pre-encryption (vssadmin shadow copy deletion), confirmed credential compromise (LSASS memory access), active C2 beacon activation. For these, consider NRT rules (DE1.6) instead of 5-minute scheduled rules. Limit to 3-5 rules at this frequency.

High severity → 5-15 minute frequency. Detections where the attack is in progress but containment within 15 minutes prevents significant damage. AiTM token theft, lateral RDP to a domain controller, PIM Global Admin activation, suspicious inbox rule creation from a risky session. The attacker has a foothold but has not achieved their objective. Allocate 10-15 rules at this frequency.

Medium severity → 30 minutes to 4 hours. Detections where the pattern is suspicious but not confirmed malicious. Anomalous sign-in properties, unusual file access volumes, first-time access to a sensitive resource, app registration with elevated permissions. These require investigation to confirm. Running them at 5-minute frequency adds alert volume without proportional detection value. Allocate 15-25 rules.

Low/Informational severity → 12-24 hours. Detections for posture monitoring — configuration changes, new app registrations, permission grants, user lifecycle events. These are not incidents requiring immediate response. They are data points for the daily security review or the weekly posture report. Allocate 10-15 rules.

Trigger logic

The trigger condition determines when the query results become an alert. The default trigger is “Alert when number of query results is greater than 0” — any row returned generates an alert.

Threshold triggers filter for volume-based patterns. A single failed sign-in is normal. Fifty failed sign-ins from one IP in 30 minutes is a password spray. Setting the trigger to “greater than 50” means the rule fires only when the aggregate threshold is exceeded — not on every individual failure. The threshold applies to the row count returned by the query, not to a field within the results. If your query uses summarize count() by IPAddress and returns 3 rows (3 IPs each exceeding the threshold), the trigger evaluates against “3 rows returned” — it fires because 3 > 0.

Dynamic thresholds via KQL: For more sophisticated triggering, encode the threshold in the query itself rather than the trigger configuration. Use | where FailedAttempts > 50 and DistinctUsers > 5 in the KQL — the query returns 0 rows when the condition is not met (no alert) and returns rows only when the multi-dimensional threshold is exceeded (alert fires). This approach keeps the trigger at “greater than 0” while the KQL handles the complex threshold logic.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// THRESHOLD IN KQL — multi-dimensional trigger
let timeWindow = 30m;
let failThreshold = 50;
let userThreshold = 5;
SigninLogs
| where TimeGenerated > ago(timeWindow)
| where ResultType == "50126"  // Invalid username or password
| summarize
    FailedAttempts = count(),
    DistinctUsers = dcount(UserPrincipalName),
    TargetUsers = make_set(UserPrincipalName, 25),
    FirstAttempt = min(TimeGenerated),
    LastAttempt = max(TimeGenerated)
    by IPAddress
| where FailedAttempts > failThreshold
    and DistinctUsers > userThreshold
// Only rows exceeding BOTH thresholds are returned
// Trigger config: "Alert when results > 0" — the KQL handles filtering

Event grouping within a trigger

When the query returns multiple rows and the trigger fires, Sentinel can handle the results in two ways:

Group all events into a single alert. All rows from the query execution are bundled into one alert. The alert details contain all results as an array. Use this for detections where the aggregate pattern is the finding (one password spray = one alert containing all targeted users).

Trigger an alert for each event. Each row produces its own alert. Use this for detections where each row represents an independent finding that requires separate tracking (each compromised account from a spray needs its own investigation thread).

The choice affects SOC workflow directly. A spray rule with “each event” grouping and 15 rows returned produces 15 alerts — if alert-to-incident grouping is also “one per alert” (DE1.9), the SOC sees 15 incidents for one attack. Usually wrong. A spray rule with “all events in one alert” produces 1 alert, which creates 1 incident containing the complete spray data. Usually correct.

Troubleshooting: Frequency and trigger issues

“My rule fires too often.” Two causes: the threshold is too low for your environment’s baseline activity, or the frequency is creating duplicate detections across overlapping lookback windows. Run the query in Advanced Hunting for 7 days. Count unique detections per day. If it exceeds 10 per day for a single rule, increase the threshold or add filtering.

“My rule never fires.” Either the threshold is too high (no events reach it), the attack pattern does not occur, or the lookback/frequency alignment is wrong (DE1.2). Validate by running the query manually against a known time period when the activity should have occurred.

“My rule fires with stale data — alerting on events from hours ago.” The lookback window is too long relative to the frequency. If the rule runs every hour with a 24-hour lookback, events from 23 hours ago are re-evaluated on every execution. Without deduplication (alert grouping), the same event generates alerts repeatedly. Reduce the lookback to match the frequency + buffer, or configure alert grouping to suppress duplicates.

References used in this subsection

• Course cross-references: DE1.2 (lookback window), DE1.5 (severity-frequency alignment), DE1.6 (NRT for sub-minute latency), DE1.9 (alert-to-incident grouping), DE9 (threshold tuning)