2.5.2. Sentinel Analytics Rules
💡 First Principle: Sentinel analytics rules turn KQL over workspace tables into alerts, and their settings decide how raw query results become investigable incidents: which columns become entities, how many results make one alert, and how alerts group into incidents. A rule that fires correctly but produces 400 one-alert incidents has still failed the SOC.
The rule types each fit a job:
| Type | How it works | Key constraints |
|---|---|---|
| Scheduled | Your KQL runs at an interval over a lookback period; results above a threshold raise alerts | Built-in five-minute delay for ingestion lag; the most flexible and most common type |
| Near-real-time (NRT) | Runs every minute over data ingested in the previous minute | Up to 50 NRT rules per tenant; up to 30 alerts per run (the 30th summarizes the rest); limited event grouping; two-minute delay; for sources with low ingestion latency |
| Threat intelligence | Microsoft Defender Threat Intelligence analytics matches CEF, Syslog, and DNS events against Microsoft indicators; built-in indicator templates match your imported indicators (2.2.5) | Microsoft rule isn't customizable |
| Machine learning behavior analytics | Built-in ML detects anomalous SSH and RDP logins | Not customizable |
| Anomaly | ML baselines that write to the Anomalies table | No alerts (2.5.3) |
A scheduled rule's wizard covers the decisions the exam asks about. Rule logic: the query, entity mapping (up to 10 entity mappings per rule, each with up to three identifiers, mapped from result columns using identifiers such as an account's UPN or a host's name), custom details (surfacing extra columns on the alert), and alert details (dynamic title and description from result columns). Query scheduling: run frequency and lookback ("run every 1 hour, look up data from the last 1 hour" avoids gaps and overlaps). Alert threshold: how many results must appear. Event grouping: one alert for all results, or one alert per result. Suppression: stop running for a period after the rule fires. Incident settings: whether alerts create incidents, and alert grouping, which combines related alerts from the same rule into one incident within a time window, optionally only when entities match.
Onboarding Sentinel to the Defender portal changes two rule types. Incident creation moves to Defender XDR's correlation engine, so Microsoft security (incident creation) rules are automatically disabled, and Fusion (advanced multistage detection) is unavailable because XDR correlation replaces it. Analytics rules keep an access token so they continue to work if their creator leaves; rules querying across tenants or subscriptions use the creator's credentials and fail if that access is lost.
⚠️ Exam Trap: "A rule must alert within one minute of ingestion and must join three tables over 14 days of data" can't be NRT, which evaluates only the last minute of ingested data. Use a scheduled rule (or redesign the logic). Conversely, "alert as fast as possible on a single high-value event in SigninLogs" fits NRT.
Reflection Question: A brute-force rule produces one incident per failed sign-in, overwhelming the queue. Which two settings, one on event grouping and one on incident alert grouping, consolidate the noise without losing detections, and what entity mapping must exist for grouping by entity to work?
