CoreOS: AU-2 AUDIT EVENTS

[shawndwells]

https://nvd.nist.gov/800-53/Rev4/control/AU-2

Control Description The organization: a. Determines that the information system is capable of auditing the following events: [Assignment: organization-defined auditable events];

b. Coordinates the security audit function with other organizational entities requiring audit-related information to enhance mutual support and to help guide the selection of auditable events;

c. Provides a rationale for why the auditable events are deemed to be adequate to support after-the-fact investigations of security incidents; and

d. Determines that the following events are to be audited within the information system: [Assignment: organization-defined audited events (the subset of the auditable events defined in AU-2 a.) along with the frequency of (or situation requiring) auditing for each identified event].

Supplemental Guidance An event is any observable occurrence in an organizational information system. Organizations identify audit events as those events which are significant and relevant to the security of information systems and the environments in which those systems operate in order to meet specific and ongoing audit needs. Audit events can include, for example, password changes, failed logons, or failed accesses related to information systems, administrative privilege usage, PIV credential usage, or third-party credential usage. In determining the set of auditable events, organizations consider the auditing appropriate for each of the security controls to be implemented. To balance auditing requirements with other information system needs, this control also requires identifying that subset of auditable events that are audited at a given point in time. For example, organizations may determine that information systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Auditing requirements, including the need for auditable events, may be referenced in other security controls and control enhancements. Organizations also include auditable events that are required by applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of auditable events, the auditing necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented architectures.

[zerolagtime]

JSIG dated 2016Apr11 defines the "organization-defined events" in AU-2.a as:

1. Authentication events: (1) Logons (Success/Failure) (2) Logoffs (Success)
2. Security Relevant File and Objects events: (1) Create (Success/Failure) (2) Access (Success/Failure) (3) Delete (Success/Failure) (4) Modify (Success/Failure) (5) Permission Modification (Success/Failure) (6) Ownership Modification (Success/Failure)
3. Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)
4. Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)
5. User and Group Management events: (1) User add, delete, modify, disable, lock (Success/Failure) (2) Group/Role add, delete, modify (Success/Failure)
6. Use of Privileged/Special Rights events: (1) Security or audit policy changes (Success/Failure) (2) Configuration changes (Success/Failure)
7. Admin or root-level access (Success/Failure)
8. Privilege/Role escalation (Success/Failure)
9. Audit and security relevant log data accesses (Success/Failure)
10. System reboot, restart and shutdown (Success/Failure)
11. Print to a device (Success/Failure)
12. Print to a file (e.g., pdf format) (Success/Failure)
13. Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure);

[zerolagtime]

The scap-security-guide v2.8.4 that ships with Red Hat/CentOS seems to meet most of the JSIG AU-2 events types except for 3/4 (digital media), 9 (audit and security relvant log data accesses), and 11/12 (printing). For digital media, watches on mkisofs and all binaries from the wodim package (/usr/bin/cdrecord, /usr/bin/devdump, /usr/bin/dvdrecord, /usr/bin/readom, and /usr/bin/wodim) should be watched for execute. Example audit rule "-w /usr/bin/wodim -p x -k media" To monitor who is reading logs, watches for read and access are recommended for these files: /var/log/audit/audit.log, /var/log/secure, /var/log/lastlog, /var/log/tallylog, and /var/log/wtmp. I'm not sure what to add to the audit subsystem for 11/12 with regard to printing, but we may need to limit this to the lp/lpr command line options and leave the GUI out for now. Optionally, we could just audit locally attached printers.

[redhatrises]

scap-security-guide v2.8.4

Never heard of scap-security-guide v2.8.4. We haven't even gotten to version 1.0 yet (never will because security is never done.... ;)

JSIG is an organizationally defined guide and has gone through and selected the applicable controls from NIST 800-53. It's going to require a new and separate profile (like the OSPP, C2S, STIG, etc profiles) to be developed which will probably be separate from the FISMA projects.

CentOS as an operating system fails to meet JSIG requirements due to failing encryption at rest and cipher requirements.

[redhatrises]

@zerolagtime since you are going through the JSIG, if you want to create a new profile under the version of RHEL that you are looking at, please feel free to. Tickets (Issues) can be created for the items that are missing from our content to meet JSIG requirements.