MITRE D3FEND

1. Introduction

MITRE D3FEND is a knowledge graph of cybersecurity countermeasures. It is the defensive counterpart to the widely adopted MITRE ATT&CK knowledge base of adversary behaviour. Where ATT&CK catalogues what attackers do, D3FEND catalogues what defenders can do about it, expressing each defensive technique as a semantically precise node in an ontology and linking those techniques to the specific offensive techniques they counter. For security architects, blue teams, detection engineers and auditors, D3FEND provides a shared, vendor-neutral vocabulary for reasoning about defensive coverage in a rigorous, evidence-based way.

D3FEND was developed by MITRE with funding from the United States National Security Agency (NSA). It was first released publicly in June 2021 as a beta and has matured through successive releases; version 1.0 was published in 2023, and the ontology continues to evolve under an open, community-informed model. Unlike a prescriptive compliance standard, D3FEND is a reference knowledge base: it does not tell an organisation that it must implement a fixed list of controls, but rather gives it a structured way to describe, relate and assess the countermeasures it has chosen to deploy. This makes D3FEND an exceptionally powerful analytical instrument, particularly when it is combined with ATT&CK for threat-informed defence and with control frameworks such as NIST SP 800-53 for governance.

This guide is written for practitioners who intend to use D3FEND as the backbone of a defensive capability assessment. It walks through the structure of the knowledge graph, enumerates every tactic and technique family in the D3FEND matrix, provides an auditor-grade assessment checklist keyed to each defensive tactic, and sets out a phased implementation and maturity model so that an organisation can move from ad hoc defence to a measured, threat-informed, continuously improving programme.

2. What is MITRE D3FEND

MITRE D3FEND (a Detection, Denial and Disruption Framework Empowering Network Defense) is a formally structured knowledge graph that inventories the technical countermeasures available to cyber defenders and relates them, through a precise ontology, to the digital artefacts they operate on and to the offensive techniques they counter. It is not a policy standard, a maturity model in the ISO sense, nor a certification scheme. It is a reference ontology and matrix intended to bring engineering precision to conversations about defence.

The intellectual innovation of D3FEND is its use of a formal ontology. Each defensive technique is defined not merely by a name and a paragraph, but by a set of asserted relationships expressed in terms of a 'Digital Artifact Ontology'. For example, the technique 'File Analysis' is defined as an operation that analyses a 'File' artifact; 'Network Traffic Analysis' operates on 'Network Traffic' artifacts. Because both defensive techniques and offensive techniques are anchored to the same underlying set of digital artefacts, D3FEND can infer which defences are relevant to which attacks: if an attack technique produces or manipulates a particular artefact, and a defensive technique observes or modifies that same artefact, the two are related. This 'digital artifact' bridge is what allows automated, inference-driven mapping between D3FEND and ATT&CK.

D3FEND organises defensive techniques into a small number of high-level defensive tactics, each of which contains one or more base techniques, and each base technique may contain more specific sub-techniques. The result is a matrix visually reminiscent of the ATT&CK matrix but oriented around defence rather than offence. The knowledge graph also carries 'references' linking each technique to the academic literature and patents that inform it, giving the framework strong evidentiary grounding.

• It is descriptive and analytical, not prescriptive or mandatory.
• It is threat-informed: defences are meaningful only in relation to the attacks they counter.
• It is ontology-driven, enabling machine-readable reasoning and automated mapping to ATT&CK.
• It is vendor-neutral, describing capabilities rather than products.
• It is complementary to, not a replacement for, control frameworks such as NIST SP 800-53, ISO/IEC 27001 or the CIS Controls.

3. Who should use MITRE D3FEND

D3FEND is relevant to any organisation that operates a defensive security capability and wishes to reason about it systematically. Because it is not a regulatory mandate, there is no population that 'must comply'; rather, there are roles and organisation types for which D3FEND delivers particular value. The table below sets out the principal audiences.

4. Structure of MITRE D3FEND

The D3FEND knowledge graph is organised into a hierarchy. At the top sit the defensive tactics, which describe the defender's high-level goal (for example, to detect or to isolate). Each tactic contains base techniques, and base techniques contain sub-techniques of increasing specificity. Underpinning all of this is the Digital Artifact Ontology, which enumerates the observable and mutable artefacts (files, processes, network traffic, user accounts and so on) that both attacks and defences act upon.

The current D3FEND matrix organises techniques under a set of defensive tactics. Earlier releases used five core tactics (Harden, Detect, Isolate, Deceive, Evict); version 1.0 and later added Model and Restore, giving the seven tactics shown below. 'Model' captures the essential activities of understanding one's own environment and threats before acting, and 'Restore' captures recovery activities. The counts below are indicative of the published matrix and will vary between releases as MITRE extends the ontology.

Each technique carries a D3FEND identifier of the form D3-XXX (for example, D3-FA for File Analysis, D3-NTA for Network Traffic Analysis, D3-DNSTA for DNS Traffic Analysis). The Digital Artifact Ontology (d3f: prefixed classes) provides the semantic glue: techniques are asserted to 'analyze', 'harden', 'isolate', 'filter', 'restore' or otherwise relate to specific artefact classes, and those same artefact classes are 'produced' or 'used' by ATT&CK techniques.

