MITRE D3FEND Guide: Defensive Techniques Mapped

Most security teams can name the attacker techniques they worry about, but few can say precisely which defensive techniques they run, against which system objects, and where the gaps are. MITRE D3FEND gives the defensive side a shared vocabulary: a knowledge graph of countermeasures, each tied to the digital artefacts it acts on and, through them, to ATT&CK. This guide explains how D3FEND is built, lists its techniques by tactic with IDs and example controls, and shows how to use it for coverage analysis, procurement and engineering. It is written for detection engineers, security architects and control owners.

Key takeaways

• D3FEND names what defenders do. Version 1.6.0 organises defensive techniques under seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict and Restore.
• Digital artefacts are the join. Defensive and offensive techniques are linked because both act on the same artefacts, and D3FEND calls those ATT&CK links "inferred, experimental".
• It is a catalogue, not a baseline. D3FEND "does not prescribe specific countermeasures, it does not prioritize them", so pair it with a threat model and a control framework.
• Procurement is the main use so far. MITRE says the dominant use case "has been to inform acquisition and investment", because vendor claims can be compared as technique IDs.
• Identity is well covered. Credential hardening, user behaviour analysis, credential eviction and credential reissue give identity and NHI teams precise terms.

What MITRE D3FEND is

D3FEND stands for "Detection, Denial, and Disruption Framework Empowering Network Defense". MITRE calls it "a knowledge base, but more specifically a knowledge graph, of cybersecurity countermeasure techniques"; it is funded by the NSA Cybersecurity Directorate. Version 1.0 (16 January 2025) is the point from which MITRE considers it stable, and content is updated quarterly. That release added identity and access control, OT and source code hardening content, CWE modelling, an OWL 2 DL foundation and the Cyber Attack-Defense (CAD) tool.

• Ontology, not a list: each technique is a class related to artefacts (Strong Password Policy "strengthens" Password and User Account). The public d3fend/d3fend-ontology repository (MIT licence) publishes d3fend.ttl, d3fend.owl, d3fend.json and a tabular d3fend.csv.
• Identifiers: every technique has a D3- ID (D3-MFA) and an ontology name such as d3f:ProcessLineageAnalysis, which is also its URL path.
• Evidence base: technique pages cite patents, papers and MITRE CAR analytics; Process Lineage Analysis cites CAR-2014-11-002 Outlier Parents of Cmd, a ready starting point for detection content.

The seven tactics

The tactic pages list about 270 technique entries including parent groupings; Detect is largest (90), then Isolate (57) and Harden (55).

Digital artefacts and the ATT&CK mapping

A digital artefact is the object a technique touches: a process, user account, credential, certificate, kernel module or DNS network traffic. The Digital Artifact Ontology runs from high-level classes down to items such as Linux Execve, Windows NtCreateProcess and NTFS Junction Point, and newer event artefacts such as User Account MFA Disable Event, "An event where multi-factor authentication (MFA) is disabled for a user account", which has no linked techniques yet.

The mapping is inferred. ATT&CK techniques are linked to artefacts they use or modify; D3FEND techniques to artefacts they analyse, harden, isolate or evict. Where both meet on one artefact, the technique page lists the ATT&CK technique as related, with the caveat that mappings "are inferred, experimental, and will improve as the knowledge graph grows".

A related technique is a candidate, not proof of coverage: D3FEND itself notes that parent process ID spoofing defeats lineage analysis. Mappings can also lag ATT&CK: v20 retired Impair Defenses, yet some D3FEND pages still list its old sub-technique IDs, so translate IDs to your ATT&CK release before reporting.

Defensive technique reference by tactic

IDs were checked against the D3FEND 1.6.0 tactic pages. Example controls are illustrations, not D3FEND content.

Model

Harden

Detect

To turn these into tested analytics, see the Detection Engineering Guide.

Isolate

Deceive

Also in Deceive: Decoy Object D3-DO, Decoy Network Resource D3-DNR, Decoy Persona D3-DP, Decoy Public Release D3-DPR. See the Deception Technology Guide.

Evict

Playbooks automate many of these. See the SOAR and Security Automation Guide.

Restore

Other techniques and artefacts tracked

