On Choosing SIEM

Everybody knows how to figure out whether you need a Security Information and Event Management tool (SIEM) and also how to pick the right SIEM product for your organization. Extremely smart people with years of experience in the field spent years dealing with that exact problem (example). However, it sure seems like the right way – requirement-driven and use-case driven – is also the least popular way of picking and justifying SIEM deployments. Folks just want to do it wrong and make themselves suffer in the process while wasting money, generating annoyance and sparking intense hatred of SIEM vendors.

Great!

If doing it right  is not a popular option since many organizations are hell-bent on doing it wrong, let’s try to determine “What is the least wrong way which will actually get used in real-life?”

First, let me refer to my classic deck on SIEM and log management “worst practices.” The first two practices are related to choosing a SIEM product and are shown below:

•WP1: Skip need determination step altogether – just buy something

–“My boss said that we need a correlation engine” (more about this mistake)

–“I know this guy who sells log management tools …”

•WP2: Define the need for SIEM in general

–“We need, you know, ‘do SIEM’ and stuff” :-)

These situations are actually quite common and most unquestionably wrong; and many a SIEM project has been slaughtered as a result.

BTW, what partially inspired this post was a  lot of Google queries for “which siem system is right for security in my company?” that landed on my blog. Think about this! Folks think that Google actually knows what SIEM is best for their organizations :-) An additional inspiration was provided by a discussion I had with a colleague who said that many SIEM purchases also had a hidden “opportunity cost.” Namely, the money spent on a SIEM were thus not spent on something that could have contributed a lot more to risk reduction at this particular organizations. The final inspiration came from all the “MARS tossing” that is going on now; the organizations who acquired a SIEM product a few years ago and never managed to apply it to anything useful are now on the market for – you guessed it! – a new SIEM. These same folks then google for “SIEM justification” since they literally cannot say why they wasted $280,000 of perfectly good dollars…

In any case, what IS the least wrong way? How about this flow (drastic oversimplification alert!):

1. Do you really need a SIEM? Or do you want a SIEM? Figure this one out please….
2. If you need a SIEM to solve a particular problem, what would it cost (time, staff time, money) to solve it with SIEM and without SIEM? Which is cheaper, better, faster?
3. What problems won’t you solve due to engaging in a multi-month SIEM project? Is this acceptable?
4. Next, will a simpler – and cheaper!-  log management tool do the trick?
5. Are existing SIEM solutions actually capable to solving that problem you have? At a cost you can afford to pay?
6. Will existing SIEM solutions work in your organizations: politically, culturally, geographically, etc?
7. Are you prepared to WORK (yes, w-o-r-k!) to make SIEM solve your problem? What exactly is your expectation, SOC-in-a-box, perchance?
8. How about open source SIEM combined with other tools and integration services?
9. Only here you can start planning the deployment, phased approach, log source integrations, correlation rules, dashboards, etc.

(we can call it an “almost right” approach)

And by all means, study vendor stuff on “how to choose a SIEM?” [some of it will in fact be written by the same party as this post :-)], but don’t take it as gospel. The above list should get you going at least.

Here are some example of “SIEM gone wild” from recent experience.

In one case, a company called a consultant and said that they needed assistance with SIEM implementation. He asks: do you have business requirements defined? No. Do you have a product selected? No. But you want to implement already? Yes. <painful pause>

In another case, a company picked a SIEM that was [supposedly] the easiest to deploy. While undoubtfully an important criteria, wouldn’t an enlightened reader of my blog agree that this requirement comes a close SECOND right after the “Will it solve my security problem?!!!” This particular organization just focused on ease of deployment… and FAIL didn’t have to wait too long :-)

BTW, lately I’ve been puzzled about the whole concept of “co-managed SIEM” (subject of one of the future blog posts). I think it is gaining popularity (example) for that very reason mentioned in this post: folks don’t want to figure that stuff out, the want the crack team of mercenaries to parachute in, deploy and operationalize a SIEM for them – and then continue running it for some time…or forever. I was told that sometimes it is cheaper than signing up for an MSSP – and you retain more control while learning from the experts on how to do it.  But more on this in the future post.

Finally, just have to mention it: I am available for SIEM and log management consulting projects.

Possibly related posts:

• Log Management + SIEM = ?
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• On SIEM Complexity
• SIEM Bloggables
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• Short Observation on Open Source SIEM
• All posts labeled SIEM