MITRE ATT&CK vs MITRE D3FEND: How to Use Both for Detection Coverage

Most teams treat MITRE ATT&CK and MITRE D3FEND as two competing matrices, when they are two halves of one question: what can the adversary do here, and what exactly do we do about it? ATT&CK describes adversary behaviour seen in real intrusions; D3FEND describes defensive techniques and the system objects they act on. Used together, they let a detection engineer move from a technique in a threat report to a named countermeasure, a log source and a testable rule, and let an architect show where a control portfolio is thin. This guide compares the two ontologies, explains how the digital artefact layer links them, and shows how to run a combined coverage and gap analysis with a worked example. It is for detection engineers, SOC leads, security architects and control owners who already know the basics of each; the overviews are in the MITRE ATT&CK Guide for Defenders and the MITRE D3FEND Guide.

Key takeaways

• They answer different questions. ATT&CK is a knowledge base of adversary techniques based on real-world observations; D3FEND is a knowledge graph of countermeasure techniques whose stated goal is to standardise the vocabulary of defensive technology functionality.
• Artefacts are the bridge, and the bridge is inferred. D3FEND links a defensive technique to an ATT&CK technique when both act on the same digital artefact, such as a password, a process or an authentication event. A shared artefact suggests relevance; it does not prove coverage.
• Use ATT&CK to choose, D3FEND to describe. Pick and prioritise techniques with ATT&CK threat data, then describe the controls that address them in D3FEND terms so that vendor claims, tools and gaps can be compared like for like.
• Coverage needs three layers. A credible map shows the adversary technique, the defensive technique that acts on its artefacts, and the evidence (data source, rule, test date) that the defence works in your estate.
• Keep the versions aligned. ATT&CK is on v20.1 and D3FEND on knowledge graph 1.6.0 at the time of writing; translate retired ATT&CK IDs before you report, or the join silently breaks.

The short answer

Use ATT&CK when you need to know what adversaries do, in what order and with what evidence: threat modelling, detection priorities, adversary emulation and reporting incidents in a shared language. Use D3FEND when you need to say precisely what a control does, to which artefact, so that you can compare products, scope tests and find defensive gaps. Most mature programmes use ATT&CK as the demand side and D3FEND as the supply side of the same analysis.

Two ontologies, two threat models

The frameworks look similar on a poster, but they model different things and that shapes how each fails.

ATT&CK: behaviour-first

ATT&CK organises what adversaries have been seen to do. Each technique carries procedure examples, the groups and software known to use it, mitigations and, since the move away from data sources, detection strategies that contain platform-specific analytics. Its threat model is empirical: a technique enters the knowledge base because it has been observed. MITRE lists four uses on the ATT&CK resources page: detections and analytics, threat intelligence, adversary emulation and red teaming, and assessment and engineering.

• Strength: it reflects real intrusions, so prioritising by ATT&CK group and campaign data keeps effort tied to likely threats.
• Weakness for defence: mitigations are broad. M1036 Account Use Policies covers lockout, conditional access and more under one ID, which says little about what a specific product actually does.

D3FEND: function-first

D3FEND organises what defensive technology does. Each technique is an ontology class related to artefacts through verbs: Strong Password Policy (D3-SPP) strengthens Password, Password Rotation regenerates Password, Account Locking (D3-AL) disables User Account, Credential Revocation (D3-CR) deletes Credential, Authentication Event Thresholding (D3-ANET) analyzes Authentication. Its threat model is functional: a technique enters because it is described in the defensive literature.

• Strength: precise, comparable language. Two products that both claim "identity threat detection" can be expressed as D3-ANET plus User Geolocation Logon Pattern Analysis (D3-UGLPA), or as D3-ANET alone.
• Weakness for defence: no notion of likelihood or effectiveness. D3FEND will list a technique that a determined adversary routinely bypasses next to one that is hard to defeat, with no weighting.

How digital artefacts link the two

The join between the frameworks is the digital artefact: the object a technique touches, such as a file, a process, a credential, a log or a kind of network traffic. In the D3FEND ontology both sides are modelled against the same artefact classes, offensive techniques with verbs such as accesses, modifies, produces and creates, defensive techniques with analyzes, hardens, isolates, evicts and restores. When an ATT&CK technique and a D3FEND technique meet on one artefact, the D3FEND interface shows them as related.

Three properties of this link matter in practice:

