Computerworld - I mentioned in my previous column that in my new job, I inherited a project to implement a security incident and event management (SIEM) tool. In response, several readers e-mailed to tell me about their experiences. Here's what I've learned in tackling this project over the past couple of weeks.
There are a few different ways to use SIEM. It can alert you to anomalous behavior and malicious code. By pulling in data from our antivirus scanning management console, our patch management reporting tools and our DNS, DHCP, switch and firewall logs, SIEM can quickly alert us, for example, that a particular unpatched system is infected and even identify which switch port it is connected to. SIEM can also be an investigative tool, providing additional information when an intrusion-detection tool logs an event. And a SIEM tool can be used for asset management, detecting the addition to the network of things like unauthorized virtual servers or the activation of unauthorized services such as FTP.
But with SIEM, you get out of the tool only as much as you put into it, and you have to spend a considerable amount of time figuring out what exactly you want this new contraption to do for you. The failed SIEM deployments that I've seen were victims of poor planning.
The first rule to acknowledge is that you just can't make assumptions. For example, we assumed that by pointing the logs of our domain controllers to the SIEM tool, we would be able to obtain logs related to employees' log-in and log-off data. That didn't happen, and we ended up scratching our heads. As it turns out, unless you've properly configured the audit policy setting on a domain controller, you're not going to see those logs. And Windows domain controllers offer 16 different options just for DNS logging.
Assumptions can also be costly. Many SIEM licenses are based on events per second. You may run into license limits and budget overruns later on if you find that you need to enable a bunch of logs that you had assumed you were already collecting. And, of course, you wouldn't have accounted for those newly enabled logs during rule configuration, which means you may need to revisit your rules. You can see how easy it is for a SIEM deployment to fail.
SIEM tools also require a lot of tuning. You have to build your rules with care, manage false positives and classify assets properly. We keep making some progress in these areas and then having to backtrack when we discover that we have made yet another assumption that needs correction. It's quite frustrating.
Take asset identification. We initially enabled the SIEM tool with default rules and discovered that we had about 35 DHCP servers, 60 DNS servers, hundreds of Web and FTP servers, and all sorts of devices claiming to be routers, mail servers and other types of equipment. It can be tough to get a handle on everything we have and what it's doing, especially with virtual machines seeming to spin up on an hourly basis and a plethora of third-party networks created as a result of partnerships, mergers and remote offices being connected to the corporate network.
A critical factor in our deployment planning is that I have only one analyst to administer, configure, manage and monitor the SIEM tool. That lack of human resources will greatly influence how we finally tune it. I hope that as time goes by, I'll be able to justify additional analyst head count and significantly expand the scope of our SIEM setup.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Read more about Security in Computerworld's Security Topic Center.
Free Insider GuideCopyright © 1994 - 2013 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
