D3FEND System Mapping (D3-SYSM) Implementation Guide

Teams that can list their assets often still cannot say which systems depend on which, what data flows between them, or which weakness in one component puts a whole service at risk. MITRE D3FEND calls this work System Mapping (D3-SYSM), a technique in the Model tactic that it defines as identifying the organisation's systems, how they are configured and decomposed into subsystems and components, how they depend on one another, and where they are physically located. This guide is for security architects, risk teams and platform engineers who need to turn that definition into a maintained model: the four child techniques, how to build and sequence them, how to keep the model current, and how to tell whether it is any use. For D3FEND as a whole see the MITRE D3FEND Guide.

Key takeaways

System Mapping sits between inventory and risk. Asset inventory says what exists; System Mapping says how it fits together and where a weakness spreads.
It has four child techniques. System Dependency Mapping, Service Dependency Mapping, Data Exchange Mapping and System Vulnerability Assessment.
Intended design and observed reality both matter. D3FEND frames Data Exchange Mapping as the intended design and notes that observed exchanges may not be part of that design; the gap is a finding.
D3FEND infers one ATT&CK relation for the parent. D3FEND still lists it under a revoked sub-technique ID; the ATT&CK v20 technique is T1689 Downgrade Attack, and D3FEND labels the relation inferred and experimental.
A map nobody queries is shelfware. Measure System Mapping by the decisions it informs: incident scoping time, change impact reviews and supply chain risk analysis.

What D3FEND means by System Mapping

D3-SYSM is one of the Model tactic techniques, alongside Asset Inventory, Network Mapping and Operational Activity Mapping. In the ontology it "enables" Model, and its children each declare a "maps" relation to a specific artefact: a System Dependency, a Service Dependency or a Data Dependency, while System Vulnerability Assessment "evaluates" a Digital System and "identifies" a Vulnerability.

The useful distinction is with the neighbours. Asset Inventory records the things. Network Mapping records what can talk to what at the network layer. System Mapping records how systems are composed and what they rely on to function, which is the view an incident responder needs to answer "if this fails or is compromised, what else breaks?". This site's MITRE D3FEND Asset Inventory Implementation Guide and MITRE D3FEND Network Mapping Implementation Guide cover those families.

The child techniques

Every child of D3-SYSM in the D3FEND ontology, with its purpose from the D3FEND definition and the synonyms D3FEND records.

D3FEND technique	Purpose	D3FEND synonyms	Typical sources of truth
System Dependency Mapping (D3-SYSDM)	Identify and model the dependencies of system components on each other to carry out their function	None recorded	Architecture records, CMDB relationships, package manager data, SBOMs
Service Dependency Mapping (D3-SVCDM)	Determine the services on which each given service relies	Distributed Tracing	Distributed traces, service mesh telemetry, API gateway logs
Data Exchange Mapping (D3-DEM)	Model the intended design for flows of data types, formats and volumes between systems at the application layer	Data Flow Mapping, Information Exchange Mapping	Data flow diagrams, interface specifications, integration catalogues
System Vulnerability Assessment (D3-SYSVA)	Relate all vulnerabilities of a system's components in the context of their configuration and dependencies, including risk from the design as a whole	None recorded	Vulnerability scans and SBOM matches joined to the dependency model

The "sources of truth" column is NHI Mgmt Group guidance. D3FEND's own references for these children include the Unified Architecture Framework (UAF) and an application dependency discovery product, which signals that both modelled architecture and discovered dependencies are expected inputs.

How to choose and sequence the children

Recommended order

Service Dependency Mapping for critical services. It is the quickest to automate where services are instrumented, and D3FEND's own considerations say dependencies for critical systems should be prioritised for supply chain risk analysis.
System Dependency Mapping for the same services. Add the hosts, platforms, libraries and products underneath each service. D3FEND notes that external knowledge bases such as package managers are essential, because product configuration can fix internal dependencies.
Data Exchange Mapping where regulated or sensitive data moves. Model the intended flows, then compare them with what traces and network data show. See the Data flow mapping for security and privacy guide.
System Vulnerability Assessment last. It needs the other three: a vulnerability in a library only becomes a system risk once you know which services load it and what data they handle.

Discovered versus designed

Approach	Strength	Weakness	Use it for
Designed model (architecture records, UAF-style views, interface catalogues)	Shows intent, ownership and why a dependency exists	Drifts from reality; depends on people updating it	Data Exchange Mapping, critical system decomposition
Discovered model (traces, flow logs, agent-based discovery, SBOMs)	Reflects what actually runs and connects	Cannot tell intended from accidental; misses uninstrumented paths	Service and System Dependency Mapping
Reconciled model (both, with differences reviewed)	Turns drift into findings	Needs an owner and a review cadence	Mature programmes and critical services

D3FEND's considerations for System and Service Dependency Mapping both say architectural design artefacts and subject matter experts may need to be consulted to decide whether a dependency is intended or essential. That review step is what separates a map from a diagram.

Implementation roadmap

