D3FEND Model Tactic: Mapping Assets, Dependencies and Risk Before You Defend

Every other D3FEND countermeasure assumes you know what you are defending, and most organisations find out what they own only during an incident. MITRE D3FEND puts that knowledge work into its first tactic, Model, which it defines as being "used to apply security engineering, vulnerability, threat, and risk analyses to digital systems" by "creating and maintaining a common understanding of the systems being defended, the operations on those systems, actors using the systems, and the relationships and interactions between these elements." This hub lists all 27 Model techniques from the D3FEND ontology, explains how the four families fit together, shows which ATT&CK techniques D3FEND relates to them, and sets out an order of work for building the model. It is written for security architects, asset and configuration owners, vulnerability management leads and risk teams who already know the framework basics from the MITRE D3FEND Guide.

Key takeaways

• Model is the foundation tactic. D3FEND lists it first among its seven tactics: Harden, Detect, Isolate, Deceive, Evict and Restore all depend on knowing which assets, links, identities and activities exist.
• Four families, 27 techniques. Asset Inventory (D3-AI), Network Mapping (D3-NM), System Mapping (D3-SYSM) and Operational Activity Mapping (D3-OAM) are the four base techniques; the other 23 sit beneath them in the ontology.
• The model runs from bits to business. Inventory records what exists, network and system mapping record how it connects and depends, and operational mapping ties it to the activities, people and risks the organisation actually cares about.
• ATT&CK relations are inferred, not designed. D3FEND's site links some Model techniques to ATT&CK techniques through shared digital artefacts and labels those links "inferred, experimental"; the mapping families mostly show none.
• Inventory without ownership decays. The practical test of a model is not its size but whether each record has an owner, a last-seen date and a criticality that other controls consume.

What Model means in D3FEND

None of the Model techniques act on an attacker directly. They produce the shared picture the other tactics need (see "How Model feeds the other tactics").

In the ontology each of the four base techniques carries the relation enables Model. Their children inherit that relation and add a specific relation to a digital artefact, for example Software Inventory inventories Software, Logical Link Mapping maps Logical Link, and System Vulnerability Assessment evaluates Digital System and identifies Vulnerability. Those artefact relations are what D3FEND uses to infer links to ATT&CK, so they matter for the mapping section below.

Every technique in the Model tactic

The table lists every technique the D3FEND ontology places under Model, grouped by base technique, with its parent and a one-line purpose drawn from the D3FEND definition. Model techniques do not have individual technique pages on this site; this hub is their reference page, and the family sections that follow cover each one.

Asset Inventory family

Asset Inventory (D3-AI) is the base of the model. D3FEND's definition is broader than a list of machines: it includes enrichment with vulnerability knowledge, which is why Asset Vulnerability Enumeration sits inside this family rather than in a separate one.

• Network Node Inventory (D3-NNI): D3FEND describes collection through management queries (SNMP, WBEM, WMI) and, where those are not available, through host discovery and port and service scanning. Its considerations warn that scanning can cause side effects in IT and OT systems, so passive sensors or agent data are the safer first source for fragile networks.
• Hardware Component Inventory (D3-HCI) and Software Inventory (D3-SWI): both rely on management tooling that queries each node, with scripted or remote collection as a fallback. D3FEND notes that adversary enumeration can resemble inventory activity but needs administrative privileges, so inventory accounts are privileged identities.
• Configuration Inventory (D3-CI): configuration retrieved over SNMP MIBs, WBEM CIM records or scripts, stored in a repository that D3FEND names as typically a CMDB.
• Data Inventory (D3-DI): schemas, formats, volumes and locations of data in databases and document files. See the Data Classification Guide for sensitivity labels.
• Asset Vulnerability Enumeration (D3-AVE): evaluates software and physical artefacts and identifies vulnerabilities. This is scanner and advisory matching work; see the Risk-Based Vulnerability Management Guide for prioritisation.
• Container Image Analysis (D3-CIA): scanning images during the build workflow for outdated libraries, known vulnerabilities and misconfigurations such as unnecessary ports or permissions. D3FEND describes enforcing it with an admission controller webhook; Kubernetes documents that admission controllers act after a request is authenticated and authorised but before the object is persisted. D3FEND also notes the limit: scanning does not stop a build from including insecure or unprotected files. The Container Security Guide covers the wider pipeline.

