AU-2 Audit Events (L) (M) (H)

NIST 800-53 (r4) Control:

The organization:

a. Determines that the information system is capable of auditing the following events: [FedRAMP Assignment: (L)(M)(H) successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes];

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: [FedRAMP Assignment: (L)(M)(H) organization-defined subset of the auditable events defined in AU-2 a to be audited continually for each identified event].

AU-2 Additional FedRAMP Requirements and Guidance: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.

NIST 800-53 (r4) 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. Related controls: AC-6, AC-17, AU-3, AU-12, MA-4, MP-2, MP-4, SI-4.

References: NIST Special Publication 800-92; Web: http://idmanagement.gov.

NIST 800-53 (r5) Discussion:

An event is an observable occurrence in a system. The types of events that require logging are those events that are significant and relevant to the security of systems and the privacy of individuals. Event logging also supports specific monitoring and auditing needs. Event types include password changes, failed logons or failed accesses related to systems, security or privacy attribute changes, administrative privilege usage, PIV credential usage, data action changes, query parameters, or external credential usage. In determining the set of event types that require logging, organizations consider the monitoring and auditing appropriate for each of the controls to be implemented. For completeness, event logging includes all protocols that are operational and supported by the system.

To balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. The types of events that organizations desire to be logged may change. Reviewing and updating the set of logged events is necessary to help ensure that the events remain relevant and continue to support the needs of the organization. Organizations consider how the types of logging events can reveal information about individuals that may give rise to privacy risk and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the logging event is based on patterns or time of usage.

Event logging requirements, including the need to log specific event types, may be referenced in other controls and control enhancements. These include AC-2(4), AC-3(10), AC-6(9), AC-17(1), CM-3f, CM-5(1), IA-3(3)(b), MA-4(1), MP-4(2), PE-3, PM-21, PT-7, RA-8, SC-7(9), SC-7(15), SI-3(8), SI-4(22), SI-7(8), and SI-10(1). Organizations include event types that are required by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Audit records can be generated at various levels, including at the packet level as information traverses the network. Selecting the appropriate level of event logging is an important part of a monitoring and auditing capability and can identify the root causes of problems. When defining event types, organizations consider the logging necessary to cover related event types, such as the steps in distributed, transaction-based processes and the actions that occur in service-oriented architectures.

38North Guidance:

Meets Minimum Requirement:

• Part a.

  • Define and document the significant auditable events relevant to the security of the system. The audit events are chosen by the organization based on the audit events they deem significant to support auditing capabilities, security incidents and after-the-fact investigations of malicious activity.

• Part b.

  • The list of auditable events should be determined by all system main points of contact, from compliance, network, application, legal, etc. This ensures the system is capturing the proper audit events to support the system, security incidents and after-the-fact investigations.

• Part c.

  • Formally document the rationale for why the defined auditable events documented in Part a are adequate to support the system requirements, security incidents or after-the-fact investigations. Typically the organization will document the rationale within the AU-2 Part c of the SSP. It could also be found within audit and accountability policy.

• Part d.

  • Document the auditable events defined within AU-2 Part a and determine the frequency for capturing the audit event or identifying the situation that would require each identified event to be captured.

Best Practice:

• Define the approved list of auditable events for the system (ex, password changes, failed logins, failed access to the system, administrative usage, etc.) based on the security requirements of the system and to support security incidents/after-the-fact investigations.

Unofficial FedRAMP Guidance:

• TBD

Assessment Evidence:

• The most recent AU policy for the system and System Security Plan. The policy and SSP should contain the defined list of approved audit events for the system in question. There could also be a system level ticket (ex. JIRA ticketing system) that contains the list of audit events that were reviewed and approved. You could use that artifact to support AU-2 and AU-2(3).

CSP Implementation Tips:

• Amazon Web Services (AWS): TBD

• Microsoft Azure: TBD

• Google Cloud Platform: TBD