5. Master assessment checklist

This is the core of the guide. It enumerates every defensive tactic in the D3FEND matrix and, within each, the principal base technique families. For each family it sets out what an assessor should verify and the typical evidence that demonstrates the capability is present and effective. Because D3FEND is a coverage framework, the assessment question is always twofold: (a) is the countermeasure present, and (b) does it operate on the correct artefacts against a defined threat model. Assessors should map each verified capability back to the ATT&CK techniques it is claimed to counter.

5.1 Model (D3-M)

The Model tactic covers the foundational understanding of assets, network, systems, operational activity and threats. Without an accurate model of the environment, no downstream defensive technique can be sized or targeted correctly.

5.2 Harden (D3-H)

The Harden tactic reduces the attack surface before an incident. It comprises four base technique families: Application Hardening, Credential Hardening, Message Hardening and Platform Hardening.

5.3 Detect (D3-D)

The Detect tactic is the largest in the matrix. It observes digital artefacts to identify adversary activity and comprises technique families for analysing files, identifiers, messages, network traffic, platforms, processes and user behaviour.

5.4 Isolate (D3-I)

The Isolate tactic creates logical or physical barriers that limit an adversary's ability to execute code or communicate. It comprises Execution Isolation and Network Isolation.

5.5 Deceive (D3-DE)

The Deceive tactic presents adversaries with misleading environments or objects to detect, delay and study them. It comprises Decoy Environment and Decoy Object.

5.6 Evict (D3-E)

The Evict tactic removes an adversary and their footholds from the environment. It comprises Credential Eviction, Process Eviction and File Eviction.

5.7 Restore (D3-R)

The Restore tactic returns affected systems to a known-good state. It comprises Restore Access, Restore Object (data/software) and Restore Configuration.

6. Scoping

Because D3FEND is not a conformity standard, scoping is an exercise in defining which environments, threat models and defensive tactics an assessment will cover, rather than defining a certifiable boundary. A well-scoped D3FEND assessment answers three questions clearly before work begins.

• Environmental scope: which systems, networks, business units, cloud tenants and OT/IT domains are in scope for the defensive coverage assessment.
• Threat scope: which adversary behaviours (typically expressed as an ATT&CK Navigator layer of prioritised techniques) the defence must counter, derived from the organisation's threat intelligence and risk appetite.
• Tactical scope: which of the seven D3FEND tactics are in scope for this assessment cycle (an organisation may, for example, assess Detect and Isolate deeply in one cycle and Deceive and Restore in the next).

Scoping should also record assumptions about data sources and telemetry availability, since D3FEND detection techniques are only assessable where the underlying artefacts are actually being collected. A honest scope explicitly excludes tactics or environments where telemetry is not yet available, and captures those exclusions as gaps for the roadmap.

7. Implementation approach

Adopting D3FEND as the organising framework for defensive capability is best done in phases. Each phase builds on the previous one, moving from understanding the environment (Model) through building and assessing countermeasures to continuous, threat-informed improvement.

Phase 1 - Model the environment and threat

Activities: build or validate the asset inventory, network map and system/data-flow maps; establish the threat model as a prioritised ATT&CK layer; identify available telemetry sources and their artefact coverage. Deliverables: authoritative asset and network inventories, a documented threat model, an ATT&CK prioritisation layer, and a telemetry/artefact coverage matrix.

Phase 2 - Baseline current defensive coverage

Activities: catalogue existing controls and map each to D3FEND techniques and the artefacts it acts on; use the D3FEND-to-ATT&CK inference to identify which prioritised attack techniques are currently uncovered. Deliverables: a current-state D3FEND coverage map, a coverage heat-map overlaid on the ATT&CK layer, and a prioritised gap register.

Phase 3 - Harden and reduce attack surface

Activities: implement Model-informed Harden techniques (application, credential, message and platform hardening) to close the cheapest, highest-value gaps first. Deliverables: hardening baselines, enforced configuration standards, and evidence of drift monitoring.

Phase 4 - Build detection and isolation depth

Activities: engineer detections across the Detect families for prioritised techniques; implement Isolate controls (execution and network isolation) to constrain lateral movement; validate detections through purple-team exercises. Deliverables: mapped detection content, segmentation architecture, and validated detection-firing evidence.

Phase 5 - Add deception, eviction and restoration capability

Activities: deploy deception assets (honeytokens, decoy environments); formalise eviction playbooks (credential, process, file); test restoration against RTO/RPO. Deliverables: deception coverage, tested IR eviction runbooks, and validated recovery capability.

Phase 6 - Operationalise continuous, threat-informed improvement

Activities: integrate D3FEND coverage tracking into BAU; refresh the threat model as intelligence evolves; run recurring purple-team cycles; report coverage and residual risk to leadership. Deliverables: a living coverage dashboard, a governance cadence, and periodic threat-informed re-prioritisation.

8. Capability maturity model

