Defenders cannot judge an alert, a firewall change or a vulnerability without knowing which systems can actually reach which, yet most network diagrams are drawn once and are out of date within months. MITRE D3FEND names this work Network Mapping (D3-NM), a technique in the Model tactic with eight descendant techniques covering physical links, logical links, allowed traffic pathways and network level vulnerability assessment. This guide treats D3-NM as a programme: what each child contributes, which to build first, how to keep the model current, how to verify it and where it goes wrong. It is written for network security architects, detection engineers and vulnerability management leads. For D3FEND itself, see the MITRE D3FEND Guide.
Key takeaways
- Network Mapping is a modelling technique, not a scan. D3FEND defines it as identifying and modelling the physical layer, network layer and data exchange layers of the network, their physical location, and the allowed pathways through it.
- Its eight descendant techniques answer three questions. What is physically connected (physical link mapping), what actually talks to what (logical link mapping), and what is allowed to talk (traffic policy mapping), with network vulnerability assessment built on top.
- Allowed paths matter more than drawn paths. Network Traffic Policy Mapping turns firewall, IPS, proxy and DLP rules into a model of permitted flows, which is what an attacker exploits.
- Passive and active methods complement each other. D3FEND separates active mapping (sending traffic, querying devices) from passive mapping (listening only), and warns that active scanning in OT networks needs OT-safe options.
- The ATT&CK links are inferred. D3FEND labels its offensive mappings for D3-NM "inferred, experimental"; most arrive through the access control configuration artefact, so they are a prompt for testing, not evidence of coverage.
What D3FEND means by Network Mapping
D3-NM sits in the Model tactic, alongside Asset Inventory, Operational Activity Mapping and System Mapping. Model techniques do not block or detect anything themselves: they produce the reference picture that Harden, Detect, Isolate and Evict techniques depend on. A network model tells a detection engineer whether a connection is unusual, tells a firewall owner which rule is unused or too broad, and tells a vulnerability team which exposed weakness is actually reachable.
D3FEND's definition covers three layers: physical (cables, ports, switches and their location), network (logical node to node links) and data exchange (the pathways traffic is allowed to take). The last part is easy to miss. A network map that shows devices and links but not policy cannot answer the question an incident responder asks first: from this compromised host, what else could the attacker reach?
Every child technique
The table lists every descendant of D3-NM in the D3FEND ontology with its purpose and the artefacts D3FEND relates it to. Indented rows are children of the row above.
| Technique | Purpose (from D3FEND) | Artefacts in the ontology |
|---|---|---|
| Logical Link Mapping (D3-LLM) | Model existing or previous node to node connections using network layer data or metadata | Maps Logical Link, Network, Network Node |
| Active Logical Link Mapping (D3-ALLM) | Send and receive traffic to map logical data flows, for example LLDP data aggregated over SNMP, or traceroute | May query Network Agent |
| Passive Logical Link Mapping (D3-PLLM) | Only listen to traffic to map logical data flows | None further listed |
| Physical Link Mapping (D3-PLM) | Model the link connectivity of devices in the physical network (synonym: Layer 1 Mapping) | Maps Network Node, Physical Link |
| Active Physical Link Mapping (D3-APLM) | Send and receive traffic to map the physical layer | May query Network Agent |
| Direct Physical Link Mapping (D3-DPLM) | Record physical links by direct observation (synonym: Manual Physical Link Mapping) | None further listed |
| Network Traffic Policy Mapping (D3-NTPM) | Model the allowed pathways of data at network, transport and application levels (synonyms include Firewall Mapping, IPS Policy Mapping, DLP Policy Mapping, Web Security Gateway Policy Mapping) | Maps Access Control Configuration; queries Network Agent |
| Network Vulnerability Assessment (D3-NVA) | Relate vulnerabilities of network components in the context of configuration and interdependencies, including risk from the network design as a whole | Evaluates Network; identifies Vulnerability |
What delivers each child in practice
D3FEND's own references point at familiar mechanisms: LLDP and SNMP based auto discovery and traceroute for active logical mapping, spanning tree data for active physical mapping, passive network monitoring for passive mapping, and router access list configuration for traffic policy mapping. The table translates that into data sources. Categories are examples, not recommendations.
| Child | Typical data sources | Watch out for |
|---|---|---|
| D3-ALLM | LLDP neighbour tables polled over SNMP, routing tables, traceroute from management hosts | Use SNMPv3 with authentication and privacy; D3FEND advises encrypting monitoring data and authenticating queries |
| D3-PLLM | Flow records (NetFlow, IPFIX), SPAN or TAP fed sensors, cloud flow logs | Only sees links that carry traffic while you listen |
| D3-APLM | LLDP and CDP neighbour data, spanning tree topology, switch MAC address tables | Unmanaged switches and media converters are invisible |
| D3-DPLM | Cable audits, patch panel records, site surveys | D3FEND notes manual mapping is slow for large networks; use it where automated methods cannot reach |
| D3-NTPM | Firewall, router ACL, security group, proxy, IPS and DLP rule exports, normalised into a path model | Rules without object resolution, and cloud and on premises policy modelled separately |
| D3-NVA | Vulnerability scan results joined to the reachability model (attack path or reachability graph analysis) | Treating every finding equally regardless of reachability |
For the underlying telemetry see the NetFlow and IPFIX Flow Telemetry Guide and the SNMP Security Guide; for safe active discovery see the Nmap for Defenders Guide.
Choosing, combining and sequencing
The sequence below is an NHI Mgmt Group recommendation. It builds the model that answers incident questions first and leaves the most expensive work to last.
- Start with policy (D3-NTPM). Export rule sets from perimeter and internal firewalls, cloud security groups and proxies. Even without topology, a normalised rule model shows which zones may reach tier 0 systems and which rules are any to any. Pair it with the Firewall Rule Review Checklist.
- Add passive logical mapping (D3-PLLM). Flow logs show the connections that actually happen. Comparing observed flows with allowed flows is the single most useful output of D3-NM: allowed but never used paths are candidates for removal, used but not allowed paths reveal policy you have not modelled.
- Add active logical and physical mapping (D3-ALLM, D3-APLM). Poll LLDP, CDP, routing and MAC tables from network devices on a schedule to keep topology current. Use read only, SNMPv3 or API credentials scoped to monitoring.
- Fill gaps directly (D3-DPLM). Physically survey sites the automated methods cannot see: unmanaged switches, OT cells, branch closets.
- Build network vulnerability assessment on top (D3-NVA). Join scan results to the reachability model so a critical finding reachable from user networks ranks above the same finding on an isolated segment. See the Vulnerability Scanning Guide.
Testing the model
- Spot check paths: pick ten source and destination pairs, predict reachability from the model, then test with an approved connectivity check. Record the agreement rate.
- Reconcile with inventory: nodes seen on the network but absent from the asset inventory, and inventory items never seen on the network, are both findings. See the Asset Inventory and CMDB Security Guide.
- OT caution: in industrial networks start passive. D3FEND advises special consideration before active scanning and choosing OT-safe options; see the OT Asset Visibility Guide.
- Rollback: mapping is read only, but active polling can load fragile devices. Throttle polling, schedule it outside peak hours, and keep a switch to pause collection per device class.
Small versus large organisations
- Small: firewall and cloud security group exports plus cloud flow logs give a usable D3-NTPM and D3-PLLM model with little tooling. A maintained diagram with change dates covers D3-PLM.
- Large and regulated: automated topology collection, a rule analysis or network security policy management capability, and reachability aware vulnerability prioritisation across on premises and cloud.
- OT operators: passive sensors and direct physical surveys first, mapped to zones and conduits; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
ATT&CK techniques D3FEND relates to Network Mapping
D3FEND relates defensive and offensive techniques through shared digital artefacts. For D3-NM most offensive links arrive through the Access Control Configuration artefact that Network Traffic Policy Mapping maps, which is why several of them are about permissions rather than networks. D3FEND labels them "inferred, experimental". The table lists the entries the page shows with IDs, using ATT&CK v20; one entry D3FEND still shows under a revoked ID is given with its successor.
| ATT&CK v20 technique | How a network model helps |
|---|---|
| T1686.002 Network Device Firewall | A rule model baseline shows unexpected firewall changes (D3FEND lists the revoked predecessor, Disable or Modify Network Device Firewall) |
| T1556.009 Conditional Access Policies | Policy modelling extends to network conditions in access policies |
| T1578.002 Create Cloud Instance, T1578.003 Delete Cloud Instance, T1578.004 Revert Cloud Instance | New or vanished nodes show up as model drift |
| T1505.003 Web Shell, T1505.002 Transport Agent | Unexpected inbound or mail paths to servers |
| T1114.002 Remote Email Collection | Unexpected flows to mail services |
| T1548.001 Setuid and Setgid, T1548.005 Temporary Elevated Cloud Access, T1134.005 SID-History Injection, T1552.006 Group Policy Preferences | Linked through access control configuration rather than topology; treat as weak links for network mapping |
The adversary side of network knowledge is covered in T1018 Remote System Discovery, T1016 System Network Configuration Discovery and MITRE ATT&CK T1046 Network Service Discovery: these are not D3FEND mappings for D3-NM, but defenders should know their network at least as well as an attacker using them would.
Where identity fits
Flow and policy models are usually keyed on addresses, while the subjects behind them are increasingly workloads and service accounts. Where possible, enrich observed flows with the workload or service identity behind each connection, so allowed paths can be reviewed per identity rather than per subnet. The monitoring credentials used for active mapping are themselves non-human identities with wide read access to network devices: scope them to read only, store them in a secrets manager and rotate them. See the Network Segmentation Guide.
Detection and measurement
The model becomes a detection source once it is current: alert on flows between zones that policy does not allow, on new devices appearing on network segments, on firewall rule changes outside change control, and on new paths to tier 0 systems.
Metrics we suggest at NHI Mgmt Group (example targets are illustrations, not standards):
- Policy coverage: share of enforcement devices and cloud accounts whose rules are in the D3-NTPM model.
- Model freshness: median age of topology and rule data (example target under 24 hours for rules).
- Path prediction accuracy: agreement rate between modelled and tested reachability in spot checks.
- Unused allowed paths: count of permitted flows with no observed traffic in 90 days, trended down.
- Unknown nodes: devices seen on the network but absent from inventory.
- Reachable critical findings: share of critical vulnerabilities reachable from user or internet zones.
Framework mapping
| Framework | Reference | Link to D3-NM |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03 | Representations of authorised network communication and internal and external data flows are maintained |
| NIST CSF 2.0 | ID.RA-01, DE.CM-01 | Vulnerabilities identified; networks monitored for adverse events |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory, PL-8 Security and Privacy Architectures | Node inventory and documented architecture |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection, RA-5 Vulnerability Monitoring and Scanning | Boundaries the policy model describes; scanning for D3-NVA |
| MITRE D3FEND | Model tactic | The tactic D3-NM sits in |
Common failure patterns
- Diagrams instead of models. A drawing cannot be queried for reachability or compared with flows.
- Topology without policy. Knowing what is cabled tells you little about what an attacker can reach; D3-NTPM is the high value child.
- Cloud and on premises modelled apart. Hybrid paths through VPNs and interconnects disappear between two tools.
- Over privileged mapping credentials. Write capable SNMP communities or admin API keys used for discovery become an attacker's route into network devices.
- Active scanning in OT without planning. Fragile controllers can fault under discovery traffic.
- Stale models. A model refreshed annually misleads more than it helps during an incident.
Practitioner checklist
- Export and normalise firewall, ACL, security group and proxy rules into one path model.
- Collect flow logs and compare observed with allowed flows.
- Poll topology from network devices with read only, SNMPv3 or API credentials held in a secrets manager.
- Survey sites and OT cells that automated methods cannot see.
- Reconcile network nodes with the asset inventory monthly.
- Rank vulnerabilities by modelled reachability.
- Alert on flows that policy does not allow and on rule changes outside change control.
- Report model freshness, path prediction accuracy and unused allowed paths quarterly.
Standards and references
- MITRE D3FEND: Network Mapping
- MITRE D3FEND: Active Logical Link Mapping
- MITRE D3FEND: Network Traffic Policy Mapping
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Disable or Modify System Firewall
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Network Segmentation Guide · NetFlow and IPFIX Flow Telemetry Guide · Attack Surface Management Guide · MITRE D3FEND Access Mediation Implementation Guide