Framework

MITRE D3FEND
the defensive technique knowledge graph paired with ATT&CK

MITRE D3FEND is an open knowledge graph of defensive countermeasure techniques, organised as a directed graph anchored on Digital Artefacts the offensive and defensive sides both operate on. Where ATT&CK is the offensive technique catalogue, D3FEND is the defensive technique catalogue paired with ATT&CK at the artefact level. SecPortal operates a D3FEND-aligned engagement as one structured record across the in-scope offensive technique set, the in-scope defensive technique set, the in-scope Digital Artefact inventory, and the per-finding ATT&CK-and-D3FEND pairing.

Get Started Free

No credit card required. Free plan available forever.

MITRE D3FEND: a defensive countermeasure knowledge graph, paired with ATT&CK by Digital Artefact

MITRE D3FEND is an open knowledge graph of defensive countermeasure techniques, organised as a directed graph anchored on Digital Artefacts the offensive and defensive sides both operate on. Where MITRE ATT&CK is the offensive technique catalogue (what the attacker did, observed in real intrusions), D3FEND is the defensive technique catalogue paired with ATT&CK at the artefact level. A D3FEND technique reads against a Digital Artefact (process, file, credential, network flow, authentication event, executable binary, identifier, scheduled task, container, image, message) that an ATT&CK technique produces or relies on. The pairing surface is the Digital Artefact, not the textual name match, which is why the two knowledge bases read as a structural pair on the same engagement record.

For security operations leaders, detection engineering teams, security engineering and security architecture teams, AppSec and product security teams handing off to the operating defensive estate, GRC and compliance teams reading defensive evidence against NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, PCI DSS, CIS Controls, DORA, and NIS2, and CISOs carrying the board risk-committee read on defensive coverage, D3FEND is the per-technique evidence catalogue the threat-informed defence claim reads through. The value is the technique-level traceability that turns defensive coverage from a tooling inventory into a durable per-technique operating record.

This page covers how D3FEND is structured (seven defensive tactics, Digital Artefacts as the join surface, technique-and-sub-technique layering), how the pairing with ATT&CK works mechanically, how to run a threat-informed defence engagement that reads coverage against D3FEND technique tags, where D3FEND sits next to ATT&CK, NIST CSF 2.0, NIST SP 800-53, the Cyber Kill Chain, MITRE Engage, and MITRE CALDERA, the audience read for SOC, detection engineering, security engineering, AppSec, GRC, and CISO functions, the framework crosswalk the same engagement record satisfies, and how SecPortal operates a D3FEND-aligned engagement as one structured record.

The seven D3FEND tactics

D3FEND organises defensive techniques into seven top-level tactics, each named for the defensive objective at that step. The tactics are not severity-ranked; they are objective-ranked against the operating shape of a defensive estate, and a single defensive control often reads against techniques across more than one tactic. The tactics give the knowledge graph its navigable shape; the techniques and sub-techniques underneath each tactic give the per-class evidence the engagement record reads against.

ModelD3FEND tactic

Capture the inventory the defence operates against. Asset inventory, network mapping, source code asset mapping, system mapping, software inventory, and operational dependency mapping techniques sit here. Model output names the digital artefacts every other D3FEND technique reads against.

HardenD3FEND tactic

Reduce the attack surface before the attacker arrives. Application hardening, credential hardening, message hardening, platform hardening, and biometric authentication techniques live here. Harden techniques pair against ATT&CK Initial Access and Defense Evasion classes by removing the precondition the offensive technique relies on.

DetectD3FEND tactic

See offensive behaviour in operating data. File analysis, identifier analysis, message analysis, network traffic analysis, platform monitoring, process analysis, and user behaviour analysis techniques sit here. Detect techniques pair against ATT&CK Execution, Persistence, Privilege Escalation, Credential Access, Discovery, and Lateral Movement classes through Digital Artefact matches.

IsolateD3FEND tactic

Constrain an in-progress intrusion to a smaller blast radius. Execution isolation, network isolation, and account isolation techniques sit here. Isolate techniques pair against ATT&CK Lateral Movement and Command and Control classes by removing the path the offensive technique would have taken.

DeceiveD3FEND tactic

Channel adversary behaviour into observable surfaces. Decoy environment, decoy object, and decoy user techniques live here. Deceive techniques pair against ATT&CK Reconnaissance, Discovery, and Collection classes by giving the attacker a controlled surface to act on.

EvictD3FEND tactic

Remove the adversary from the environment once the operating record shows the path. Credential eviction, process eviction, and account eviction techniques sit here. Evict techniques pair against ATT&CK Persistence and Credential Access classes by reversing the persistence or credential possession that let the attacker stay.

RestoreD3FEND tactic

Return the asset to a known-good state. Restore techniques cover account, object, and system restoration after eviction. Pairs with the incident response after-action review and the post-incident lessons learned cycle that feed the next planning round.

Digital Artefacts: the join surface between D3FEND and ATT&CK

D3FEND is a knowledge graph, not a checklist, and the join with ATT&CK happens at the Digital Artefact level. Naming the join surface is the difference between a coverage claim that survives an architectural review and one that does not. The mechanic below is the structural pairing the knowledge graph encodes; tag accordingly so the engagement record reads against both knowledge bases at once.

