Businesses have finally identified the need for strong security mechanisms to protect their technical infrastructure, proprietary data and confidential client information.
Most businesses have implemented a layered approach to security that can include many of the following security mechanisms: User authentication, intrusion detection and prevention devices, antimalware software, file rights management and backup and archiving mechanisms. Often there is a large capital investment in these security mechanisms and there is a misconception that the hardware and software will simply just “do their jobs” and keep the network and assorted digital assets protected.
It is important to recognize that these devices can and will malfunction periodically. Or they can be compromised by a technically sophisticated attacker. While I do not mean to imply that these mechanisms are faulty and worthless, they should not be relied on as “set it and forget it” solutions.
Fortunately all security devices provide the ability to log their activities, which theoretically makes monitoring their effectiveness a simple process of reviewing the logs. As with anything associated with computers, nothing is ever as easy as it sounds. For a non-technical business professional, it is difficult to understand the volume of activity that occurs on an individual computer, let alone a corporate network. A simple demonstration that highlights the activity on a computer is simply to take your hands off the keyboard and watch the hard drive light. Those lights flash constantly, indicating activity.
A Complex Task
To get a more technical perspective of what is happening on a computer, download and run Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926). Within seconds of starting, Process Monitor will capture thousands of events occurring on your computer. To get a glimpse of what is happening on the network, one can run a network packet capturing program like tcpdump (http://sourceforge.net/projects/tcpdump/) or windump (http://www.winpcap.org/windump/).
Once again, the amount of activity is astounding. Now imagine the volume of activity and network traffic occurring on a large corporate network. The amount of activity is nearly incomprehensible. Unfortunately, the issues surrounding logging of activities does not stop with the vast amount of information that can be captured — interpreting the logs and the significance of their contents can provide challenges as well. One only has to look at the events captured on your desktop system to understand these challenges. By opening event viewer (Windows XP Pro: click on Start, Settings, Control Panel, Administrative Tools, Event Viewer) you can start to grasp the fact that interpreting log information requires specialized training and expertise.
On my system, the Application log provides the following informational message:
“Performance counters for the WmiApRpl (WmiApRpl) service were removed successfully. The Record Data contains the new values of the system Last Counter and Last Help registry entries.” This is meaningless, so I use the Help and Support Center link for additional information. I am presented with the following:
“Performance counters for the %1!s! (%2!s!) service were removed successfully.” While on the surface this appears amusing, when combined with the numerous devices on a network and the volume of activity generated, this becomes truly frightening.
Regardless of the complexity of capturing, monitoring, and archiving network and system activities, it is a reality faced by businesses today. In addition to being a smart business decision to review log files to determine the security and health of a network, it is now being suggested and even required by a variety of regulations, including the Federal Information Management Act (FISMA), Gramm Leach Bliley Act (GLBA), Health Insurance Portability and Accountability Act (HIPAA), Sarbanes Oxley Act (SOX) and the Payment Card Industry Data Security Standard (PCI DSS). For many, these regulations seem nothing more than a drain on resources. But if strictly followed, there is less risk of business interruptions, incidents can be mitigated much more efficiently with less exposure to lawsuits.
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.
John Mallery is a managing consultant for BKD, LLP, one of the ten largest accounting firms in the United States. He works in the Forensics and Dispute Consulting unit and specializes in computer forensics. He is also a co-author of “Hardening Network Security,” which was published by McGraw-Hill. He can be reached at [email protected].
