Security Log Collection

Step 4: Identify security log and event platforms. Identify the platforms on which the security logs and sources of security event data reside. Most business environments are heterogeneous, having a mix of Windows, UNIX, Linux, Cisco Systems, and NETGEAR hardware and software, for instance. Count appliances, workstations, and servers alike. For each platform, determine whether there's a security log of interest. If the platforms don't use SNMP, syslog, or another protocol to export their logs, you need to make sure that your chosen log management solution will work on those platforms.

Step 5: Determine how you want to use the data. Do you want to analyze security data in real time—perhaps using a security event management tool—or simply collect it for analysis (to be done later or only if a particular need arises)? If you have multiple systems, each running a different OS and each with a security log, you might want a tool that lets you configure and manage the security log on each system as well as collect data.

After you've identified the security log data you're interested in, where it can be found in your environment, and what you want to do with it, compile all the information into a reference table similar to Table 1. You'll use this table when you're evaluating security log collection tools so that you'll be sure to choose a product that can collect the necessary events in the proper formats for the required realtime or batch analysis.

There are four additional questions unrelated to your security logs and the data contained within them that you must ask yourself before choosing a management tool. Security logs can contain sensitive information, so the first question is: Does the tool need to encrypt log data that it collects and moves across the network? The second question is: Does the tool need to authenticate the source of the data? If the data source isn't authenticated, an attacker could anonymously mount a Denial of Service (DoS) attack or at least spam the system with falsified data, making it difficult for you to find real data of interest admidst all the noise.

The third question is: Must the tool authenticate itself to a central collection server component, and must the server authenticate itself to the tool? Mutual authentication, combined with encryption, guarantees that the tool will supply the collected logs— which can contain sensitive information—to a legitimate server and that no one can eavesdrop on communications.

Finally, ask yourself whether maintaining the integrity of security logs during transit and in storage is a requirement. If you can't guarantee the integrity of the data, it might not satisfy your external auditors or be admissible in a court case. The answer to each of these questions is probably yes.

Security Log Management Tools
Now that you have your criteria, you can begin evaluating management tools. There are several high-quality free or inexpensive tools that you can download and use. I recommend experimenting with each in a test lab environment before choosing one and deploying it in a production environment.

No discussion of security log management tools can omit syslog. Designed as a log collection tool for UNIX systems, syslog captures security log data from UNIX and Linux hosts and appliances such as firewalls and routers but suffers from many of the security problems that other UNIX management tools do, including lack of confidentiality, integrity, and availability. Windows implementations of syslog are also available.

Request for Comments (RFC) 3195, which you can read at http://www.ietf.org/rfc/rfc3195.txt, defines a newer standard for syslog. There are other proposed extensions and standards, including San Diego Supercomputer Center (SDSC) Secure Syslog (http://security.sdsc.edu/software/sdscsyslog) and BalaBit IT Security's syslogng (http://www.balabit.com/products/syslog_ng). All proposed extensions and standards were designed to address the weaknesses of the original syslog. You need to be aware of the differences between standards when selecting products that claim to be syslog-compatible.

You already have a syslog server on your network if you're running Microsoft Operations Manager (MOM) 2005, including MOM 2005 Workgroup Edition. You can create a syslog data provider and create and configure a rule group to log syslog messages to the MOM Operator Console. Unfortunately, MOM 2005 supports only classic syslog with all its security problems. If you can wait, the upcoming version of MOM, MOM System Center 2007 (currently in Beta 2), comes with Audit Collection—formerly known as Audit Collection System— which lets you securely consolidate security event logs from Windows systems for central analysis.

   Previous  1  [2]  3  Next