Prevent non-privileged users from executing privileged functions
📖 What This Means
This practice ensures that only authorized users with elevated privileges can perform critical system operations, such as installing software, changing system settings, or accessing sensitive data. Non-privileged users, who have limited access rights, should not be able to execute these functions. This is essential to prevent accidental or intentional misuse of system privileges, which could lead to security breaches or data loss. For example, a regular employee should not be able to install unauthorized software on a company computer, as this could introduce malware. Similarly, a non-admin user should not be able to modify firewall settings, which could expose the network to external threats.
🎯 Why It Matters
Allowing non-privileged users to execute privileged functions can lead to significant security risks, such as unauthorized access to sensitive data, system compromise, or malware installation. For instance, in the 2017 Equifax breach, attackers exploited a vulnerability that allowed them to execute privileged commands, leading to the exposure of personal data of 147 million people. The Department of Defense (DoD) and CMMC emphasize this control to ensure that only trusted personnel can perform critical operations, reducing the risk of insider threats and external attacks. Failing to implement this control can result in costly data breaches, reputational damage, and non-compliance penalties.
✅ How to Implement
- 1. Use Identity and Access Management (IAM) tools (e.g., AWS IAM, Azure AD) to define roles and permissions.
- 2. Assign privileged roles only to authorized administrators.
- 3. Enable Multi-Factor Authentication (MFA) for privileged accounts.
- 4. Use Policy as Code tools (e.g., Terraform, CloudFormation) to enforce least privilege.
- 5. Regularly audit permissions using cloud-native tools (e.g., AWS Config, Azure Security Center).
- 6. Implement Just-In-Time (JIT) access for privileged functions using tools like PAM (Privileged Access Management).
- 7. Monitor and log all privileged actions using cloud logging services (e.g., AWS CloudTrail, Azure Monitor).
📋 Evidence Examples
IAM Role Configuration
Privileged Access Logs
RBAC Policy Document
Audit Report
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AC.L2-3.1.7 ("Prevent non-privileged users from executing privileged functions"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AC.L2-3.1.7 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to prevent non-privileged users from executing privileged functions. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"AC.L2-3.1.7 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to prevent non-privileged users from executing privileged functions. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AC.L2-3.1.7 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all access points to CUI systems (VPN, direct network, cloud portals)
- • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
- • Map user roles to system access levels
- • Ensure this control covers all systems within your defined CUI boundary where prevent non-privileged users from executing privileged functions applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Access Control Policy
- 📄 IAM configuration documentation
- 📄 Access request and approval records
- 📄 Evidence artifacts specific to AC.L2-3.1.7
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Are privileged roles restricted to authorized personnel?
Question 2: Is Multi-Factor Authentication (MFA) enabled for privileged accounts?
Question 3: Are privileged actions logged and monitored?
Question 4: Are privileged access policies reviewed quarterly?
Question 5: Is training provided to personnel on privileged access management?
⚠️ Common Mistakes (What Auditors Flag)
1. Over-assigning privileged roles
2. Not enabling MFA for privileged accounts
3. Inadequate logging of privileged actions
4. Outdated access policies
5. Missing training records
📚 Parent Policy
This practice is governed by the Access Control Policy