Part 3 of CampusGuard’s series covering each of the critical controls from NIST SP 800-171 rev.1
The third family of controls within the NIST SP 800-171, Audit and Accountability, is critical in both the prevention and detection of data breaches. Comprehensive and accurate system logging can significantly reduce the impact of a potential breach. Let’s first look at the two Basic Security Requirements.
Requirement 3.3.1 states that organizations should “Create, protect, and retain system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate system activity.”
If a malicious individual were to gain access to a user account or create a new, unauthorized account with access to sensitive information, up to date and accurate log files can provide you with a record of which accounts may have been compromised and when each was impacted. If something does go wrong, having a historical account of all people and activities associated with the network will allow you to know who was logged into or using a system at any given time, what they did on the system, and whether they accessed the system in person or remotely.
Requirement 3.3.2 requires that “…the actions of individual system users be able to be uniquely traced to those users so they can be accountable for their actions.” In other words, you must never allow group, shared, or generic IDs or passwords, as this will make it impossible to trace system access and activities back to an individual. Administrator accounts have a greater potential to impact the security or functionality of a system. By logging the activities of these accounts, organizations can trace issues back to a specific individual and determine if it was an administrative mistake or misuse of privileges.
The Derived Security Requirements (3.3.3 through 3.3.9) provide more detail on how your logging mechanisms should be configured, but the first step is to identify and inventory all systems that are accessing or storing confidential information, accepting network connections, or controlling access rights. All of these systems should have some form of logging enabled. Most systems will have logging capabilities, but they might not be automatically enabled, so verify all systems have the logs turned on. You will then need to decide when to generate the logs for each system and what data elements to include.
First, make sure all systems have the correct and consistent time configured (3.3.7). If the time is not accurate, it will be impossible for the forensics team to compare log files from different systems or reconstruct an exact sequence of events. Use time synchronization technology, like Network Time Protocol (NTP), to ensure all critical systems and applications are accessing and documenting accurate timestamps. You should also make sure that access to the time data is restricted, and any changes to the time settings are logged, monitored, and reviewed.
The next step is to determine how often the logs should be reviewed and analyzed (3.3.3). Many organizations have implemented system logging with storage, but only look at the log reports after an event that requires attention has occurred, such as a data breach or a network issue. While it is good that the organizations are documenting system activity and have that information available to them; from a security perspective, logs should be utilized as more of a prevention tool and configured to alert staff of potentially suspicious activities to be investigated before too much damage is done.
It is important to review the following at least daily:
- All security events
- Logs of all system components that store, process, or transmit sensitive data
- Logs of all critical system components
- Logs of all servers and system components that perform security functions, like firewalls, intrusion detection systems, authentication servers, e-commerce re-direction servers, etc.
The challenge for many organizations is that finding specific information and pertinent warnings in log files can be a daunting task. The timeframe for reviewing logs of system components should be determined during your annual risk assessment.
Configuring applicable rules for alert generation is very important. Use file integrity monitoring, or other change detection software to identify attempts to make changes to logs or other key files, and trigger an immediate alert to the appropriate IT personnel if an anomaly is detected. You should also be alerted if an audit logging process fails (3.3.4). Other scenarios that should be considered when creating alerts include:
- Repeated, failed login attempts (exceeding a predetermined number)
- Changes to access or permissions
- Changes to critical system components or sensitive networking files
- Starting or stopping of applications, logging, other critical processes
- Large data transfer activities (upload or download)
Work with your IT team to execute a review and reporting process that requires logs to be viewed regularly and automatically delivers scheduled reports to those assigned individuals that need to see them. Document the plan for reviewing the alerts in your organizational procedures. Maintain alert levels that determine what logs require immediate attention, and which are lower priority so can be handled later, but within a defined time period.
Audit trails should be regularly reviewed, both during real-time operations and after any type of security incident or data breach has taken place. Without regular review of audit logs, unauthorized activity can go undetected for extended periods of time. According to the 2018 Verizon Data Breach Report, 68% of data breaches took months or longer to discover, but it took attackers only minutes to successfully compromise systems. Detecting intrusions at the earliest possible moment allows you to immediately respond and limit the data loss. In 2017, Memorial Healthcare Systems (MHS) in Florida agreed to a $5.5 million Office for Civil Rights (OCR) settlement. The OCR stated that a lack of audit controls was a major factor in the determined settlement. MHS failed to implement procedures to regularly review records of information system activity. In their cyber newsletter following, the OCR urged organizations to properly safeguard audit logs and audit trails to prevent hackers and malicious insiders from creating a potential data breach. If organizations regularly review system logs they can proactively identify and address unauthorized access, and more accurately and quickly pinpoint system compromises. Verify that if unauthorized or suspicious activity is identified, all teams understand the proper investigation and response procedures (3.3.5).
Collect logs from all systems and send the log files to a central log server for analysis. Only administrators should have access to view, modify, or delete these logs (3.3.9), and all administrator activities should be logged and protected (3.3.8). Should the need arise, this audit trail must include enough detail to enable the forensics team to reconstruct events. Typical activities that should be tracked include:
- Logon/logoff activity, including failed login attempts
- All actions taken by any individual with root or administrative privileges
- Use of and changes to identification and authentication methods
- All access to sensitive data
- System changes
- Creation or deletion of system-level objects, such as database tables or stored procedures
- Logging start/stop requests
Some other event types you may want to consider including are:
- Password changes
- First-time logins with new accounts
- Irregular scans on your firewalls’ open and closed ports
- Errors on network devices
- File name changes
- Data being exported from the system
- New applications launching or running; processes stopping or failing
- New service installations or system changes, including installation of patches and updates
In short, you are looking to identify any abnormal activity. You can determine what that is for your organization by looking at the regular patterns of access around files with sensitive data. The same user accounts will typically access the same files, with the same frequency, during the same days and times, from the same systems – so anything outside of this should be considered potential areas of concern. PCI DSS Requirement 10 outlines the requirements for logging system activities within your cardholder data environment. Using a combination of the requirements from the PCI DSS and the Derived Requirements from the NIST SP 800-171 should help your organization determine appropriate logging to protect your organization’s data.
Some additional guidance from our Security Advisor Team below:
[Burt]: Whether it’s for compliance with PCI DSS, HIPAA, or GLBA, or just the need to implement general Information Security best practices, auditing (i.e. logging) is potentially the most critical piece of the puzzle. From day to day monitoring of events, to identifying potential malicious activity, to the need for forensic investigations, an organization should have a robust auditing/logging environment in place.
With all the different types of logs and the need to review critical events in near real time, the most common way to accomplish the monitoring/correlating/storage needs is to implement a Security Information and Event (SIEM) solution. Although not an inexpensive part of Information Security to say the least, this may be arguably the most important. One of the best strategies is to implement an overall solution that can meet the different organizational and regulatory requirements, and then create a project plan to implement in stages. Keep in mind that auditing/logging can be very labor intensive in the beginning, and sometimes requires a dedicated resource to maintain. Feel free to talk with your Security Advisor about different strategies as they deal with all different sizes of organizations.
