Vulnerability Discussion

Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.

Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Associating event types with detected events in audit logs provides a means of investigating an attack, recognizing resource usage or capacity thresholds, or identifying an improperly configured AlmaLinux OS 9 system.

Satisfies: SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000392-GPOS-00172, SRG-OS-000122-GPOS-00063, SRG-OS-000473-GPOS-00218, SRG-OS-000472-GPOS-00217, SRG-OS-000474-GPOS-00219, SRG-OS-000365-GPOS-00152, SRG-OS-000358-GPOS-00145, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000337-GPOS-00129, SRG-OS-000062-GPOS-00031, SRG-OS-000054-GPOS-00025

Check

Verify that the auditd service is enabled with the following command:

$ systemctl status auditd.service

auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-01-05 14:04:30 UTC; 10min ago

If the audit service is not "active" and "running", this is a finding.

Fix

To enable the auditd service run the following command:

$ systemctl enable --now auditd