Scheduled Analytics Rules vs NRT Rules

Microsoft Sentinel analytics rules are the backbone of threat detection. They define conditions under which alerts are generated from ingested data. The two primary types are Scheduled and NRT (Near-Real-Time). Scheduled rules run Kusto Query Language (KQL) queries on a recurring schedule (e.g., every 5 minutes) against your Log Analytics workspace. NRT rules also run KQL queries but at a much higher frequency (every 1 minute) and with a shorter evaluation window. The key difference is latency vs. throughput: Scheduled rules can handle complex queries across large datasets, while NRT rules prioritize speed with simpler queries.

A Scheduled rule is defined with a query, a run frequency, a lookback period (query period), and alert threshold logic. When the rule triggers, Sentinel runs the query against the workspace, looking at data within the lookback period. The query returns results, and if they meet the threshold (e.g., number of results > 0), an alert is created. The schedule is independent of the lookback; for example, you can run a query every 5 minutes looking back 1 hour. This allows detection of patterns that span multiple ingestion intervals.

Key parameters: - Frequency: How often the rule runs. Default: 5 minutes. Minimum: 5 minutes. Maximum: 14 days. - Query Period: How far back the query looks. Must be >= frequency. Default: 5 hours. Maximum: 14 days. - Threshold: Number of results to trigger an alert. Default: >0. - Suppression: After an alert is generated, you can suppress further alerts for a configurable duration (up to 24 hours). - Event Grouping: Can group multiple events into a single alert (by entity or by time window).

Performance considerations: Scheduled rules can run complex joins, aggregations, and machine learning functions. However, they consume resources from the workspace. If too many rules run simultaneously, they may be throttled. Microsoft recommends keeping the total number of scheduled rules under 500 per workspace.

NRT rules are designed for scenarios where sub-minute latency is critical. They run every 1 minute and evaluate only the last 1 minute of data. The query must be simple — no cross-workspace queries, no join with more than one table, no complex aggregations like summarize over large windows. The rule processes data in near-real-time using a dedicated pipeline that bypasses the standard query engine. This reduces latency but limits query complexity.

Key parameters: - Frequency: Fixed at 1 minute. Cannot be changed. - Query Period: Fixed at 1 minute. Cannot be changed. - Threshold: Similar to scheduled rules. - Suppression: Supported. - Event Grouping: Supported but limited to single event per alert.

Limitations: - Only one table or function can be queried (no cross-table joins). - summarize is allowed but only with bin on TimeGenerated and simple aggregations like count(). - make-series and complex time-series functions are not allowed. - Maximum query length: 10 KB. - Cannot use externaldata or evaluate plugin.

Use Scheduled rules when:

Use NRT rules when:

Both rule types can generate alerts that are grouped into incidents. Incident creation can be enabled or disabled per rule. For Scheduled rules, you can configure alert grouping by entities or time windows. NRT rules automatically create one incident per alert (unless grouping is disabled). Both can trigger automation rules and playbooks.

To check rule status:

For example, find all NRT rules:

ScheduledQueryRules
| where Properties contains "NRT"
| project RuleName, Status, LastRunTime

The SC-200 exam tests your ability to select the appropriate rule type. Key differentiating factors: - Latency: NRT = ~1 minute, Scheduled = frequency (default 5 min). - Query complexity: Scheduled = high, NRT = low. - Data scope: Scheduled = lookback period (up to 14 days), NRT = last 1 minute. - Limits: NRT max 50 per workspace, scheduled max 500. - Grouping: Scheduled supports advanced grouping; NRT supports only single event per alert.

A common exam scenario: "You need to detect a DDoS attack within 30 seconds of onset. Which rule type?" Answer: NRT, because it runs every minute and has low latency. However, if the detection requires correlating firewall logs with server logs, you must use Scheduled because NRT cannot cross tables.

A large enterprise deploys Sentinel to detect ransomware early. The SOC needs to alert within 1 minute of a known ransomware process starting. The detection logic is simple: look for process creation events where the file name matches a list of known ransomware hashes. This is a perfect use case for an NRT rule because the query is simple (single table SecurityEvent or DeviceProcessEvents), the threshold is >0, and latency must be under a minute. The rule is configured to run every minute and trigger a playbook that automatically isolates the affected machine via Microsoft Defender for Endpoint. In production, the rule generates an alert on average 45 seconds after the event occurs (including ingestion delay). The SOC receives the alert before the ransomware can encrypt many files.

What goes wrong when misconfigured: If the SOC mistakenly uses a Scheduled rule with 5-minute frequency, the alert might fire 5-6 minutes after the process starts, by which time the ransomware could have encrypted critical data. Conversely, if they try to use an NRT rule with a complex query (e.g., joining process events with network logs), the query times out and no alerts are generated, leaving the threat undetected.

A financial institution needs to detect brute force attacks against its VPN. The attack typically involves hundreds of failed logins from multiple IPs over 30 minutes. The detection requires correlating multiple failed login events (from SigninLogs) and grouping by source IP. This requires a query that aggregates over a 30-minute window and filters for IPs with >10 failures. A Scheduled rule is appropriate because the query uses summarize and count() over a 30-minute lookback. The rule is set to run every 5 minutes with a 30-minute query period. It triggers an alert when any source IP has >10 failures. The alert is then escalated to the SOC for investigation.

What goes wrong when misconfigured: If an NRT rule is used, it can only look at 1 minute of data, so it would only detect a very aggressive brute force (e.g., >10 failures in 1 minute). Most attacks spread out failures to avoid detection, so NRT would miss them. Also, the query would need to be simplified to avoid joins, potentially losing correlation across different user accounts.

A healthcare provider must monitor for unauthorized data access. They need to detect when a user accesses more than 100 patient records in an hour, which could indicate data exfiltration. This requires querying OfficeActivity logs for FileAccessed events, aggregating by user over a 1-hour window. A Scheduled rule is used with a 1-hour query period and a 5-minute frequency. The rule uses summarize to count accesses per user and triggers if count > 100. The alert is sent to the compliance team.

What goes wrong when misconfigured: If the rule frequency is set too high (e.g., every 5 minutes with a 1-hour lookback), the same events are evaluated multiple times, potentially causing duplicate alerts. Proper suppression settings (e.g., suppress for 1 hour after alert) prevent this. If NRT were used, it could only detect >100 accesses in 1 minute, which is unrealistic for normal use, leading to missed detections.