Security controls are not a yes or no thing. Think critically about how extreme of measure you can take to ensure no audit events are lost. Get creative about alternative controls.
CIS apparently now puts implementation checklists behind a contact form. Found an old copy at CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.2.0.pdf to discuss implementation details. Terminology and numbering may change, but the reasoning is for the most part timeless.
4.1.1.3 Ensure audit logs are not automatically deleted (Scored) Profile Applicability:
- Level 2 - Server
- Level 2 - Workstation
Description: The max_log_file_action setting determines how to handle
the audit log file reaching the max file size. A value of keep_logs
will rotate the logs but never delete old logs.
Rationale: In high security contexts, the benefits of maintaining a
long audit history exceed the cost of storing the audit history.
Audit: Run the following command and verify output matches:
# grep max_log_file_action /etc/audit/auditd.conf
max_log_file_action = keep_logs
Remediation: Set the following parameter in /etc/audit/auditd.conf:
max_log_file_action = keep_logs
CIS Controls:
6.3 Ensure Audit Logging Systems Are Not Subject To Loss (i.e. rotation/archive)
Ensure that all systems that store logs have adequate storage space
for the logs generated on a regular basis, so that log files will not
fill up between log rotation intervals. The logs must be archived and
digitally signed on a periodic basis.
Note that the rationale talks about high security environments. Level 2, which I assume maps to implementation group 2 in newer terminology. This is for situations where you cannot afford to lose any events at all, high impact due to compliance environment or other risks.
A safe thing to do would be to let a log file archiving process delete old files, only after they are backed up. Of course you can delete log files from hosts. But take care that a failure in archiving does not result in log rotation deleting files early.
For the archival storage, do not let audit logs be altered or deleted. Sign files to confirm their integrity. Remove edit and delete permissions from object storage accounts. Consider cold storage on tape media.
This checklist in some situations also recommends admin_space_left_action = halt. Yes, this means the audit system will shut down the host if it cannot log. If this horrifies you due to your service level objectives, you may need to reexamine if this level of paranoia is appropriate for your environment.
Also implement a centralized audit logging system. Forward or otherwise collect events in a system with a large amount of storage. Easier to secure, query, and retain.
Which provides better security: a central database with 6 months of data ready to be queried and years backed up, or a fleet of hosts always running out of storage because someone thought a checklist prohibited deleting files?