D3FEND techniques are anchored to Digital Artefacts (DAOs) that name the data classes the technique reads against: process, file, credential, network flow, authentication event, executable binary, identifier, scheduled task, scheduled job, registry key, container, image, or message.
Each ATT&CK technique is also expressed in terms of the Digital Artefacts it produces or operates on. The pairing between an ATT&CK technique and a D3FEND technique happens at the Digital Artefact level, not at the textual name level.
A Digital Artefact match means the defensive technique observes or controls the same data class the offensive technique produces or relies on. The match is the structural pairing the knowledge graph encodes.
A finding tagged at the technique level (T1059 Command and Scripting Interpreter, for example) maps to defensive techniques that read process and command-line artefacts (D3-PA Process Analysis, D3-PSA Process Spawn Analysis, D3-PCSV Process Code Segment Verification) through the Digital Artefact join.
The knowledge graph form means the same engagement record can be read three ways: as a list of offensive techniques exercised (the ATT&CK side), as a list of defensive techniques the operating environment runs (the D3FEND side), and as a list of Digital Artefacts the two sides read against (the join surface).
D3FEND is versioned. Each release of the knowledge graph adds techniques, refines descriptions, and updates the Digital Artefact pairings. Engagements that cite D3FEND should record the D3FEND version used so the operating record is reproducible against a versioned graph state.

Tagging principles that survive contact with the engagement

Most D3FEND programmes start strong on knowledge-graph fidelity and decay because tagging happens at report time rather than during the engagement. By then the operator memory is gone, the operating-tool inventory has drifted, and the Digital Artefact pairing ends up approximate. Build the discipline into the workflow so the coverage matrix is derived from the operating record, not constructed from memory at report time.

Tag defensive control evidence at the D3FEND technique level when the operating tool produces detection or prevention output that maps to a named technique (D3-PA Process Analysis for EDR process telemetry, D3-NTA Network Traffic Analysis for NDR flow analytics, D3-UAP User Account Permissions for IAM hardening output).
Pair every D3FEND defensive technique tag with the ATT&CK offensive technique it is intended to address through the Digital Artefact join. The pair is the coverage record, not the D3FEND tag alone.
Treat the absence of a D3FEND tag for a given ATT&CK technique as a coverage gap. A red team or pentest finding that exercises T1078 Valid Accounts with no D3-UAP, D3-LFP, or D3-MFA defensive evidence on the engagement record is an open gap, not a closed risk.
Always record the D3FEND version used for the engagement. D3FEND is a versioned knowledge graph; coverage claims should be reproducible against a named graph state.
Tag defensive evidence at engagement time, not at report time. The defensive technique reads against the operating telemetry, the firewall policy, the IAM policy, or the patch baseline that exists at that moment; rebuilding it months later loses fidelity.
Distinguish prevented attempts (D3FEND Harden, Isolate techniques) from detected attempts (D3FEND Detect techniques) on the same finding record. Prevention and detection answer different audit questions and read against different control families.

Running a threat-informed defence engagement, end to end

Threat-informed defence work benefits from D3FEND even when the engagement is a single application scope, a single network segment, or a single operating-system class. The knowledge graph gives the work a structure that connects the offensive techniques exercised, the defensive techniques the operating estate runs, and the Digital Artefacts the pairing reads against. The workflow below assumes the engagement is run as a structured project on SecPortal rather than a collection of ad-hoc artefacts.

Inventory the in-scope operating estate against the D3FEND Model tactic

D3FEND Model techniques (Asset Inventory, Network Mapping, Source Code Asset Mapping, System Mapping, Software Inventory) establish the baseline the defensive coverage is measured against. The estate is the network of digital artefacts the rest of the knowledge graph reads against, not a separate document. SecPortal carries the in-scope domain set under verified-domain ownership, the connected repositories under OAuth, the authenticated-scanning credentials under encrypted storage, and the third-party scanner imports under bulk-finding import, so the inventory baseline reads against the verified workspace state.

Map the threat model to the offensive techniques in scope

Pair the agreed threat actor profile with the ATT&CK techniques the actor is known to use. A commodity ransomware affiliate, a credential-harvesting access broker, an APT-style operator, and a malicious insider exercise different technique subsets. The threat model defines which D3FEND techniques the engagement is measuring coverage against. The ATT&CK technique scope becomes the engagement record the D3FEND coverage record reads against.

Record the defensive operating estate against the relevant D3FEND techniques

Translate the existing operating tools and policies into D3FEND technique tags: EDR process telemetry to D3-PA Process Analysis, EDR command-line telemetry to D3-CSPP Command and Scripting Process Profile, NDR flow analytics to D3-NTA Network Traffic Analysis, NDR DNS analytics to D3-DNSTA DNS Traffic Analysis, IAM MFA enforcement to D3-MFA Multi-Factor Authentication, IAM session timeout to D3-SCF Session Configuration, network segmentation to D3-NI Network Isolation, patch programme to D3-SU Software Update, application allow-listing to D3-EAL Executable Allow Listing, decoy systems to D3-DE Decoy Environment. The mapping is descriptive, not prescriptive.

Run the offensive engagement with technique-level evidence on each finding

Every finding gets an ATT&CK technique tag at creation, with the offensive procedure (the command, the payload, the toolchain) captured alongside. The engagement record carries the ATT&CK technique inventory the engagement exercised; the D3FEND coverage record pairs to that inventory by Digital Artefact join. SecPortal stores ATT&CK technique tags in the finding record alongside CVSS, CWE, OWASP categorisation, and the free-text mapping fields. The D3FEND technique tag joins through the same finding record.

