MITRE D3FEND Access Mediation Implementation Guide: Deploying and Measuring Access Mediation Controls

Most organisations own a dozen access enforcement points, from firewalls and proxies to kernel policy and USB control, yet cannot say which attacks each one actually stops. MITRE D3FEND groups these controls under Access Mediation (D3-AMED), a base technique in the Isolate tactic with 16 child techniques covering network, web session, file, system call, device port, operational technology and physical access. This guide treats D3-AMED as an implementation programme: what each leaf technique means in practice, what you deploy to deliver it, what telemetry proves it is working, which ATT&CK behaviours it constrains, and how to roll it out and measure it. It is written for security architects, detection engineers and identity teams. For D3FEND itself, its tactics and the CAD tool, see the MITRE D3FEND Guide; for the policy side (who should have which permission) see the companion MITRE D3FEND Access Policy Administration Implementation Guide.

Key takeaways

• Access Mediation is the enforcement half of access control. D3FEND defines it as granting or denying specific requests to use information, services or facilities, with the synonym Access Control, and says decisions should be scoped in time and just in time where possible.
• It has 16 leaf techniques across very different layers. Network, LAN and routing mediation sit beside web session, remote and local file, system call filtering, IO port, OT variable, operating mode, physical access and credential transmission scoping.
• Each leaf maps to an enforcement point you already own or can buy. The work is assigning ownership, closing gaps and proving each point logs its decisions.
• D3FEND's ATT&CK links are inferred. The D3FEND site labels its offensive mappings "inferred, experimental", so use them to prioritise and test, not as proof of coverage.
• Deny decisions are the measurable output. An enforcement point that never logs a denial is either perfectly configured or not enforcing; you need to know which.

What D3FEND means by Access Mediation

D3FEND sources its definition from the CNSSI-4009 glossary. Access mediation is the process of granting or denying requests to obtain and use information and processing services, and to enter physical facilities. D3FEND adds three expectations: least privilege through access granted for scoped durations to prevent privilege creep, just-in-time access where applicable, and denials that can either block initial access or end access already granted, so enforcement is continuous rather than a one-time gate.

In zero trust language this is the policy enforcement point described in NIST SP 800-207: the component that sits in the path of a request and acts on a decision. D3-AMED is distinct from the policy itself, which D3FEND models separately as Access Policy Administration (D3-APA). Keeping the two apart is useful in practice: enforcement points are owned by network, platform and application teams, while policy is owned by identity and data owners. See the NIST SP 800-207 Zero Trust Architecture Guide.

The leaf techniques and what delivers them

The table lists every child technique in the D3FEND ontology under D3-AMED, the control category that typically implements it, and the decision log you need. Product categories are examples, not recommendations.

For deeper treatment of individual layers see the Network Access Control (NAC) Guide, Identity-Aware Proxy Guide, Reference Monitors and Mandatory Access Control Guide and Removable Media and USB Control Guide.

ATT&CK behaviours each leaf constrains

D3FEND links defensive and offensive techniques through the digital artefacts both act on. For Access Mediation the site lists offensive techniques under Discovery, Collection, Credential Access, Lateral Movement, Command and Control, Exfiltration and more, and labels them inferred and experimental. The table below is a practical selection for testing, using ATT&CK v20 IDs; it shows where a leaf narrows the behaviour, not that it prevents it.

See the T1530 Data from Cloud Storage Defensive Guide and the MITRE ATT&CK T1080 Taint Shared Content guide for those techniques in depth.

Implementation roadmap

