- Nokia's new N97 vs. the iPhone
- 10 Microsoft research projects
- Hard to get justice in MySpace case
- Smartphone smackdown: Storm vs. iPhone
- Apple removes antivirus support page
Introduction|Are SIEM and log management the same thing?|Scorecard|How we did it|Slideshow|Test archive
We brought all of the products into the production computing environment of a small multinational with six locations in five countries and ran them over the course of four months. Our environment consisted of a distributed range of devices including Linux machines (RedHat and SUSE), Microsoft Windows 2003 systems, VMware ESX servers, Cisco routers, switches (Cisco and HP), intrusion-detection systems, VPN devices (Cisco and Juniper), and firewalls (Cisco PIX and ASA models).
To create an even playing field for testing we first built out a centralized syslog server. This system served two major purposes. First it gave us a single point to "relay" all event data to all SIEM platforms simultaneously. Secondly, it gave us a "clean" data set to perform searches against to validate SIEM findings. For example, if SIEM X failed to detect something we thought it should have, we could go back and look at the raw event data on our syslog server.
To get all of the syslog data distributed we used the open-source syslog-ng package from Balabit IT, with the "spoof source" directive enabled. (We had to re-compile syslog-ng as the native build of the package in SUSE Linux was compiled without this feature.) The spoof-source option is essential to having the SIEM tools properly detect the IP addresses of the log sources.
The native Windows event logging mechanisms threw us a bit of a curveball as Microsoft's servers don't natively use the syslog protocol. Deploying half a dozen Windows event-scrapping agents wasn't attractive or feasible so we opted to deploy the free "Snare" agent from InterSect Alliance on select domain controllers. Snare can scrape native windows event logs and forward them via the syslog protocol, and most of the products we tested supported the format.
Once everything was up and running we began the tuning process, started checking the dashboards on a daily basis, and started building correlation rules and working through our test use-cases.
Learning where features reside in each tool was a bit troubling at first, but over the course of several months we were able to get reasonably familiar with the different approaches the vendors took. For anyone planning on "trying this at home" we have one word of advice: block out some serious time! We spent hundreds of man hours on this project. While time requirements will vary based on complexity, size, use cases tested, and the number of participants, don't plan on it being a short endeavor.
< Return to main story: SIEM tools come up short >
Partner Content
Brilliantly simple security and control solutions for email, web and endpoint
www.sophos.com
Stopping data leakage
Learn how to exploit your current security investment to control the information that flows into, through and out of your network.
Download the white paper.
Why detection rates aren't enough
Evaluating endpoint security products is a time-consuming and daunting task. Learn the six critical questions you need to ask prospective vendors to get the right endpoint solution.
Download the white paper.
Applications: taking back control
Employees installing unauthorized applications is a growing threat to business security and productivity. Cost-effectively reduce this threat by integrating control into your malware protection.
Learn more today.
Comments (3)
Many of the products weBy gshipley on June 30, 2008, 7:23 pmMany of the products we tested had push/pull methods of gathering data and approaches varied heavily on what the data source was. (e.g. a Cisco firewall vs. a vulnerability...
Reply | Read entire comment
RSA declined to participateBy cburns on June 30, 2008, 5:04 pmSo we can not verify these claims based on testing. Christine Burns Executive Editor, Testing Network World
Reply | Read entire comment
None of the solutions offered an agentless approach?By Anonymous on June 30, 2008, 3:48 pmYou noted in the article that many customers prefer not to install agents on DCs - were none of the solutions under test capable of collecting events from Windows...
Reply | Read entire comment
View all comments