Detection Coverage Mapping: From Attack Technique to Evidence

Open most detection coverage maps and you will find a grid of ATT&CK techniques shaded by how many rules mention each one. The shading answers a single question: does a rule exist? It does not answer the questions a SOC lead or CISO needs answered. Will the rule see the technique as an attacker actually performs it? Is the data it depends on being collected? Will the alert reach someone who knows what to do with it?

Those are separate failures with separate owners. Coverage mapping becomes useful when it records each of them. This explainer follows one technique from attacker behavior to analyst action and shows where the chain usually breaks.

Why a heatmap overstates coverage

Take OS Credential Dumping: LSASS Memory (T1003.001) as an illustration. A team can write a rule for it in an afternoon. Whether that rule detects anything depends on facts the rule file does not contain: whether process-access telemetry for the LSASS process is collected from the endpoints that matter, whether the field holding the requested access rights is parsed and searchable, and whether the logic survives the other routes to the same memory.

Those routes differ. An attacker can use a dedicated tool, a built-in utility such as comsvcs.dll invoked through rundll32, or capture memory from outside the guest operating system, for example from a virtual machine snapshot. A rule written around one route leaves the others open, and the heatmap shows the technique green for all of them. This is a hypothetical case used to show the mechanism, not a finding about any organization.

ATT&CK has moved toward this way of thinking. Its data sources model has been deprecated, and detection guidance is now organized as detection strategies for each technique. Each strategy groups platform-specific analytics, and data components describe the telemetry those analytics need. The structure gives you a vocabulary for the chain: strategy, analytic, data component. It does not tell you whether your environment collects the data or whether your analytic works. That part belongs to you.

The evidence chain

A technique is covered only when every link below holds for the variants you care about. In practice a heatmap usually records the fifth link and nothing else.

Links 2 to 4 are where coverage most often disappears without anyone noticing. A rule that cannot receive its data never fires, never produces a false positive, and never draws attention. It looks like a quiet environment.

Recording coverage so it can be trusted

Replace binary shading with states that say what has actually been shown:

• Not covered. No telemetry and no logic.

• Telemetry only. The data is collected and searchable, but no detection logic exists. This is an honest state, and it is where threat hunting starts.

• Rule exists. Logic is deployed but has not been validated.

• Validated. The behavior was executed in a controlled test, for named variants, and the alert was observed.

• Validated and actionable. As above, and the alert carries context, has an owner and has a runbook.

Each record should hold the technique and the variants in scope, the telemetry required and where it comes from, collection status by environment segment, the logic reference, the last validation result and what was tested, the response owner, and a field for known blind spots. The blind-spot field is the one most teams leave out and the one leadership needs most. It converts an unknown risk into a stated one.

Measuring depth, not just presence

MITRE Center for Threat-Informed Defense runs a project called Summiting the Pyramid that scores detection beyond an ATT&CK heatmap. It looks at two things: implementation coverage, meaning how many behavioral variations of a technique an analytic can detect, and detection quality, meaning how robust and precise the underlying signal is.

You do not need to adopt its scoring to use the idea. For each rule, ask how many ways an attacker could perform this technique and still avoid it, and how easily the signal could be defeated by changing a tool name or an argument. A rule that fails the second question is detecting a tool, not a technique.

Choosing what to map first

Mapping all of ATT&CK is neither feasible nor useful. Start with the techniques that appear in the activity of actors targeting your sector, plus the techniques that sit on realistic paths to your most important systems and data. Ten to fifteen techniques mapped properly will tell you more than three hundred shaded loosely. That number is a working recommendation, not a standard.

Give early priority to techniques that use legitimate tools. Joint guidance from CISA and partner agencies on living-off-the-land activity notes that such behavior is difficult to distinguish from normal administration and that many organizations lack the capabilities to detect it. For these techniques the outcome is decided by telemetry and baselines, links 2 and 5, long before it is decided by rule volume.

Where SIEM, threat intelligence and the SOC fit

• SIEM. Links 3 to 5 usually live here. Cost-driven ingestion changes quietly remove telemetry, so any filter change should be reviewed by whoever owns the coverage record. A SIEM stores and queries data; it does not by itself provide detection capability.

• Threat intelligence. It defines which variants matter at link 1 and should trigger a review when actor behavior shifts. Intelligence that never changes a coverage record is not yet being used.

• SOC or MDR. They own link 7. If a provider triages your alerts, confirm which of your detections they operate, on what telemetry, and who is responsible for validating them. Ownership that is unclear at this link produces coverage that exists on paper only.

Where to start

1. Pick ten techniques from your threat model and the attack paths to your crown jewels.

2. For each, complete all seven links honestly, including the ones you suspect are broken.

3. Execute each in-scope variant in a controlled test and record whether the alert fired and how long it took to reach an analyst.

4. Report the result as states and blind spots, not as a percentage. A percentage invites debate about the denominator. A list of known gaps invites decisions.

Next step

**** Start with the ten techniques your threat model ranks highest and build their evidence chains before writing another rule. Cybrilliant works with security teams on detection engineering and can review an existing coverage map against these seven links.

Sources

1. MITRE ATT&CK, Detection Strategies. https://attack.mitre.org/detectionstrategies/

2. MITRE ATT&CK, Data Sources (deprecated) and Data Components. https://attack.mitre.org/datasources/

3. MITRE Center for Threat-Informed Defense, Summiting the Pyramid. https://ctid.mitre.org/projects/summiting-the-pyramid

4. CISA and partner agencies, Identifying and Mitigating Living Off the Land Techniques. https://cisa.gov/resources-tools/resources/identifying-and-mitigating-living-land-techniques