1. Inventory enforcement points by leaf. For each of the 16 leaves record the systems that enforce it, the owning team, and whether decision logs reach your SIEM. Gaps in the table are your first findings.
2. Prioritise by identity exposure. Start with leaves that guard credentials and remote access: D3-CTS (phishing-resistant authentication), D3-NAM and D3-NRAM for administration paths, and D3-RFAM for shared storage. This ordering is an NHI Mgmt Group recommendation: these leaves guard the credential and remote access routes most intrusions use.
3. Run new rules in audit mode. SELinux permissive, AppArmor complain mode, firewall and proxy log-only rules and device control audit policies all let you see what would be denied. Collect at least two business cycles of data.
4. Enforce in rings. Pilot on a small group, then a business unit, then everything. Keep a documented rollback per ring (switch back to audit, or revert a rule set) and a named owner who can do it out of hours.
5. Add time limits. Apply D3FEND's scoped duration expectation: remote access sessions, privileged routes and share grants should expire. See the JIT Access Guide.
6. Test with ATT&CK. For each leaf, run a safe emulation of the behaviours in the previous table in a test environment and confirm both the deny and the log line.

Choosing where to invest

• Small organisations: focus on four leaves you can buy as managed services: D3-CTS through passkeys, D3-NRAM through an identity-aware proxy or ZTNA, D3-WSAM through conditional access, and D3-IOPR through endpoint device control.
• Large and regulated organisations: add D3-SCF on servers and containers, D3-LAMED with 802.1X, and full D3-RFAM coverage of file shares and cloud storage.
• OT operators: D3-OVAR and D3-OPR matter more than web leaves; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Where identity fits

Every leaf decision is made about a subject, and in most estates the majority of subjects are non-human: service accounts reaching file shares, workloads calling APIs through a mesh, CI runners using VPNs. Enforcement points that only understand user identity leave machine traffic allowed by IP address. Make sure each enforcement point can identify the workload or service account behind a request, and that service identities get the same time limits and denials as people. See the Least Privilege Techniques Guide.

Detection and measurement

Access Mediation produces two kinds of signal: denials that show an attempted action, and allows that should not have happened. Useful detections include repeated denials for one identity across several enforcement points, a non-human identity hitting a deny it has never hit before, SELinux AVC or AppArmor DENIED records from an internet-facing service, and device control blocks on servers.

Metrics we suggest at NHI Mgmt Group:

1. Leaf coverage: percentage of the 16 D3-AMED leaves with a named enforcement point and owner.
2. Log coverage: percentage of enforcement points whose allow and deny decisions reach the SIEM.
3. Enforcement ratio: percentage of policies in enforce rather than audit mode, per leaf.
4. Time-bound access: percentage of remote and privileged access grants with an expiry.
5. Emulation pass rate: percentage of tested ATT&CK behaviours that produced both a deny and an alert.
6. Phishing-resistant share: percentage of sign-ins using origin-bound authenticators (D3-CTS).

Framework mapping

Common failure patterns

• Enforcement without logs. Rules deny traffic but the decisions never reach detection, so attempted misuse is invisible.
• Audit mode as the end state. SELinux permissive or device control in report-only for years gives a false sense of coverage.
• IP-based rules for machine identities. Workloads move and share addresses, so rules allow far more than intended.
• Standing grants. Remote access and share permissions that never expire become the privilege creep D3FEND warns about.
• Treating inferred mappings as coverage. A D3FEND link from a leaf to an ATT&CK technique is a test idea, not evidence.

Practitioner checklist

• Map each of the 16 D3-AMED leaves to a named enforcement point and owner.
• Confirm every enforcement point sends allow and deny decisions to the SIEM.
• Prioritise D3-CTS, D3-NAM, D3-NRAM and D3-RFAM for remote access, credentials and shared storage.
• Pilot new rules in audit mode for two business cycles, then enforce in rings with a rollback plan.
• Put expiry on remote, privileged and share access grants.
• Make enforcement points identify workloads and service accounts, not only users.
• Emulate the mapped ATT&CK behaviours and check for both a deny and an alert.
• Report leaf coverage, log coverage and enforcement ratio quarterly.

Standards and references

• MITRE D3FEND: Access Mediation
• MITRE D3FEND: Credential Transmission Scoping
• MITRE D3FEND: System Call Filtering
• MITRE D3FEND: Web Session Access Mediation
• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Data from Cloud Storage

Related NHI Mgmt Group resources: MITRE D3FEND Guide · MITRE D3FEND Access Policy Administration Implementation Guide · Identity-Aware Proxy Guide · Phishing-Resistant MFA Guide · Network Segmentation Guide