Measuring Real Detection Coverage Against ATT&CK Sub-techniques

Why coverage measurement is harder than it looks

ATT&CK gives you a matrix. SIEM vendors give you a rule set. The assumption most teams make is that if their SIEM vendor claims coverage of a technique, the technique is covered. This assumption fails in practice for three reasons: the vendor rule may depend on a log source not collected in your environment, the rule may cover the technique in name but not in the specific sub-technique your attacker uses, and the rule may be technically correct but tuned out of production because of excessive false positives.

Measuring real coverage requires exercising each technique in the environment you actually have and observing what the SIEM actually sees.

The measurement methodology

We ran the same methodology across six enterprise SIEM deployments (four Elastic, two Splunk) using the following approach:

**Step 1: Select scope.** Not all ATT&CK techniques are relevant to every environment. We pre-filtered to the 89 sub-techniques most commonly observed in incidents affecting the target industry vertical.

**Step 2: Map log sources to sub-techniques.** For each sub-technique, document which log sources the detection depends on (Sysmon Process Create, Windows Security 4688, CloudTrail, etc.) and verify those log sources are actually flowing at the expected volume.

**Step 3: Execute atomic tests.** Using Atomic Red Team and custom scripts, execute a representative action for each sub-technique in a staging environment instrumented identically to production.

**Step 4: Verify detection.** Check the SIEM for the expected alert within the expected latency window. "Covered" requires an alert, not just the presence of a rule.

Results

Median coverage across deployments: 34%. The range was 19% to 47%. No deployment exceeded 50% coverage of the sub-techniques we tested.

The distribution was non-uniform. Discovery techniques (T1087, T1016, T1057) were consistently covered because their telemetry is easy to collect and the patterns are distinctive. Execution techniques were moderately covered. Initial access and persistence were poorly covered - below 20% in most deployments.

Defense evasion was the most interesting finding. Most deployments had the highest rule count for this tactic, but the highest false positive rates. Rules for process injection, LOLBIN abuse, and masquerading generated enough noise that most had been either disabled or de-prioritised in alert routing. The volume of rules was not matched by functional detection.

What this changes operationally

Coverage measurement at this granularity changes the operational question from "do we have rules?" to "which specific techniques can we actually detect today?" That question has a different answer, and the answer enables different prioritisation decisions. The gaps in initial access coverage, for example, argue for investing in identity-layer detection (MFA anomalies, impossible-travel alerts, account enumeration patterns) rather than more endpoint rules.