How should a SOC use MITRE ATT&CK?

Not as a coverage checklist. A SOC should derive an in-scope set of techniques from the intersection of what it runs, what it protects and who realistically targets it, which typically narrows hundreds of techniques to a working subset. Those techniques are then mapped to crown jewels, translated into telemetry requirements, engineered into detections, and validated through adversary emulation. Coverage counted across the full matrix measures ambition, not capability.

How do you map MITRE ATT&CK to crown jewels?

Start from the asset rather than the matrix. For each crown jewel, build a threat model describing how a realistic adversary would reach it, then identify the techniques that appear on those attack paths. This produces a prioritised technique set anchored to business consequence, so detection effort is allocated by what compromise would cost rather than by what the matrix contains.

What is DeTT&CT and how does it relate to ATT&CK?

DeTT&CT is an open methodology for scoring detection coverage against ATT&CK using data source quality, visibility and detection maturity. Where ATT&CK describes adversary behaviour, DeTT&CT measures whether you could actually see and detect it. UTIOM anchors both to crown jewels so coverage is prioritised by business consequence rather than technique count.

MITRE ATT&CK in the SOC — Beyond Coverage Percentage

Q: What is wrong with measuring ATT&CK coverage percentage?

A coverage percentage treats every technique as equally relevant and every detection as equally real. A rule that has never fired, running on a log source that stopped reporting, mapped to a technique your adversaries do not use, counts the same as a detection proven to catch a real intrusion. Coverage claimed without visibility and capability asserted without evidence are the two failures the metric hides.

The problem with coverage

MITRE ATT&CK is the most useful thing to happen to detection engineering in a decade. It is also the most commonly misused, because it is easy to turn into a percentage and hard to turn into capability.

A coverage figure treats every technique as equally relevant and every detection as equally real. A rule that has never fired on a true positive, running on a log source that stopped reporting six weeks ago, mapped to a technique your adversaries do not use, counts exactly the same as a detection proven to catch a real intrusion in minutes.

Two failures hide inside a coverage percentage. Coverage claimed without visibility: the rule exists, is enabled, is mapped, and cannot fire because the data source covers 60% of the estate. And capability asserted without evidence: would we detect credential dumping? There is a rule for it, so yes. That answer reaches a board pack and is tested for the first time by an adversary.

Using ATT&CK operationally: five steps

The sequence that turns the matrix into capability runs from your environment inward, not from the framework outward.

1. Scope from your environment

Derive an in-scope technique set from the intersection of what you run, what you protect and who realistically targets you. Attempting to cover the entire enterprise matrix is not ambition, it is the absence of scoping. A properly scoped set is typically a fraction of the total.

2. Anchor to crown jewels

Start from the asset, not the matrix. For each crown jewel, model how a realistic adversary would reach it, then identify the techniques on those paths. This allocates detection effort by what compromise would cost rather than by what the matrix contains.

3. Translate to telemetry

Every prioritised technique implies specific data sources. Map them, then measure what you actually collect and at what quality. Techniques you are structurally unable to observe are not detection gaps, they are visibility gaps, and no amount of rule writing closes them.

4. Engineer detection, do not enable it

Detection content should be written against a normalised schema, held in version control, tested before production and traceable back to the technique, the threat model and the crown jewel it protects. A rule that cannot make that trace is consuming analyst attention without a defensible reason.

5. Validate with emulation

Emulate the adversaries in your threat profile, not generic technique tests. Validate three things: whether the telemetry was complete, whether detection fired in time, and whether the analyst made the right decision. Failed detections are engineering defects with owners and dates.

Where ATT&CK sits in UTIOM

ATT&CK is not the operating model. It is the shared vocabulary the operating model uses to describe adversary behaviour, and it appears at four distinct points in the lifecycle.

Lifecycle phase	How ATT&CK is used	What it produces
Strategy	Threat profiling: which actors target this sector, and which techniques they are documented using	A prioritised technique set derived from named adversaries rather than from the full matrix
Crown jewels	Techniques mapped to each critical asset through modelled attack paths	Attack path diagrams and a technique-to-asset mapping anchored to business consequence
Threat visibility	Techniques translated into required data sources, scored with DeTT&CT	A visibility blueprint and an accepted gap report naming what cannot currently be seen
Threat detection	Rules tagged by technique, tactic, log source and severity, written portably in Sigma where practical	A traceable detection library where every rule maps to a behaviour and an asset
Validation	Emulation plans built from the profiled adversaries and their documented techniques	Evidence of which detections fire, how fast, and which do not

DeTT&CT scores detection coverage against ATT&CK using data source quality and visibility. Where ATT&CK describes what adversaries do, DeTT&CT measures whether you could see it. UTIOM anchors both to crown jewels, and TID-CMM takes this furthest: it computes which prioritised behaviours are structurally undetectable given the telemetry you actually collect, and names what to enable to change that.

Measure it

The metrics that make ATT&CK usage honest are all ratios against a scoped, asset-anchored set rather than against the matrix.

Coverage per tactic

Tactics with adequate crown jewel telemetry, over tactics in the threat profile

Coverage per threat model

Modelled attack paths with the required telemetry, over total modelled paths

Trace completion rate

Rules traceable rule to model to technique to crown jewel to impact, over rules sampled

Detection validation rate

Rules tested by emulation, over total live rules

Proven attack path coverage

Paths proven by testing, over total modelled paths

MTTD per priority TTP

Measured against top techniques, not as an aggregate that hides the important cases

Open the metrics calculator Assess detection capability TID-CMM detection maturity

MITRE ATT&CK® is a registered trademark of The MITRE Corporation. UTIOM is not affiliated with or endorsed by MITRE.

Join the UTIOM community. Discuss, contribute evidence and share implementation experience. About the community →