NIST 800-53 logging controls are primarily categorized within the AU (Audit and Accountability) control family. Within AU, there are multiple controls specifically addressing audit and logging. A closer examination reveals the authors' deep understanding of audit logging. They explicitly detail processes and procedures crucial for establishing a robust auditing program— aspects often overlooked by many organizations when configuring their cybersecurity logging systems. The auditing controls are:
AU-1: Audit And Accountability Policy And Procedures
AU-2: Audit Events
AU-3: Content Of Audit Records
AU-4: Audit Storage Capacity
AU-5: Response To Audit Processing Failures
AU-6: Audit Review, Analysis, And Reporting
AU-7: Audit Reduction And Report Generation
AU-8: Time Stamps
AU-9: Protection Of Audit Information
AU-10: Non-Repudiation
AU-11: Audit Record Retention
AU-12: Audit Generation
AU-13: Monitoring For Information Disclosure
AU-14: Session Audit
AU-15: Alternate Audit Capability
AU-16: Cross-Organizational Auditing
It's crucial to understand that simply labeling a system as "Security Information & Event Management (SIEM)" doesn't automatically ensure the fulfillment of the audit controls listed. While SIEMs satisfy some of these controls, the comprehensive management of logging systems and the application of all controls require a level of complexity that surpasses what an out-of-the-box SIEM can offer.
???info graphic????
CMMC AU.L2-3.3.1 System Auditing
AU-1: Audit And Accountability Policy And Procedures
a. Audit audit logs to support monitoring, investigations, and reporting are specified
b. The content of audit records needed to support monitoring, investigations , and reporting are defined
c. Audit logs are generated
d. Audit logs once created, contain defined content
e. Retention requirements for audit logs are defined
f. Audit log records are retained as defined
This control requires the establishment of auditing policies and procedures that are distributed to all relevant personnel and that they should be regularly reviewed and updated.
AU-2: Audit Events
This control aims to ensure that the organization identifies a comprehensive list of auditable events (such as logons, privilege escalation, etc.). The selection of auditable events is a coordinated effort involving multiple groups. This coordination ensures that the teams responsible for monitoring and investigations comprehend the available log data, specify the required log data for their tasks, and that system owners understand the settings needed on the systems they manage to generate the required log data. Furthermore, the rationale behind why the selected audited events are considered sufficient for investigations is also documented.
AU-3: Content Of Audit Records
Auditing events and generating logs is one aspect, but the logs must contain essential details to establish basic facts such as the type, timing, location, source, outcome, and the identity of systems and users involved in the event. Without this pertinent information, the log lacks utility. This control mandates that the 'content' of the log must include this crucial information.
AU-4: Audit Storage Capacity
The lesson from this control is, someone may attempt to find a log for an investigation only to discover it's no longer available due to insufficient storage. This doesn't necessarily mean keeping and storing every piece of data, as some log vendors might suggest. Instead, it emphasizes the importance of defining what is practical or required for your specific context.
Systems can generate a substantial amount of log data that accumulates rapidly. Audit log data is typically stored in two locations: on a local file on the system where the audit log originates and on a remote log storage system. As log storage space diminishes, older logs are overwritten by new ones. Local systems, not designed for extensive log storage, have varying levels of local log storage capacity.
To extend log storage duration and facilitate centralized correlation and management, it is essential to employ centralized logging storage systems. This is where the control enhancement, AU-4(1): Transfer To Alternate Storage, becomes crucial. It involves moving logs from the audited system to a separate system, typically a centralized log store. The process of transferring logs to centralized storage is commonly known as 'Log Shipping.' This is usually achieved using a logging agent, referred to as a 'Log Shipper,' or through a network-based 'Log Shipping' capability, such as remote syslog. However, these centralized log storage systems can also face capacity limitations, requiring sufficient storage to accommodate the organizationally defined audited events for the specified time period.
It's also important to note that just because a log isn't in a centralized Security Information and Event Management (SIEM) system, it does not doom an investigation. In many cases, log data related to the incident can still exist on the local systems, especially if there is not a lengthy time lapse between the incident and the investigation. Additionally, investigators will often still have to pivot to the system during the investigation, because the system only contains granular artifacts, including some less common logs that are impractical to always collect from every system.
CMMC AU.L2-3.3.4 Audit Failure Alert
a. personalor or roles to be alerted of n audit logging process failure
b. types of audit process
c. identified perosnal are alerted
AU-5: Response To Audit Processing Failures
Logging systems are intricate, and various components can fail in numerous ways. The sub-control enhancements outlined here are equally logical. It's crucial to monitor log storage capacity (AU-5(1): Audit Storage Capacity). In case of issues with log processing, real-time alerts (AU-5(2): Real-Time Alerts) ensure that the relevant person is promptly notified and can take appropriate action. Some systems, like those handling network traffic logs, can generate an overwhelming volume of logs, potentially overwhelming the logging function. This control (AU-5(3): Configurable Traffic Volume Thresholds) aims to guarantee that your logging system can regulate high-volume logs and avoid being flooded to the point of losing log processing functionality.
Finally, there's a less commonly implemented sub-control that introduces a level of controversy. It essentially suggests that the logging component of the system is so crucial that if the system can't log, it shouldn't function. Consequently, the system is either shut down or partially shut down (AU-5(4): Shutdown On Failure).
CMMC AU.L2-3.3.3 Event Review
a. The org define sone or more policies and/or procedures for event log review and analysis
b. The org defned olices and procedures got review and info
c. The or reviews logs for indicatios of org defined occurrence of
AU-6: Audit Review, Analysis, And Reporting
Simply logging data is one thing, but the ability to access, query, and utilize that data is equally crucial. Organizations need to consider whether they have automated processes for integrating log analysis into investigations, as outlined in AU-6(1): Process Integration.
Given that organizations have multiple systems with their own backend storage, logging data often resides in different locations. AU-6(3): Correlate Audit Repositories ensures that searches can span across all repositories where log data is stored.
Additionally, AU-6(4): Central Review And Analysis addresses the challenge of siloed organizational structures, ensuring that the right people have access to the logs they need for investigations.
A high-fidelity cybersecurity alert is the integration of vulnerability data with the logging system (AU-6(5): Integration / Scanning And Monitoring Capabilities). This integration results in an exceptionally strong alert, signaling when a log indicates a system is under a specific type of attack, and that the system is vulnerable to that specific attack. Achieving this level of alert precision necessitates the integration of vulnerability data with the logging system.
Furthermore, AU-6(6): Correlation With Physical Monitoring emphasizes the power of correlating physical monitoring log activity with logical log activity for comprehensive system monitoring and detection. This allows physical systems such Access Control badging systems, that place people in locations, to be correlated with computer system activities from those locations.
Access control to the centralized logs is critical, and AU-6(7): Permitted Actions ensures that personnel using the logs have Role-Based Access Control (RBAC) defined rights based on the principle of 'least privilege.' For example, a SOC analyst should not be allowed to delete logs.
Monitoring privileged commands is a significant aspect of cybersecurity, and AU-6(8): Full Text Analysis Of Privileged Commands highlights the importance of scrutinizing privileged commands with tools like sysmon in Windows and sudo in Linux.
???picture here???
AU-6(9): Correlation With Information From Nontechnical Sources stresses the need to incorporate non-technical information, such as data from Human Resources, into logging processes. Examples could be employees on Performance-Improvement-Plans (PIP) or who have other instabilities that necessitate an increased level of monitoring.
Finally, AU-6(10): Audit Level Adjustment addresses the flexibility of altering logging levels based on specific threats, providing a cost-effective approach to managing logging system expenses.
AU-7: Audit Reduction And Report Generation
Just having stored logs doesn't guarantee easy searchability and retrievability. According to AU-7(1): Automatic Processing, logs must undergo normalization during processing into the logging system. This normalization ensures that log data, including attributes like Date/Time of the event, IP address, username, etc., is retrievable. Typically achieved by ingesting logs into an index, this construct allows for consistent normalization, facilitating effective search and retrieval, along with managing the storage lifecycle of the log.
???pic???
AU-8: Time Stamps
Timing plays a crucial role in logging; it is critical logs have accurate timestamps with the occurrence time of the events they represent. The challenge arises when attempting to reconstruct a timeline from logs with unsynchronized timestamps across different systems. Addressing this issue is straightforward—establish a centralized decision and policy on system timing, mandating administrators to set their system clocks uniformly. Opting for 'Coordinated Universal Time' (UTC) as the standard time zone simplifies matters. Furthermore, automatic synchronization with centralized timing sources is essential to manage time synchronization across many systems, and counter local clock drift. This automatic time synchronization is mandated with control enhancements AU-8(1) and AU-8(2) in the 'Audit and Accountability' family. However, these controls also have overlap with controls in the 'System and Communications' family, specifically SC-45(1): Synchronization with Authoritative Time Source.
???pic???
oroiginal event time, log shipper time, siem log recipt time,
AU-9: Protection Of Audit Information
This control mandates that audit logs be protected from unauthorized access, modification, or deletion. Several AU-9 enhancements are in place to ensure that this doesn't happen. AU-9(1): Hardware Write-Once Media is implemented so that the storage for log data is not overwritten. This was more commonly an issue when data was being backed up to tape and DVD-like systems. The system that created the audit event typically has the audit data. AU-9(2): Audit Backup On Separate Physical Systems / Components is fairly straightforward; it mandates that the audit log data be stored on a separate system. This is done when logs are sent to a centralized logging system like a SIEM. AU-9(3): Cryptographic Protection specifies the protection of audit log data using cryptography. AU-9(4): Access By Subset Of Privileged Users is crucial for a robust cybersecurity program. System administrators, whose actions should be highly audited ('subject of system audit'), also have the ability to impact audit functions (e.g., turn them on and off). To prevent this from happening, this control mandates that auditing be a separately defined administrative function. AU-9(5): Dual Authorization specifies that dual authorization is required for log data modifications and deletions. Finally, AU-9(6): Read-Only Access specifies read-only access to audit logs for normal users, which helps prevent abuse, mistakes, etc.
???pic???
AU-10: Non-Repudiation
Log data asserts that an event occurred at a specific time, as described by the log event message/data and time. This log data can then serve as proof of nefarious activities, with resulting outcomes that may have legal (civil/criminal) and job performance impacts. It is crucial for logging processes to have non-repudiation, which helps prevent claims from individuals under investigation that they did not create, send, receive, or sign specific activities/actions/documents. In this area you will often also hear the term 'Immutability'; meaning something is unable to be changed after its creation.
????pic?????
CMMC AU.L2-3.3.2 User Accountability
a. The content of the audit records can uniquely trace users to define dactions
b. Audit records, once created contain defined content
AU-10(1): Association Of Identities specifies that the identity of the person producing the activity/action/document is bound to the audit log for that activity/action/document, and the identity can be retrieved by a reviewer of the audit log. This association is commonly seen in many log types like authentication events but doesn't occur in other log types that only report the system as the generator of the activity/action. In these cases, forensic investigators commonly look to other sources of evidence to prove a person was the only one logged into the system and could perform the activity/action at that time.
AU-10(2): Validate Binding Of Information Producer Identity specifies that identities be validated at defined organizational frequencies. This validation is commonly seen when IP addresses are used to define the identity of a system, and changes to system IP addresses can invalidate a documented IP address to system identification.
AU-10(3): Chain Of Custody deals with the reviewers of information throughout its investigation life cycle, ensuring that the date/time of information collection and reviews are documented, as well as the handling of the information.
AU-10(4): Validate Binding Of Information Reviewer Identity aims to ensure that the identity of reviewers/investigators is also bound at 'transfer/release' points.
AU-11: Audit Record Retention
While AU-4(1): Transfer To Alternate Storage mandates the relocation of logs to alternate storage, AU-5: Response To Audit Processing Failures oversees all facets of log processing, ensuring the capability to meet log retention requirements. AU-11: Audit Record Retention focuses on understanding, documenting, and fulfilling both regulatory and organizational information retention requirements essential for post-incident security investigations. Storing logs for the mandated time period is one aspect; however, the ability to effectively search them during that period is another. This aspect is specifically addressed in the enhancement AU-11(1): Long-Term Retrieval Capability.
???pic, renetion mandates by requirement?????
AU-12: Audit Generation
Determining the appropriate audit settings, as mandated in AU-2: Audit Events, is one aspect. Another critical aspect involves configuring these audit settings and ensuring their successful transmission to a centralized logging system. AU-12: Audit Generation specifies that the audit settings selected in AU-2: Audit Events must not only be configured to generate logs but also to ensure the logs are successfully shipped. Additionally, the individuals authorized to make these settings must be defined and have the ability on the system to configure the audit setting's.
?????selecting and setting auditing settings?????
Additional enhancements to this control involve ensuring the centralized logging system is time-correlated, as outlined in AU-12(1): System-Wide / Time-Correlated Audit Trail. Another crucial aspect is confirming that logs are normalized, addressed in AU-12(2): Standardized Formats. Achieving standardized formats is commonly done through log parsing and indexing processes.
???pic???
It's important to acknowledge that enabling all audit settings continuously is impractical due to the system resources required. However, there is an expectation that your logging program possesses the capability to adjust logging settings in response to specific threats and requirements, as outlined in AU-12(3): Changes By Authorized Individual.
???pic???
Finally, the enhancement AU-12(4): Query Parameter Audits of Personally Identifiable Information is in place to ensure that the organization controls the access, usage, and sharing of any Personally Identifiable Information (PII) that may be present in the logs being stored, used, and analyzed.
????pic???
AU-13: Monitoring For Information Disclosure
If someone steals log data containing valuable information, they often dump, sell, or post it on external data source locations. This control outlines the importance of monitoring these external sites to detect any such unauthorized disclosure of information. Typically, Cyber Threat Intelligence (CTI) tools are employed for this purpose, utilizing a function known as 'watch lists.' In simple terms, a watch list involves the organization establishing key terms and relevant data. Automated tools are then employed to search selected sites for dumps and unauthorized releases of information listed on the watch lists. It's crucial to recognize that unauthorized information releases can frequently result from organizational mistakes rather than just hacking into the organization's data.
Under this control, AU-13(1): Use Of Automated Tools emphasizes the use of automated tools for analysis, while AU-13(2): Review Of Monitored Sites specifies the continuous review and updating of the list of sites monitored for dumps and unauthorized information release to ensure relevance. Additionally, there's a related aspect where hackers may mirror an organization's sites and information to impersonate them for potential attacks. Detection of such unauthorized replication is addressed in the enhancement AU-13(3): Unauthorized Replication of Information.
AU-14: Session Audit
This capability involves monitoring a user session for recording and/or viewing, presenting a valuable feature. Often, its implementation is necessary to gain precise insights into someone's actions or clicks, extending beyond the realm of cybersecurity. This feature significantly impacts monitoring shared systems, such as engineering workstations and 3rd-party jump hosts managing critical organizational systems. Tools like ObserveIT and Beyond Trust offer such capabilities.
When conducting full system recording, considerations arise involving human resources and potential legal sensitivities. Therefore, coordination with HR and legal teams is essential. However, it's crucial not to overthink it. If the system undergoing session recording belongs to the organization, and users are not supposed to engage in personal activities on the system, recording sessions should not pose an issue.
????pic????
Enhancements dictate that the session recording feature initiates automatically when the system starts, as outlined in AU-14(1): System Start-Up.
???pic???
Moreover, there is a desire to guarantee that the system possesses the capability to conduct session monitoring remotely, as specified in AU-14(3): Remote Viewing / Listening.
???pic???
AU-15: Alternate Audit Capability
Backup logging Supsercded by AU-5: Response To Audit Processing Failures because this is duplication of coevrage
AU-16: Cross-Organizational Auditing
Audit logs ma be located in different places and syste/user activity that creates logs may cross those boudnarioes so that the complete picture of usre/system activity exists in logs across different organizational boundary. This control nessicates that identity information can be preserved across the organizational log repos. For example, computer system A in logging repo 1 can be traced to system AB in logging repo 2. It also necessitates cross functional sharing of log information so organizational units can do a complete investigation.
AU-16(1): Identity Preservation
AU-16(2): Sharing Of Audit Information
CMMC Mapping
AU.L2-3.3.1 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.
AU.L2-3.3.2 Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
AU.L2-3.3.3 Review and update logged events.
AU.L2-3.3.4 Alert in the event of an audit logging process failure.
AU.L2-3.3.5 Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
AU.L2-3.3.6 Provide audit record reduction and report generation to support on-demand analysis and reporting.
AU.L2-3.3.7 Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
AU.L2-3.3.8 Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
AU.L2-3.3.9 Limit management of audit logging functionality to a subset of privileged users.
Comments