Audit and Accountability (AU)¶

AU.L2-3.3.1 – System Auditing¶

Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 21.

Determine if:

• [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
• [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
• [c] audit records are created (generated);
• [d] audit records, once created, contain the defined content;
• [e] retention requirements for audit records are defined; and
• [f] audit records are retained as defined.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 21.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing auditable events; system security plan; system design documentation; system configuration settings and associated documentation; procedures addressing control of audit records; procedures addressing audit record generation; system audit logs and records; system auditable events; system incident reports; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; personnel with audit review, analysis and reporting responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms implementing system audit logging].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 17-18.

An event is any observable occurrence in a system, which includes unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those events which are significant and relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, failed logons or failed accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the monitoring and auditing appropriate for each of the CUI security requirements. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that 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. 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 logging capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of event types, the logging 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 or cloud-based architectures. Audit record content that may be necessary to satisfy this requirement includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or failure indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred). Detailed information that organizations may consider in audit records includes full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit log information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest. Audit logs are reviewed and analyzed as often as needed to provide important information to organizations to facilitate risk-based decision making. NIST SP 800-92 provides guidance on security log management.

Further Discussion¶

OSAs must ensure that all applicable systems create and retain audit logs that contain enough information to identify and investigate potentially unlawful or unauthorized system activity. OSAs must define the audit logs it needs to collect as well as the specific events to capture within the selected logs. Captured audit records are checked to verify that they contain the required events.

In defining the audit log retention period, OSAs must ensure that logs are retained for a sufficiently long period to allow for the investigation of a security event. The retention period must take into account the delay of weeks or months that can occur between an initial compromise and the discovery of attacker activity.

Examples¶

• You set up audit logging capability for your company. You determine that all systems that contain CUI must have extra detail in the audit logs. Because of this, you configure these systems to log the following information for all user actions [b,c]:

• time stamps;

• source and destination addresses;
• user or process identifiers;
• event descriptions;
• success or fail indications; and
• filenames.

Potential Assessment Considerations¶

• Are audit log retention requirements appropriate to the system and its associated level of risk [e]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.1

AU.L2-3.3.2 – User Accountability¶

Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 21-22.

Determine if:

• [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
• [b] audit records, once created, contain the defined content.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 21-22.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing audit records and event types; system security plan; system design documentation; system configuration settings and associated documentation; procedures addressing audit record generation; procedures addressing audit review, analysis, and reporting; reports of audit findings; system audit logs and records; system events; system incident reports; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms implementing system audit logging].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 18.

This requirement ensures that the contents of the audit record include the information needed to link the audit event to the actions of an individual to the extent feasible. Organizations consider logging for traceability including results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, communications at system boundaries, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of VoIP.

Further Discussion¶

Capturing the necessary information in audit logs ensures that you can trace actions to a specific user. This may include capturing user IDs, source and destination addresses, and time stamps. Logging from networks, servers, clients, and applications should be considered in ensuring accountability. This requirement, AU.L2-3.3.2, which ensures logging and traceability of user actions, supports the control of non-privileged users required by AC.L2-3.1.7 as well as many other auditing, configuration management, incident response, and situation awareness requirements.

Examples¶

• You manage systems for a company that stores, processes, and transmits CUI. You want to ensure that you can trace all remote access sessions to a specific user. You configure the VPN device to capture the following information for all remote access connections: source and destination IP address, user ID, machine name, time stamp, and user actions during the remote session [b].

Potential Assessment Considerations¶

• Are users uniquely traced and held responsible for unauthorized actions [a]?
• Does the system protect against an individual denying having performed an action (non-repudiation) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.2

AU.L2-3.3.3 – Event Review¶

Review and update logged events.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 22.

Determine if:

• [a] a process for determining when to review logged events is defined;
• [b] event types being logged are reviewed in accordance with the defined review process; and
• [c] event types being logged are updated based on the review.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 22.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing audit records and event types; system security plan; list of organization-defined event types to be logged; reviewed and updated records of logged event types; system audit logs and records; system incident reports; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms supporting review and update of logged event types].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 18-19.

