If you already know MITRE ATT&CK, you understand how attackers operate: tactics, techniques, and sub-techniques that describe adversary behavior in the real world.
D3FEND picks up where ATT&CK intentionally stops.
While ATT&CK answers:
“What is the attacker doing, and how?”
D3FEND answers:
“What can I do to stop, detect, or mitigate that?”
The team behind D3FEND built a comprehensive graph model of defensive knowledge: techniques, artefacts, and relationships that describe how defenders respond to specific adversary behaviors.
It is powerful, but it is also a lot to take in all at once.
Consider this post a short, ATT&CK-native introduction to D3FEND: not a replacement for the framework, but a way to understand how the two fit together.
In this post
This post is a conceptual introduction to MITRE D3FEND for people who already know ATT&CK.
We will cover:
- how D3FEND mirrors ATT&CK structurally, while flipping the perspective from attacker to defender
- why D3FEND goes deeper than ATT&CK in some areas, and where that extra depth matters
- how artefacts make the object of defensive actions explicit
- how relationships connect attacker behavior to defensive responses
The general concepts
If you are already comfortable with ATT&CK, the easiest way to understand D3FEND is to stop thinking about defence as tooling and start thinking about counter-techniques.
ATT&CK models what an adversary does.
D3FEND models what a defender can do in response.
The perspective changes, but the underlying structure remains surprisingly familiar.
Tactics: defender goals, not attacker phases
In ATT&CK, tactics represent why an attacker is doing something, the goal they’re trying to achieve at that stage of the intrusion.
In D3FEND, tactics represent defender objectives.
Instead of:
- Initial Access
- Persistence
- Lateral Movement
You get things like:
- Detect
- Isolate
- Restore
- Harden
Think of D3FEND tactics as:
“What outcome am I trying to achieve as a defender?”
They are not time-based, and they don’t describe an attack sequence.
They describe defensive intent.
Techniques: concrete defensive actions
Just like ATT&CK techniques describe how attackers achieve their goals, D3FEND techniques describe how defenders achieve theirs.
Examples include:
- Filtering
- Credential hardening
- Network segmentation
- Process isolation
These are real, implementable actions, not abstract controls.
If ATT&CK techniques answer:
“How does the attacker do this?”
D3FEND techniques answer:
“What specific action can I take to counter it?”
Sub-techniques (and, sub-sub-techniques): defensive specificity
At a high level, D3FEND uses sub-techniques the same way ATT&CK does: to add precision.
A defensive technique describes what you’re doing, while sub-techniques describe how it’s implemented.
This mirrors how ATT&CK lets you go from Credential Access to LSASS Memory Dumping
The mental model is the same, only the perspective changes.
Where D3FEND goes further is that it introduces an additional level of depth.
Some D3FEND sub-techniques are themselves broken down into more specific defensive actions, what you could reasonably call sub-sub-techniques (best I could do I’m afraid!).
These capture implementation details such as:
- specific control placements
- concrete enforcement mechanisms
- or narrowly scoped defensive patterns
ATT&CK deliberately stops at two levels.
D3FEND doesn’t — because defensive controls often need that extra granularity to be meaningful.
From a defensive engineering perspective, that extra step is often exactly where the difference lies between a good idea and something you can actually deploy.
Artefacts: what the defence actually touches
One major difference between ATT&CK and D3FEND is that D3FEND explicitly models what defensive actions operate on.
These are called artefacts.
Artefacts represent concrete things in an environment, such as:
- files
- processes
- network traffic
- identities
- configurations
- system states
They answer a question ATT&CK usually leaves implicit: “What is this defensive action inspecting, modifying, or protecting?”.
In ATT&CK, the object of an action is often implied.
In D3FEND, it’s explicit, and linkable.
This turns defensive reasoning from: “We do network filtering” into: “We apply this defensive technique to this artefact, at this point in the system.”
That distinction matters when you’re trying to reason about:
- coverage gaps
- overlapping controls
- or why a defence exists but still doesn’t work
Relationships: how defensive measures compose
D3FEND is not meant to be read as a flat list.
It’s a graph.
Relationships describe how defensive concepts connect to each other, for example:
- a technique protecting an artefact
- a defensive technique mitigating an offensive technique
- a sub-technique specialising a broader technique
This allows you to chain concepts together, such as; attacker technique -> affected artefact -> defensive technique -> defensive outcome
Which is exactly the question defenders tend to ask in practice: “Given this behavior, what specifically can I do about it?”.
ATT&CK has relationships too, but D3FEND leans on them much more heavily to express how defences layer and reinforce each other.
A graphical summary
Note, this image is taken from d3fend2stix docs (which I will cover in another post soon), hence the STIX references.
For now the important part is the shape of the model, not the implementation details.
The key shift: perspective, not structure
The most important thing to internalise is this: ATT&CK and D3FEND are not competing frameworks.
They are two sides of the same graph.
- ATT&CK: adversary behavior
- D3FEND: defender countermeasures
ATT&CK asks:
“What happened?”
D3FEND asks:
“What can we do about it?”
When you start thinking about them being complementary rather than separate, you unlock much more useful ways of reasoning about security:
- defensive options alongside attacker techniques
- coverage and gaps from both perspectives
- defensive knowledge as something you can query, enrich, and operationalise
CTI Butler
The most important cyber threat intelligence knowledgebases.
Discuss this post
Head on over to the dogesec community to discuss this post.
Never miss an update
Sign up to receive new articles in your inbox as they published.