# Active Directory Security Framework Detailed Control Catalog
## Purpose
This document is an expanded draft of the Active Directory security framework with individual controls listed under each control domain so the framework can be used as the basis for an auditable control register, control testing workbook, or management review package.[1][2][3]
The control statements are designed to be tailored to the organization’s actual implementation status and evidence sources while retaining mapping to recognized standards and vendor guidance.[1][2][4]
## How to use this catalog
Each control should be assigned a unique internal control ID, owner, implementation status, review frequency, and evidence source during the next draft iteration.[3][2]
The standards mapping shown here is intended as a practical starting point rather than a legal or certification opinion, and it should be validated against the organization’s chosen compliance framework.[3][5]
## Standards basis
This draft uses Microsoft Active Directory security guidance and Canadian Centre for Cyber Security practitioner guidance as the operational baseline for technical control design.[1][2]
NIST SP 800-53 Rev. 5 is used as the primary crosswalk for industry-standard control mapping, particularly across the AC, IA, AU, CM, SI, CP, IR, RA, CA, SC, and PE families.[3][5]
CIS Microsoft Windows Server Benchmarks are included as a supporting hardening reference because the Cyber Centre explicitly recommends CIS benchmarks as a useful augmentation and verification mechanism.[2][4]
## Governance and architecture controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| GOV-01 | A documented AD security standard defines security requirements for forests, domains, trusts, domain controllers, privileged administration, service accounts, and recovery. | Primary | Approved standard, policy repository | PL-2, PM-1, CM-1 [3] | Supported by Microsoft and Cyber Centre architecture and governance guidance.[1][2] |
| GOV-02 | Current architecture diagrams identify forests, domains, domain controllers, trusts, admin tiers, critical applications, and legacy dependencies. | Primary | Architecture diagrams, CMDB extracts | CM-8, PL-8, RA-3 [3] | Visibility into AD architecture supports risk-driven protection.[2] |
| GOV-03 | Every trust relationship has a documented business rationale, data flow description, owner, approval record, and periodic review date. | Primary | Trust register, approvals, review minutes | AC-4, CA-7, RA-3 [3] | Trusts should be risk reviewed and minimized where possible.[2][1] |
| GOV-04 | Security exceptions for legacy systems, unsupported protocols, elevated privileges, and trust-related exposure are formally risk accepted. | Secondary | Exception register, signed risk acceptances | RA-3, RA-7, PM-9 [3] | Cyber Centre recommends risk assessment where ideal alignment is not practical.[2] |
| GOV-05 | AD administrative duties are segregated across infrastructure, identity, backup, monitoring, and audit roles where feasible. | Primary | RACI, role matrix, admin role definitions | AC-5, PM-12 [3] | Separation of duties reduces concentration of privilege and supports governance.[2] |
| GOV-06 | Control owners review AD security standards and architecture at least annually and after major platform changes. | Secondary | Annual review attestations, CAB records | CA-7, CM-3 [3] | Ongoing review is consistent with maintaining a secure baseline.[1][2] |
## Identity and privileged access controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| IAM-01 | Separate named privileged accounts are used for administration instead of standard user accounts. | Primary | Account inventory, naming standard | AC-2, AC-6, IA-4 [3] | Microsoft and the Cyber Centre recommend separate privileged accounts.[1][2] |
| IAM-02 | Membership in Domain Admins, Enterprise Admins, Schema Admins, Administrators, Backup Operators, Account Operators, and other high-privilege groups is minimized and regularly reviewed. | Primary | Group membership reports, review sign-offs | AC-2, AC-6, AU-6 [3] | Microsoft hardening guidance emphasizes minimizing privilege and monitoring changes to privileged groups.[6][1] |
| IAM-03 | Privileged access is granted through just-in-time or time-bound elevation where technically feasible. | Primary | PAM/PIM reports, workflow approvals | AC-2, AC-6, IA-2 [3] | Cyber Centre recommends JIT privileged account provisioning.[2] |
| IAM-04 | Emergency or break-glass privileged access is controlled by formal approval, enhanced logging, and post-use review. | Secondary | Emergency access SOP, access logs, review records | AC-2, AU-2, IR-4 [3] | Controlled emergency access supports resilience while limiting abuse.[1][2] |
| IAM-05 | Privileged accounts are marked as sensitive and not trusted for delegation where applicable. | Primary | AD account settings export, hardening checklist | AC-6, IA-4, SC-2 [3] | Microsoft recommends enabling the sensitive-and-cannot-be-delegated control for privileged accounts.[7] |
| IAM-06 | Privileged accounts require phishing-resistant MFA or hardware-token MFA for administrative access. | Primary | MFA configuration, token inventory, auth reports | IA-2, IA-5, AC-7 [3] | Cyber Centre recommends hardware-token MFA for user and administrative accounts.[2][8] |
| IAM-07 | Built-in Administrator accounts are secured with strong restrictions and reserved for repair or recovery scenarios. | Secondary | Account configuration, safe custody procedure | AC-2, IA-5, CP-9 [3] | Microsoft recommends tightly securing built-in Administrator accounts for recovery use.[7] |
| IAM-08 | Delegated administrative rights are documented, approved, and periodically reviewed for least privilege. | Primary | Delegation matrix, ACL review records | AC-2, AC-6, AU-6 [3] | Microsoft recommends review of delegated access as part of least-privilege hardening.[6][7] |
| IAM-09 | Stale, disabled, orphaned, and temporary privileged accounts are identified and removed on a defined schedule. | Secondary | Identity review outputs, disablement logs | AC-2, IA-4, CA-7 [3] | Lifecycle control is part of account management good practice.[2] |
| IAM-10 | Password filtering or banned-password protection is enabled for AD accounts. | Primary | Password protection settings, GPO evidence | IA-5, SI-10 [3] | Cyber Centre recommends AD password filtering to block compromised or bad passwords.[9] |
## Service account controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| SVC-01 | Managed service accounts or group managed service accounts are used where possible. | Primary | gMSA inventory, deployment records | AC-2, IA-5 [3] | Cyber Centre recommends managed service accounts where possible.[2][9] |
| SVC-02 | Service accounts are granted only the minimum rights needed for the service and are not members of built-in privileged groups unless explicitly approved. | Primary | Rights review, group membership review | AC-6, AC-2 [3] | Cyber Centre advises against placing service accounts in built-in privileged groups.[2][9] |
| SVC-03 | Service accounts are prohibited from interactive logon and user-style endpoint use. | Primary | GPO rights assignments, account settings | AC-6, IA-4 [3] | Cyber Centre recommends denying interactive logon for service accounts.[2][9] |
| SVC-04 | Service account ownership, purpose, associated systems, and credential rotation requirements are documented. | Secondary | Service account register | CM-8, IA-5, RA-3 [3] | Account inventory supports secure lifecycle management.[2] |
| SVC-05 | Service account activity is logged and reviewed for anomalous use, especially for privileged and tier-0 services. | Secondary | SIEM reports, use cases | AU-6, SI-4 [3] | Logging and monitoring of privileged use align to Microsoft and Cyber Centre guidance.[1][2] |
## Administrative workstation and session security controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| AWS-01 | AD administration is performed only from dedicated secure administrative workstations or equivalent hardened administrative hosts. | Primary | PAW inventory, build standard | AC-6, CM-6, SC-7 [3] | Microsoft and the Cyber Centre recommend secure admin workstations or administrative hosts.[1][2][10] |
| AWS-02 | Privileged accounts are blocked from logging on to lower-tier systems, standard user workstations, and internet-facing devices. | Primary | Logon restrictions, GPOs, tiering standard | AC-6, SC-7 [3] | Cyber Centre states privileged accounts used on dedicated admin workstations should be blocked from lower-tier zones.[2] |
| AWS-03 | Secure administrative workstations are hardened with application allowlisting, disk encryption, restricted software, and enhanced endpoint controls. | Primary | PAW baseline, AppLocker/WDAC, BitLocker reports | CM-6, CM-7, MP-6, SI-7 [3] | Microsoft PAW guidance describes hardened locked-down workstations for sensitive tasks.[10][11] |
| AWS-04 | Internet browsing, email, and general productivity functions are restricted or prohibited on administrative workstations. | Secondary | Proxy restrictions, browser policy, workstation standard | AC-6, SC-7 [3] | Separation of privileged and normal-use activities reduces credential exposure.[1][10] |
| AWS-05 | Administrative sessions are monitored and remote administration paths are restricted to approved protocols and management segments. | Secondary | Jump host configs, session logs, firewall rules | AU-12, SC-7, SI-4 [3] | Restricting administration paths supports secure operation of privileged systems.[1][2] |
## Domain controller and infrastructure hardening controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| DC-01 | Domain controllers are deployed only for directory-related functions and do not host unnecessary non-AD workloads. | Primary | Server inventory, build standard | CM-7, CM-8 [3] | Microsoft and the Cyber Centre recommend minimizing services on critical systems.[1][2] |
| DC-02 | Domain controllers are patched on a defined schedule and emergency security updates are applied according to risk. | Primary | Patch reports, vulnerability reports | SI-2, CM-3 [3] | Microsoft prioritizes patching as an AD security best practice.[1] |
| DC-03 | Domain controllers are configured to a secure baseline and periodically assessed against the baseline. | Primary | Baseline documents, compliance scans | CM-2, CM-6, CA-7 [3] | Baseline hardening is recommended by Microsoft and supplemented by CIS benchmarks.[1][2][4] |
| DC-04 | Host-based firewalls on domain controllers are enabled and restricted to required communications. | Primary | Firewall policy, endpoint configuration | SC-7, CM-7 [3] | Microsoft and the Cyber Centre recommend restricting inbound and outbound connectivity.[1][2] |
| DC-05 | Physical and virtual access to domain controllers is limited to authorized administrators and approved infrastructure teams. | Primary | Access lists, virtualization RBAC, badge logs | PE-2, PE-3, AC-6 [3] | Domain controllers are high-value assets that require stronger access restrictions.[1][2] |
| DC-06 | Read-only domain controller password replication settings exclude privileged accounts and are periodically reviewed where RODCs are used. | Secondary | RODC configuration, group review | AC-6, IA-5 [3] | Microsoft highlights careful control of password replication groups for RODCs.[6] |
| DC-07 | Time synchronization, DNS security, and directory replication health are monitored as foundational AD service controls. | Secondary | Monitoring dashboards, health checks | AU-6, SI-4, CP-2 [3] | Operational integrity supports secure authentication and directory function.[1][2] |
## Authentication, protocol, and trust security controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| AUTH-01 | Weak and legacy authentication methods and protocols are disabled where possible. | Primary | GPOs, protocol settings, exception records | IA-2, CM-7, SC-8 [3] | Canadian guidance requires disabling weak and legacy protocols where possible.[12][2] |
| AUTH-02 | Kerberos is preferred over NTLM where technically feasible and NTLM use is reduced and monitored. | Primary | NTLM audit logs, hardening roadmap | IA-2, AU-6, SI-4 [3] | Reducing weaker protocols lowers credential abuse risk.[1][2] |
| AUTH-03 | Privileged and sensitive accounts are configured to prevent unconstrained or inappropriate delegation. | Primary | Account flags, delegation review records | AC-6, SC-2 [3] | Microsoft recommends preventing delegation exposure for privileged accounts.[7] |
| AUTH-04 | Each trust is configured according to least privilege and reviewed for direction, scope, authentication method, and necessity. | Primary | Trust config exports, trust review records | AC-4, AC-6, CA-7 [3] | Trusts should be minimized and governed as security boundaries of concern.[2][1] |
| AUTH-05 | Selective authentication is enabled on trusts when cross-domain or cross-forest access should be limited to specific systems. | Secondary | Trust settings, access lists | AC-4, AC-6, SC-7 [3] | Restricting trust use is a core compensating strategy for trust exposure.[2] |
| AUTH-06 | SID filtering or equivalent protection is enabled where applicable to prevent unauthorized privilege transfer across trusts. | Secondary | Trust settings, security review | AC-4, SC-7 [3] | SID filtering is a common hardening measure for trust-related privilege risk.[1] |
| AUTH-07 | Foreign security principals and cross-domain group memberships are periodically reviewed for appropriateness. | Secondary | FSP inventory, access review sign-offs | AC-2, AC-6, AU-6 [3] | Cross-boundary access should be periodically reviewed.[2] |
| AUTH-08 | Weak encryption algorithms and unsupported directory-related technologies are disabled or isolated behind documented exceptions. | Primary | Encryption policy, exception register | SC-13, CM-7, RA-3 [3] | Cyber Centre recommends disabling weak technologies such as DES and SMBv1.[2] |
## Logging, monitoring, and change auditing controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| LOG-01 | Advanced audit policy is enabled to capture account management, logon, object access, policy change, directory service change, and privileged use events relevant to AD. | Primary | Audit policy exports, GPOs | AU-2, AU-12 [3] | Microsoft recommends monitoring AD for significant events and compromise indicators.[1] |
| LOG-02 | Logs from domain controllers and other critical identity systems are forwarded to a centralized logging or SIEM platform. | Primary | SIEM onboarding records, connector configs | AU-4, AU-6, AU-9 [3] | Centralized logging supports tamper resistance and detection.[1][2] |
| LOG-03 | Alerts exist for privileged group changes, trust changes, GPO changes, account lockout anomalies, service account misuse, and sensitive object modifications. | Primary | Use case catalog, alert definitions | AU-6, SI-4, IR-5 [3] | Microsoft and the Cyber Centre emphasize monitoring of sensitive changes and privileged activity.[1][2] |
| LOG-04 | Log retention and protection standards ensure security logs are retained for investigation and protected from unauthorized modification. | Secondary | Retention policy, storage controls | AU-9, AU-11, MP-5 [3] | Protected retention improves forensic usefulness.[5] |
| LOG-05 | Security operations or designated control owners review AD alerts and exceptions on a defined cadence and track remediation. | Secondary | SOC review records, case tickets | AU-6, CA-7, IR-4 [3] | Review and response are required for monitoring to be effective.[1][2] |
| LOG-06 | Domain controller health, replication, DNS, and authentication telemetry are included in security monitoring because service degradation can indicate compromise or control failure. | Secondary | Monitoring dashboards, runbooks | SI-4, CP-2, AU-6 [3] | Operational monitoring supports secure service continuity.[1][2] |
## Group Policy and secure configuration controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| GPO-01 | Security-relevant Group Policies are documented, approved, and version controlled. | Primary | GPO inventory, change records | CM-3, CM-5, CM-8 [3] | Controlled configuration management is fundamental to AD hardening.[1][2] |
| GPO-02 | GPO creation, modification, linking, and permissions are restricted to authorized administrators. | Primary | Delegation settings, GPO ACL reviews | AC-6, CM-5, AU-6 [3] | Restricting configuration authority reduces abuse risk.[1][2] |
| GPO-03 | A secure baseline exists for domain controllers, member servers, and administrative workstations, and it is periodically validated. | Primary | Baselines, benchmark reports | CM-2, CM-6, CA-7 [3] | Microsoft guidance plus CIS benchmarks support this baseline approach.[1][2][4] |
| GPO-04 | Changes to critical GPOs are monitored and independently reviewed after implementation. | Secondary | Change tickets, alerting records | AU-2, AU-6, CM-3 [3] | Monitoring and review of sensitive changes align to Microsoft compromise-detection guidance.[1] |
| GPO-05 | Unsupported, duplicate, or obsolete GPOs are periodically removed or consolidated to reduce configuration sprawl and hidden risk. | Secondary | GPO cleanup records | CM-8, CA-7 [3] | Reducing unnecessary complexity supports secure maintainability.[1][2] |
## Network segmentation and legacy dependency controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| NET-01 | Domain controllers and tier-0 systems reside in restricted network segments with tightly controlled inbound and outbound traffic. | Primary | Firewall rules, network diagrams | SC-7, AC-4 [3] | Cyber Centre recommends restricted communications for critical AD servers.[2] |
| NET-02 | Legacy systems that require weaker protocols or elevated access are isolated in segmented zones with documented compensating controls. | Primary | Segmentation design, exception register | SC-7, RA-3, CM-7 [3] | Microsoft and the Cyber Centre recommend isolating legacy systems where immediate modernization is not possible.[1][2] |
| NET-03 | Administrative paths into domain controllers and other tier-0 assets are limited to approved management networks, jump servers, or PAWs. | Primary | ACLs, jump host configs | AC-6, SC-7 [3] | Restricting administrative paths aligns with Microsoft privileged access guidance.[1][10] |
| NET-04 | Cross-domain or cross-boundary transfers use higher-assurance transfer mechanisms rather than broad trust-based access where possible. | Secondary | File transfer design, gateway records | AC-4, SC-7 [3] | Cyber Centre notes broad transfer mechanisms between domains of differing sensitivity are not generally recommended.[13] |
| NET-05 | Compensating monitoring exists for legacy segments, including heightened alerting, vulnerability tracking, and exception expiry reviews. | Secondary | Legacy segment dashboards, review minutes | RA-5, SI-4, CA-7 [3] | Increased monitoring is appropriate where risk cannot be removed immediately.[2] |
## Backup, recovery, and resilience controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| REC-01 | AD system state, configuration, and other required recovery data are backed up according to an approved schedule. | Primary | Backup schedules, backup reports | CP-9, CP-10 [3] | Microsoft recommends incident recovery planning and preparation for compromise.[1] |
| REC-02 | Backup repositories for AD recovery are protected from routine administrative compromise through segregation, immutability, offline storage, or equivalent controls. | Primary | Backup architecture, access controls | CP-9, AC-6, SC-28 [3] | Protected recovery assets improve resilience against directory compromise.[1] |
| REC-03 | A documented forest or domain recovery plan exists and identifies roles, prerequisites, communication paths, and validation steps. | Primary | Recovery runbook, contact trees | CP-2, CP-4, IR-8 [3] | Microsoft recommends planning and updating incident recovery plans for AD.[1] |
| REC-04 | Recovery exercises and restore tests are performed periodically and tracked to closure for identified gaps. | Secondary | Test results, tabletop reports | CP-4, CA-7, IR-4 [3] | Testing is necessary to demonstrate recoverability.[1] |
| REC-05 | Break-glass procedures exist for loss of normal admin access, including protected credentials and controlled storage. | Secondary | Emergency procedures, custody records | CP-2, IA-5, IR-4 [3] | Controlled recovery access supports continuity while limiting misuse.[7][1] |
## Vulnerability, assessment, and assurance controls
| Control ID | Individual control | Control type | Example evidence | NIST mapping | Alignment |
|---|---|---|---|---|---|
| ASM-01 | Domain controllers, administrative workstations, and other identity infrastructure are included in vulnerability scanning and remediation processes. | Primary | Scan schedules, remediation records | RA-5, SI-2 [3] | Continuous visibility into vulnerabilities supports AD protection.[1][2] |
| ASM-02 | Secure configuration compliance is measured against an approved baseline and, where used, CIS benchmark criteria. | Primary | Compliance scans, benchmark reports | CA-7, CM-6 [3] | Cyber Centre recommends CIS benchmarks as augmentation and verification.[2][4] |
| ASM-03 | AD attack path exposures, delegated privilege risks, and trust-related risks are periodically assessed. | Primary | Purple team reports, exposure reviews | RA-3, RA-5, CA-2 [3] | Microsoft and Cyber Centre guidance both support risk-based evaluation of privilege and trust exposure.[6][2] |
| ASM-04 | Internal audit or second-line reviews independently assess the design and operating effectiveness of critical AD controls. | Secondary | Audit programs, issue logs | CA-2, CA-7, PM-9 [3] | Independent review strengthens assurance and governance.[3] |
| ASM-05 | AD security metrics are reported to management, including privileged account counts, stale accounts, unpatched DCs, trust exceptions, and recovery test status. | Secondary | KPI dashboards, management reporting | PM-6, CA-7, AU-6 [3] | Metrics improve oversight and remediation accountability.[2] |
## Individual secondary controls specifically relevant when trusts remain in place
The following secondary controls are especially useful where the organization has necessary but unavoidable trust relationships across domains or forests.[2][1]
- Review trust configuration, trust direction, and necessity at least annually and after material change.[2]
- Enable selective authentication when only specific systems should be reachable across the trust.[2]
- Validate SID filtering or equivalent trust hardening settings where applicable.[1]
- Review foreign security principals and cross-domain group nesting on a fixed schedule.[2]
- Alert on trust creation, removal, and modification events through centralized monitoring.[1]
- Restrict administrative activity across trusts to approved accounts, approved hosts, and approved management paths only.[1][2]
- Segment legacy applications that depend on the trust and track them through an exception register with target remediation dates.[1][2]
- Maintain tested recovery procedures that assume trust-related compromise may spread beyond a single domain.[1][2]
## Recommended columns for the next version
To convert this catalog into a working control register, add the following fields for each individual control:[3][2]
- Internal control ID
- Control domain
- Control objective
- Detailed control statement
- Primary or secondary classification
- Technical owner
- Process owner
- Implementation status
- Evidence source
- Testing procedure
- Review cadence
- Exception reference
- NIST mapping
- Microsoft or Cyber Centre reference
## Drafting notes
This draft is intentionally written at the control-statement level so it can be copied directly into an Excel workbook or GRC platform and then customized to the organization’s exact environment, evidence sources, and operating model.[3][2]
The next useful iteration would be an Excel control matrix with one row per control and prebuilt columns for status, evidence, owner, and control testing notes.[3][2]
No comments:
Post a Comment