As a reference point for scan cadence, CISA Binding Operational Directive 23-01 requires US federal civilian agencies to perform automated asset discovery every 7 days, covering at least their entire IPv4 space, and to initiate vulnerability enumeration across all discovered assets every 14 days. Elsewhere these are benchmarks, not obligations. The Asset Inventory and CMDB Security Guide covers the inventory platform itself.

Network Mapping family

Network Mapping (D3-NM) models three layers: physical connectivity, logical node-to-node connections, and the policy that says which pathways are allowed. The distinction between observed links and allowed pathways is the most useful idea in the family, because the gap between them is where unexpected exposure lives.

Logical Link Mapping (D3-LLM) is the parent of the active and passive logical techniques; Physical Link Mapping (D3-PLM) is the parent of the active and direct physical techniques. Network Traffic Policy Mapping feeds directly into the Firewall Rule Review Checklist and into Isolate techniques, which need an approved pathway list before they can enforce one.

System Mapping family

System Mapping (D3-SYSM) moves up from network links to systems: how they decompose into subsystems and components, how they depend on each other and where they physically sit.

• Data Exchange Mapping (D3-DEM): the intended design of application-layer data flows, with synonyms Data Flow Mapping and Information Exchange Mapping. It records intent, which is why it pairs with the observed flows from network mapping.
• Service Dependency Mapping (D3-SVCDM): the services each service relies on. D3FEND lists Distributed Tracing as a synonym and notes that dependencies in cloud and microservice architectures may be discovered that way, and that dependencies of critical systems should be prioritised for supply chain risk analysis. See Service Dependency Mapping for Security.
• System Dependency Mapping (D3-SYSDM): how components depend on each other to carry out a function. D3FEND's considerations say data exchanges found in network mapping usually indicate such dependencies but may not be part of the intended design, and that architecture artefacts and subject matter experts may be needed to decide whether a dependency is intended or essential.
• System Vulnerability Assessment (D3-SYSVA): relates the vulnerabilities of a system's components in the context of configuration and internal dependencies, including risk from the system's design as a whole, not just the sum of component findings.

Operational Activity Mapping family

Operational Activity Mapping (D3-OAM), with the synonym Mission Mapping, connects the technical model to what the organisation does. It identifies activities, the sub-organisations, roles and individuals that carry them out, and their dependence on systems and people.

• Organization Mapping (D3-OM): people, roles and groups and their relations.
• Access Modeling (D3-AM): the access permissions granted to identities, which D3FEND lists as administrators, users, groups and systems, optionally including how those identities are stored, managed and shared across systems. Its only reference is RFC 7642, the SCIM definitions and requirements document.
• Operational Dependency Mapping (D3-ODM): how activities depend on each other and on people, systems and services, including a hierarchy of higher- and lower-level activities. The Business Impact Analysis Template captures much of the same information from a continuity angle.
• Operational Risk Assessment (D3-ORA): the vulnerabilities of and risks to activities individually and as a whole. D3FEND's references for it are NIST SP 800-37 Rev. 2, SP 800-53A Rev. 5, SP 800-160 Vol. 1 and NISTIR 8011 Vol. 1; the NIST SP 800-30 Risk Assessment Guide covers the method.

Where identity fits

Access Modeling is the one Model technique that is about identities rather than assets, and D3FEND explicitly includes systems among the identities it covers. Service accounts, workload identities, API keys and OAuth grants therefore belong in the access model alongside human accounts. Two other points connect the tactic to non-human identity work. First, inventory and scanning tools run with privileged credentials across the estate, so their accounts need the same ownership and rotation discipline as any other high-value machine credential. Second, an NHI inventory is an asset inventory with an access dimension: the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide and NHI Inventory Reconciliation apply the Model approach to machine identities, and the Identity Attack Paths Guide shows what an access model makes visible.

ATT&CK techniques D3FEND relates to Model

D3FEND does not design Model techniques to counter specific ATT&CK techniques. Its site infers relations when a defensive technique and an offensive technique touch the same digital artefact, and labels the result "inferred, experimental". The Model tactic page lists no ATT&CK relations of its own. The table shows representative inferred relations from the technique pages checked in November 2026; the mapping-only techniques such as System Dependency Mapping show none.