Derive the coverage matrix from the operating record

The coverage matrix is the cross-product of ATT&CK techniques exercised and D3FEND techniques recorded. Cells where an ATT&CK technique was exercised and a D3FEND technique recorded a prevention or detection are positive coverage; cells where the offensive technique succeeded with no defensive evidence are open gaps. The matrix is read at engagement close, not improvised at report time. SecPortal AI-assisted reports compose the matrix narrative from the live finding tags and the recorded defensive evidence without re-keying the knowledge graph into a document.

Hand each gap to a named defensive owner with a target Digital Artefact

A D3FEND coverage gap is not actionable until it names which Digital Artefact the missing defensive technique would read against and which owner holds the operating tool that produces that artefact. The owner record sits on the finding through the team-management RBAC layer; the artefact reference lives in the finding description. The retest after the defensive change is paired to the same ATT&CK technique exercised the first time, so the closure record reads against the same join surface.

Routines that read against the D3FEND knowledge graph

D3FEND is closest to its operational shape during the recurring routines that read the defensive estate against the threat model. The routines below all read coverage against the same engagement record on SecPortal; the value comes from the cycle-over-cycle comparison the engagement record supports. For collaborative exercises where the red and the blue operators record outcomes per technique on the same engagement, the purple team operations workflow applies the same Digital Artefact pairing with the detection outcome captured inline against each action, and the red team workflow runs the offensive side with the technique-level tagging that the D3FEND coverage record reads against.

Adversary emulation cycles that exercise a documented threat actor playbook (an ATT&CK G-group profile) and read the coverage against the D3FEND techniques the operating estate runs
Purple-team operations where the red operator exercises the technique and the blue operator records the D3FEND technique that detected, prevented, or missed the action on the same engagement record
Detection engineering test cycles where each new analytic is validated by re-running the relevant ATT&CK techniques and the D3FEND technique pairing is updated on the engagement record
Pre-deployment defensive review cycles that score the proposed control set in D3FEND technique terms before a new platform or application ships
Post-incident lessons-learned reviews that close the loop between the offensive technique chain observed and the D3FEND coverage that was in place at the time
Annual coverage reviews that score the overall defensive surface against the threat model and produce the next-cycle defensive roadmap

Recurring failure modes that weaken a D3FEND record

Programmes that struggle with D3FEND typically hit a small set of recurring failure modes. Naming the failure modes up front lets the engagement design controls to avoid them rather than discovering them during the report review or the audit fieldwork.

Treating D3FEND as ATT&CK-with-defensive-techniques rather than as a separate knowledge graph paired by Digital Artefacts. The pairing happens at the artefact level; programmes that translate ATT&CK technique names into "defensive technique names" by text matching lose the join the knowledge graph encodes and produce a coverage matrix that does not survive an architectural review.

Tagging defensive techniques against a single product rather than against the operating control. EDR is a product, not a D3FEND technique. The D3FEND technique is the analytic the product runs (D3-PA Process Analysis, D3-CSPP Command and Scripting Process Profile, D3-FA File Analysis, and so on). Tagging at the product level loses the discrimination the knowledge graph supports and produces a coverage matrix the audit reads as overstated.

Reading D3FEND as a checklist rather than as a knowledge graph. The graph form means the same defensive technique can read against multiple ATT&CK techniques (a single D3-MFA Multi-Factor Authentication record pairs to T1078 Valid Accounts, T1110 Brute Force, T1556 Modify Authentication Process, and T1621 Multi-Factor Authentication Request Generation). Checklist-style reads count the same evidence multiple times and undercount the techniques each control actually addresses.

Skipping the Digital Artefact step in the pairing. The Digital Artefact is the join surface; a D3FEND coverage claim that does not name the Digital Artefact the defensive technique reads against is a claim without evidence the knowledge graph supports.

Treating D3FEND as a one-time mapping exercise. The knowledge graph is versioned and the operating environment changes; defensive coverage scored against an unspecified D3FEND version against an unrecorded set of operating tools is not reproducible. The coverage record needs the D3FEND version, the operating tool inventory, and the Digital Artefact inventory the coverage was scored against.

Counting prevented and detected outcomes as the same coverage signal. D3FEND Harden techniques prevent the offensive technique from succeeding; D3FEND Detect techniques observe the offensive technique when it does succeed. Programmes that combine the two without distinction produce a coverage record the audit reads as conflated and the next-cycle planning round reads as ambiguous.

Stopping at coverage measurement without closing the gap. The coverage matrix is the input to the defensive roadmap, not the output. A gap that names which Digital Artefact is missing observation, which operating tool would produce that artefact, and which owner holds the budget for that tool is actionable; a gap that names only the absence is filing.

Treating D3FEND as a substitute for an incident response runbook. The knowledge graph is the planning and coverage layer; the incident response runbook is the operating procedure when the offensive technique is observed in real time. The two read against each other but do not replace each other.

How D3FEND sits next to ATT&CK, NIST CSF 2.0, NIST SP 800-53, Engage, CALDERA, and the kill chain

D3FEND is rarely used in isolation. It is the per-technique defensive catalogue that the offensive knowledge base, the outcome-oriented framework, the control catalogues, the adversary engagement framework, the test execution platform, and the executive-narrative kill chain all read into. The contrast below is a working view, not a buyer comparison: the practitioner question is which artefacts to pair D3FEND with, not which to pick instead of it.

