MITRE ATT&CK Coverage Is Not Detection Capability

“Our dashboard says we cover the technique, so we would catch it.”

Let me stop you before a green square becomes somebody’s incident report.

ATT&CK coverage is not detection capability.

MITRE ATT&CK is a taxonomy of adversary behaviour.

Endpoint security is a system that has to collect a signal, interpret it, put an alert in front of a person, and support a decision after your alert fires.

A mapping connects the two.

It doesn’t merge them into one thing.

That should not be controversial.

A catalogue entry isn’t a working control.

Nobody looks at a network diagram with a firewall icon and announces that every rule was tested, every packet logged, and every on-call engineer will understand your alert.

Yet attach a T-number to a product feature and suddenly the icon gets a cape.

ATT&CK gives a tactic, the adversary’s why, a TA-prefixed identifier.

It gives a technique, the how, a T-prefixed identifier.

A more specific sub-technique gets the parent T-code plus a numeric suffix.

A procedure is a cited real-world implementation in a technique’s Procedure Examples table.

Useful distinctions.

None of them is telemetry.

None is an analytic.

None is a responder during an incident deciding whether isolation will help, or cut off a production endpoint for no reason.

1. “But the EDR Vendor Maps the Feature to the Technique.”

It may be a sensible map.

It says only that your vendor believes a feature relates to the named behaviour.

Take T1055, Process Injection.

ATT&CK assigns it to Privilege Escalation, TA0004, and Stealth, TA0005.

Renamed from Defense Evasion in the Enterprise matrix in April 2026.

The technique has twelve current sub-techniques, from T1055.001 Dynamic-link Library Injection to T1055.015 ListPlanting, across Windows, macOS and Linux.

The missing .006, .007 and .010 do not mean somebody forgot to count.

ATT&CK preserves deprecated objects rather than renumbering them.

That tells you how MITRE organizes a family of behaviour.

It does not tell you which operating systems are enrolled.

Whether your agent produces the necessary events.

Whether the analytic handles the relevant variant.

Whether the console turns the result into an intelligible case.

So your dashboard’s cell is an intent claim.

It may point to an analytic.

It may point to a prevention feature.

It may point to a marketing spreadsheet that once met an intern.

The cell alone can’t tell you which.

A technique is a description of behaviour. A detection is evidence-producing logic on a particular collection path.

Treating them as synonyms is like labelling a building “fire” and concluding the sprinkler valves must work.

The vocabulary is excellent.

The water is still somebody else’s job.

2. “But the Event Source Is Enabled.”

Enabled where?

Endpoint telemetry is not a metaphysical mist that forms because your EDR tenant has a checkbox.

Collection has to occur on the actual device, on the actual supported operating system, in the actual configuration, and arrive in time for the analytic expecting it.

A source can be configured and still be absent.

Or incomplete.

Or delayed.

Or missing the relationship your rule needs.

The May 2024 RansomHub-linked incident Sophos documented makes the point without requiring any fantasy about magic telemetry.

Sophos flagged EDRKillShifter as Troj/KillAV-KG.

The observable defensive sequence was a new signed but vulnerable driver appearing, a driver-load event, and repeated process-termination attempts against security software.

The analytic was behavioural, a sequence and relationship between events, not a hash match for one static file.

That chain is why the behaviour was observable.

It is also the chain that has to exist locally.

A claim to “cover” Process Injection does not demonstrate that a particular endpoint emits all relevant driver, process and agent-health evidence.

Or that your evidence reaches your service.

Or that the analytic ties it together.

Collection status precedes analytic confidence.

An event source that is enabled but never verified is a smoke detector still in the box.

Except its administration console has a beautifully reassuring icon.

3. “But the Rule Fired in a Lab Test.”

Good.

Keep the result.

Do not promote it beyond what it earned.

A controlled test can establish that a stated procedure created an expected signal, that the intended telemetry arrived, and that a specific analytic generated an alert.

