The growing requirement for statutory and regulatory compliance has many systems administrators scrambling for a way to manage their security logs more effectively. Security logs can be a great way to prove compliance and detect noncompliance. Even for companies that aren't subject to regulatory compliance requirements, security logs are an effective means of detecting violations of security policy and attempted and successful intrusions by attackers. The Windows event logs provide comprehensive security logging, but managing logs across many systems has always been challenging.
Solutions have sprung up to address this difficulty. Many are designed for larger enterprises and are quite expensive; fewer are what I would consider affordable for small-to-midsized businesses (SMBs). Fortunately, some free tools fill the gaps.
Let's look at how to identify some criteria you can use to help choose a security log management tool. I'll also show you some free and low-cost security log management tools and describe some security log management best practices.
Evaluating Your Security Log Management Needs
Before you begin testing security log management tools, you should spend some
time thinking about your security log data collection requirements. The following
five steps outline a process that can help you identify which security event
data you need to collect. This exercise will give you some criteria to use to
determine which collection tool is right for you.
Step 1: Identify the security event data you're interested in. Windows
and other systems generate a wealth of security data. Typically you'll want
to log the results of authentication and authorization operations, such as user
logon and logoff activity; access to restricted pages on Web sites; and database
and Internet access. Think about what data you actually need. Do you need all
authentication and authorization-related data, or are you interested in only
failed attempts? Do you need both logon and logoff data for all logon and logoff
events (e.g., interactive, network, services, batch) or only interactive logon
data?
In this step, I recommend thinking at a high level instead of very specifically—for
example, think failed user authentication instead of failed interactive
logon to a Windows XP Professional Edition desktop—so that you'll
be less likely to miss or overlook sources of data. If you aren't sure what
security event data you actually need, consult business decision makers and
other stakeholders, such as your inhouse legal counsel or audit group for guidance
about what data might be required to prove compliance or look for policy violations.
Step 2: Identify available security logs and the format of each. You might find that there are more security logs in your environment than you originally thought. For starters, there's a Security event log on every Windows system. On UNIX and Linux systems, there's probably a file called Messages (or something similar) that might contain security information. Microsoft IIS and Internet Authentication Service (IAS) also have log files containing security information. These logs can be written in a variety of text and database-compatible formats. You can use the Microsoft Management Console (MMC) snap-ins for IIS and IAS to configure the format used by the services. Generally, it's easier to search text files for items of interest.
Firewalls, access points (APs), routers, and so forth typically create security
log data. If these are devices that send their security log data to a logging
host—as opposed to services running on a host—note the protocols
used and make sure that your log management system can support those protocols.
Chances are the devices use the syslog protocol (or a variant of it) or SNMP.
You should also record potential sources of security log data, even if the data
isn't currently available. For example, a Web server or database might be able
to generate security log data even though it isn't currently configured to do
so.
Step 3: Map the needed security data to its specific sources. If you need to manage security log data to identify potential attacker activity related to failed authentication attempts, list each source that provides that data. You also might be able to eliminate some sources of data in this step. For example, if you decide to keep a record of user logon and logoff activity in your forest or domain, you could record all activity from the Windows Security event log on each XP and Windows Server system. Alternatively, if everyone has a domain account, each system is a member of a domain, and resources are centralized, you could record logon and logoff activity from the Windows Security event log only on key servers and domain controllers (DCs).
Map the high-level data requirements to the specific logs and events that provide
that information. This step is perhaps the most difficult because it requires
you to understand what data is available in each log.