D3-RAM Routing Access Mediation: Deploy and Verify

Once traffic can be routed between two networks, every host on one side is a potential path to the other, so the points where routing happens are where network-layer access has to be decided. MITRE D3FEND names this countermeasure Routing Access Mediation (D3-RAM) and defines it as "a network security approach that manages and controls access at the network layer using VPNs, tunneling protocols, firewall rules, and traffic inspection to ensure secure and efficient data routing." It sits under the Isolate tactic as a child of Network Access Mediation (D3-NAM), alongside LAN Access Mediation (D3-LAMED), which governs who may join a local network in the first place. This card turns D3FEND's short definition into something a network or security engineer can deploy and test: the four mechanisms it names, where each runs, how to verify the policy is actually enforced, and how attackers get around it. Firewall operations and VPN design have their own guides, linked below, and are not repeated here.

Key takeaways

Four mechanisms, one decision point. D3FEND groups VPNs, tunnelling protocols, firewall rules and traffic inspection under D3-RAM. All of them decide, at the network layer, which traffic may cross from one network to another.
No ATT&CK mapping in D3FEND. D3FEND lists no direct or inferred ATT&CK relationship for D3-RAM (D3FEND 1.6.0, checked November 2026). The techniques shown on this page are an NHI Mgmt Group view, labelled as such.
Default deny at every routed boundary. The IPsec architecture in RFC 4301 recommends a final catch-all policy entry that discards anything not explicitly matched; the same principle applies to firewall and router rule sets.
Network position is not identity. NIST SP 800-207 says zero trust grants no implicit trust based on network location. Routing access mediation limits paths; it does not replace authentication of the user or workload at the resource.
Verify from both sides. A rule set is only as good as a test that tries forbidden paths and confirms they fail and are logged.

D3-RAM at a glance

Attribute	Value
D3FEND ID	D3-RAM (d3f:RoutingAccessMediation)
Tactic	Isolate
Parent technique	Network Access Mediation (D3-NAM), under Access Mediation (D3-AMED)
Digital artefact	Network (D3FEND relation: isolates Network)
Mechanisms named by D3FEND	VPNs, tunnelling protocols, firewall rules, traffic inspection (Cisco Context-Based Access Control given as the example)
D3FEND reference	Fortinet, "What is Network Access Control?"
ATT&CK relationships in D3FEND	None listed
Main limitation	Controls paths, not intent; traffic that is allowed, tunnelled inside an allowed protocol or carried by a trusted party passes

How it works

D3FEND's article describes D3-RAM as managing access at the network layer through four means. In practice each is a policy enforcement point at a routed boundary.

Firewall rules: ordered allow and deny rules on addresses, protocols and ports, applied on firewalls, routers (access control lists) and cloud network controls. NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, covers packet filtering, proxies, network and host-based firewalls and the policy lifecycle.
Traffic inspection: stateful inspection that tracks sessions so return traffic is allowed only for sessions started from the permitted side. D3FEND cites Cisco's Context-Based Access Control (CBAC) as the example; it keeps a session state table and opens temporary entries in the inbound access list for reply packets.
VPNs: authenticated, encrypted paths that admit remote users or sites into a network. With IPsec, the Security Policy Database in RFC 4301 gives each packet one of three outcomes: PROTECT (apply IPsec), BYPASS (pass without IPsec) or DISCARD. RFC 4301 states that AH and ESP offer access control enforced through the distribution of cryptographic keys.
Tunnelling protocols: encapsulation that carries one network's traffic across another, such as IPsec tunnel mode or GRE between sites. Tunnels extend a routed boundary, so the same allow and deny decisions must apply at the tunnel endpoints.

ATT&CK techniques and D3-RAM

Relationship type: none in D3FEND. D3FEND lists no ATT&CK technique for D3-RAM, direct or inferred, because no ATT&CK technique in its model acts on the Network artefact that D3-RAM isolates (checked November 2026). The table below is an NHI Mgmt Group view of the techniques whose paths routing access mediation constrains, not a D3FEND mapping. Each ID was checked against ATT&CK v20.

ATT&CK ID	Technique	How routing access mediation bears on it (NHI Mgmt Group view)
T1133	External Remote Services	VPN and remote access gateways are the entry point; the rules behind them decide what an authenticated session can reach. See the T1133 External Remote Services Defensive Guide.
T1021	Remote Services	Inter-segment rules that block RDP, SMB and SSH between peers limit lateral movement. See T1021 Remote Services.
T1046	Network Service Discovery	Default deny shrinks what a scan from a compromised host can see.
T1572	Protocol Tunneling	The bypass: attackers wrap traffic in an allowed protocol. See the T1572 Protocol Tunnelling Defensive Guide.
T1599	Network Boundary Bridging	The bypass at the device itself: an attacker who controls the router or firewall can change the rules. See MITRE ATT&CK T1599 Network Boundary Bridging.
T1199	Trusted Relationship	Partner and supplier VPNs need rules scoped to the systems they serve, not whole networks.

Where it is implemented

Implementation class	Mechanism	Typical placement
Network firewalls	Stateful rules, often with application inspection	Internet edge, data centre core, between security zones
Routers and layer 3 switches	Access control lists on interfaces, stateful inspection features on some platforms	Branch edges, inter-VLAN routing, WAN links
VPN concentrators and gateways	IPsec or TLS VPN with per-group access policies	Remote access entry, site-to-site links, partner connections
Cloud network controls	Security groups, network ACLs, route tables and managed firewalls	Between virtual networks, subnets and peered accounts. See AWS Network Firewall for one example
Host operating system firewalls and IPsec policy	Local filtering and IPsec rules on servers that route or forward	Hosts acting as gateways; complements network controls. See the Linux Firewall Guide

