NIST 800-53 REV 5 • AUDIT AND ACCOUNTABILITY
AU-5 — Response to Audit Logging Process Failures
Alert {{ insert: param, au-05_odp.01 }} within {{ insert: param, au-05_odp.02 }} in the event of an audit logging process failure; and Take the following additional actions: {{ insert: param, au-05_odp.03 }}.
Supplemental Guidance
Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Organization-defined actions include overwriting oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel.
Practitioner Notes
If the audit logging system fails — the SIEM goes down, a disk fills up, or a log forwarder crashes — the system must alert someone. You cannot afford silent logging failures.
Example 1: In Splunk, create a saved search that checks for "log source silence" — if a host that normally sends logs every minute has not sent anything in 15 minutes, trigger an alert. Use the Deployment Monitor app to track forwarder health.
Example 2: Configure your monitoring system (PRTG, Nagios, Zabbix) to watch the audit logging services on every system. Monitor the Windows Windows Event Log service, Linux auditd service, and your log forwarder agents. If any service stops, generate an immediate alert to the IT operations team.