AC-5 Separation of Duties
Guidance: draftPolicy clause: draftWhat these mean
ac5ctl| Baselines | Implementation level | Enhancements |
|---|---|---|
| Moderate, High | Organization | None |
Related controls: AC-2, AC-3, AC-6, AU-9, CM-5, CM-11, CP-9, IA-2, IA-4, IA-5, IA-12, MA-3, MA-5, PS-2, SA-8, SA-17
Control statement
Section titled “Control statement”- a. Identify and document [Assignment: organization-defined duties of individuals] ; and
- b. Define system access authorizations to support separation of duties.
NIST discussion
Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in AC-2 , access control mechanisms in AC-3 , and identity management activities in IA-2, IA-4 , and IA-12.
Assessment objectives (SP 800-53A)
Section titled “Assessment objectives (SP 800-53A)”Objectives and methods for AC-5
Determine if:
- AC-05a. [Assignment: organization-defined duties of individuals] are identified and documented;
- AC-05b. system access authorizations to support separation of duties are defined.
Examine: Access control policy; procedures addressing divisions of responsibility and separation of duties; system configuration settings and associated documentation; list of divisions of responsibility and separation of duties; system access authorizations; system audit records; system security plan; other relevant documents or records.
Interview: Organizational personnel with responsibilities for defining appropriate divisions of responsibility and separation of duties; organizational personnel with information security responsibilities; system/network administrators.
Test: Mechanisms implementing separation of duties policy.
Policy statement
- The System owner shall identify and document Fill in: duties of individuals requiring separation Typical: requesting and approving access; developing and deploying code to production; administering a system and reviewing its audit logs. (AC-5a)
- The System owner shall define system access authorizations that support separation of those duties. (AC-5b)
From the Access Control Policy template (draft). Highlighted fields are values your organization sets.
How to apply it
Section titled “How to apply it”AC-5 asks you to name the duties that no one person should hold together, and to set up access so the system keeps them apart. The aim is that misuse of access, or a single mistake, needs a second person to go unnoticed. NIST’s discussion gives one pairing every system should consider: people who administer access control should not also administer audit functions.
Common implementations. A short table in the account management procedure (section 4) or the system security plan listing the duty pairs and the roles that hold each side. Access requests approved by someone other than the requester, enforced in the ticketing or identity governance tool. Code changes that need an approving review from someone other than the author before the pipeline deploys them to production (see CM-5). Audit logs sent to a log platform that system administrators cannot change or delete (see AU-9). Identity governance tools that flag toxic combinations of roles at request time and in each access review.
Organization-defined parameters. Typical values, which your organization may set differently:
| Parameter | Typical value |
|---|---|
| Duties of individuals that require separation (a) | Requesting and approving access; developing and deploying code to production; administering a system and reviewing its audit logs |
Evidence assessors ask for.
- The documented list of duties that require separation, with the roles on each side
- Role definitions or a role matrix for the system, from the identity provider or the application
- A sample of access requests showing the approver is not the requester
- Pipeline or repository settings requiring an independent review before deployment, and a sample of merged changes
- Permissions on the audit log platform, showing who can administer it and who can change or delete records
- The last access review, with any conflicting role combinations found and how they were resolved
Inheritance. The identity governance tool and the central log platform are often common controls, and they carry part of the separation. The system owns its own duty pairs and its application roles, so AC-5 is usually a hybrid control.
Common findings.
- Small teams where one administrator requests, approves and grants their own access, with no compensating review.
- Developers with standing write access to production.
- System administrators who can delete or alter the audit logs of the systems they run.
- A documented list of duties that the role design does not enforce.
Enhancements in the Moderate baseline. AC-5 has no enhancements.
Artifacts
Independent guidance, not an official NIST publication. Control text is from NIST SP 800-53 Rev. 5 and SP 800-53A (public domain). Original content is licensed CC BY 4.0; program templates and the downloadable kit are dedicated to the public domain under CC0 1.0.