Choosing a placement

Small organisations: one edge firewall with default deny inbound, a remote access VPN with group-based rules, and a separate segment for servers is usually enough to start.
Large or regulated estates: zone-based designs with firewalls between zones, per-partner VPN policies, and cloud network controls managed as code with review. Where per-user or per-workload access is needed, ZTNA Guide approaches move the decision closer to the resource.

Implementation steps

Map the routed boundaries. List every place traffic crosses between networks: edges, inter-VLAN routers, VPN gateways, cloud peering and transit, site-to-site tunnels. Each is an enforcement point that needs a rule set and an owner.
Write the flow matrix. For each pair of zones, record the required flows (source, destination, protocol, port, business owner). Everything else is denied. The M1030 Network Segmentation and M1037 Filter Network Traffic guides cover segmentation design and filtering in depth.
Scope VPN access by group. Remote users and partners should land in policies that permit only the systems they need, not a full route into the internal network.
Apply the same rules to tunnels. Site-to-site and cloud tunnels terminate inside your network; filter at both ends rather than trusting everything that arrives encrypted.
Stage changes. Add new deny rules in log-only or hit-count mode where the platform supports it, review what would have been blocked, then enforce. Keep the previous rule set exported so a change can be rolled back quickly.
Log denies and allows at boundaries. Send boundary logs to the SIEM: denied attempts show probing and misconfiguration, allowed flows to sensitive zones show what to review.
Review on a schedule. Remove unused rules and expired partner access. The Firewall Rule Review Checklist gives a review routine.

How to verify it works

Negative path testing: from a test host in each zone, attempt connections that the flow matrix forbids (for example, user segment to database ports) and confirm they fail and appear in the deny logs.
VPN scope testing: connect with a test account in each VPN group and confirm it reaches only its permitted systems.
Rule hit analysis: rules with zero hits over a review period are candidates for removal; broad rules with many hits are candidates for narrowing.
Configuration drift: compare running configuration on routers, firewalls and cloud controls with the approved baseline after every change window.

Metric	Example target (NHI Mgmt Group suggestion, not a standard)	Why it matters
Forbidden paths that pass in testing	Zero	Direct measure of enforcement
Rules with a recorded owner and business reason	100%	Unowned rules are rarely removed
Any-to-any or any-port rules at internal boundaries	Falling to zero	Broad rules defeat segmentation
Boundary devices sending logs to the SIEM	100%	Unlogged boundaries hide probing and bypass
Partner VPN policies reviewed in the last 12 months	100%	Third-party paths tend to outlive their purpose

Limits, bypasses and failure patterns

Tunnelling through allowed protocols: outbound HTTPS and DNS are allowed almost everywhere, and attackers use them to carry other traffic. Inspection and egress control at the edge are needed in addition to port rules. See Cloud Egress Filtering.
Flat VPN access: a VPN that routes authenticated users to the whole internal network turns one stolen credential into network-wide reach.
Compromise of the enforcement device: an attacker with administrative access to the router or firewall can rewrite the rules or disable logging. Protect the management plane and alert on configuration changes; see MITRE ATT&CK T1686 Disable or Modify System Firewall.
Inspection blind spots: Cisco's CBAC documentation states that it inspects only TCP and UDP packets, does not inspect IPsec packets when the router is not the IPsec endpoint, and does not inspect packets with the firewall itself as source or destination.
Rule creep: temporary allow rules that are never removed gradually reopen the paths segmentation closed.
Trusting the path, not the caller: a database reachable only from the application subnet is still exposed to anyone who compromises a host in that subnet. Resource-level authentication remains necessary.

Where identity fits

VPN gateways and firewalls authenticate with certificates, pre-shared keys and service accounts, and site-to-site tunnels often run for years on the same pre-shared key. These are non-human credentials with network-wide reach: inventory them, prefer certificates over shared keys where the platform supports it, and rotate on a schedule. The IPsec Security Guide covers authentication choices for IPsec.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	SC-7 Boundary Protection	Monitor and control communications at external and key internal managed interfaces
NIST SP 800-53 Rev 5	AC-4 Information Flow Enforcement	Approved flows between zones
NIST SP 800-53 Rev 5	AC-17 Remote Access	Usage restrictions and authorisation for each type of remote access, including VPN
NIST CSF 2.0	PR.IR-01, DE.CM-01	Networks protected from unauthorised logical access; networks monitored
MITRE ATT&CK mitigations	M1030 Network Segmentation, M1037 Filter Network Traffic, M1035 Limit Access to Resource Over Network	The ATT&CK mitigations that describe the same controls. See M1035 Limit Access to Resource Over Network
MITRE D3FEND	D3-AMED, D3-NAM, D3-RAM	Parent chain and technique. See the MITRE D3FEND Access Mediation Implementation Guide

Practitioner checklist

List every routed boundary and give each rule set an owner.
Maintain a flow matrix and deny everything not in it.
Scope VPN access per user group and per partner.
Filter at both ends of every site-to-site and cloud tunnel.
Stage new deny rules in log-only or hit-count mode and keep a rollback export.
Send boundary allow and deny logs to the SIEM.
Run negative path tests from each zone after every change window.
Remove zero-hit and expired rules on a schedule.
Protect and monitor the management plane of routers and firewalls.
Replace long-lived VPN pre-shared keys with certificates where supported.

D3-RAM Routing Access Mediation: How It Contains Attacks and How to Verify It