Skip to content
Ongoing2026Detection engineering

38 ATT&CK-mapped analytics rules

Every rule written for a small, quiet tenant, mapped to a tactic, and tuned so cadence and grouping produce signal instead of a queue of duplicates.

Microsoft SentinelKQLMITRE ATT&CKAnalytics rulesEntity mapping
0
rules
0
categories
0
data sources

The problem

Vendor analytics rules leave gaps in ATT&CK coverage and fire noisily out of the box. Ad-hoc hunting doesn't compound. Manual response drifts under load. The result is that "what are we covered for?" becomes a guess instead of a list.

The approach

One rule per behaviour, each mapped to a MITRE ATT&CK tactic so coverage and gaps stay explicit on a matrix. Every rule is written for a small, quiet tenant — thresholds like "more than eight failures in ten minutes" are meaningful with a handful of accounts and meaningless with thousands, so they carry a note to re-baseline before deploying anywhere real.

Cadence is split deliberately by source. A decoy has no legitimate users, so its rules run every 5–30 minutes: any activity is hostile, false positives are near zero, fast detection costs nothing. Rules over real traffic — website, identity, control plane — run hourly, because faster evaluation produced multiple incidents for the same attacker and an analyst queue that's mostly duplicates trains people to close things without reading them.

What got built

Thirty-eight scheduled-query rules across six categories — honeypot, web application, identity and authentication, Azure control plane, threat intelligence, and operations. Each carries its real KQL, severity, cadence, MITRE mapping, entity mappings and incident-grouping settings, exported from a live workspace rather than written as examples.

The full library is browsable, with the query for each rule and a copy button — under Detections.

What it taught

The alert-to-incident ratio is a configuration choice, not a property of the rule — event grouping and incident grouping decide whether one rule produces fifty incidents or one. Benign-positive and false-positive are not the same close reason: false-positive means fix the rule, benign-positive means the rule worked and the activity was authorised. If analysts conflate them, the tuning data is wrong and a working detection gets weakened. And the two settings that actually decide whether a detection is useful or ignored — cadence and grouping — are the two that don't transfer unchanged from a lab to a busy tenant.