Security Log Collection

If you don't have MOM, or you require a higher level of security, a great freeware syslog server is Kiwi Enterprises Syslog Daemon for Windows, which is available at http://www.kiwisyslog.com. A retail version with additional features is also available. Syslog Daemon allows incoming connections from syslog agents over TCP as well as UDP, addressing the original syslog's limitation of using only UDP. Neither the freeware nor the licensed version of Syslog Daemon addresses syslog's confidentiality problems, so syslog data will be sent across the network in clear text. You can encrypt the data sent to the syslog server using Kiwi Secure Tunnel, although the freeware version restricts you to a single secure tunnel.

Deploying a syslog server in your environment is great if you want to capture security log data from UNIX and Linux hosts and appliances such as firewalls and routers, but it doesn't help you gather data from your IIS and IAS logs, security logs generated by servers and applications, or Windows Security event logs. One option is to deploy agents that can gather data from these security log sources and convey it to a central syslog server. LogLogic's Project Lasso (http://www.loglogic.com/logforge/#) can capture the Windows Security event log and several other Windows event logs. Project Lasso sends security log data to a centralized logging server by using the syslog-ng protocol.

Syslogng doesn't offer client or server authentication or encryption, but it does use TCP instead of UDP to transport messages across the network. (You can use a third-party tool or IPsec if you want to encrypt traffic and add authentication.)

Another great tool that's based on syslog is InterSect Alliance's System iNtrusion Analysis and Reporting Environment (SNARE), available at http://www.intersectalliance.com/projects/index.html. SNARE supports multiple platforms and applications, including Windows, Microsoft ISA Server, IIS, Apache, IBM's Lotus Notes, and a variety of UNIX and Linux systems. This support makes SNARE easy to deploy, and SNARE's remote administration features make it easy to use. SNARE also comes with a server to consolidate logs from agents. However, SNARE uses classic syslog and might not be suitable for your environment due to the security problems I described earlier.

Microsoft offers a tool called Event-CombMT that can be used to collect Windows Security event logs for centralized analysis. For more information about EventCombMT, see "Take Advantage of the EventComb-MT Utility," February 2003, Instant-Doc ID 37450, and the Web-exclusive article "Collecting and Analyzing Event and System Logs," March 2006, InstantDoc ID 49492.

Another popular tool for working with the Windows event logs is Log-Parser. You can read more about this tool in "LogParser," May 2004, Instant-Doc ID 42174. And the new Windows PowerShell offers the Get-EventLog cmdlet, which you can read about in Reader to Reader: "Use Cmdlets to Monitor Your Security Event Logs," page 12.

In a future article, I'll look at products that SMBs can use if they need more features than the free tools provide.

Best Practices
Regardless of the security log management solution you choose, following some best practices can ensure that the security log data under management is as useful as possible. First, be sure you secure the repository of stored logs. I recommend that you use a dedicated server and restrict interactive and network logon access to the server.

Second, ensure that the clock on every system that has security logs from which data is collected is synchronized with a reliable time source. You have a variety of options to choose from, ranging from the very expensive (dedicated time servers on your network that are synchronized with reference clocks by radio) to the cheap (an application that checks an Internet-based Network Time Protocol— NTP—server such as time.windows .com). If your system clocks aren't synchronized, correlating events from multiple systems is extremely difficult— if not impossible.

Third, frequently revisit your decision about what security log data to manage to ensure that the data you're collecting is what you need to fulfill your compliance and security policy requirements. Also, whenever you reconfigure or add to your environment, consider the impact the change has on your security log management strategy.

Fourth, calculate how much storage you'll need for the log data you've collected. You'll need to figure out how much data is collected daily and how long you need to retain it. If you're subject to compliance requirements around retention periods, chances are you'll need to back up log data to long-term storage, such as tapes or CD-R discs, and purge old logs that are no longer necessary online. Assume worst-case scenarios to ensure that security log data isn't inadvertently lost due to storage problems.

Finally, check your log collection system frequently to ensure that logs are being collected correctly. Create a series of tests to generate representative security log data, then use that data to verify that you're collecting and managing log data properly. There's nothing worse than turning to collected logs to determine what happened after a security incident, only to find that the logs weren't collected and are now lost.

If you choose a classic syslog-based security log management tool, I recommend that you create a management network between your monitored servers and your centralized logging server. You can use a physical or virtual network. Only data related to management should flow over this network, and your security log management traffic should be restricted to this network. These practices will address potential confidentiality and availability concerns (but don't address integrity problems).

The National Institute of Standards and Technology (NIST)—part of the US Department of Commerce—recently released a draft of NIST Special Publication 800-92, "Guide to Computer Security Log Management." Some of the best practices I've described can be found in this guide. Although the guide was designed for use by federal agencies, you can use it and other special publications in the 800 series in your company.You can obtain this guide from http://csrc.nist.gov.