• It is inferred: the relationship is derived from shared artefacts, not from testing, and D3FEND notes on its artefact pages that some relationships are inferred through parent classes. Treat a link as a hypothesis to validate.
• It is coarse at high levels: an artefact such as Process is touched by hundreds of techniques, so links through very general artefacts generate long, weak candidate lists. Links through specific artefacts (Authentication Log, Kerberos ticket, Password) are more useful.
• It ignores bypass: D3-ANET's own considerations say that if malicious activity is not statistically different from benign activity, the threshold will not trigger. A low-and-slow spray from residential proxies is exactly that case.

D3FEND also publishes curated cross-walks that are not artefact-based: ATT&CK Mitigations to D3FEND techniques, and NIST SP 800-53 Rev. 5 to D3FEND techniques. The mitigations mapping gives M1032 to D3-MFA, M1027 to One-time Password (D3-OTP) and D3-SPP, M1036 to D3-AL, Authentication Cache Invalidation (D3-ANCI) and D3-ANET, and M1043 Credential Access Protection to Hardware-based Process Isolation (D3-HBPI). The 800-53 mapping labels each pair exactly, broader, narrower or related; AC-7 Unsuccessful Logon Attempts maps exactly to Account Locking.

Where each framework fails on its own

The scope gap is the one that hurts. In the Microsoft Midnight Blizzard breach, a low-volume password spray succeeded against a legacy, non-production test tenant account without MFA. A portfolio described as "D3-MFA deployed" would have looked complete; the question that would have found the gap is "on which user accounts, in which tenants?", which only an asset-scoped coverage record answers.

Running a combined coverage and gap analysis

The method below joins the two frameworks without pretending the join is exact. It assumes you already keep an ATT&CK coverage map; the scoring model for that is in the MITRE ATT&CK Coverage Mapping Guide.

1. Select techniques from threat data. Start with 20 to 40 techniques used by adversaries relevant to your sector and estate, plus choke points such as T1078 Valid Accounts. Record the ATT&CK version (v20.1 today).
2. List the artefacts each technique touches. Read them from the D3FEND ontology (the TTL or JSON downloads, or the API) rather than by hand, so the list is reproducible. Drop links that run only through very general artefacts.
3. Pull candidate countermeasures. For each artefact, list D3FEND techniques that harden, detect, isolate, evict or restore it. Add the curated ATT&CK mitigations cross-walk for each technique.
4. Inventory what you run in D3FEND terms. Describe each control by technique ID, platform and asset scope: "D3-ANET in the identity provider for workforce accounts; not for local accounts on Linux servers". Ask vendors to state claims the same way.
5. Score three things separately. For each technique and countermeasure pair: deployed (yes, partial, no, with scope), observable (the ATT&CK data component is collected, retained and parsed), and validated (a test or incident proved it, with a date).
6. Classify gaps. Use four labels: no countermeasure in place, countermeasure without visibility, visibility without a rule, rule never tested. Each needs a different owner and fix.
7. Validate before you report. Test the highest-priority pairs through purple team exercises or breach and attack simulation, and only then mark them covered. See the Purple Teaming Guide.
8. Re-run on each release. ATT&CK and D3FEND both version their content; rebuild the join when either changes and keep the previous result for comparison. Roll back to the prior map if a release breaks too many links to review in one cycle.

Worked scenario: password spraying against the identity provider

A CTI team flags password spraying against cloud identity as the top initial access risk for the year. The detection engineering lead runs the combined analysis for T1110.003.

The outcome is a gap list that both frameworks were needed to produce: bring excluded tenants and accounts under D3-MFA, forward VPN and network device authentication logs, add a long-window distributed spray analytic, and extend credential revocation to machine identities. The detection logic and response steps are in the Password Spraying and Credential Stuffing Defence Guide and the Password Spraying Attack Response Playbook.

Using both in detection engineering

Day to day, the two frameworks attach to different fields of a detection's lifecycle record. A useful convention is to tag every rule with both.

