In this post
In a previous post, we made D3FEND work inside a STIX-native ecosystem.
That solved an important problem: defensive knowledge could now exist as structured CTI data, not just documentation.
But it still lived in isolation from the rest of the CTI ecosystem.
To make D3FEND operationally useful, it needs to connect to the rest of the security knowledge landscape, especially ATT&CK and CWE.
This post focuses on those connections.
Why link D3FEND to ATT&CK and CWE?
D3FEND is strong at describing defensive techniques.
ATT&CK is strong at describing adversary behaviour.
CWE is strong at describing structural weaknesses.
Individually, each is valuable. Together, they answer a more useful question:
Not: “Can we detect this technique?”
But: “What defensive actions actually reduce the risk?”
Detection coverage is not the same as defensive coverage.
ATT&CK alone helps you understand what an adversary might do.
D3FEND helps you understand what you can do in response.
Linking them turns those perspectives into a graph so offensive and defensive teams can freely move between the two.
The D3FEND ontology already contains external knowledge
D3FEND is not an isolated model.
Its ontology already includes references to:
- ATT&CK Tactic, Techniques, Sub-Techniques and Mitigations
- CWE Weaknesses
- DISA CCI
- NIST 800-53
These are not simple text references.
They exist as structured OWL entities embedded in the graph.
For example:
ATT&CK Techniques/Sub-Techniques
{
"@id": "d3f:T1098.001",
"@type": [
"owl:Class",
"owl:NamedIndividual"
],
"d3f:attack-id": "T1098.001",
"d3f:creates": {
"@id": "d3f:Credential"
},
"d3f:definition": "Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.",
"d3f:produces": {
"@id": "d3f:IntranetAdministrativeNetworkTraffic"
},
"rdfs:label": "Additional Cloud Credentials",
"rdfs:subClassOf": [
{
"@id": "d3f:T1098"
},
{
"@id": "_:N5061ec09a28745f09bb467a05979d442"
},
{
"@id": "_:Ncb7d77eae1ce46d7a3c75089c1f0b1c4"
}
]
}
ATT&CK Mitigations
{
"@id": "d3f:M1056",
"@type": [
"owl:NamedIndividual",
"d3f:ATTACKEnterpriseMitigation"
],
"d3f:related": [
{
"@id": "d3f:DecoyEnvironment"
},
{
"@id": "d3f:DecoyObject"
}
],
"rdfs:label": "Pre-compromise"
}
Weaknesses
{
"@id": "d3f:CWE-825",
"@type": [
"owl:Class",
"owl:NamedIndividual"
],
"d3f:cwe-id": "CWE-825",
"d3f:definition": "The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.",
"d3f:synonym": "Dangling pointer",
"d3f:weakness-of": {
"@id": "d3f:UserInputFunction"
},
"rdfs:label": "Expired Pointer Dereference",
"rdfs:subClassOf": [
{
"@id": "d3f:CWE-119"
},
{
"@id": "d3f:CWE-672"
},
{
"@id": "_:N858266ab414241afac30220321e84635"
}
]
}
These objects are already part of the ontology.
The work is not inventing links.
The work is resolving and operationalising them in the same way we did in the last post.
Artefacts are the join points
The key structural insight is simple.
D3FEND artefacts act as the bridge between frameworks.
- ATT&CK techniques produce or interact with artefacts
- weaknesses affect artefacts
- D3FEND mitigations operate on artefacts
That makes artefacts the natural “join node” in the graph. They are the shared surface where offensive behaviour, structural weakness, and defensive action all intersect.
Graphically:
- ATT&CK → artefact
- CWE → artefact
- D3FEND mitigation → artefact
From there, traversal becomes possible in any direction.
OWL restrictions: where the real relationships live
As with the previous post, the important relationships are not always explicit fields.
They often appear through OWL restrictions.
For example:
{
"@id": "_:N858266ab414241afac30220321e84635",
"@type": "owl:Restriction",
"owl:onProperty": {
"@id": "d3f:weakness-of"
},
"owl:someValuesFrom": {
"@id": "d3f:UserInputFunction"
}
},
This expresses:
CWE-825 is a weakness of the D3FEND artefact UserInputFunction.
Not as a flat property.
But as a graph constraint.
Resolving these restrictions allows us to generate explicit STIX relationships linking:
- ATT&CK ↔ artefacts
- CWE ↔ artefacts
- mitigations ↔ artefacts
Once expressed in STIX, these relationships become explicit, queryable, and usable across CTI tooling.
Traversing the graph in practice
This is where the model stops being theoretical and starts being operational. The value of this model is traversal.
You can start from an offensive technique, a mitigation, or a weakness and move through the graph to defensive actions.
ATT&CK technique → defensive mitigations
T1098.001: Additional Cloud Credentials
This technique produces the artefact Credential, which becomes the pivot into defensive modelling.
From there, we can identify D3FEND mitigations that operate on that artefact:
- Decoy User Credential (D3-DUC)
- Multi-factor Authentication (D3-MFA)
- Authentication Cache Invalidation (D3-ANCI)
- Credential Transmission Scoping (D3-CTS)
- Credential Compromise Scope Analysis (D3-CCSA)
- Credential Rotation (D3-CRO)
- Credential Hardening (D3-CH)
- Credential Revocation (D3-CR)
- Reissue Credential (D3-RIC)
The path is:
ATT&CK technique → artefact → D3FEND mitigation
ATT&CK mitigation → D3FEND mitigation → ATT&CK techniques
M1056 Pre-compromise
This maps to D3FEND mitigations such as:
- Decoy Environment (D3-DE)
- Decoy Object (D3-DO)
From those nodes, the graph can be traversed back to:
- related artefacts
- related ATT&CK techniques
This creates a two-way bridge:
ATT&CK ↔ D3FEND
CWE weakness → defensive mitigations
CWE-825 Expired Pointer Dereference
Weaknesses connect the model at a different level. They shift the perspective from adversary behaviour to structural exposure.
CWE-825 is linked to the artefact User Input Function.
From there, you can traverse to:
- defensive techniques
- mitigations targeting that artefact class
- other weaknesses linked to the artefact
This answers a different operational question:
Not “How do attackers use this?”
But: “What defensive controls reduce exposure to this class of weakness?”
This is not enrichment. It is structural integration.
It is tempting to describe this as enrichment. It is not.
We are not attaching labels.
We are integrating graphs.
The distinction matters.
Enrichment:
- adds metadata
Integration:
- enables traversal
- enables reasoning
- enables coverage analysis across frameworks
The goal is not to decorate ATT&CK or CWE.
The goal is to make defensive knowledge first-class in the same graph.
What this enables operationally
Once D3FEND sits alongside ATT&CK and CWE in STIX:
You can:
- move from adversary behaviour to defensive technique
- move from weakness to mitigation strategy
- identify artefact-centric defensive gaps
- evaluate defence posture beyond detection coverage
This shifts the model from: “What attacks exist?”
To: “What defensive actions reduce exposure?”
D3FEND in CTI Butler
The examples above were generated directly from CTI Butler.
The platform now allows you to:
- explore D3FEND artefacts as graph nodes
- traverse to ATT&CK techniques and mitigations
- traverse to CWE weaknesses
- identify defensive mitigations in context
This is how we use D3FEND internally for our research. Not as documentation. But as a navigable defensive knowledge graph embedded in CTI workflows.
Defensive knowledge should not sit beside ATT&CK.
It should connect through it.
CTI Butler
The most important cyber threat intelligence knowledgebases.
Discuss this post
Head on over to the dogesec community to discuss this post.
Open-Source Projects
All dogesec commercial products are built in-part from code-bases we have made available under permissive licenses.
Never miss an update
Sign up to receive new articles in your inbox as they published.