Ensure that actions of users can be uniquely traced to those users
📖 What This Means
This practice means that every action taken by a user on your systems must be linked back to their unique identity. Think of it like a security camera in a bank—every transaction or access event should have a digital 'name tag' showing who did it. For example, if an employee accesses a sensitive file, the logs must clearly show their username (not just 'admin'). Another example: if someone modifies a system configuration, the change must be tied to their individual account, not a shared login. This is critical for investigations, accountability, and detecting insider threats.
🎯 Why It Matters
Without unique user attribution, you can't detect malicious activity, investigate incidents, or hold users accountable. A 2022 Verizon DBIR report found that 82% of breaches involved human elements (misuse or stolen credentials). If all actions log as 'admin,' you can't tell if it's a compromised account or an insider threat. The DoD requires this to protect CUI—imagine a data leak where you can't identify who accessed the files. Average breach cost for SMBs is $165K (IBM 2023). CMMC enforces this to meet DFARS 252.204-7012 requirements for traceability.
✅ How to Implement
- 1. **AWS**: Enable AWS CloudTrail with 'management events' and 'data events' for S3. Set 'logAllUsers' to capture IAM user actions.
- 2. **Azure**: Configure Azure Activity Logs + Diagnostic Settings to stream to Log Analytics. Enable 'Sign-in logs' for AAD.
- 3. **GCP**: Turn on Audit Logs for all services (Admin Activity + Data Access). Use 'cloudaudit.googleapis.com' in logging sinks.
- 4. Enforce multi-factor authentication (MFA) to prevent shared account use (e.g., AWS IAM MFA, Azure Conditional Access).
- 5. Tag resources with owner metadata (e.g., AWS Resource Groups, Azure Tags).
- 6. Disable shared credentials (e.g., AWS root account, Azure shared mailboxes).
- 7. Use SIEM integration (e.g., Splunk, Azure Sentinel) to correlate logs with user identities.
📋 Evidence Examples
Audit Policy Document
Screenshot of AWS CloudTrail settings
Windows Security Event Log sample
SIEM Alert Report
MFA Enforcement Screenshot
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AU.L2-3.3.2 ("Ensure that actions of users can be uniquely traced to those users"), 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 your audit logging infrastructure, including which events are logged, the SIEM/log management platform, retention periods, log protection mechanisms, and review processes. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AU.L2-3.3.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to ensure that actions of users can be uniquely traced to those users. 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']."
"AU.L2-3.3.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to ensure that actions of users can be uniquely traced to those users. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AU.L2-3.3.2 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 systems generating audit logs within the CUI boundary
- • Document log flow from sources to centralized SIEM
- • Specify log storage locations and retention tiers
- • Ensure this control covers all systems within your defined CUI boundary where ensure that actions of users can be uniquely traced to those users applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Audit and Accountability Policy
- 📄 SIEM architecture documentation
- 📄 Log retention configuration
- 📄 Evidence artifacts specific to AU.L2-3.3.2
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that required events are logged, check log completeness (all required fields present), test log protection mechanisms, and review evidence of regular log reviews.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do all systems log user actions with unique identifiers (not shared accounts)?
Question 2: Can you produce a log showing a specific user's actions from the past 30 days?
Question 3: Are privileged actions (e.g., admin logins) logged with command details?
Question 4: Is there a process to review attribution logs weekly?
Question 5: Have you tested by tracing a sample action to a user this quarter?
⚠️ Common Mistakes (What Auditors Flag)
1. Shared service accounts with no individual attribution
2. Logs show generic 'SYSTEM' or 'root' instead of actual user
3. No MFA allows credential sharing
4. Time sync issues make logs unreliable
5. Logs exist but aren't reviewed
📚 Parent Policy
This practice is governed by the Audit and Accountability Policy