Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs

How do attackers exploit the lack of this control?

Deficiencies in security logging and analysis allow attackers to hide their location, malicious software used for remote control, and activities on victim machines. Even if the victims know that their systems were compromised, without protected and complete logging records, the victim is blind to the details of the attack and to the subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.

Sometimes logging records are the only evidence of a successful attack. Many organizations keep audit records for compliance purposes but attackers rely on the fact that such organizations rarely look at the audit logs so they do not know that their systems have been compromised. Because of poor or non-existent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.

How can this control be implemented, automated, and its effectiveness measured?

1. QW: Validate audit log settings for each hardware device and the software installed on it, ensuring that logs include a date, timestamp, source addresses, destination addresses, and various other useful elements of each packet and/or transaction. Systems should record logs in a standardized format such as syslog entries or those outlined by the Common Event Expression (CEE) initiative. If systems cannot generate logs in a standardized format, deploy log normalization tools to convert logs into a standardized format.
2. QW: Ensure that all systems that store logs have adequate storage space for the logs generated on a regular basis, so that log files will not fill up between log rotation intervals.
3. QW: System administrators and security personnel should devise profiles of common events from given systems, so that they can tune detection to focus on unusual activity, avoid false positives, more rapidly identify anomalies, and prevent overwhelming analysts with insignificant alerts.
4. QW: All remote access to an internal network, whether through VPN, dial-up, or other mechanism, should be logged verbosely.
5. QW: Operating systems should be configured to log access control events associated with a user attempting to access a resource (e.g., a file or directory) without the appropriate permissions.
6. QW: Security personnel and/or system administrators should run bi-weekly reports that identify anomalies in logs. They should then actively review the anomalies, documenting their findings.
7. Vis/Attrib: Each agency network should include at least two synchronized time sources, from which all servers and network equipment retrieve time information on a regular basis, so that timestamps in logs are consistent.
8. Vis/Attrib: Network boundary devices, including firewalls, network-based IPSs, and inbound and outbound proxies should be configured to log verbosely all traffic (both allowed and blocked) arriving at the device.
9. Vis/Attrib: For all servers, organizations should ensure logs are written to write-only devices or to dedicated logging servers running on separate machines from hosts generating the event logs, lowering the chance that an attacker can manipulate logs stored locally on compromised machines
10. Config/Hygiene: Organizations should periodically test the audit analysis process by creating controlled, benign events in logs and monitoring devices and measuring the amount of time that passes before the events are discovered and action is taken. Ensure that a trusted person is in place to coordinate activities between the incident response team and the personnel conducting such tests
11. Advanced: Organizations should deploy a Security Event/Information Management (SEIM) system tool for log aggregation and consolidation from multiple machines and for log correlation and analysis. Deploy and monitor standard government scripts for analysis of the logs, as well as using customized local scripts. Furthermore, event logs should be correlated with information from vulnerability scans to fulfill two goals. First, personnel should verify that the activity of the regular vulnerability scanning tools themselves is logged. And, secondly, personnel should be able to correlate attack detection events with earlier vulnerability scanning results to determine whether the given exploit was used against a known-vulnerable target.

Associated NIST SP 800-53 Rev 3 Priority 1 Controls:

AC-17 (1), AC-19, AU-2 (4), AU-3 (1,2), AU-4, AU-5, AU-6 (a, 1, 5), AU-8, AU-9 (1, 2), AU-12 (2), SI-4 (8)

Procedures and tools for implementing this control:

Most free and commercial operating systems, network services, and firewall technologies offer logging capabilities. Such logging should be activated, with logs sent to centralized logging servers. Firewalls, proxies, and remote access systems (VPN, dial-up, etc.) should all be configured for verbose logging, storing all the information available for logging should a follow-up investigation be required. Furthermore, operating systems, especially those of servers, should be configured to create access control logs when a user attempts to access resources without the appropriate privileges. To evaluate whether such logging is in place, an organization should periodically scan through its logs and compare them with the asset inventory assembled as part of Critical Control 1, to ensure that each managed item actively connected to the network is periodically generating logs.

Analytical programs for reviewing logs can be useful, but the capabilities employed to analyze audit logs is quite wide-ranging, including just a cursory examination by a human. Actual correlation tools can make audit logs far more useful for subsequent manual inspection by people. Such tools can be quite helpful in identifying subtle attacks. However, these tools are neither a panacea nor a replacement for skilled information security personnel and system administrators. Even with automated log analysis tools, human expertise and intuition are often required to identify and understand attacks.

List Of Controls

• Critical Control 1: Inventory of Authorized and Unauthorized Devices
• Critical Control 2: Inventory of Authorized and Unauthorized Software
• Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers
• Critical Control 4: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
• Critical Control 5: Boundary Defense
• Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs
• Critical Control 7: Application Software Security
• Critical Control 8: Controlled Use of Administrative Privileges
• Critical Control 9: Controlled Access Based on Need to Know
• Critical Control 10: Continuous Vulnerability Assessment and Remediation
• Critical Control 11: Account Monitoring and Control
• Critical Control 12: Malware Defenses
• Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services
• Critical Control 14: Wireless Device Control
• Critical Control 15: Data Loss Prevention

Additional Security Controls

The following sections identify additional controls that are important but that cannot be automatically or continuously monitored.

• Critical Control 16: Secure Network Engineering
• Critical Control 17: Penetration Tests and Red Team Exercises
• Critical Control 18: Incident Response Capability
• Critical Control 19: Data Recovery Capability
• Critical Control 20: Security Skills Assessment and Appropriate Training to Fill Gaps