• Further confirmed techniques: Emulated File Analysis D3-EFA, Homoglyph Detection D3-HD, Identifier Activity Analysis D3-IAA, Identifier Reputation Analysis D3-IRA, Inbound Session Volume Analysis D3-ISVA, IPC Traffic Analysis D3-IPCTA, RPC Traffic Analysis D3-RTA, Protocol Metadata Anomaly Detection D3-PMAD, Remote Firmware Update Monitoring D3-RFUM, Service Binary Verification D3-SBV, User Session Init Config Analysis D3-USICA, File Creation Analysis D3-FCA, Process Code Segment Verification D3-PCSV, Process Self-Modification Detection D3-PSMD, Shadow Stack Comparisons D3-SSC, LAN Access Mediation D3-LAMED, Routing Access Mediation D3-RAM, Local File Access Mediation D3-LFAM, Remote File Access Mediation D3-RFAM, Proxy-based Web Server Access Mediation D3-PBWSAM, File Content Decompression Checking D3-FCDC, File Internal Structure Verification D3-FISV, File Metadata Consistency Validation D3-FMCV, File Metadata Value Verification D3-FMVV, Application Hardening D3-AH, Exception Handler Pointer Validation D3-EHPV, Integer Range Validation D3-IRV, Memory Block Start Validation D3-MBSV, Null Pointer Checking D3-NPC, Physical Enclosure Hardening D3-PEH, RF Shielding D3-RFS.
• Artefacts confirmed in the ontology: Application Installer, Application Shim, Binary Large Object, Computing Snapshot, Storage Snapshot, Credential Management System, Kernel Module, Kernel Process Table, Linux Delete Module, Linux Execve, Linux Execveat, Linux Init_Module, Linux Mmap, Linux Ptrace arguments such as PTRACE_ATTACH, Logon User, OS API Exec, Named Pipe, Firmware, NTFS Link, NTFS Hard Link, NTFS Symbolic Link, NTFS Junction Point, Operating System Packaging Tool, Orchestration Controller, Reverse Proxy Server, Saved Instruction Pointer, Software Repository, Stack Frame Canary.
• Also tracked, not individually verified here: User Account MFA Enable Event, User Account Password Reset Event, WMI Creation, Windows Registry Key Creation, Modification, Deletion and Access, Snapshot Deletion, Logon Session Creation, Logon Session Metadata, OS API Execution, Named Pipe Metadata, Firmware Modification, Kernel Module Load Event, PTRACE_TRACEME, PTRACE_POKETEXT, Domain Controller Authentication, Active Directory Credential Request, Active Directory Object Creation, Modification, Access and Deletion, Group Permission Footprinting.

The matrix and the CAD tool

The matrix on the D3FEND home page shows every technique under its tactic; each technique page gives the definition, how it works, considerations, artefact relationships, related ATT&CK techniques and references. The CAD tool lets you place and connect nodes on a canvas, apply D3FEND inference with a right-click and share the graph. Draw one scenario at a time, such as credential dumping followed by lateral movement, with the artefacts involved and the countermeasures you run against each: architecture boards can then review the reasoning, not just a heat map.

Running a control coverage analysis

1. Pin the versions. Record the D3FEND release (1.6.0) and ATT&CK release (v20) so results are comparable and you can fall back to the previous baseline if a release changes IDs.
2. Scope by threat. Pick 10 to 20 ATT&CK techniques from your threat model, for example T1003.001, T1110.003 and T1558.001 for an Active Directory estate.
3. Pull candidate countermeasures from each technique's D3FEND relationships, with the artefacts involved.
4. Inventory what you run as D3FEND IDs with scope: "D3-PLA on 92% of Windows servers", not "we have EDR".
5. Grade each cell as tested, untested, partial scope or absent, and note the tactic: an Evict or Restore gap matters as much as a Detect gap.
6. Test on a pilot segment with adversary emulation before claiming coverage. See the Breach and Attack Simulation (BAS) Guide.
7. Assign and repeat. Turn gaps into backlog items with owners and dates; re-run quarterly, in step with D3FEND releases.

Using D3FEND for procurement and engineering