Read these as "this inventory would show the artefact the attacker changes", not "this technique stops the attack". Model also counters adversary reconnaissance indirectly: you should know your own network better than the attacker learns it through the techniques in the ATT&CK Discovery Tactic (TA0007) Guide and ATT&CK Reconnaissance Tactic (TA0043) Guide.

Where to start: an order of work

D3FEND sets no sequence; this is NHI Mgmt Group's suggested order based on the dependencies between families.

1. Network Node Inventory and Software Inventory first. Combine at least two sources, for example agent data and passive observation, so each exposes the other's gaps. Record owner, last-seen date and environment for every node.
2. Configuration Inventory and Asset Vulnerability Enumeration next. Once nodes are known, collect configuration and match vulnerabilities. Pilot scanning in one segment, exclude fragile OT assets until a passive method exists, and roll back by pausing the scan profile.
3. Access Modeling for privileged and machine identities. Record who and what holds administrative rights, starting with domain, cloud tenant and CI/CD scopes.
4. Network Traffic Policy Mapping and logical link mapping. Export the allowed pathways from firewall and gateway policy, then compare them with observed flows. Every observed flow without a policy, and every policy without a flow, is a finding.
5. Service and System Dependency Mapping for critical services. Begin with the services that support the top business activities, using tracing data where it exists and architects where it does not.
6. Operational Activity, Organization and Operational Dependency Mapping. Link systems to activities and owners so that criticality can be assigned.
7. Network, System and Operational Risk Assessment last. These assessments need the rest of the model to be credible; run them on a fixed cycle and after major change.

Small vs large organisations: a small organisation can cover steps 1 to 4 with endpoint management, a vulnerability scanner and firewall exports, and map dependencies for a few critical services in a spreadsheet. A large organisation needs reconciliation across many sources through cyber asset attack surface management tooling and a governed CMDB; see the Attack Surface Management Guide for the external view.

Measuring the model

Example measures; the targets are examples to set for your own environment:

Framework mapping

The mapping above is NHI Mgmt Group's alignment by subject; D3FEND itself publishes no mapping from Model techniques to these frameworks.

Common failure patterns

• One source of truth that is not true. A CMDB populated by hand drifts within months. Reconcile it against discovery data and treat disagreement as a finding.
• Scanning that breaks things. D3FEND warns that probing can cause side effects in IT and OT systems.
• Observed flows mistaken for design. D3FEND notes that data exchanges seen in network mapping may not be intended. Copying them into firewall policy legitimises whatever is already there.
• Access model limited to people. Leaving service accounts, keys and tokens out of Access Modeling hides the identities attackers most often reuse.
• Inventory tooling as an unmanaged privileged identity. Scanner and discovery credentials often hold administrative rights everywhere and are rarely rotated or monitored.
• Risk assessment without the model. Running an operational risk assessment before dependencies are known produces scores that do not reflect which outage would actually stop the business.

How Model feeds the other tactics

Each later tactic consumes a specific part of the model. The D3FEND Harden Tactic needs configuration and software inventory to set baselines; Detect needs asset criticality and normal flows to tune analytics; Isolate needs the allowed-pathway map from Network Traffic Policy Mapping; Deceive needs to know what real assets look like to build convincing decoys; Evict needs the access model to find every credential to revoke; and Restore needs service and system dependency maps to recover in the right order. For access decisions built on the model, see the MITRE D3FEND Access Policy Administration Implementation Guide.

Practitioner checklist

• Inventory network nodes and software from at least two independent sources and reconcile them weekly.
• Record an owner, environment, criticality and last-seen date on every asset record.
• Store configuration baselines in a repository that hardening and detection tools can query.
• Scan container images in the build pipeline and enforce policy at admission before deployment.
• Include service accounts, workload identities, API keys and OAuth grants in the access model.
• Manage inventory and scanner credentials as privileged machine identities with owners and rotation.
• Export allowed pathways from firewall and gateway policy and compare them with observed flows.
• Map service and system dependencies for every tier 1 service and review them after major change.
• Link systems to business activities and owners before running operational risk assessments.

Standards and references

• MITRE D3FEND: Model tactic
• MITRE D3FEND: Access Modeling (D3-AM)
• MITRE D3FEND: Container Image Analysis (D3-CIA)
• CISA: Binding Operational Directive 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• CIS: CIS Controls v8.1 list
• Kubernetes: Admission Control

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Asset Inventory and CMDB Security Guide · Service Dependency Mapping for Security · NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments · D3FEND Harden Tactic