MITRE D3FEND vs MITRE ATT&CK

ATT&CK is the offensive technique knowledge base: tactics, techniques, sub-techniques, and procedures observed in real intrusions. D3FEND is the defensive countermeasure knowledge graph paired with ATT&CK through Digital Artefacts. ATT&CK answers "what did the attacker do"; D3FEND answers "what control class was supposed to address that". Mature threat-informed defence programmes use the two as paired reference layers on the same engagement record, with the finding carrying both the ATT&CK technique exercised and the D3FEND defensive technique that did or did not prevent or detect it.

MITRE D3FEND vs NIST CSF 2.0

NIST CSF 2.0 is the outcome-oriented cybersecurity framework with six functions (Govern, Identify, Protect, Detect, Respond, Recover) and named categories and sub-categories per function. D3FEND is the technical countermeasure knowledge graph that supplies the per-technique evidence layer the CSF Protect and Detect functions read against. CSF asks "is the outcome present"; D3FEND names "which technique class is producing the outcome and against which Digital Artefact". Programmes pair the two with CSF as the outcome scorecard and D3FEND as the technique evidence catalogue underneath the Protect (PR.PS, PR.AA, PR.IR), Detect (DE.CM, DE.AE), and Respond (RS.AN, RS.MA) categories.

MITRE D3FEND vs NIST SP 800-53

NIST SP 800-53 Rev 5 is the control catalogue with about a thousand security and privacy controls across 20 families. D3FEND is the technique knowledge graph the SI (System and Information Integrity), SC (System and Communications Protection), AU (Audit and Accountability), IA (Identification and Authentication), and AC (Access Control) families read against on the technical layer. SP 800-53 catalogues controls; D3FEND catalogues the techniques each control implements. The Federal Risk and Authorisation Management Program (FedRAMP) and the Federal Information Security Modernisation Act (FISMA) read the SP 800-53 control evidence; D3FEND supplies the per-technique trace underneath that control evidence.

MITRE D3FEND vs MITRE Engage and MITRE CALDERA

MITRE Engage is the framework for adversary engagement, deception, and denial planning (different scope: engagement strategy rather than countermeasure inventory). MITRE CALDERA is the open-source adversary emulation platform that operationalises ATT&CK techniques in a test environment (different scope: test execution rather than knowledge graph). D3FEND sits next to both as the defensive countermeasure knowledge graph that the Engage strategy and the CALDERA-driven test cycle read coverage against.

MITRE D3FEND vs the Cyber Kill Chain

The Lockheed Martin Cyber Kill Chain is the seven-stage intrusion model (Reconnaissance, Weaponisation, Delivery, Exploitation, Installation, Command and Control, Actions on Objectives). The kill chain gives a planning-side narrative shape; ATT&CK and D3FEND give the technique-level catalogues underneath the narrative. Programmes that operate the kill chain as the executive-narrative layer still use ATT&CK and D3FEND as the technique-level operating record the audit and the defensive roadmap read against.

MITRE D3FEND vs IOCs and threat intelligence feeds

Indicators of compromise (file hashes, IP addresses, domain names, URLs) are the per-event observable layer. Threat intelligence feeds are the curated indicator and behaviour sets vendors publish. D3FEND is one level above: the technique class catalogue the indicator-based detections fit inside. A detection rule that alerts on a specific IP is a procedure-level signal; the D3FEND technique that the rule implements (D3-NTA Network Traffic Analysis, D3-DNSTA DNS Traffic Analysis) is the per-class coverage record the audit reads against.

Buyers procuring a threat-informed defence engagement should pair the D3FEND coverage record with MITRE ATT&CK as the offensive technique catalogue the engagement exercises against, with NIST CSF 2.0 as the outcome scorecard the technique evidence reads against, with continuous threat exposure management as the exposure-management programme the technique coverage reads through, and with CREST and TIBER-EU as the assurance frameworks the threat-led testing cycle reads against on the offensive side.

How auditors and regulators read a D3FEND citation

D3FEND is not itself a regulator-issued standard; it is the open defensive technique knowledge graph that regulator-issued standards, audit frameworks, and procurement processes accept as the per-technique evidence record for the defensive estate. The list below maps D3FEND to the regulator-side and audit-side references that read against it; the same engagement record satisfies several reads at once when the per-technique coverage is honest.

