Defenders cannot segment, monitor or contain what they have not mapped, and most network diagrams are out of date the week after they are drawn. MITRE D3FEND names one answer Active Logical Link Mapping (D3-ALLM) and defines it as a technique that "sends and receives network traffic as a means to map the whole data link layer, where the links represent logical data flows rather than physical connection". It sits under the Model tactic as a child of Logical Link Mapping (D3-LLM), next to its listening counterpart, Passive Logical Link Mapping (D3-PLLM). This page explains what D3-ALLM produces, which protocols and data sources feed it, how to run it safely (including in OT networks), how to keep the map current, and how the result feeds detection and hardening. It is written for network engineers, security architects and detection teams who already know the family overview in the MITRE D3FEND Network Mapping Implementation Guide.
Key takeaways
- It is a modelling technique, not a control. D3-ALLM blocks nothing. Its value is an accurate, current record of which nodes talk to which, that other countermeasures such as segmentation and traffic analysis depend on.
- Active means asking the network. D3FEND describes link layer discovery protocols such as LLDP, aggregated through SNMP, plus path tracing with traceroute. The mapper queries devices or sends probes rather than only listening.
- The mapper is a privileged identity. It holds SNMP credentials for every switch and router. D3FEND's own considerations ask for encrypted monitoring data and authenticated queries, which in practice means SNMPv3 with authentication and privacy.
- OT needs a different approach. D3FEND warns that active scanning in OT networks needs special consideration and OT-safe options; passive mapping (D3-PLLM) is often the safer first step there.
- D3FEND gives it only inferred ATT&CK relations. They come from generic artefacts such as Network Node, so treat them as context rather than a coverage claim.
D3-ALLM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ALLM (d3f:ActiveLogicalLinkMapping) |
| Tactic | Model |
| Parent technique | Logical Link Mapping (D3-LLM), under Network Mapping (D3-NM) |
| Sibling | Passive Logical Link Mapping (D3-PLLM) |
| Ontology relations | Inherits "maps" Logical Link, Network and Network Node from D3-LLM; adds "may-query" Network Agent |
| D3FEND references | SolarWinds patent US10079749B2 (identification of traceroute nodes); Device42 user manual, SNMP network auto-discovery |
| Typical inputs | LLDP and CDP neighbour tables, ARP and MAC forwarding tables, routing protocol neighbours, VLAN and subnet data, traceroute paths |
| Output | A node and link graph of logical connections, ideally stored in a source of truth with timestamps |
| Effort | Low to start with existing network monitoring tooling; medium to keep complete and current across sites and clouds |
How it works
D3FEND's knowledge base article describes three mechanics. In practice an implementation combines them.
- Neighbour discovery read over SNMP: devices run a link layer discovery protocol (LLDP, defined in IEEE 802.1AB, currently the 2026 edition, or a vendor protocol such as CDP) and keep a table of directly connected neighbours. A collector polls those tables, plus ARP tables (IP to MAC), MAC forwarding tables (MAC to switch port), VLANs and subnets, over SNMP on UDP port 161. The Device42 manual cited by D3FEND lists exactly these data types and notes that LLDP and CDP neighbours are only found when the same SNMP credentials work on the neighbours.
- Routing adjacency discovery: collectors also read routing protocol neighbours. LibreNMS, an open source monitoring tool, for example, discovers new devices from xDP (CDP, LLDP, FDP) neighbours, OSPF, OSPFv3 and BGP peers by default, with ARP discovery off by default, and reruns discovery every 6 hours by default.
- Path tracing: traceroute style probes reveal the hop by hop path between two points, which shows routed paths that neighbour tables alone do not. The SolarWinds patent D3FEND cites uses multi-path tracerouting probes to estimate the complete topology and to tie each hop to a device.
D3FEND notes that data can be polled by network management software or pushed by sensors after one-time configuration, and that push reduces bandwidth when reliable transport is used. The output is a graph of logical links. "Logical" matters: a VLAN that spans three switches, a routing adjacency over a tunnel and a path through a firewall are all logical links, whatever cabling sits beneath them. The cable view is Active Physical Link Mapping (D3-APLM), covered in the D3-APLM Active Physical Link Mapping page.
Active versus passive
| Question | Active (D3-ALLM) | Passive (D3-PLLM) |
|---|---|---|
| How data is gathered | Queries devices and sends probes | Only listens to traffic, for example from a SPAN port or tap |
| Sees idle links | Yes, if a device reports them | No, only links that carry traffic while you listen |
| Needs device credentials | Yes (SNMP or API) | No, but needs sensor placement |
| Risk to fragile devices | Higher, especially in OT | Low |
| Fits when | Managed enterprise networks with a monitoring platform | OT, unmanaged segments, or where you cannot hold credentials |
Most mature programmes run both and reconcile them: a link seen in traffic that no device reports is either unmanaged equipment or a gap in the active map. See D3-PLLM Passive Logical Link Mapping.
Deploying it safely
- Define scope and the source of truth. List the subnets, sites and cloud networks in scope, and decide where the map lives (a network source of truth, a CMDB or the monitoring platform). Record each link with first seen, last seen and the method that found it.
- Create a dedicated, read-only collector identity. Use SNMPv3 with authentication and privacy. RFC 3414 (Internet Standard STD 62) defines the User-based Security Model, which provides authentication, integrity, privacy and replay protection. Restrict the SNMP view to the MIBs the collector needs and accept queries only from the collector's addresses. Avoid SNMPv1 and v2c community strings; RFC 2922 already noted in 2000 that SNMPv1 alone is not considered secure for topology data.
- Enable neighbour discovery where it adds value. Run LLDP on internal infrastructure links. Decide per port type whether it should run on user and internet-facing ports, since LLDP advertisements disclose device names, models and management addresses to anything connected.
- Pilot on one site. Run discovery, compare the result with known diagrams and interview the network team about differences. Tune exclusions (for example, LibreNMS supports excluding neighbours by sysName or sysDescr pattern) rather than accepting noise.
- Handle OT separately. Follow D3FEND's caution: agree an OT-safe method with the asset owner, prefer reading switch tables over probing controllers, schedule any active probing in maintenance windows, and start with passive mapping.
- Schedule and diff. Rerun discovery on a fixed cycle and diff each run against the previous one. New links, vanished links and new neighbours become change records or alerts.
- Roll back cleanly. If a device misbehaves under polling, remove it from the collector scope, record the exception, and map it by passive or manual methods instead. Retired collectors must have their SNMPv3 users removed from every device.
Where identity fits
The collector account is a non-human identity with read access to the whole network's topology, and often to device configuration. Treat it like any other privileged service account: one identity per collector, credentials in a secrets manager, rotation on a schedule, and logging of where it authenticates from. An attacker holding those credentials gets the same map you do, which is exactly what Gather Victim Network Information (T1590) and Remote System Discovery (T1018) describe. The SNMP Security Guide covers SNMP hardening in depth.
How it feeds other D3FEND techniques
| Consumer | What it takes from the logical link map |
|---|---|
| Network Traffic Policy Mapping (D3-NTPM) | The observed paths to compare against the allowed paths in firewall and ACL policy |
| Network Node Inventory (D3-NNI) | Neighbours and ARP entries that reveal nodes not yet in the inventory |
| Network Vulnerability Assessment (D3-NVA) | Reachability between vulnerable nodes and critical assets |
| Network traffic analysis techniques, for example D3-NTCD Network Traffic Community Deviation | A baseline of expected node to node communication against which deviations stand out |
| Network isolation, for example D3-NTF Network Traffic Filtering | Knowledge of which flows a new filter would break before it is applied |
See also D3-NTPM Network Traffic Policy Mapping and D3-NNI Network Node Inventory.
ATT&CK techniques D3FEND relates to D3-ALLM
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-ALLM. Its site shows a short list of "inferred and experimental" relations that arise because D3-ALLM maps Network Node, Network and Logical Link and may query Network Agent (D3FEND 1.6.0, checked November 2026). The artefacts are broad, so the list reads as context rather than a coverage claim:
- Server Software Component: Web Shell (T1505.003) and Transport Agent (T1505.002)
- Remote Email Collection (T1114.002)
- Modify Cloud Compute Infrastructure: Create Cloud Instance (T1578.002), Delete Cloud Instance (T1578.003), Revert Cloud Instance (T1578.004)
- Network Device Firewall (T1686.002). D3FEND still lists this under an ID that ATT&CK has revoked; T1686.002 is its ATT&CK v20 successor.
Our view, not D3FEND's: the most practical security use of a current logical map is noticing change, such as a new cloud instance or a new path through a firewall, which is where the cloud instance and firewall rows make sense.
Measuring it
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) |
|---|---|
| Managed network devices successfully polled in the last cycle | Above 95% |
| Links seen passively but absent from the active map | Falling each quarter, each one explained |
| Age of the oldest unrefreshed site map | Under 7 days |
| Collectors still using SNMPv1 or v2c | Zero |
| Unexplained new links per discovery cycle | Tracked and each one triaged |
Limits and failure patterns
- Credential gaps hide whole segments: neighbour discovery stops at the first device the collector cannot authenticate to, so the map looks complete while missing a site.
- Unmanaged devices are invisible: unmanaged switches, consumer access points and devices with LLDP disabled report nothing. Reconcile with passive mapping and with ARP and DHCP data.
- Cloud and overlay networks need different sources: virtual networks, peering, transit gateways and service meshes do not answer LLDP. Use the provider's network APIs and flow logs for those parts of the map.
- Traceroute shows one path at a time: load balancing and filtering of ICMP or UDP probes produce partial or misleading paths.
- The collector becomes a target: a collector with write community strings or shared credentials is a path to reconfigure the network. Read-only, SNMPv3, scoped views.
- Snapshots without history: a map without first seen and last seen timestamps cannot answer "when did this path appear?" during an investigation.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03 | Representations of authorised network communication and internal and external data flows are maintained |
| NIST CSF 2.0 | DE.CM-01 | Networks and network services are monitored; the map is the baseline |
| NIST SP 800-53 Rev 5 | CM-8, CM-8(3) | System component inventory and automated detection of unauthorised components |
| NIST SP 800-53 Rev 5 | PL-8, SC-7 | Security architecture and boundary protection, which rely on knowing the paths |
| CIS Controls v8.1 | Safeguard 12.4 | Establish and maintain architecture diagrams |
| MITRE D3FEND | D3-NM, D3-LLM, D3-ALLM | Family, parent and technique |
Practitioner checklist
- Choose one source of truth for links, with first seen, last seen and discovery method per link.
- Use a dedicated SNMPv3 collector identity with authentication, privacy and a restricted view.
- Store collector credentials in a secrets manager and rotate them; remove them from devices when a collector is retired.
- Run LLDP on infrastructure links and decide deliberately about edge ports.
- Agree OT-safe methods with asset owners before any active discovery in OT.
- Diff each discovery run and route unexplained new links to triage.
- Reconcile the active map with passive observations and with cloud network APIs.
- Feed the map to traffic policy mapping, segmentation planning and detection baselines.
Standards and references
- MITRE D3FEND: Active Logical Link Mapping (D3-ALLM)
- IEEE: 802.1AB Station and Media Access Control Connectivity Discovery
- IETF: RFC 3414 User-based Security Model (USM) for SNMPv3
- IETF: RFC 2922 Physical Topology MIB
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- Device42: SNMP Network Auto-Discovery
- LibreNMS: Auto-Discovery
- Google Patents: US10079749B2 Identification of traceroute nodes and associated devices
Related NHI Mgmt Group resources: MITRE D3FEND Network Mapping Implementation Guide · D3-LLM Logical Link Mapping · D3FEND Model Tactic · SNMP Security Guide · MITRE D3FEND Guide