A network diagram shows what was designed; a logical link map shows which nodes have actually exchanged traffic, and the difference is where unexpected access paths, forgotten integrations and lateral movement hide. MITRE D3FEND names this Logical Link Mapping (D3-LLM) and defines it as creating "a model of existing or previous node-to-node connections using network-layer data or metadata." It is a Model tactic technique under Network Mapping, with two children: Active Logical Link Mapping (D3-ALLM) and Passive Logical Link Mapping (D3-PLLM). This page explains which data sources produce logical links, how to build and maintain the map, how it feeds segmentation and detection, and its limits. It is written for network security, detection engineering and architecture teams, and goes deeper on one child of the MITRE D3FEND Network Mapping Implementation Guide.
Key takeaways
- Observed, not designed. D3FEND defines the model from network-layer data or metadata about existing or previous connections, so it records what happened rather than what was intended.
- History is part of the definition. "Previous" connections matter: a link seen once last month can be a forgotten integration or an intrusion, and a map that keeps only current links loses both.
- Two ways to collect. D3-PLLM only listens (flow records, connection logs); D3-ALLM sends and receives traffic, for example by querying device neighbour tables or tracing paths.
- The map is the baseline for detection. New node pairs, new protocols and links that cross segment boundaries are the signals; see D3-NTCD Network Traffic Community Deviation.
- D3FEND's ATT&CK links are inferred and indirect. They arrive through the Network Node artefact the technique maps and are labelled inferred and experimental.
D3-LLM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-LLM (d3f:LogicalLinkMapping) |
| Tactic | Model |
| Parent technique | Network Mapping (D3-NM) |
| Child techniques | Active Logical Link Mapping (D3-ALLM); Passive Logical Link Mapping (D3-PLLM) |
| Sibling techniques | Network Traffic Policy Mapping, Network Vulnerability Assessment, Physical Link Mapping |
| Digital artefacts | D3FEND relation: maps Logical Link, maps Network, maps Network Node |
| D3FEND reference | LibreNMS documentation, Network Map extension |
| Typical data sources | Flow records (IPFIX, NetFlow), ARP and IPv6 neighbour tables, firewall and proxy logs, cloud network flow logs, LLDP and CDP neighbour data, traceroute |
D3FEND defines a Logical Link as "an abstract or virtual connection between two entities that facilitates communication or data exchange without requiring a direct physical connection." That is the contrast with D3-PLM Physical Link Mapping, which models cables and ports.
Data sources for logical links
| Source | Child | What a link record contains | Limits |
|---|---|---|---|
| Flow export: IPFIX (RFC 7011) or NetFlow v9 from routers, switches and firewalls | Passive | Source and destination address and port, protocol, bytes, packets, time window | Sampling hides low-volume links; exporters must cover the paths that matter |
| Firewall, proxy and load balancer logs | Passive | Allowed and denied connections with policy and user context | Only traffic that crosses those devices |
| Cloud network flow logs | Passive | Accepted and rejected flows per interface or subnet | Must be enabled per network; cost and retention limits |
| ARP and IPv6 neighbour tables (IP-MIB ipNetToPhysicalTable, RFC 4293) | Active query of devices | Which IP and MAC pairs are adjacent at the network layer | Adjacency only, not end-to-end conversations |
| LLDP and CDP neighbour data | Active query of devices | Which devices are neighbours on a link | Infrastructure only; often configured off on edge ports |
| Traceroute and path probes | Active | Layer 3 hops between two points | Point in time; filtered by firewalls |
| Host connection tables from agents (EDR or monitoring) | Passive on host | Process to remote address and port, with the account that made it | Only hosts with agents |
D3FEND's own reference shows one practical combination: the LibreNMS network map builds links from xDP neighbour data (FDP, CDP or LLDP) and from ARP entries that match an interface's IP and MAC address, controlled by the network_map_items setting. The LibreNMS documentation also warns that the global map becomes slow on large networks and suggests per-device or per-group maps. That scaling problem is general: logical link maps need aggregation and filtering to stay usable.
How to implement
- Define the node set. Links are between nodes, so start from the node inventory in D3-NNI Network Node Inventory and label each node with role, segment and owner.
- Collect passive data at boundaries first. Enable flow export or flow logs where traffic crosses segments: internet edge, data centre core, cloud network boundaries, and between user, server, management and OT zones.
- Aggregate into edges. Reduce raw flows to node pair, destination port and protocol, with first seen, last seen and volume. Keep the aggregated edges for at least as long as your investigation window; 13 months is an example that covers annual jobs.
- Enrich. Join node roles and owners, and on hosts with agents the process and account behind the connection.
- Add active collection where passive is blind. Query neighbour tables and run path probes for segments without flow export, following the D3-ALLM Active Logical Link Mapping page; test probes in a pilot range and keep them away from fragile OT devices.
- Review and baseline. Have owners confirm expected edges for critical systems; anything unconfirmed becomes a finding. Store the confirmed set as the baseline.
- Roll back safely. Passive collection changes nothing on the network; if flow export loads a device, lower the sampling rate or move collection to a tap.
How the map feeds other techniques
| Use | What D3-LLM supplies |
|---|---|
| Segmentation design and review | The real flows a segmentation policy must allow, and the ones it should stop; see M1030 Network Segmentation |
| Policy validation | Observed links compared with the allowed paths modelled by Network Traffic Policy Mapping |
| Anomaly detection | A baseline of node communities for D3-NTCD and new-edge alerts |
| Incident scoping | Which nodes a compromised host talked to, and when, including links that are no longer active |
| Dependency mapping | Evidence for service and system dependency maps; see the Service Dependency Mapping Security Guide |
Decision guidance
- Passive first. It is safe, continuous and records history. Add active methods only where there is no vantage point.
- Boundary versus full coverage: small organisations get most of the value from firewall logs and cloud flow logs at boundaries; large estates add flow export inside data centres to see east-west links.
- Sampling: sampled flows are fine for capacity views but miss rare links, which are the security-relevant ones; use unsampled export or firewall logs on critical segments.
- Host versus network data: host agent data adds process and account but covers only managed hosts; network data covers everything that crosses a sensor. Use both for crown-jewel systems.
ATT&CK techniques D3FEND relates to D3-LLM
Relationship type: inferred only. D3FEND hand-maps no ATT&CK technique to D3-LLM. The D3FEND page lists the relations below, derived through the Network Node artefact the technique maps, and labels them inferred and experimental (checked November 2026). Each ID was checked against ATT&CK v20. D3FEND still shows one relation under a revoked ID (Disable or Modify Network Device Firewall); the table gives its v20 successor.
| ATT&CK v20 ID | Technique | What a logical link map contributes |
|---|---|---|
| T1578.002, T1578.003, T1578.004 | Create, Delete and Revert Cloud Instance | New instances show up as new nodes with new edges |
| T1505.003 | Web Shell | Unexpected inbound or outbound links from web servers |
| T1505.002 | Transport Agent | Mail servers with links to unexpected destinations |
| T1114.002 | Remote Email Collection | New links from internal or external hosts to mail services |
| T1686.002 | Network Device Firewall (successor to the revoked ID D3FEND shows) | Links that appear across a boundary after a firewall change |
Lateral movement and command and control are where a logical link map is most useful in practice, but D3FEND does not relate them to D3-LLM, so they are not listed above. The attacker's own view is covered in T1016 System Network Configuration Discovery.
Where identity fits
Many logical links are made by non-human identities: a service account polling a database, an integration calling an API, a workload using a cloud role. Enriching edges with the account or workload identity behind them, from host agents, proxy logs or cloud flow and audit logs, turns "host A talks to host B" into "this service account talks to that database", which is what an owner can confirm and what an access review can act on. Flow collectors and log pipelines are also privileged: restrict who can change exporters and read raw flow data.
Detection and measurement
- Vantage coverage: share of segment boundaries and critical subnets with passive link collection.
- Baseline confirmation: share of edges to critical systems confirmed by an owner.
- New-edge rate: new node pairs per day into server, management and OT segments, and the share explained by a change record.
- Policy gap: observed edges that the intended policy does not allow, and allowed paths never used (candidates for removal).
- History depth: how far back aggregated edges can be queried during an investigation.
Framework mapping
| Framework | Reference | Link to D3-LLM |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03 Representations of the organization's authorized network communication and internal and external network data flows are maintained | Direct; the logical link map is the observed side of this representation |
| NIST SP 800-53 Rev. 5 | CA-9 Internal System Connections; SC-7 Boundary Protection; PL-8 Security and Privacy Architectures | Evidence of actual connections for authorisation, boundary review and architecture |
| CIS Controls v8.1 | Control 12 Network Infrastructure Management; Control 13 Network Monitoring and Defense | Network architecture records and flow monitoring |
Common failure patterns
- Diagram treated as the map. The design diagram is never compared with observed flows, so undocumented links persist.
- Current state only. Edges are overwritten, so during an incident there is no record of which nodes talked weeks ago.
- Edge-only collection. Only internet traffic is logged; east-west links, where lateral movement happens, are invisible.
- Sampled data used for security. One-in-a-thousand sampling misses the rare connection that matters.
- A map nobody can read. A global graph of every node becomes unusable at scale, as the LibreNMS documentation notes; build per-segment and per-service views.
- No owner review. Edges are collected but never confirmed, so nothing distinguishes expected from unexpected.
Practitioner checklist
- Base link endpoints on the node inventory with roles and owners.
- Enable flow export or flow logs at every segment boundary and cloud network.
- Aggregate flows into edges with first seen, last seen, port and volume, and keep the history.
- Use unsampled data on critical segments.
- Enrich edges with the account or workload identity where available.
- Add active neighbour queries and path probes only where passive data is missing, tested first.
- Get owners to confirm edges for critical systems and store that as the baseline.
- Alert on new edges into sensitive segments and compare observed links with policy.
Standards and references
- MITRE D3FEND: Logical Link Mapping
- LibreNMS: Network Map extension
- IETF: RFC 7011 IP Flow Information Export (IPFIX) Protocol
- IETF: RFC 4293 Management Information Base for the Internet Protocol
- IEEE: 802.1AB Station and Media Access Control Connectivity Discovery
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE D3FEND Network Mapping Implementation Guide · D3-PLLM Passive Logical Link Mapping · D3-ALLM Active Logical Link Mapping · CIS Control 13 Network Monitoring and Defense Guide