The "RISKY BUSINESS" Blog

Ever have one of those really intriguing moments ... where for the rest of the day your mind keeps circling back and considering the possibilities? I had one yesterday.

A client asked us to help them on a SIEM Proof of Concept leveraging OSSIM (Open Source Security Information Manager). We had tried OSSIM a few years ago with minimal success, but had been intrigued by Alien Vault's stewardship of the project, so we were excited to participate. We figured the best way to get started was to deploy OSSIM in our environment.

Just a few hours later our SIEM Practice Manager grabbed me by the arm with a big smile, "you gotta see this!"

Remarkably, our network had been auto-discovered, a Vulnerability Assessment had been run, net-flows were being captured, we had real-time visibility to network traffic, a snort ids sensor with an appropriate signature set had been deployed, and basic network monitoring functionality was in place.

Now if OSSIM doesn't sound like a conventional SIEM, it isn't. OSSIM integrates a diverse array of existing Open Source security tools into a unified whole which is notably more valuable than the sum of its parts. Surfing our security related data gave me greater insight into our operations and our information security posture. Very quickly we had a comprehensive view of our environment, with one notable exception, we were not yet monitoring device logs (which is really the lynch-pin of SIEM).

It took another 10 minutes or so and OSSIM was receiving logs from one of our more chatty Cent-OS boxes. After updating Snare on our 2008 Active Directory box OSSIM happily consumed our AD logs, although, the regex's will need a bit of fine-tuning to handle a few of the event types we want to capture.

So would Devin Woodcomb proclaim that OSSIM is "awesome"? Not sure yet, but I am intrigued as hell at its ability to provide significant value right out of the box. BTW, I wonder if mentioning that everything we have tested to this point is part of the open source version (free!) would tip his opinion ...

• STORAGE: SIEM's require a lot of storage when you are reaching 500,000,000 events/day.  The raw data, indexes to speed searching, summary data to facilitate reporting and related meta data can easily drive a requirement for 50 Terra Bytes of storage or more if you need to keep the data around for a year to meet compliance standards (e.g. PCI Data Security Standard).  You also need fast, easily manageable storage, which often means SAN - which definitely means expensive.
• LICENSES: SIEM's also require a number of servers running potentially expensive OS's, databases, and BI/Reporting Tools.   

During a recent engagement the cost to implement the SIEM per the original design got a bit too pricey so we looked for ways to reduce the cost.

1. We limited the online (SAN based) storage from one year to 90 days.  The other 275 days of data will sit on a highly compressed text indexed server that will provide them the ability to run searches on older data the handful of times that it may be necessary.
2. We moved from a Solaris to Linux (which also allowed us to move from Sun to x86 servers).
3. We moved from Oracle to MySQL (with 4  CPU's the cost and maintenance savings were notable).
4. We moved from Crystal Reports to Jasper Reports.

The net was the cost was reduced by several hundred thousand dollars with minimal impact to functionality .... Not too bad for an afternoon's work !

Visit our SIEM page to download additional resources!

SIEM tools, video and more on our SIEM resource page.