Enforcement points can only be as good as the permissions they enforce, and in most estates those permissions grew by accident. MITRE D3FEND captures the work of defining and maintaining them as Access Policy Administration (D3-APA), a base technique in the Isolate tactic with the synonym Access Control Administration and four leaf techniques: User Group Permissions, User Account Permissions, Local File Permissions and Domain Trust Policy. D3FEND links D3-APA to a long list of ATT&CK behaviours, from Valid Accounts and Create Account to Account Manipulation and Abuse Elevation Control Mechanism. This guide turns D3-APA into an implementation programme: what each leaf covers, how to deploy it in directories, cloud platforms and hosts, which change events prove it is under control, and how to measure progress. It is written for identity architects, IAM and IGA teams and detection engineers. For enforcement (firewalls, proxies, kernel policy) see the companion MITRE D3FEND Access Mediation Implementation Guide, and for D3FEND as a whole see the MITRE D3FEND Guide.
Key takeaways
- D3-APA is the policy layer, not the gate. D3FEND defines it as defining, implementing and managing the access control policies that dictate user permissions to resources; Access Mediation then enforces them.
- Four leaves cover the estate. Groups and roles (D3-UGPH), individual accounts (D3-UAP), local files (D3-LFP) and inter-domain trust (D3-DTP) together describe where permissions live.
- The ATT&CK techniques it constrains are mostly identity techniques. D3FEND's (inferred) mappings include T1078 Valid Accounts, T1136 Create Account, T1098 Account Manipulation sub-techniques and T1548 elevation abuse.
- Policy changes are the telemetry. Group membership, role assignment, ACL and trust changes are high-value events that most SOCs under-collect.
- Non-human identities hold most of the permissions. Service accounts, workload roles and automation identities need owners, reviews and expiry just like people.
What D3FEND means by Access Policy Administration
D3FEND describes D3-APA as restricting access by configuring user groups, directories and directory services, user accounts and files. It sits in the Isolate tactic because well-administered policy confines what any one identity can reach. The four children in the D3FEND ontology are:
| Leaf technique | D3FEND definition (summarised) | Where it lives in practice |
|---|---|---|
| User Group Permissions (D3-UGPH) | Access determined by attributes of users and the objects being accessed; D3FEND lists Role Based Access Controls as a synonym | Directory groups, cloud IAM roles, application roles, Kubernetes RBAC |
| User Account Permissions (D3-UAP) | Restricting a user account's access to resources | Direct grants on accounts, service principals and service accounts |
| Local File Permissions (D3-LFP) | Managing operating system configuration that controls which users can access files on a local system | NTFS ACLs, POSIX permissions and ACLs, SUID bits |
| Domain Trust Policy (D3-DTP) | Restricting inter-domain trust by modifying domain configuration | Active Directory domain and forest trusts, cross-tenant access settings |
For the models behind D3-UGPH (role, attribute and relationship based), see the Authorisation Models Guide.
Implementing each leaf
User Group Permissions (D3-UGPH)
- Grant through groups or roles only: make direct grants the exception, so that every permission has a group owner and a business reason.
- Design roles from evidence: mine current usage before defining roles; see the Role Mining and Role Design Guide.
- Separate duties: define toxic combinations (create supplier and approve payment, deploy and approve change) and block them at assignment time.
- Express policy as code where the platform allows: versioned, reviewed policy makes change visible. See the Policy-as-Code for Authorisation Guide.
User Account Permissions (D3-UAP)
- Remove standing direct grants: report accounts with permissions assigned outside groups and move them into roles or remove them.
- Give every non-human account an owner and an expiry: service accounts, service principals and API identities without an owner are the first to drift.
- Use time-bound elevation for admin rights: see the JIT Access Guide.
Local File Permissions (D3-LFP)
- Baseline sensitive paths: credential stores, configuration files with secrets, scheduled task and service binaries, and SUID binaries on Linux.
- Remove broad write access: Everyone, Authenticated Users or world-writable permissions on executables and scripts are a common route to privilege escalation. See the Linux File Permissions, SUID and ACLs Guide.
Domain Trust Policy (D3-DTP)
- Inventory trusts: record direction, transitivity and purpose for every trust. Microsoft documentation notes that forest trusts can be one-way or two-way and are transitive, and that a two-way trust is two one-way trusts in opposite directions.
- Restrict what crosses: prefer one-way trusts and filter what the trusted side can claim. See the Active Directory Trusts and SID Filtering Guide.
- Treat trust creation as a tier 0 change: Microsoft states that creating a forest trust requires Domain Admins in the forest root domain or Enterprise Admins.
ATT&CK behaviours D3-APA constrains
The D3FEND site maps D3-APA to many offensive techniques and labels those mappings inferred and experimental. The selection below uses ATT&CK v20 IDs and shows what good policy administration changes. Use it to plan tests, not as a coverage claim.
| ATT&CK technique | Most relevant leaf | What good administration changes |
|---|---|---|
| T1078.001 to T1078.004 Valid Accounts (default, domain, local, cloud) | D3-UAP, D3-UGPH | A stolen account reaches only what its role needs |
| T1136 Create Account | D3-UGPH | Few identities hold account creation rights, and use is reviewed |
| T1098.003 Additional Cloud Roles | D3-UGPH | Role assignment rights restricted and changes alerted |
| T1098.002 Additional Email Delegate Permissions | D3-UAP | Mailbox delegation reviewed and limited |
| T1548.003 Sudo and Sudo Caching | D3-LFP, D3-UAP | Sudoers rules scoped to named commands |
| T1548.005 Temporary Elevated Cloud Access | D3-UAP | Elevation and impersonation rights granted only to named identities |
| T1087 Account Discovery and T1069 Permission Groups Discovery | D3-DTP, D3-UGPH | Less to enumerate across trust boundaries |
| T1484.002 Trust Modification | D3-DTP | Trust changes restricted to tier 0 and alerted |
Implementation roadmap
- Build the entitlement inventory. Pull groups, roles, direct grants, local admin and sudo rights, and trusts from every directory and cloud platform into one catalogue with owners. See the Entitlement Catalogue Guide.
- Turn on change auditing first. Before changing any permission, make sure group, role, ACL and trust changes are logged and reach the SIEM, so you can see what your own clean-up does.
- Remove the obvious excess. Disable unused accounts, empty unused privileged groups and remove direct grants that duplicate group grants. Announce changes, keep a record of removed rights and restore within an agreed window if a business owner shows need.
- Introduce roles and separation of duties. Pilot with one business unit and one cloud account, then expand.
- Run access reviews. Our recommendation at NHI Mgmt Group is quarterly reviews for privileged and non-human entitlements and at least twice-yearly reviews for the rest. See the Access Reviews Guide.
- Automate joiner, mover and leaver events. Most drift comes from movers keeping old rights and from automation identities nobody retires. See NHI lifecycle automation.
Small and large organisations
- Small organisations: start with one directory and one cloud platform, keep a short list of roles, and use built-in access review features rather than a full IGA programme.
- Large organisations: an IGA platform and a CIEM capability become necessary to catalogue entitlements at scale; see the Cloud PAM and CIEM Guide.
Where identity fits
D3-APA is identity governance under another name, and the hardest part is non-human identities. Service accounts often sit in privileged groups because that was the quickest way to make an integration work, cloud workload roles accumulate permissions as features ship, and automation identities outlive the projects that created them. Give every non-human identity a human owner, a purpose, a review date and an expiry, and include them in every review cycle.
Detection and measurement
Policy administration generates change events, and those are the signal. Collect and alert on:
| Platform | Change events to collect | Why |
|---|---|---|
| Active Directory | 4728, 4732, 4756 (member added to security-enabled global, local, universal group); 5136 (directory object modified); 4706 and 4716 (trust created or modified) | Privileged group changes, ACL and delegation changes, trust changes |
| Windows hosts | 4670 (permissions on an object changed); 4732 for local Administrators | Local file and local admin drift |
| Cloud IAM | Role assignment and policy attachment events in the provider's audit log | T1098.003 style escalation |
| Linux | auditd watches on sudoers files and permission changes on sensitive paths | Sudo and file permission drift |
See the Active Directory Security Monitoring and Event IDs Guide for tuning. Metrics we suggest at NHI Mgmt Group:
- Percentage of entitlements granted through groups or roles rather than directly.
- Percentage of non-human identities with a named owner and an expiry or review date.
- Access review completion rate and percentage of entitlements revoked per review.
- Number of members in tier 0 groups, tracked over time.
- Percentage of trusts documented with direction, purpose and filtering.
- Median time from leaver event to removal of all access.
Framework mapping
| Framework | Reference | Link to D3-APA |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AC-2(1) Automated System Account Management | D3-UAP and lifecycle |
| NIST SP 800-53 Rev. 5 | AC-3(7) Role-based Access Control, AC-3(13) Attribute-based Access Control, AC-5 Separation of Duties | D3-UGPH |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege, AC-6(7) Review of User Privileges | All leaves, reviews |
| NIST SP 800-53 Rev. 5 | CM-5 Access Restrictions for Change, AU-12 Audit Record Generation | Who can change policy, and logging of changes |
| NIST CSF 2.0 | PR.AA-05 | Permissions defined in policy, managed, enforced and reviewed with least privilege and separation of duties |
| MITRE D3FEND | D3-AMED Access Mediation | Enforces the policy D3-APA defines |
Common failure patterns
- Clean-up without logging. Removing rights before auditing changes means outages cannot be traced and attacker changes look like your own.
- Roles defined from org charts. Roles that ignore actual usage either over-grant or are bypassed with direct grants.
- Service accounts in privileged groups. Convenience grants for integrations become the easiest path to domain or tenant control.
- Reviews that only cover people. Non-human identities are left out, so their permissions only ever grow.
- Undocumented trusts. Old two-way trusts from mergers stay in place long after their purpose has gone.
Practitioner checklist
- Catalogue groups, roles, direct grants, local admin, sudo rights and trusts with owners.
- Enable and forward group, role, ACL and trust change events before any clean-up.
- Move direct grants into roles and define separation of duties rules.
- Give every non-human identity an owner, purpose and expiry or review date.
- Run quarterly reviews of privileged and non-human entitlements (our recommendation).
- Restrict trust creation and modification to tier 0 and alert on every change.
- Baseline permissions on sensitive local paths and sudoers files.
- Report the six metrics above to the identity steering group quarterly.
Standards and references
- MITRE D3FEND: Access Policy Administration
- MITRE D3FEND: Domain Trust Policy
- MITRE D3FEND: User Group Permissions
- Microsoft Learn: How trust relationships work for forests
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Valid Accounts
- MITRE ATT&CK: Additional Cloud Roles
Related NHI Mgmt Group resources: MITRE D3FEND Guide · MITRE D3FEND Access Mediation Implementation Guide · Access Reviews Guide · Least Privilege Techniques Guide · Active Directory Trusts and SID Filtering Guide