Valuable evidence.

Not proof that every endpoint population, software version, policy state, network path and operating condition behaves the same way.

Your test record needs the technique and procedure represented.

The telemetry source. Collection status.

The analytic.

The expected adversary signal.

Your environment.

Alert latency.

Investigation outcome.

False-positive owner.

Response playbook.

That isn’t paperwork for its own sake.

It is the minimum needed to learn whether your rule works as an operational control rather than as a demo.

An alert has to enter a queue, identify the affected device and user, and carry evidence somebody can investigate.

Microsoft Defender for Endpoint documents an alert page with an alert story, a tree of related entities and events, and an alert timeline, a condensed chronological view for triage.

Not decorative console furniture.

That is the translation layer between a detection engine and an analyst’s decision.

Then the analyst resolves the case as **Resolved.

True alert** with a determination, or Resolved, False alert.

A lab test ending at “rule fired” has not tested that decision.

It has tested the doorbell.

4. “But ATT&CK Evaluations Include the Product.”

They do.

Read what that means before turning it into a trophy.

ATT&CK Evaluations are open-book adversary emulations.

Vendors receive months of advance notice of the adversary being emulated and its tactics, techniques and procedures.

Detection is assessed in a controlled lab, not as a surprise intrusion.

Vendors can and are expected to tune configurations for the announced scenario.

That makes the results useful.

You can ask whether a product detected and articulated a documented behaviour under defined conditions.

It does not make the evaluation a blind red-team exercise.

Or a production deployment.

Or proof that every customer has the tested telemetry and tuning.

The methodology also separates protection testing from detection testing.

Protection testing enables defensive controls and expects them to block.

Detection testing lets the emulated intrusion continue, so investigators can assess visibility.

Recent rounds can permit a configuration change after the first detection pass.

That resembles a real SOC tuning after a miss.

It doesn’t mean the first configuration already had universal capability.

MITRE’s rule is admirably unambiguous.

It does not crown winners, publish rankings, or hand out scores.

Results are technique-level detail: the category of detection, supporting evidence, and specific emulated step.

Recent rounds also track alert volume and false-positive counts, so a vendor cannot manufacture apparent coverage with thousands of low-value alerts.

An Evaluation is dated, scenario-specific evidence. It is not a capability certificate issued to every tenant.

If a product’s logo appears in a result, your next question is “under which configuration and evidence category?”

Not “where do we hang the pennant?”

5. “But Tuning False Positives Would Take Too Long.”

Then you have learned something important.

You may not own a usable detection for that behaviour.

False positives aren’t a minor aesthetic defect in an otherwise complete capability.

They consume the people who have to distinguish benign activity from a real incident.

In Defender for Endpoint, a recurring benign pattern can be excluded with a suppression rule after analysts resolve it as false.

That is a concrete feedback path from triage to tuning.

It isn’t a reason to pretend triage is optional.

Which is why your evidence record needs a named false-positive owner.

Without one, your rule’s cost has no budget and its errors have no route back to the logic.

Your queue grows.

Analysts learn that a category is noisy.

And the coverage dashboard remains quite pleased with itself.

Every detection has a burden of proof in both directions.

Enough fidelity to justify response, and an accountable process for the benign cases it will inevitably surface.

A system that always rings and cannot be investigated is not more capable because it is enthusiastic.

6. “But We Cannot Test Every Technique.”

Correct.

Nobody should promise that.

ATT&CK isn’t a finite compliance checklist.

MITRE adds and changes content on a bi-annual release cadence.

Major versions carry substantive content; minor versions carry typo and data corrections.

Version 7.0, released in March 2020, replaced 266 flatter techniques with 156 parent techniques and roughly 260 new sub-techniques.

The taxonomy changes because your model gets more precise.

It isn’t waiting for procurement to finish colouring its matrix.

Inclusion also does not say a technique is equally probable or equally observable in every environment.