NIST CSF 2.0 functions Protect (PR.PS Platform security, PR.AA Identity management, authentication, and access control, PR.IR Technology infrastructure resilience, PR.DS Data security), Detect (DE.CM Continuous monitoring, DE.AE Anomalies and events), and Respond (RS.AN Incident analysis, RS.MA Incident management): the D3FEND knowledge graph is the per-technique evidence catalogue the CSF outcome categories read against.
NIST SP 800-53 Rev 5 SI-3 (System monitoring), SI-4 (Information system monitoring), SI-7 (Software, firmware, and information integrity), CA-7 (Continuous monitoring), IR-4 (Incident handling), IR-5 (Incident monitoring), SC-7 (Boundary protection), AU-12 (Audit record generation): D3FEND defensive techniques are the per-technique trace evidence the SI, IR, SC, and AU family controls read against on the operating layer.
ISO/IEC 27001:2022 Annex A 5.7 (Threat intelligence), A 5.24 (Information security incident management planning and preparation), A 8.16 (Monitoring activities), A 8.20 (Networks security), A 8.21 (Security of network services), A 8.22 (Segregation of networks), and A 8.27 (Secure system architecture and engineering principles): D3FEND is the per-technique evidence catalogue auditors read against the ISMS-in-scope defensive estate.
SOC 2 Trust Services Criteria CC6.1 (Logical and physical access), CC6.6 (Logical access security measures), CC7.1 (Detection of unauthorised actions), CC7.2 (Incident response evaluation), CC7.3 (Incident response communication), CC7.4 (Response to security incidents): D3FEND defensive techniques are the per-technique trace evidence the SOC 2 auditor reads on the operating estate.
PCI DSS Requirement 10 (Log and monitor all access to system components and cardholder data), Requirement 11.4 (Penetration testing), Requirement 11.5 (Intrusion detection and prevention), Requirement 12.10 (Incident response plan): D3FEND supplies the per-technique evidence the QSA reads on the cardholder-data environment defensive estate.
CIS Controls v8.1 Control 13 (Network monitoring and defence) Safeguards 13.1 through 13.11, Control 17 (Incident response management) Safeguards 17.1 through 17.9, Control 8 (Audit log management) Safeguards 8.1 through 8.12, Control 4 (Secure configuration of enterprise assets and software) Safeguards 4.1 through 4.12: D3FEND techniques supply the per-technique verification evidence the Control 13 and Control 17 safeguards expect.
NIST SP 800-115 (Technical guide to information security testing and assessment) and the broader threat-informed assessment discipline: D3FEND is the per-technique defensive catalogue the technical assessment evidence reads against alongside ATT&CK as the per-technique offensive catalogue.
DORA Article 9 (ICT security policies, procedures, protocols and tools), Article 10 (Detection), Article 11 (Response and recovery), Article 12 (Backup policies and recovery), Article 13 (Learning and evolving), and Article 17 (ICT-related incident management): D3FEND is the per-technique evidence the financial-entity supervisory authority reads against the defensive estate supporting in-scope ICT services.
NIS2 Article 21(2)(a) (Policies on risk analysis and information system security), 21(2)(b) (Incident handling), 21(2)(d) (Supply chain security), 21(2)(e) (Security in network and information systems acquisition, development and maintenance), 21(2)(g) (Basic cyber hygiene practices and cybersecurity training), 21(2)(h) (Policies and procedures regarding cryptography), and Article 23 (Reporting obligations): D3FEND supplies the per-technique evidence the competent authority reads against essential and important entity defensive estates.
NIST AI Risk Management Framework (AI RMF 1.0) Govern, Map, Measure, and Manage functions and the Generative AI Profile: D3FEND techniques that read against AI-system Digital Artefacts (model artefacts, inference logs, prompt-and-response logs, retrieval artefacts) supply the per-technique evidence the AI RMF Measure function reads against on the operating AI-system surface.
NIST CSF 2.0 Govern (GV.OC Organisational context, GV.RR Roles, responsibilities, and authorities, GV.PO Policy, GV.SC Cybersecurity supply chain risk management, GV.OV Oversight) function: D3FEND is the per-technique evidence the leadership-and-oversight read consults for the defensive estate the governance function manages.

For the broader audit-evidence story (how the same finding can satisfy multiple regulator reads without rebuilding the evidence pack per audit), see the vulnerability evidence reuse across audits research and the multi-framework control crosswalk economics research. The control-validation discipline that reads outputs from D3FEND-tagged exercises is covered in the control validation vs detection validation pairing research.

The D3FEND read across defensive-estate functions

D3FEND is a cross-functional artefact. The same coverage record reads differently depending on which function holds the work. Programmes that run threat-informed defence as a SOC exercise alone lose the architectural depth the catalogue supports; programmes that run it as a CISO scorecard alone lose the engineering depth. The named functions below own different parts of the same defensive-coverage record.

Security operations leaders and SOC managers

Security operations leaders use D3FEND as the per-technique catalogue the SOC operating tools score against. The leader-side question is no longer how many alerts fired, it is which D3FEND techniques are present, which Digital Artefacts the operating tools cover, which ATT&CK techniques are paired against each D3FEND technique on the engagement record, and which gaps are deferred with a named compensating control. The catalogue gives the answer a structured shape the audit reads and the budget cycle plans against.

Detection engineering and threat-led purple teams

Detection engineering teams use D3FEND as the technique inventory each new analytic, each new rule, and each new content pack is tagged against. A new SIEM rule is not a generic detection, it is a D3FEND technique implementation that reads against a named Digital Artefact. Purple-team operations use the catalogue as the shared coverage matrix the red operator and the blue operator update on the same engagement record at exercise time, not at report time.

Security engineering and security architecture teams

Security engineering and security architecture teams use D3FEND as the per-technique threat-model anchor for new platforms, new applications, and new integrations. The pre-deployment review reads the proposed control set in D3FEND technique terms (D3-PA Process Analysis presence, D3-EAL Executable Allow-Listing presence, D3-NI Network Isolation scope, D3-MFA Multi-Factor Authentication scope, D3-SU Software Update cadence) rather than as a generic control checklist, so the review claim is technique-traceable.

AppSec and product security teams

AppSec and product security teams use D3FEND as the cross-discipline language the application security findings hand off to the operating defensive estate against. A finding that lands as exposed credential class (CWE-256, CWE-798) reads against the IAM-side D3FEND techniques (D3-MFA, D3-LFP, D3-CRP Credential Rotation) on the same engagement record, so the per-finding fix is not handed off to "the SOC" as an abstract entity but to the specific D3FEND technique pair the finding evidences.

