2.5.3. MITRE ATT&CK Coverage and Anomalies

💡 First Principle: Coverage is a question about the whole set of detections, not any single rule: across the attacker behaviors that matter to us, where do we have eyes and where are we blind? Mapping rules to ATT&CK techniques makes that question answerable. Anomalies attack the problem from the other side: instead of encoding known patterns, they learn what normal looks like and flag deviations for investigation.

The MITRE ATT&CK page in Sentinel (Threat management > MITRE ATT&CK) lays the matrix out by tactic and technique and shows coverage from your active scheduled and NRT rules, hunting queries, and anomaly rules. It can also simulate coverage from rules and queries that are available but not yet enabled, which makes it a planning tool: filter to a tactic, find techniques with no active detection, then enable templates, write custom rules, or add hunting queries for the gap. Coverage is only as good as the tagging: rules you write should carry the correct tactics and techniques (custom detections and analytics rules both have MITRE fields), and SOC optimization's coverage recommendations (2.1.3) apply the same matrix to specific threat scenarios.

Anomaly rules use machine learning baselines to flag unusual behavior, such as atypical volumes of downloads, unusual sign-in locations, or rare process executions. Key behaviors to remember:

• Anomaly rules are enabled by default and write their findings to the Anomalies table, with an AnomalyReasons field explaining what was unusual.
• They do not raise alerts or incidents. Use their output in hunting and investigation, or build a scheduled rule on top of the Anomalies table if a particular anomaly should alert.
• Built-in anomaly rules can't be edited. To tune one, duplicate it; the copy runs in Flighting mode (staging) alongside the original in Production so you can compare results, then switch the tuned copy to Production, which moves the original to Flighting. Only one version runs in Production at a time.
• Too many anomalies usually means the threshold is too low; raise it in the duplicate.

Anomalies are especially useful for entity enrichment. When an analyst investigates a user, recent anomalies for that user add context that no single rule captured. User and Entity Behavior Analytics (UEBA) builds similar behavioral baselines for users and hosts and feeds entity pages and the BehaviorAnalytics table.

⚠️ Exam Trap: "Tune the threshold of a built-in anomaly rule without losing the original's results during testing" means duplicate the rule and run the copy in Flighting mode, not edit the built-in rule (not allowed) and not disable the original first.

Reflection Question: The ATT&CK page shows strong coverage for Initial Access and none for Exfiltration. Describe three different actions you could take to close the gap, and how you'd confirm each actually improved detection rather than just the heat map.