MITRE ATT&CK

ATT&CK is built from observed intrusions rather than from theory. Its core structure is two levels. Tactics answer why an attacker is doing something: getting in, running code, staying, gaining rights, avoiding detection, taking credentials, finding their way around, moving sideways, collecting, communicating out, exfiltrating, and causing impact. Techniques answer how, and most carry sub-techniques for the specific variants.

Everything has an identifier, and the identifiers are the point. When a report says an intruder used a particular technique, everyone reading it means the same thing, can look it up, and can check whether their own detection covers it. That is what the industry lacked before it existed, and it is why it has become the common language between red teams, detection engineers and threat intelligence analysts who otherwise describe the same event three different ways.

Around that core the project publishes entries for known groups and for tooling, each mapped to the techniques attributed to them, and detection and mitigation guidance per technique. There are separate matrices for enterprise environments, for mobile, and for industrial control systems, because the techniques genuinely differ.

For a defender the practical use is coverage mapping: take the techniques that are relevant to your estate and your threat picture, and record for each whether you have telemetry, whether you have a detection, and whether it has been tested. The output is a picture with gaps in it, expressed in terms everyone recognises.

The failure is turning it into a scoreboard. A matrix coloured green from left to right looks like progress and usually is not, because coverage is claimed at technique level while attacks happen at sub-technique and procedure level. Having a detection for credential dumping does not mean having a detection for the specific way we do it. On engagements we routinely execute a technique that the client’s coverage map showed as covered, and it is not detected, because the rule was written against one tool’s default behaviour and we did not use that tool.

The second failure is scope. The knowledge base describes what has been observed and attributed. It is not exhaustive, it is not predictive, and it does not tell you what someone will invent next month. Teams that treat it as a complete list of threats build a defence against the past.

The third is confusing what it is for. ATT&CK is a vocabulary and a reference; it is not a control framework and it does not tell you what to do first. Prioritisation has to come from your own context: what an attacker would want in your estate, what you have that is reachable, and what you would not survive. A team that starts at the left of the matrix and works right will spend its first quarter on techniques that do not apply to it.

What it is genuinely excellent at is settling arguments. When a red team says it moved laterally and the blue team says it saw nothing, mapping each step to a technique identifier turns a disagreement about impressions into a specific list: this technique was recorded, this one was not, this one alerted and nobody acted. That conversation is the useful one, and it is the basis of every purple team exercise we run.

Both describe an intrusion in stages and they are frequently presented as alternatives. They operate at different resolutions and answer different questions.

They coexist comfortably. The cyber kill chain is the better slide for a board, because seven stages fit on one page and the narrative is intuitive. ATT&CK is the better tool for anyone who has to write a rule, because a phase name is not something you can detect and a technique identifier is.

Reporting coverage as a percentage of the matrix. The denominator includes techniques that cannot apply to your estate, and the numerator counts rules that have never been tested. Two numbers, both wrong, divided.

Mapping after the fact to look thorough. Attaching identifiers to a report you had already written adds nothing. Mapping is useful when it drives what you test next.

Ignoring the sub-technique level. Coverage claimed at technique level is where the gap hides. If the rule only catches one procedure, say so.

Assuming a mapped detection works. A rule that exists and a rule that fires are different states, and the only way to know which one you have is to execute the technique.

Using it as a threat model. It tells you what has been done, not what matters to you. Threat modelling starts from your assets and your design; ATT&CK is an input to it, not a replacement.

Start narrow. Pick the techniques that map to the way intrusions actually begin in your sector and your estate, which is usually a short list around identity, mail and remote access, and go deep on those instead of wide on everything.

For each one, record three separate states rather than one: is the telemetry being collected, does a detection exist, and has it been executed and confirmed. Most teams that believe they have coverage have the first two. The third is what an exercise establishes, and it is where the honest number comes from.

Feed the results back into detection engineering as work items with technique identifiers attached, so the backlog is legible to everyone and progress is measurable against something concrete. Re-test after platform changes, because upgrades break rules silently.

And write intelligence in the same vocabulary. When a report about a group relevant to your sector lists techniques, you can compare it directly against your tested coverage, which turns reading threat intelligence into a work plan rather than an activity.

Every red team and adversary emulation report we write maps each executed step to a technique identifier, and the deliverable is that mapping placed next to the client’s own detection outcome: recorded, alerted, or acted on. That table is usually the most-read page of the report, because it is the only place where offence and defence are described in the same terms.

We are explicit about what the mapping does not mean. A technique we did not execute is not a technique you are covered for. Coverage is only ever claimed for what was tested, and the untested remainder is listed as untested rather than left blank, because a blank cell reads as green to whoever sees the report next.

Mapping to the framework is how we structure adversary emulation against a real detection stack, and it is what makes the follow-up exercise comparable to the first one.

Is MITRE ATT&CK a compliance framework? No. It is a knowledge base and a vocabulary. It has no requirements, no levels and nothing to certify against. Frameworks such as ISO 27001 or the ENS impose obligations; ATT&CK describes technique.

How do we measure our ATT&CK coverage honestly? By executing techniques and recording what happened, not by counting rules. For each technique, three answers: was it recorded, did something fire, did anyone act. Anything not executed is reported as untested.

What is the difference between a tactic and a technique? A tactic is the attacker’s goal at that moment, such as gaining higher privileges. A technique is a specific way of achieving it. Tactics are few and stable; techniques are many and grow with each update.

Do we need it if we already run penetration tests? It makes the results comparable. Mapping the steps of a penetration test to technique identifiers lets you compare this year against last year, compare the test against your detections, and compare both against what threat intelligence says about your sector.