Microsoft Sentinel Analytics Rules — Detection Engineering & MITRE ATT&CK

① The five analytics rule types — your detection menu

Every Microsoft Sentinel alert is born from one of five analytics rule types. Scheduled rules are KQL queries you author (or deploy from the Content Hub) that run on a configurable interval — every 5 minutes to once a day — against Log Analytics tables. They are the workhorse of custom detection engineering. Near-Real-Time (NRT) rules are a special subset: hardcoded to run every minute with sub-5-minute end-to-end latency, ideal for high-priority detections like privilege escalation or credential spray where seconds matter.

Microsoft Security rules require no KQL at all: they auto-import alerts from connected Microsoft products — Microsoft Defender for Endpoint, Microsoft Defender for Cloud, Microsoft Defender for Identity, and others — and let you filter by product and severity threshold. Fusion is a Microsoft-managed ML engine you cannot author yourself; it correlates seemingly unrelated low-fidelity signals across multiple attack stages (initial access, lateral movement, exfiltration) into a single high-confidence multistage-attack incident. Anomaly rules use ML to build a behavioural baseline over time and fire when an entity strays significantly from that baseline — no static threshold needed.

② Scheduled & NRT rules — writing KQL detections that hold up

A Scheduled rule has four key dials: the KQL query itself, the query frequency (how often it runs), the lookback window (how far back the query looks each time), and the alert threshold (how many results trigger an alert). The most common mistake is setting a lookback shorter than the frequency — you create a gap and miss events. Set lookback to at least equal the frequency, or longer for slow-burn detections.

Entity mapping and alert grouping

Entity mapping tells Sentinel which KQL columns are Accounts, Hosts, IPs, or URLs so the SOC can pivot on them. Alert grouping controls whether multiple rule hits within a time window merge into one incident or create separate ones — merge aggressively to reduce alert fatigue. NRT rules share the same KQL and entity-mapping interface but strip away the frequency dial (always 1 minute) and restrict queries to a single table for speed. Use NRT for your top-tier, time-sensitive detections only; their compute cost is higher.

③ Fusion & Anomaly rules — letting ML carry the heavy multistage load

Fusion is Sentinel's correlation engine for multistage attacks. It ingests signals from across your connector estate — anomalous sign-ins, impossible travel, malware detections, suspicious process execution, unusual data access — and uses scalable ML to find combinations that indicate a coherent kill-chain even when no single signal crosses a threshold. The output is a Fusion incident with all contributing signals listed, mapped to MITRE ATT&CK tactics, and a high confidence score. You cannot tune the Fusion model directly, but you can toggle which source signal types it consumes.

Anomaly rules work differently: each rule observes one specific behaviour (e.g. login-hour distribution, data-volume per user, process execution patterns) over a training window, sets a statistical baseline, and fires a low-severity anomaly record when an entity drifts beyond the threshold. Anomalies are not incidents by themselves — they feed Fusion and can be queried in hunting. The important operations task is to set the anomaly rule to Flighting mode first, validate the baseline fits your environment, then promote to Production.

④ Detection tuning & MITRE ATT&CK coverage — closing the gaps

Detection engineering in Sentinel has two loops. The first is tuning: start in Observe mode (rule creates alerts but no incidents), watch the false-positive rate for a week, add KQL where exclusions or tighten entity filters, then promote to Active. Use watchlists (CSV lookup tables in Sentinel) to maintain exception lists without touching the KQL query itself — update the watchlist, not the rule. Use automation rules to auto-close known-safe patterns the moment an incident opens.

The second loop is coverage. Sentinel's MITRE ATT&CK page shows a heat-map of every active and available rule mapped to a technique cell. Cells that are empty mean no active rule covers that technique — an adversary using it would be invisible. Detection engineers review this matrix, prioritise the emptiest cells against their threat model, and deploy or write rules to fill them. Content Hub solutions (Microsoft-authored rule packs for specific products and threats) are the fastest way to add coverage; custom Scheduled rules fill the remaining gaps specific to your environment.