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????
AU-1: Audit And Accountability Policy And Procedures
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 that 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.
[???pic of log storage and overflow include oldest writeover???]
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. 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
[[??centralized???]
AU-5: Response To Audit Processing Failures
Logging systems are intricate, and various components can fail in numerous ways. The sub-controls 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 it can't log, the system shouldn't function. Consequently, the system is either shut down or partially shut down (AU-5(4): Shutdown On Failure).
[[??pic of autit process failure???]
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. 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.
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. 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
Logs are too much to handle. Queries take forvere. This control nessuicates that the system has a way to filter logs for conumsption. Most commonly this is done my beserahcin date/time ranges. This can also be done by narrowing the search down to certain log type s(ie., indexes) or certain values.
Events of interest could be IP addresses usernames in the log data. This control specifies being able to filter on those values.
AU-7(1): Automatic Processing
Replacves by AU-7(1): Automatic Processing.
AU-7(2): Automatic Sort And Search
AU-8: Time Stamps
Timing is huge in logging. Nithing stuks more than trying to analyze logs usinga timeline and the log times are not synchronized. There is always confusion about timezones. Set the times to UTC. Time should be automatically synchronized to a cenralized timing sources because local tim,e sources often drift.
Suncryboise with centrail timing source. Some overalp here so replaced with SC-45(1): Synchronization with Authoritative Time Source.
AU-8(1): Synchronization With Authoritative Time Source
Bacup timing. Also replaced with SC-45(1): Synchronization with Authoritative Time Source.
AU-8(2): Secondary Authoritative Time Source
AU-9: Protection Of Audit Information
dd
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