V-280965

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DOD has defined the list of events for which RHEL 10 will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels). 2) Access actions, such as successful and unsuccessful login attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logins from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system. 3) All account creations, modifications, disabling, and terminations. 4) All kernel module load, unload, and restart actions. Satisfies: SRG-OS-000062-GPOS-00031, SRG-OS-000471-GPOS-00215

Check Content

Note: If the system is a virtual machine with no virtual or physical USB peripherals attached, this is not applicable.

Verify RHEL 10 audit logging is enabled for the USBGuard daemon. 

Confirm the setting with the following command:

$ sudo grep AuditBackend /etc/usbguard/usbguard-daemon.conf
AuditBackend=LinuxAudit

If "AuditBackend" is not set to "LinuxAudit", this is a finding.