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.
End of Article
Prev. page
1
2
[3]
next page -->