MITRE uses four empirical-use tiers: Reported, Reported non-public, Underreported, Unreported.

An Unreported technique has no public or non-public confirmation of in-the-wild use, and may still be included at MITRE’s discretion based on utility and likely adversary use.

So prioritize.

Start with behaviours that matter to your endpoints, the business processes and the response options.

Test them in representative environments.

Record your evidence.

Make the gaps visible.

The objective is not a full matrix. It is a defensible answer about priority behaviour.

An ATT&CK navigator rendered entirely green is not a threat model.

It is a colouring exercise with better typography.

7. No, This Does Not Mean ATT&CK Mapping Is Useless.

It isn’t.

ATT&CK is valuable precisely because it provides a common language for planning, discussing, testing and comparing behaviour.

T1055 means more to a practitioner than “some suspicious process thing.” A tactic, technique, sub-technique and procedure let your teams locate the level of abstraction they are actually discussing.

The error is treating taxonomy as proof.

ATT&CK’s own design separates those concerns.

A proposed technique is assessed through empirical use, and MITRE considers objective, actions, use, requirements, detection and mitigations when deciding whether behaviour needs a new entry.

Six factors for curating a model.

Not six assertions that a particular EDR tenant detects it.

Use mapping as an index into evidence.

Attach the collection record, the analytic, the test result, the tuning history, the response playbook and the hardening controls to the mapped behaviour.

Then the cell becomes useful, because it tells a reader where to find the proof, and the gap.

8. What You Should Actually Do.

For every priority technique, create an evidence record. Name the ATT&CK technique and the expected adversary signal.

Record the telemetry source and collection status for each representative endpoint environment.

Name the analytic, its owner, its false-positive owner, and the response playbook.

Record the controlled test procedure, the alert latency and the investigation outcome.

Run controlled tests in representative environments, not only on the engineer’s reference device.

Test the full path: telemetry, analytic, alert context, triage, escalation, containment, recovery.

If the detection produces an alert and nobody can distinguish it from a recurring benign case, say that plainly.

That is a tuning or staffing gap.

Not a covered technique.

Exercise the response that follows a true alert. Microsoft’s device isolation can be full or selective; selective isolation retains chosen processes and destinations, while the isolated device stays connected to the Defender cloud service.

Isolation lifts automatically after seven days unless an analyst intervenes.

An offline device that receives the command has enforcement retried for up to three days.

That is what an outcome looks like, a response mechanism with scope, duration and failure conditions.

Harden where detection is unreliable. CIS Benchmarks govern configuration; Level 1 is the base, minimal-impact profile, and Level 2 is for sensitive environments and can carry operational cost.

Application allowlisting governs execution.

NIST SP 800-167 defines it as allowing authorized applications and components while blocking unauthorized code by default.

App Control for Business can enforce into the Windows System Core, and complements antivirus rather than replacing it.

Protect the controls themselves. Defender for Endpoint tamper protection locks real-time protection, cloud-delivered protection, behaviour monitoring, automatic threat response and antivirus exclusions against changes through the Windows Security app, Group Policy or the registry.

A blocked tampering attempt becomes an alert.

A different layer from detection logic: it makes a defensive setting harder to silently remove.

Retire mappings with no evidence. “Mapped” is not a safe middle state between working and missing.

It is a claim awaiting proof.

9. The Actual Model Is Not Complicated.

ATT&CK says: this is a behaviour worth naming and discussing.

Endpoint telemetry says: this environment produced evidence of it.

An analytic says: these events mean something together.

Triage says: a human can understand your alert well enough to decide.

Response says: your organization can do something proportionate after that decision.

Hardening says: some unsafe conditions do not need to be detected, because your endpoint refuses or resists them first.

A coverage map is an index. Detection capability is the load path from behaviour to evidence to action.

Keep the map.

Stop mistaking it for the territory, the sensor, the analyst and the response team all at once.