During the lessons learned review of the 2011 fly-away events, ICS CERT found that ineffective auditing and logging was one of the most consistent technical issues/obstacles encountered when responding to onsite incident visits.
Without properly configured auditing and logging practices in place, incident response teams often find it difficult to determine the significance of a cybersecurity event.
Properly configured audit logs at network, host, and application levels provide critical information for determining how an incident occurred, what the impact and scope of the issue entailed, and how best to deter future events.
The ICS-CERT has provided a collection of information resources regarding system event auditing and log management to assist vendor and asset-owner security teams to improve their current audit and logging capabilities. A list of these resources can be found at the end of this article.
Most Common Failures Associated with System Auditing and Logging
Cybersecurity teams always drive the need for robust event auditing and log management in order to support their incident response process. This is particularly true at network level events with the deployment of network intrusion detection systems (NIDS).
As the type, origin, and sophistication of attacks against computer networks has changed significantly, changes in techniques for auditing and logging for host, application, data store, user access control requires significant upgrades as well to improve network data monitoring to be able to detect advanced intrusion attempts.
Comprehensive log management and analysis policy should establish minimum security audit requirements for devices, operating systems, applications, and user access control. It should also incorporate the establishment of functional best practices and minimum requirements for auditing and logging information regarding data baseline traffic for normal and off-normal operational data traffic performance.
Such holistic approaches to event auditing and logging drive the centralization of data collection. This allows security, process control, and IT operations teams to easily isolate unusual data traffic based on aggregate analysis from one location for functional, operational, and security-impacting events.
A comprehensive log management and analysis program centralizes data collection from network devices, individual system operating systems, COTS applications like databases, and complex software environments like control system networks or proprietary application deployments. When configured and analyzed correctly, these data can assist in predicting equipment failure, equipment capacity, and failure points as well as providing security information.
Ineffective Log Management and Analysis Policies
Inconsistent application of even the best practices decreases their value. For example, using a standard COTS tool configured for default log management and analysis will not provide full range and benefit to the organization if the IT and ICS staffs do not understand each others’ operational needs to collaborate on the configuration of audit policies (functional and security) on applications and devices.
When systems and applications aren’t properly configured for auditing key events, administrative and security teams do not have effective logs to review during an event (ie important event data is not captured).
Default Audit and Logging Configurations Impede Data Gathering
Newer operating systems and applications perform more detailed configuration and event auditing options. However, the default configuration for most operating and application logs provides minimal auditing and alerting, meaning critical events don’t get recorded to the event logs. Administrators must review what information they want to see and configure systems and applications to identify and record those additional events.
Default application and operating system logging configurations typically allow historical data to be overwritten after the log file has grown to a certain percentage of drive space. Without review and file management, these files will grow without bound. Scripts designed to export logs routinely from the systems to a central log management server can prevent critical information from being overwritten. In addition, current log management tools can automate log review from multiple systems, which represents a huge improvement over earlier automatic or manual log review systems.
Auditing and Log Management Practices Inhibits Effective Implementation
IT and control system administrators no longer have to manage logs using unwieldy or homegrown, unchecked management scripts and rudimentary reporting templates. New log management and analysis tools have a wide range of features to ease the pain of event logging and incident detection. They can integrate multiple log formats from widely distributed sources and most provide support for automating log collection if it isn’t being done already. Event logs from most devices and applications— even legacy systems-can be collected remotely and automatically.
The updated analysis engines available in the log management tools also speed data processing and formatting, making it cheaper and easier to review the functional, operational, and security data. In addition, today’s log management systems provide an unprecedented level of ability to select necessary events as required for compliance reporting, root cause failure analysis, and incident detection.
Event Auditing and Log Management Resources
ICS-CERT has identified a short list of resources for improving event auditing and log management. This resource list is a starting point for learning about log management and is not intended to be comprehensive.
Policies and Recommended Practices
• “Guide to Computer Security Log Management,” NIST
• “Information System Audit Logging Requirements,” SANS
• “Log Review and Management,” OWASP
• “A Practical Application of SIM/SEM/SIEM Automating Threat Identification,” SANS
• Security audit policy template, SANS
Security Policy for Operating Systems
• “Advanced Security Audit Policy Step-by-Step Guide,” Microsoft
• “Implementing SCADA Security Policies via Security- Enhanced Linux,” Ryan Bradetich and Paul Oman