D3FEND does not itself define maturity levels, but a capability maturity overlay is invaluable for assessment. The model below adapts a standard five-level scale to defensive capability, so that each D3FEND tactic can be scored consistently.

9. Assessment and audit approach

A D3FEND assessment follows a repeatable sequence. The steps below produce a defensible, evidence-backed view of defensive coverage and maturity.

1. Agree scope: fix the environmental, threat (ATT&CK layer) and tactical scope, and record exclusions and assumptions.
2. Validate the environment model: confirm asset inventory, network map and telemetry coverage are current and authoritative.
3. Enumerate controls: catalogue every deployed countermeasure and the artefacts it acts on.
4. Map to D3FEND: assign each control to its D3FEND technique(s), noting the digital artefacts and asserted relations.
5. Infer ATT&CK coverage: use the D3FEND-ATT&CK linkage to determine which prioritised attack techniques are covered, partially covered or uncovered.
6. Test efficacy: validate a sample of detection and isolation controls through purple-team or breach-and-attack-simulation exercises.
7. Score maturity: rate each tactic against the five-level model using collected evidence.
8. Identify and prioritise gaps: rank uncovered or immature areas by threat relevance and remediation cost.
9. Report: present a coverage heat-map, maturity scores, gap register and prioritised roadmap.
10. Re-assess: schedule periodic re-assessment tied to threat-model refresh.

10. Evidence request list

The following categorised evidence supports a D3FEND coverage and maturity assessment.

• Model evidence: asset/CMDB inventory, network and data-flow diagrams, threat model documents, ATT&CK Navigator layers, telemetry/artefact coverage matrix.
• Harden evidence: hardening baselines (CIS/DISA), MFA and PKI configuration, DMARC/SPF/DKIM records, encryption and secure-boot attestation, drift/compliance reports.
• Detect evidence: EDR/NDR/SIEM configuration, detection content inventory mapped to ATT&CK, YARA rules, DNS and traffic analytics, UEBA rules, sample alerts.
• Isolate evidence: firewall and segmentation rulesets, application allowlisting policy, MAC/sandbox profiles, segmentation test results.
• Deceive evidence: deception platform configuration, honeytoken inventory, decoy-interaction alert logs.
• Evict evidence: IR eviction playbooks, credential revocation and session invalidation logs, process termination and file removal records.
• Restore evidence: backup catalogue and restore test reports, immutability/air-gap configuration, DR exercise records, RTO/RPO attainment.
• Governance evidence: coverage dashboards, purple-team reports, gap register, assessment cadence records, board reporting.

11. Roles and responsibilities

12. KPIs to track

• Percentage of prioritised ATT&CK techniques with at least one mapped D3FEND countermeasure (coverage breadth).
• Percentage of prioritised techniques with validated, firing detections (coverage depth / detection efficacy).
• Mean maturity score across the seven D3FEND tactics.
• Telemetry/artefact coverage: percentage of in-scope assets emitting required artefacts.
• Number and age of open gaps in the gap register.
• Purple-team detection rate: proportion of exercised techniques that produced an alert.
• Time to evict and time to restore for incidents (median).
• Configuration drift rate against hardening baselines.
• Proportion of critical systems with tested, immutable backups (restore assurance).

13. Readiness checklist

• Authoritative asset inventory and network map exist and are current.
• Threat model is documented as a prioritised ATT&CK Navigator layer.
• Telemetry/artefact coverage matrix has been produced.
• All deployed controls are catalogued and mapped to D3FEND techniques.
• A current-state D3FEND coverage heat-map exists over the ATT&CK layer.
• Hardening baselines are defined and continuously enforced.
• Detection content is mapped to ATT&CK and gaps are tracked.
• Execution and network isolation constrain the modelled attack paths.
• Deception assets are deployed and monitored.
• Eviction and restoration runbooks exist and have been tested.
• Maturity has been scored per tactic against a defined model.
• A prioritised gap register and roadmap are maintained.
• A coverage dashboard is reported to leadership on a defined cadence.
• Re-assessment is scheduled and tied to threat-model refresh.

14. Common gaps

• Treating D3FEND as a checklist to 'comply' with, rather than a lens for threat-informed coverage assessment.
• Assessing coverage in the abstract without first fixing a prioritised ATT&CK threat model.
• Claiming detection coverage where the underlying artefacts (telemetry) are not actually collected.
• Mapping tools to technique names superficially without verifying they act on the correct artefacts.
• Over-investing in Detect while neglecting Harden, Isolate, Evict and Restore, leaving no defence in depth.
• Never validating detections through purple-team exercises, so 'coverage' is theoretical.
• Deploying deception without monitoring, so decoy interactions go unnoticed.
• Untested backups and restoration, so the Restore tactic fails during real incidents.
• Static assessments that are never refreshed as the threat model evolves.
• No board-level reporting of residual risk, so gaps never get funded.

15. MITRE D3FEND mapped to other frameworks

D3FEND is most powerful when related to the offensive and governance frameworks around it. The mapping below is indicative and helps position D3FEND within a broader security programme.

16. How CyberSigma helps

Frequently asked questions

Need help with MITRE D3FEND?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.