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.
Register