GRC and compliance teams reading defensive evidence

GRC and compliance teams use D3FEND as the per-technique evidence artefact that maps to NIST CSF 2.0, NIST SP 800-53 Rev 5, ISO 27001 Annex A 5.7, A 5.24, A 8.16, A 8.20, A 8.21, A 8.22, A 8.27, SOC 2 CC6 and CC7, PCI DSS Requirement 10 and 11.5, CIS Controls v8.1 Control 13 and Control 17, DORA Article 9, 10, 11, 13, and 17, and NIS2 Article 21 paragraph 2 (a) through (h) and Article 23. The team consumes the per-technique record on the workspace rather than rebuilding the evidence pack per audit, with the framework crosswalk reading once into multiple regulator reads.

CISOs, security directors, and security program owners

CISOs and security directors use D3FEND as the durable, version-anchored defensive evidence layer the board risk-committee and audit-committee reads run against. The leader-side question is which D3FEND technique classes are verified at which level on which assets across the estate, which are deferred with named compensating control, and which are excluded from scope and why. The catalogue gives the answer a structured shape and the year-on-year comparison reads against a named graph state, not a moving definition of coverage.

The persona-specific entry points are SecPortal for detection engineering teams, SecPortal for security engineering teams, SecPortal for internal security teams, SecPortal for AppSec teams, SecPortal for product security teams, SecPortal for GRC and compliance teams, and SecPortal for CISOs. Each anchors a different view of the same D3FEND engagement record.

Adjacent MITRE and threat-informed defence references

D3FEND reads alongside several other MITRE and threat-informed defence references. Each one covers a different slice of the operating model; D3FEND is the per-technique evidence artefact that converts the references into a verifiable defensive record.

MITRE D3FEND and MITRE ATT&CK

The two knowledge bases are paired by design. ATT&CK names the offensive techniques observed in real intrusions; D3FEND names the defensive techniques that read against those offensive techniques through the Digital Artefacts both sides operate on. Engagements cite the ATT&CK version and the D3FEND version together so the coverage claim is reproducible against versioned graph states.

MITRE D3FEND and MITRE Engage

MITRE Engage is the adversary engagement, deception, and denial planning framework. D3FEND sits next to Engage as the broader defensive countermeasure inventory; the Engage strategy reads its denial and deception actions against the D3FEND Deceive tactic techniques (D3-DE Decoy Environment, D3-DO Decoy Object, D3-DU Decoy User) and the D3FEND Isolate tactic techniques (D3-EI Execution Isolation, D3-NI Network Isolation, D3-AI Account Isolation).

MITRE D3FEND and MITRE CALDERA

MITRE CALDERA is the open-source adversary emulation platform that operationalises ATT&CK techniques in a test environment. CALDERA produces the test-side execution record; D3FEND produces the defensive-side coverage record. The two read together: CALDERA as the test executor, D3FEND as the per-technique coverage catalogue the test outcome reads against.

MITRE D3FEND and the Cyber Kill Chain

The Lockheed Martin Cyber Kill Chain is the executive-narrative framework that names seven intrusion stages from Reconnaissance to Actions on Objectives. The kill chain is the storyline that the technique-level catalogues (ATT&CK on the offensive side, D3FEND on the defensive side) sit underneath. Programmes that operate the kill chain as the executive-summary frame still use ATT&CK and D3FEND as the technique-level operating record the audit and the defensive roadmap read against.

Running a D3FEND engagement on SecPortal

SecPortal is the operating record for a threat-informed defence engagement, not a replacement for the D3FEND knowledge graph or the detection engineering team. The platform holds the in-scope offensive and defensive technique sets, the in-scope Digital Artefact inventory, the per-finding ATT&CK technique tag, the per-finding D3FEND defensive technique pairing, the evidence per technique, and the report that ties them together. Coverage tracking, the cross-cycle comparison, and the defensive roadmap live alongside the same findings management record that drives CVSS scoring and remediation. For multi-framework programmes, the same finding can carry an ATT&CK tag, a D3FEND tag, and a mapping to NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, PCI DSS, or CIS Controls without re-keying anything.