• Procurement: ask vendors to state capabilities as D3FEND IDs with artefacts, platforms and default state. Comparing two EDR products on D3-PLA, D3-SEA, D3-SJA and D3-PT beats comparing marketing categories; prove the claims in a proof of concept.
• Engineering: technique "considerations" list known weaknesses, such as PPID spoofing against lineage analysis; make them test cases.
• Detection content: tag each analytic with the D3FEND ID it implements and the ATT&CK ID it detects, to expose over-reliance on one technique such as reputation lookups.
• Choosing a framework: ATT&CK answers "what might attackers do", D3FEND "what exactly do our controls do, and to which objects", and NIST SP 800-53 or CIS Controls "what must we have". D3FEND bridges the first and last.
• Small vs large organisations: small teams get most value from Harden and Evict and a one-page sheet for their top ten threats. Large organisations can load d3fend.json into a graph database or GRC tool and join it to asset and control inventories. See the Control Mapping Guide.

Where identity fits

Identity controls appear in six of the seven tactics. Access Modeling D3-AM records which identities hold which permissions. Agent Authentication D3-AA and Credential Hardening D3-CH cover MFA, token binding and rotation; Credential Rotation D3-CRO names API keys and certificates explicitly, making it the natural ID for non-human identity rotation. Credential Transmission Scoping D3-CTS restricts where a credential can be presented. The User Behavior Analysis family (D3-ANET, D3-CCSA, D3-DAM, D3-LAM) is the detection side; Credential Eviction, Authentication Cache Invalidation and Reissue Credential are response and recovery. See the Service Account Security Guide, the Secrets Management Guide and the ITDR Guide.

Measuring coverage

Keep evidence that each mapped technique runs: EDR process telemetry for D3-PLA, authentication logs for D3-ANET and D3-UGLPA, directory events for D3-DAM, rotation job results for D3-CRO and restore test records. Metrics:

• Threat coverage: priority ATT&CK techniques with at least one tested D3FEND countermeasure.
• Tactic depth: priority techniques covered in Harden, Detect and Evict.
• Scope: in-scope assets where each mapped technique is active.
• Validation rate: mapped controls tested by emulation in the last 90 days.
• Eviction time: median time from detection to credential revocation and session termination.
• Restore confidence: successful restore tests per quarter.

Framework mapping

D3FEND technique pages do not publish control framework mappings, so this is an indicative NHI Mgmt Group alignment, not an official mapping.

Common failure patterns

• Inferred links counted as coverage: a heat map turns green because a related technique exists, without checking it is deployed on the right artefact or that it fires.
• Partial scope reported as full: MFA (D3-MFA) is "in place" except on one gateway. The Change Healthcare breach began with a Citrix login that had no MFA.
• Harden without Evict: patching (D3-SU) closes the hole but stolen secrets stay valid. In ToolShell, stolen ASP.NET machine keys kept attackers inside after patching: a Credential Rotation and Revocation gap.
• Dormant accounts unwatched: no Domain Account Monitoring or Account Locking for unused accounts. The Colonial Pipeline attack started from one unused VPN account.
• Mixed releases: D3FEND pages citing older ATT&CK IDs mapped against a v20 threat model, so retired techniques look covered.
• D3FEND as a shopping list: it does not prioritise; buying for every cell wastes budget that should follow the threat model.

Practitioner checklist

• Record the D3FEND and ATT&CK releases used in every coverage analysis.
• Choose priority ATT&CK techniques from your threat model before opening the matrix.
• Describe each deployed control as D3FEND IDs with platform and asset scope.
• Grade coverage as tested, untested, partial or absent.
• Give every priority technique Harden, Detect and Evict coverage.
• Map machine identity rotation, revocation and reissue to D3-CRO, D3-CR and D3-RIC.
• Ask vendors to answer in D3FEND IDs, then test the claims.
• Tag detection rules with both ATT&CK and D3FEND IDs.
• Re-run the analysis quarterly and after major incidents.

Standards and references

• MITRE D3FEND: D3FEND matrix
• MITRE D3FEND: Frequently asked questions
• MITRE D3FEND: Digital Artifact Ontology
• MITRE D3FEND: Credential Hardening (D3-CH)
• MITRE D3FEND: Process Lineage Analysis (D3-PLA)
• MITRE D3FEND: d3fend-ontology repository
• MITRE: MITRE Launches D3FEND 1.0, a Milestone in Cybersecurity Ontology
• MITRE ATT&CK: T1003.001 LSASS Memory

Related NHI Mgmt Group resources: Detection Engineering Guide · Deception Technology Guide · SOAR and Security Automation Guide · Credential Dumping Guide · ITDR Guide