Log Management for Regulatory Compliance

Compliance can start with monitoring your network traffic

Starting a Log Management Program
How should someone start addressing log management? A search on the internet will lead you to many vendor-specific solutions; however, it is better to address these issues from a “vendor neutral” perspective. Security is a dynamic process, and understanding the issues and specifically how they apply to your own organization is a more effective way to start. One excellent publication is the “Guide to Computer Security Log Management: Recommendations of the National Institute of Standards and Technology.” This document provides four recommendations for initiating a log management solution:

• Prioritize log management appropriately throughout an organization;
• Establish policies and procedures for log management;
• Create and maintain a secure log management infrastructure; and
• Provide proper training for all staff with log management responsibilities.

While these could be applied to any security initiative, one of the items is frequently overlooked: All security-related logs need to be kept secure. If logs are going to be used in investigations or litigation, the log owners must verify they have not been modified.
This can be done in several ways. First, access to the logs needs to be severely restricted to those individuals responsible for log management. If logs are transmitted across the network, they need to be protected using a secure protocol. The integrity of the logs should be verified using some form of integrity check. Another option is to store the logs on a “read only” device such as a CD, DVD or WORM (Write Once Read Many) drive.

Review the Regulations
You should actually read the appropriate regulations that apply to your industry. It also makes sense to review other guidelines and regulations — as they may provide additional insight into your particular issues.
One document worth reviewing is the PCI DSS. I have included “Requirement 10” which addresses log management.
For those who do not process credit card data, simply substitute either proprietary data, financial records or health care information for “cardholder data.”
The full text of this requirement is provided below because it covers some of the same areas as other guidelines and is a good starting point on a log management program.
Requirement 10: Track and monitor all access to network resources and cardholder data.
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis if something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
10.2 Implement automated audit trails for all system components to reconstruct the following events:
• All individual user accesses to cardholder data
• All actions taken by any individual with root or administrative privileges
• Access to all audit trails
• Invalid logical access attempts
• Use of identification and authentication mechanisms
• Initialization of the audit logs
• Creation and deletion of system-level objects.
10.3 Record at least the following audit trail entries for all system components for each event:
• User identification
• Type of event
• Date and time
• Success or failure indication
• Origination of event
• Identity or name of affected data, system component, or resource.
10.4 Synchronize all critical system clocks and times.
10.5 Secure audit trails so they cannot be altered.
• Limit viewing of audit trails to those with a job-related need
• Protect audit trail files from unauthorized modifications
• Promptly back-up audit trail files to a centralized log server or media that is difficult to alter
• Copy logs for wireless networks onto a log server on the internal LAN.
• Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (new data being added should not cause an alert).
10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.
10.7 Retain audit trail history for at least one year, with a minimum of three months online availability.
Other regulations and guidelines are not as specific. As an example, some require audit trail history be maintained for an “adequate time period.” Stating that logs of all system components must by reviewed daily sounds exceptionally burdensome in the beginning; but the fact that it allows for the use of automated tools to meet that requirement makes it realistic. Products like Cisco Security Monitoring, Analysis and Response System (MARS) and GFI EventsManager consolidate logs into one location, provide alerting capabilities and assist with log entry interpretation.
While there are numerous commercial tools available, there are also free tools, including Microsoft’s Log Parser (http://tinyurl.com/5uoxz), Project Lasso (http://sourceforge.net/projects/lassolog), logcheck, (http://logcheck.org) and Swatch (http://swatch.sourceforge.net/).
Log management is a complex process and requires implementation of appropriate policies and procedures, dedicated resources, management support and properly trained personnel. But with the vast amount of proprietary data being hosted on networks, the increased technical sophistication of attackers and regulatory requirements, it is a significant part of any network security program. However, as with almost any security implementation, the initial cost will often outweigh the expense of responding to an attack or breach of security.