Findings management stores each finding with a free-text technique mapping field that accepts MITRE ATT&CK technique IDs (T-numbers) and MITRE D3FEND technique identifiers (D3-prefixed identifiers) alongside CVSS 3.1, CWE, and OWASP categorisation, so the per-finding offensive-and-defensive pair is held on the same record the verification report and the audit pack read against.
Engagement management captures a threat-informed defence engagement as a structured record: the in-scope offensive technique set (the ATT&CK subset the threat model includes), the in-scope defensive technique set (the D3FEND subset the operating estate runs), the in-scope Digital Artefact inventory the pairing reads against, the testing window, and the retest scope, so the coverage matrix is anchored to one engagement record rather than a contract attachment.
AI-assisted reports compose the coverage narrative from the live engagement, findings, and per-finding technique tags, citing the named ATT&CK technique, the named D3FEND defensive technique, the named Digital Artefact, and the named operating tool where each finding was observed rather than starting from a blank template. The matrix narrative draws on the workspace record without re-keying the knowledge graph into a document.
Compliance tracking lets one threat-informed defence engagement feed framework mappings to NIST CSF 2.0 (Identify, Protect, Detect, Respond, Recover, Govern functions), NIST SP 800-53 Rev 5 SI-3 (System monitoring), SI-4 (Information system monitoring), CA-7 (Continuous monitoring), and IR-4 (Incident handling), ISO 27001 Annex A 5.7 (Threat intelligence), A 8.16 (Monitoring activities), A 8.20 (Networks security), and A 8.21 (Security of network services), SOC 2 Trust Services Criteria CC7.1 (Detection of unauthorised actions), CC7.2 (Incident response evaluation), and CC7.3 (Incident response communication), PCI DSS Requirement 10 (Log and monitor all access), Requirement 11.5 (Intrusion detection), and Requirement 12.10 (Incident response plan), CIS Controls v8.1 Control 13 (Network monitoring and defence) and Control 17 (Incident response management), DORA Article 9 (ICT security policies), Article 10 (Detection), and Article 17 (Incident response), and NIS2 Article 21(2)(b) (incident handling) and Article 23 (notification), so the same engagement record reads several audit reads at once.
Document management holds the externally produced artefacts the platform does not generate inline: the threat model document, the defensive control inventory mapped to D3FEND techniques, the coverage matrix snapshot for the cycle, the defensive roadmap, the IDS/IPS/EDR/NDR detection content inventory, the network segmentation policy, the patch baseline document, the IAM policy document, with version history per artefact and named custodian per file, so the coverage record points at durable storage rather than email attachments.
Activity log with CSV export records the actor, the entity, the action, and the timestamp for every state change on the engagement, the findings, the override decisions, and the retests, with 30, 90, and 365-day retention windows depending on plan, so the audit trail behind the threat-informed defence operating record is portable across audit cycles and personnel transitions.
Code scanning runs SAST and SCA against connected GitHub, GitLab, and Bitbucket repositories through OAuth so the codebase-side D3FEND evidence (input validation, output encoding, credential handling, secure deserialisation) pairs to the same engagement record the network-side and operating-system-side coverage reads against.
External scanning runs the 16-module external surface check against verified domains so the perimeter-side D3FEND coverage (D3-NTA Network Traffic Analysis, D3-PMAD Per-Host Download-Source Reputation Analysis) reads against the verified surface, not against an unscoped target list.
Authenticated scanning runs the 17-module authenticated check behind verified credentials so the post-authentication D3FEND coverage (D3-UAP User Account Permissions, D3-LFP Local Account Monitoring, D3-AM Authorisation Monitoring) reads against verified surface state.
Repository connections under OAuth bind each scan back to a specific commit on a specific branch on a specific repository, so the codebase-side D3FEND evidence points at the live source state rather than a frozen export.
Bulk finding import accepts CSV intake from EDR, NDR, IAM, SIEM, and vulnerability scanner output so externally produced D3FEND-relevant findings land on the engagement record alongside the SecPortal-produced findings, with column mapping for the technique tag, the Digital Artefact, and the affected asset.
Retesting workflows pair each remediated finding to a verification step run against the post-fix operating state, with the retest evidence carrying the same ATT&CK technique tag and the same D3FEND defensive technique pairing the original finding cited, so the closure record updates the coverage matrix directly without renegotiation.
Team management with role-based access keeps security operations, security engineering, security architecture, detection engineering, vulnerability management, AppSec, GRC and compliance, and the security firm running the engagement on the same workspace with appropriate scoping per technique.
Multi-factor authentication enforcement at workspace level for the threat-informed defence operating records, so the identity assurance applies at access time as well as at evidence time.
Finding overrides hold deferred coverage-gap findings on the engagement record with a named approver, named scope, cited reason, hard expiry, and compensating control, so a deferred gap is evidenced rather than silent.

Honest scope: what SecPortal does not do

D3FEND work runs across multiple specialist tools and roles the SecPortal product does not replicate inline. The honest scope below names the boundaries so the engagement record reads against the verified product surface and the externally produced artefacts attach through document management rather than implying the platform performs work it does not perform.