The intent of this requirement is to periodically re-evaluate which logged events will continue to be included in the list of events to be logged. The event types that are logged by organizations may change over time. Reviewing and updating the set of logged event types periodically is necessary to ensure that the current set remains necessary and sufficient.

Further Discussion¶

This requirement is focused on the configuration of the auditing system, not the review of the audit records produced by the selected events. The review of the audit logs is covered under AU.L2-3.3.5 and AU.L2-3.3.6.

Examples¶

• You are in charge of IT operations for a company that processes CUI and are responsible for identifying and documenting which events are relevant to the security of your company’s systems. Your company has decided that this list of events should be updated annually or when new security threats or events have been identified, which may require additional events to be logged and reviewed [a]. The list of events you are capturing in your logs started as the list of recommended events given by the manufacturers of your operating systems and devices, but it has grown from experience. Your company experiences a security incident, and a forensics review shows the logs appear to have been deleted by a remote user. You notice that remote sessions are not currently being logged [b]. You update the list of events to include logging all VPN sessions [c].

Potential Assessment Considerations¶

• Do documented processes include methods for determining when to review logged event types (i.e., regular frequency, after incidents, after major system changes) [a]?
• Do documented processes include methods for reviewing event types being logged (i.e., based on specific threat, use case, retention capacity, current utilization, and/or newly added system component or functionality) [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.3

AU.L2-3.3.4 – Audit Failure Alerting¶

Alert in the event of an audit logging process failure.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 22.

Determine if:

• [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
• [b] types of audit logging process failures for which alert will be generated are defined; and
• [c] identified personnel or roles are alerted in the event of an audit logging process failure.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 22.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing response to audit logging processing failures; system design documentation; system security plan; system configuration settings and associated documentation; list of personnel to be notified in case of an audit logging processing failure; system incident reports; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms implementing system response to audit logging process failures].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 19.

Audit logging process failures include software and hardware errors, failures in the audit record capturing mechanisms, and audit record storage capacity being reached or exceeded. This requirement applies to each audit record data storage repository (i.e., distinct system component where audit records are stored), the total audit record storage capacity of organizations (i.e., all audit record data storage repositories combined), or both.

Further Discussion¶

Audit logging keeps track of activities occurring on the network, servers, user workstations, and other components of the overall system. These logs must always be available and functional. The company’s designated security personnel (e.g., system administrator and security officer) need to be aware when the audit log process fails or becomes unavailable [a]. Notifications (e.g., email, Short Message Service (SMS)) should to be sent to the company’s designated security personnel to immediately take appropriate action. If security personnel are unaware of the audit logging process failure, then they will be unaware of any suspicious activity occurring at that time. Response to an audit logging process failure should account for the extent of the failure (e.g., a single component’s audit logging versus failure of the centralized logging solution), the risks involved in this loss of audit logging, and other factors (e.g., the possibility that an adversary could have caused the audit logging process failure).

Examples¶

• You are in charge of IT operations for a company that processes CUI, and your responsibilities include managing the audit logging process. You configure your systems to send you an email in the event of an audit log failure. One day, you receive one of these alerts. You connect to the system, restart logging, and determine why the logging stopped [a,b,c].

Potential Assessment Considerations¶

• Will the system alert personnel with security responsibilities in the event of an audit processing failure?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.4

AU.L2-3.3.5 – Audit Correlation¶

Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 23.

Determine if:

• [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
• [b] defined audit record review, analysis, and reporting processes are correlated.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 23.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing audit record review, analysis, and reporting; system security plan; system design documentation; system configuration settings and associated documentation; procedures addressing investigation of and response to suspicious activities; system audit logs and records across different repositories; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit record review, analysis, and reporting responsibilities; personnel with information security responsibilities].

Test: [SELECT FROM: Mechanisms supporting analysis and correlation of audit records; mechanisms integrating audit review, analysis and reporting].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 19.

Correlating audit record review, analysis, and reporting processes helps to ensure that they do not operate independently, but rather collectively. Regarding the assessment of a given organizational system, the requirement is agnostic as to whether this correlation is applied at the system level or at the organization level across all systems.

Further Discussion¶

Companies must review, analyze, and report audit records to help detect and respond to security incidents in a timely manner for the purpose of investigation and corrective actions. Collection of audit logs into one or more central repositories may facilitate correlated review.

Small companies may be able to accomplish this manually with well-defined and -managed procedures. Larger companies will use an automated system for analysis that correlates log data from across the entire enterprise. Some companies may want to orchestrate the analysis process to include the use of Application Programming Interfaces (APIs) for collection, correlation, and the automation of responses based on programed rulesets.

Examples¶

• You are a member of a cyber defense team responsible for audit log analysis. You run an automated tool that analyzes all the audit logs across a Local Area Network (LAN) segment simultaneously looking for similar anomalies on separate systems at separate locations. Some of these systems store CUI. After extracting anomalous information and performing a correlation analysis [b], you determine that four different systems have had their event log information cleared between 2:00 AM to 3:00 AM, although the associated dates are different. The team monitors all systems on the same LAN segment between 2:00 AM to 3:00 AM for the next 30 days.

Potential Assessment Considerations¶

• Are mechanisms used across different repositories to integrate audit review, analysis, correlation, and reporting processes [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.5

AU.L2-3.3.6 – Reduction & Reporting¶

Provide audit record reduction and report generation to support on-demand analysis and reporting.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 23.

Determine if:

• [a] an audit record reduction capability that supports on-demand analysis is provided; and
• [b] a report generation capability that supports on-demand reporting is provided.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 23.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing audit record reduction and report generation; system design documentation; system security plan; system configuration settings and associated documentation; audit record reduction, review, analysis, and reporting tools; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit record reduction and report generation responsibilities; personnel with information security responsibilities].

Test: [SELECT FROM: Audit record reduction and report generation capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 19.

Audit record reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit record reduction and report generation capabilities do not always emanate from the same system or organizational entities conducting auditing activities. Audit record reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the system can help generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the time stamp in the record is insufficient.

Further Discussion¶

Raw audit log data is difficult to review, analyze, and report because of the volume of data. Audit record reduction is an automated process that interprets raw audit log data and extracts meaningful and relevant information without altering the original logs. An example of log reduction for files to be analyzed would be the removal of details associated with nightly backups. Report generation on reduced log information allows you to create succinct customized reports without the need to burden the reader with unimportant information. In addition, the security-relevant audit information must be made available to personnel on demand for immediate review, analysis, reporting, and event investigation support. Performing audit log reduction and providing on-demand reports may allow the analyst to take mitigating action before an adversary completes its malicious actions.

Examples¶

• You are in charge of IT operations in a company that processes CUI. You are responsible for providing audit record reduction and report generation capability. To support this function, you deploy an open-source solution that will collect and analyze data for signs of anomalies. The solution queries your central log repository to extract relevant data and provide you with a concise and comprehensive view for further analysis to identify potentially malicious activity [a]. In addition to creating on-demand data sets for analysis, you create customized reports explaining the contents of the data set [b].

Potential Assessment Considerations¶

• Does the system support on-demand audit review, analysis, and reporting requirements and after-the-fact security investigations [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.6

AU.L2-3.3.7 – Authoritative Time Source¶

Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 23-24.

Determine if:

• [a] internal system clocks are used to generate time stamps for audit records;
• [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
• [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 23-24.

Examine: [SELECT FROM: Audit and accountability policy; procedures addressing time stamp generation; system design documentation; system security plan; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms implementing time stamp generation; mechanisms implementing internal information system clock synchronization].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 19.

Internal system clocks are used to generate time stamps, which include date and time. Time is expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, for example, clocks synchronizing within hundreds of milliseconds or within tens of milliseconds. Organizations may define different time granularities for different system components. Time service can also be critical to other security capabilities such as access control and identification and authentication, depending on the nature of the mechanisms used to support those capabilities. This requirement provides uniformity of time stamps for systems with multiple system clocks and systems connected over a network.

Further Discussion¶

Each system must synchronize its time with a central time server to ensure that all systems are recording audit logs using the same time source. Reviewing audit logs from multiple systems can be a difficult task if time is not synchronized. Systems can be synchronized to a network device or directory service or configured manually.

Examples¶

• You are setting up several new computers on your company’s network, which contains CUI. You update the time settings on each machine to use the same authoritative time server on the internet [b,c]. When you review audit logs, all your machines will have synchronized time, which aids in any potential security investigations.

Potential Assessment Considerations¶

• Can the records’ time stamps map to Coordinated Universal Time (UTC), compare system clocks with authoritative Network Time Protocol (NTP) servers, and synchronize system clocks when the time difference is greater than 1 second [c]?
• Does the system synchronize internal system clocks on a defined frequency [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.7

AU.L2-3.3.8 – Audit Protection¶

Protect audit information and audit logging tools from unauthorized access, modification, and deletion.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 24.

Determine if:

• [a] audit information is protected from unauthorized access;
• [b] audit information is protected from unauthorized modification;
• [c] audit information is protected from unauthorized deletion;
• [d] audit logging tools are protected from unauthorized access;
• [e] audit logging tools are protected from unauthorized modification; and
• [f] audit logging tools are protected from unauthorized deletion.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 24.

Examine: [SELECT FROM: Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; system security plan; system design documentation; system configuration settings and associated documentation, system audit logs and records; audit logging tools; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms implementing audit information protection].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 20.

Audit information includes all information (e.g., audit records, audit log settings, and audit reports) needed to successfully audit system activity. Audit logging tools are those programs and devices used to conduct audit and logging activities. This requirement focuses on the technical protection of audit information and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by media protection and physical and environmental protection requirements.

Further Discussion¶

Audit information is a critical record of what events occurred, the source of the events, and the outcomes of the events; this information needs to be protected. The logs must be properly secured so that the information may not be modified or deleted, either intentionally or unintentionally. Only those with a legitimate need-to-know should have access to audit information, whether that information is being accessed directly from logs or from audit tools.

Examples¶

• You are in charge of IT operations in a company that handles CUI. Your responsibilities include protecting audit information and audit logging tools. You protect the information from modification or deletion by having audit log events forwarded to a central server and by restricting the local audit logs to only be viewable by the system administrators [a,b,c]. Only a small group of security professionals can view the data on the central audit server [b,c,d]. For an additional layer of protection, you back up the server daily and encrypt the backups before sending them to a cloud data repository [a,b,c].

Potential Assessment Considerations¶

• Is there a list of authorized users for audit systems and tools [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.8

AU.L2-3.3.9 – Audit Management¶

Limit management of audit logging functionality to a subset of privileged users.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 24-25.

Determine if:

• [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
• [b] management of audit logging functionality is limited to the defined subset of privileged users.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 24-25.

Examine: [SELECT FROM: Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; system security plan; system design documentation; system configuration settings and associated documentation; access authorizations; system-generated list of privileged users with access to management of audit logging functionality; access control list; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with audit and accountability responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms managing access to audit logging functionality].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 20.

Individuals with privileged access to a system and who are also the subject of an audit by that system, may affect the reliability of audit information by inhibiting audit logging activities or modifying audit records. This requirement specifies that privileged access be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges.

Further Discussion¶

Companies should restrict access to audit logging functions to a limited number of privileged users who can modify audit logs and audit settings. General users should not be granted permissions to perform audit management. All audit managers should be privileged users, but only a small subset of privileged users will be given audit management responsibilities. Functions performed by privileged users must be distinctly separate from the functions performed by users who have audit-related responsibilities to reduce the potential of fraudulent activities by privileged users not being detected or reported. When possible, individuals who manage audit logs should not have access to other privileged functions.

Examples¶

• You are responsible for the administration of select company infrastructure that contains CUI, but you are not responsible for managing audit information. You are not permitted to review audit logs, delete audit logs, or modify audit log settings [b]. Full control of audit logging functions has been given to senior system administrators [a,b]. This separation of system administration duties from audit logging management is necessary to prevent possible log file tampering.

Potential Assessment Considerations¶

• Are audit records of nonlocal accesses to privileged accounts and the execution of privileged functions protected [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.3.9