• Rule repositories: Sigma rules already carry ATT&CK tags; adding a D3FEND technique in the rule metadata lets you report coverage by defensive function as well as by threat. See the Sigma Rules Guide.
• Detection strategies: ATT&CK v20 holds roughly 700 enterprise detection strategies, each a container for platform-specific analytics. Use them as the specification for what telemetry a D3FEND Detect technique needs on each platform. See the ATT&CK Detection Strategies and Analytics Guide.
• Hardening backlog: D3FEND Harden and Isolate techniques give detection engineers a way to hand prevention work to platform teams in precise terms, instead of writing ever more alerts for an attack that a configuration change would stop.
• Deception: Decoy Object (D3-DO) and Decoy Environment (D3-DE) have no ATT&CK equivalent but produce high-fidelity detections for discovery and credential access techniques; plan them as a coverage source. MITRE Engage covers the operational side: see MITRE ATT&CK vs MITRE Engage.

Choosing where to start

• Small team, one SIEM: start with ATT&CK only. Prioritise 20 techniques, map rules and log sources, and add D3FEND IDs later as a column in the same sheet. D3FEND adds most value once you have more than one control per technique.
• Large estate, many tools: introduce D3FEND early, in procurement and tool rationalisation. MITRE's FAQ says the dominant use so far has been to inform acquisition and investment, because claimed functionality can be compared against one taxonomy.
• Regulated or audited organisations: use the D3FEND to NIST SP 800-53 mapping and the Center for Threat-Informed Defense Mappings Explorer (ATT&CK to NIST 800-53, CIS Controls, CSA CCM, cloud provider and Microsoft 365 capabilities) to connect control-based evidence with threat-informed coverage. Check which ATT&CK version each mapping was built on.
• Identity and NHI programmes: D3FEND's credential and account techniques (D3-CH, D3-CR, D3-AL, D3-MFA, D3-UBA) give identity teams words that SOC tooling also understands. See the Detection Engineering for Non-Human Identities Guide.

Measuring the combined programme

• Validated coverage of priority techniques: share of prioritised ATT&CK techniques with at least one deployed, observable and tested countermeasure, with test dates no older than your agreed window.
• Defensive depth: median number of distinct D3FEND tactics (for example Harden, Detect, Evict) in place per priority technique. One Detect technique alone is fragile.
• Scope completeness: share of in-scope asset classes (production, test tenants, service accounts, contractors) covered by each deployed countermeasure.
• Telemetry gaps closed: number of required data components still missing, trending down per quarter.
• Mapping freshness: days since the join was last rebuilt against the current ATT&CK and D3FEND releases.

Framework mapping

Common failure patterns

• Treating a D3FEND link as coverage: a related technique on a shared artefact is a candidate. Until a test shows the control catches the procedure you care about, it is not covered.
• Counting product claims, not deployments: a tool that supports D3-ANET but only ingests one identity provider covers one identity provider.
• Ignoring asset scope: controls deployed to production and absent from test, legacy or machine identities, as in the Midnight Blizzard spray.
• Mixing versions: joining a D3FEND related-technique list to an ATT&CK layer built on an older release, so revoked IDs show as gaps or false coverage.
• Using D3FEND to rank controls: it does not rate effectiveness. Rank with threat data, test results and incident history.
• Mapping everything: joining every technique through general artefacts such as Process produces lists too long to act on; prioritise first.

Practitioner checklist

• Record the ATT&CK and D3FEND versions behind every coverage report.
• Prioritise 20 to 40 ATT&CK techniques from threat data before mapping anything.
• Derive artefact links from the D3FEND ontology downloads or API, not by hand.
• Describe every control and vendor claim as D3FEND technique, platform and asset scope.
• Score deployed, observable and validated separately for each technique and countermeasure pair.
• Tag each detection rule with both an ATT&CK technique and a D3FEND technique.
• Check test tenants, legacy systems and machine identities explicitly for each countermeasure.
• Validate priority pairs with purple team or simulation before marking them covered.
• Rebuild the join after each ATT&CK or D3FEND release and compare with the previous run.

Standards and references

• MITRE ATT&CK: Getting Started and Resources
• MITRE D3FEND: Frequently Asked Questions
• MITRE D3FEND: Digital Artifact Ontology
• MITRE D3FEND: ATT&CK Mitigations to D3FEND Techniques
• MITRE D3FEND: NIST 800-53 Rev. 5 to D3FEND Techniques
• MITRE D3FEND: Authentication Event Thresholding
• MITRE ATT&CK: Password Spraying
• Center for Threat-Informed Defense: Mappings Explorer

Related NHI Mgmt Group resources: Threat-Informed Defence Guide, Detection Engineering Guide, D3-ANET Authentication Event Thresholding, MITRE ATT&CK T1110 Brute Force Guide.