Pick a scope. Start with the services that support your most critical business activities, as identified in a business impact analysis. See the Business Impact Analysis Template.
Instrument for tracing. OpenTelemetry defines span kinds Client, Server, Producer, Consumer and Internal, and relies on context propagation to join spans from different services into one trace. Client and Server spans give synchronous service edges; Producer and Consumer spans give asynchronous edges through queues, which network maps often miss.
Load relationships into one model. Use the CMDB or a graph store that already holds the asset inventory, so each dependency edge points at a recorded asset with an owner. See the Asset Inventory and CMDB Security Guide.
Attach component data. Link SBOMs and package data to each system node. See the SBOM operations guide.
Review with owners. Mark each edge as intended, accidental or unknown. Unknown edges older than a review cycle are findings.
Join vulnerability data. Score findings by the reachability and criticality the model provides, not by CVSS alone. See the Risk-Based Vulnerability Management Guide.
Use it in a test. Run a tabletop on a critical service and time how long the team takes to list affected dependencies with and without the model.

Rollback is simple because System Mapping does not enforce anything: if a discovery agent or tracing configuration causes performance problems, disable that source and keep the designed model until it is fixed.

Small and large organisations

Small organisations: a maintained spreadsheet or CMDB with a dependency column for the ten most important services, plus SBOMs from the build pipeline, covers most of the value.
Large estates: automate discovery through tracing and flow data, reconcile against architecture records quarterly, and feed the model to vulnerability management and incident response tooling.
OT operators: the joint CISA and partner publication Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators sets out a structured approach to an OT asset inventory and taxonomy, which is the base layer System Mapping builds on in industrial estates.

ATT&CK relations D3FEND infers for the parent

The D3FEND page for D3-SYSM lists one offensive relation, Downgrade Attack, inferred from the Data Dependency, Digital System, Service Dependency and System Dependency artefacts, and states that its mappings are inferred, experimental and will improve as the knowledge graph grows. D3FEND shows it under the older Impair Defenses sub-technique ID, which ATT&CK v20 has revoked; the v20 technique is T1689 Downgrade Attack. See the MITRE ATT&CK T1689 Downgrade Attack guide.

The practical link is that a dependency model shows where older protocol versions or legacy components are still in the path, which is what a downgrade relies on. More broadly, System Mapping does not stop any technique; it shortens scoping and makes prioritisation possible. That is NHI Mgmt Group's reading, not a D3FEND mapping.

Where identity fits

Every service dependency is also an authentication relationship: one service calls another using an API key, a token, a certificate or a service account. A dependency map that records the identity used on each edge gives you, for free, a map of which non-human identities would be exposed if a service were compromised and which edges break if a credential is rotated. Record the credential type and owner on each edge where you can. See the MITRE ATT&CK T1078 Valid Accounts Guide for why those identities are targeted.

Detection and measurement

System Mapping produces few alerts of its own, but it does create useful detections: a new service edge that is not in the model, a data exchange to a destination not in the intended design, and a critical service whose dependency data has not been refreshed. Metrics we suggest at NHI Mgmt Group:

Critical service coverage: percentage of critical services with mapped service and system dependencies.
Edge review rate: percentage of discovered dependencies classified as intended or accidental.
Model freshness: median age of dependency data for critical services.
Unmodelled exchanges: count of observed data exchanges not in the intended design, trending down.
Scoping time: time to list affected systems in incidents and tabletop exercises.
Vulnerability context: percentage of high-severity findings scored with dependency and data context.

Framework mapping

Framework	Reference	Link to D3-SYSM
NIST CSF 2.0	ID.AM-03	Representations of authorised network communication and internal and external data flows are maintained (Data Exchange Mapping)
NIST CSF 2.0	ID.AM-02, ID.AM-05	Software, services and systems inventoried and prioritised by criticality
NIST CSF 2.0	ID.RA-01	Vulnerabilities in assets identified, validated and recorded (System Vulnerability Assessment)
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory, PL-8 Security and Privacy Architectures	Component accountability and documented architecture with dependencies
NIST SP 800-53 Rev. 5	RA-3 Risk Assessment, RA-5 Vulnerability Monitoring and Scanning	System-level vulnerability assessment
NIST SP 800-53 Rev. 5	AC-4 Information Flow Enforcement	Enforces the flows that Data Exchange Mapping documents

Common failure patterns

One-off diagrams. A dependency map drawn for an audit and never refreshed is wrong within months.
Synchronous calls only. Maps built from HTTP traffic miss queue and event dependencies; capture Producer and Consumer edges too.
No owner per edge. Without someone to say whether a dependency is intended, accidental edges never get removed.
Vulnerability lists without context. Treating every finding equally ignores the reachability and data context the model provides.
Ignoring third-party services. SaaS and external APIs are dependencies too, and often the ones with the least visibility.

Practitioner checklist

Define the critical services in scope from a business impact analysis.
Instrument critical services for distributed tracing, including asynchronous edges.
Store dependencies in the same model as the asset inventory, with owners.
Document intended data exchanges and compare them with observed flows.
Attach SBOM and package data to each system node.
Record the non-human identity used on each service edge.
Score vulnerabilities with dependency and data context.
Review unknown edges with owners every cycle and test the model in a tabletop.

MITRE D3FEND System Mapping Implementation Guide: Modelling Dependencies, Data Exchanges and System Weaknesses