SecPortal is not an EDR, NDR, SIEM, SOAR, XDR, MDR, MTD, CASB, SSE, SASE, or DLP platform. The defensive operating telemetry (process, network, identity, file, container, image, message) is produced by the customer-managed operating tools (CrowdStrike, SentinelOne, Microsoft Defender, Cortex XDR, Carbon Black, Elastic Security, Splunk, Microsoft Sentinel, Chronicle, Sumo Logic, Datadog Security, Wazuh, Vectra, ExtraHop, Darktrace, Corelight, Zeek, Suricata, Snort, Tetragon, Falco, Auditd, sysdig, Okta, Azure AD, Ping Identity, CyberArk, BeyondTrust, Delinea, and others) and lands on SecPortal as bulk-finding import CSV intake or as engagement record evidence attached through document management.
SecPortal does not run a D3FEND technique inventory crawler against operating tools. The defensive technique inventory is captured on the engagement record as document-management artefacts (the control catalogue, the operating-tool inventory mapped to D3FEND techniques, the rule catalogue mapped to D3FEND techniques) rather than as a live API-pull from the operating tools.
SecPortal does not run live adversary emulation. The platform does not execute CALDERA plays, Atomic Red Team techniques, Mitre Caldera operations, or Open-source Cobalt Strike against customer infrastructure. The execution record from those tools lands on the engagement as evidence through bulk-finding import or document-management attachment; the operating tool runs where the customer runs it.
SecPortal does not push back to the operating tools. The platform does not write SIEM rules, EDR detections, IAM policies, firewall rules, or network segmentation configurations into customer-managed operating tools. The remediation work happens in the operating tool the team already runs; SecPortal carries the engagement record and the finding record that drives the remediation work, not the configuration that ends up in the tool.
SecPortal does not ship packaged connectors into Jira, ServiceNow, Slack, Microsoft Teams, PagerDuty, SIEM platforms, SOAR platforms, GRC platforms, or CMDB systems. The D3FEND coverage record and the per-finding ATT&CK/D3FEND pairings live on the SecPortal workspace and the wider operational ticketing, runbook, and asset-management workflows remain in the systems where the rest of the work is tracked.
SecPortal does not ship enterprise single sign-on, SCIM, or SAML at the platform layer. Workspace authentication is email-plus-password with TOTP multi-factor authentication enforcement; identity assurance for federated enterprise login remains on customer-managed identity providers.
SecPortal does not run automated approval routing for deferred coverage-gap findings. Risk acceptance, exception approval, and deferred-finding sign-off are recorded on the workspace with named approver, named scope, cited reason, hard expiry, and compensating control through the finding-override feature; the platform records the decision rather than routing it through an external approval workflow engine.
SecPortal does not maintain the D3FEND knowledge graph. The graph is maintained by MITRE; SecPortal is the operating layer that runs an engagement against a versioned snapshot of the graph, with the per-technique record paired to the workspace findings and evidence.
SecPortal does not issue D3FEND-aligned defensive verification certificates. Coverage claims at the engagement level are made by the engagement team and reviewed by the buyer; SecPortal supplies the operating record the claim is anchored in, not the certificate.
SecPortal does not replace the operating SOC, the detection engineering team, the security architecture function, the incident response retainer, the MDR service, or the MSSP relationship. The platform is the operating ledger the work is recorded on; the work is performed by the customer team and the named partners the customer engages.

The operational workstreams the D3FEND programme reads against already exist as named use cases on SecPortal. The red team workflow carries the offensive technique evidence the D3FEND coverage record reads against. The purple team operations workflow captures the per-technique outcome on the same engagement record at exercise time. The continuous threat exposure management cycle runs the exposure-management programme the technique coverage reads through. The emerging vulnerability and CVE watch program feeds the new-technique signals into the D3FEND coverage record. The security leadership reporting workflow reads the coverage matrix to the audit committee and board risk committee.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Model tactic: inventory the digital artefacts the defence operates against

Asset Inventory, Network Mapping, Source Code Asset Mapping, System Mapping, Software Inventory, and Operational Dependency Mapping techniques. Evidence: the inventory baseline the rest of the knowledge graph reads against, the named-owner record per asset class, the dependency relationships between assets, and the connection between application-layer assets and the underlying operating-system, network, and cloud assets.

Harden tactic: reduce the attack surface before the attacker arrives

Application Hardening, Credential Hardening, Message Hardening, Platform Hardening, and Authentication Hardening techniques. Evidence: the hardening baselines per asset class, the deviation register, the named compensating controls for deviations, and the verification record per hardening control on the engagement.

Detect tactic: see offensive behaviour in operating data

File Analysis, Identifier Analysis, Message Analysis, Network Traffic Analysis, Platform Monitoring, Process Analysis, and User Behaviour Analysis techniques. Evidence: the detection content inventory per Digital Artefact class, the rule catalogue mapped to D3FEND techniques, the alert-volume baseline, and the verification record per detection on the engagement.

Isolate tactic: constrain an in-progress intrusion to a smaller blast radius

Execution Isolation, Network Isolation, and Account Isolation techniques. Evidence: the isolation policy per asset class, the network segmentation diagram, the account-isolation policy, the just-in-time access provisioning record, and the verification record per isolation control.

Deceive tactic: channel adversary behaviour into observable surfaces

Decoy Environment, Decoy Object, and Decoy User techniques. Evidence: the decoy inventory per asset class, the placement record, the alerting integration, and the engagement-rules record that distinguishes decoy interaction from legitimate user error.

Evict tactic: remove the adversary from the environment

Credential Eviction, Process Eviction, and Account Eviction techniques. Evidence: the eviction playbook per asset class, the verification record per eviction action, the credential-rotation cadence, and the connection between the eviction action and the closed incident record.

Restore tactic: return the asset to a known-good state

Restore Object, Restore Access, Restore Network Access, and Restore Configuration techniques. Evidence: the restore policy per asset class, the backup integrity record, the restore-verification record, and the connection between the restore action and the closed incident record.

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

AI-powered reports in seconds, not days

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Document management for every security engagement

Find vulnerabilities before they ship

Vulnerability scanning tools that map your attack surface

Test web apps behind the login

Repository connections for SAST and SCA

Bulk finding import bring your scanner data with you

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Multi-factor authentication on every workspace

Collaborate across your entire team

Monitor continuously catch regressions early

Run a threat-informed defence engagement on one workspace

Anchor each finding to an ATT&CK technique tag, a D3FEND defensive technique pairing, and a Digital Artefact reference. Carry the same engagement record across NIST CSF 2.0, NIST SP 800-53 Rev 5, ISO 27001 Annex A 5.7 and 8.16 to 8.27, SOC 2 CC6 and CC7, PCI DSS Requirement 10 and 11.5, CIS Controls v8.1 Control 13 and 17, DORA Article 9 and 17, and NIS2 Article 21 and 23 without rebuilding the evidence pack per audit. Start free.