Knowledge is Power

Sitewide Search

Search Bare Metal Cyber

Search courses, individual lessons, wiki entries, books, podcasts, magazine articles, Daily Cyber News, and Darwin.

MITRE D3FEND™ Learning Center

D3-SYSDM — System Dependency Mapping

System dependency mapping identifies and models the dependencies of system components on each other to carry out their function.

1Parent technique
1Related artifact
4Source references

Model · D3FEND ontology 1.6.0 · Active

Open official technique ↗
Official D3FEND definition

Definition

System dependency mapping identifies and models the dependencies of system components on each other to carry out their function.

Official D3FEND knowledge-base content

How it works

The organization collects and models architectural information about the software, hardware, and products and maps the dependencies between systems, including each system's internal components and dependencies.

Considerations

  • Data exchanges identified in the network mapping efforts usually indicate such dependencies, but may not be part of the intended design.
  • Architectural design artifacts and SMEs may need to be consulted to determine if dependencies are intended or otherwise essential.
  • System dependency mapping can identify internal dependencies of standard and pre-built systems that should be incorporated into a complete system dependency model.
  • System dependencies for critical systems--those supporting critical organizational activities--should be prioritized for supply chain risk analysis.
  • System dependencies should identify the integral components of a given named system and their structure to form a system.
  • System dependencies with a given system may be fixed by a particular product's configuration, and leveraging external knowledge bases about dependencies available (e.g., from package managers) is essential.
Bare Metal Cyber interpretation

Implementation perspective

System Dependency Mapping should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes the relevant system, activity, and evidence sources.

Use the technique to improve the shared model of systems, activities, dependencies, threats, or risk before making defensive decisions.

Questions to ask

  • What system, activity, relationship, or risk is being modeled, and where is the scope boundary?
  • Which authoritative data sources populate the model, and how is their quality assessed?
  • How often is the model refreshed after architectural, operational, or threat changes?
  • Which decisions, analyses, or engineering actions are expected to use the model?

Evidence and validation

  • Documented model scope, assumptions, and ownership
  • Source inventories, data-quality checks, and refresh records
  • Version history showing material changes to the model
  • Examples of decisions or analyses that used the model

Common failure patterns

  • The model is treated as a one-time diagram rather than a maintained decision aid.
  • Unverified or stale source data is accepted without recording uncertainty.
  • The model is comprehensive in appearance but disconnected from engineering or operational decisions.

This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.

Ontology hierarchy

Technique hierarchy

Top-level family

Parent techniques

Direct child techniques

None listed at this level.

D3FEND graph relationships

Artifacts and ontology entities

These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.

Explicit technique relationships

mapsSystem Dependency
Source record

Authoritative sources