Logs are evidence. An attacker who gets in will want to edit or delete them, and an insider might too. AU-9 asks you to protect them like evidence.
NIST SP 800-53 Rev 5 binds US federal systems, and others through contract. For other organizations it is a reference.
What the control asks
Protect audit information and audit logging tools from unauthorized access, modification and deletion. Alert defined personnel or roles when you detect unauthorized access, modification or deletion of audit information.
NIST's guidance defines audit information broadly: audit records, log settings, reports and personal data in them. Logging tools count too. The control focuses on technical protection and on limiting who can access and run the tools.
What it means in practice
Three questions. Who can read the logs? Who can change or delete them? Would you know if somebody did?
A solid setup sends logs off the source system to a separate account or store, makes them write-once or versioned, limits write access to the collection pipeline, and limits read access by role. Admins of the application should not be able to delete its own audit trail.
The record lists seven enhancements: AU-9.1 Hardware Write-once Media, AU-9.2 Store on Separate Physical Systems or Components, AU-9.3 Cryptographic Protection, AU-9.4 Access by Subset of Privileged Users, AU-9.5 Dual Authorization, AU-9.6 Read-only Access and AU-9.7 Store on Component with Different Operating System. For a cloud native company, AU-9.2, AU-9.3 and AU-9.4 are the practical set: separate store, integrity protection, few privileged users.
Evidence to collect
- Access control lists or role definitions for the log store.
- Configuration showing object lock, versioning or immutability.
- Proof logs are shipped to a separate account or system.
- Integrity checks such as hashes or signatures, if used.
- Alert rules that fire on log deletion or retention changes, and a test.
- A list of the few people who can administer logging.
Common gaps
- Application admins who can delete application logs.
- Logs kept only on the host that generates them.
- No alert on changes to logging settings.
- Broad read access to logs that contain personal data.
- Backups of logs outside the access model.
How to implement it
Ship logs to a dedicated store in a separate account. Turn on versioning and a retention lock. Grant write access to the pipeline only. Restrict reads to security and audit roles. Alert on deletion events and on changes to logging configuration. Test by attempting a deletion with a low privilege account and by confirming the alert.
Quick check
Is sending logs to a separate account worth the effort?
Yes. It is the single biggest step toward protecting logs from a compromised system or administrator.
Do we need to alert on read access too?
AU-9 mentions unauthorized access, modification or deletion. Alert on what you can reliably detect and review read access regularly.
