Alert in the event of an audit logging process failure
📖 What This Means
This practice requires organizations to set up alerts that notify relevant personnel when the audit logging process fails. Audit logging is crucial for tracking and recording system activities, especially those involving sensitive data like Controlled Unclassified Information (CUI). If logging stops or fails, organizations lose visibility into potential security incidents, making it harder to detect and respond to threats. For example, if a server stops logging user access attempts due to a misconfiguration, unauthorized access could go unnoticed. Another scenario is a disk filling up, causing logs to stop being recorded, which could prevent the detection of malicious activities. This control ensures that such failures are immediately flagged so they can be addressed promptly.
🎯 Why It Matters
Audit logging is a critical component of cybersecurity, providing a record of events that can be used to detect, investigate, and respond to security incidents. If logging fails, organizations risk missing crucial evidence of unauthorized access, data breaches, or insider threats. For example, in the 2017 Equifax breach, delayed detection of unauthorized access allowed attackers to exfiltrate sensitive data over several weeks. A failure in audit logging could lead to similar outcomes, resulting in significant financial losses, reputational damage, and regulatory penalties. From a DoD/CMMC perspective, this control ensures accountability and visibility into systems handling CUI, which is essential for protecting national security interests.
✅ How to Implement
- Enable logging services in your cloud environment (e.g., AWS CloudTrail, Azure Monitor, GCP Logging).
- Configure alerts for logging failures using cloud-native monitoring tools (e.g., AWS CloudWatch Alarms, Azure Alerts, GCP Alerting).
- Set up notifications to send alerts to designated personnel via email, SMS, or integration with incident management tools like PagerDuty.
- Regularly test logging and alerting mechanisms to ensure they are functioning correctly.
- Monitor log storage capacity and configure alerts for thresholds (e.g., 80% disk usage).
📋 Evidence Examples
Alert configuration screenshots
Notification logs
Testing results
Log storage capacity monitoring report
Policy/procedure document
📝 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.4 ("Alert in the event of an audit logging process failure"), 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.4 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to alert in the event of an audit logging process failure. 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.4 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to alert in the event of an audit logging process failure. 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.4 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 alert in the event of an audit logging process failure 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.4
- 📄 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: Are audit logs enabled on all systems handling CUI?
Question 2: Are alerts configured for audit logging failures?
Question 3: Are notifications sent to designated personnel?
Question 4: Are logging and alerting mechanisms tested regularly?
Question 5: Is log storage capacity monitored and alerts configured?
⚠️ Common Mistakes (What Auditors Flag)
1. Not enabling audit logging on all systems.
2. Failing to test alerting mechanisms.
3. Not monitoring log storage capacity.
4. Incomplete documentation of procedures.
5. Using incorrect notification channels.
📚 Parent Policy
This practice is governed by the Audit and Accountability Policy