Imagine you own a broken, dilapidated, failing SIEM crap deployment. What? Really… that, like, never happens, dude! SIEM is what makes unicorns shine and be happy all the time, right?
Well…mmm… no comment. In this post, I want to address one common #FAIL scenario: a SIEM that is failing because it was deployed with a goal of real-time security monitoring, all the while the company was nowhere near ready (not mature enough) to have any monitoring process and operations (criteria for it). On my log/SIEM maturity scale (presented here, also see this related post from Raffy), they are either in the ignorance phase or maybe log collection phase.
And herein lies the problem: if you deployed one of the legacy, born in the 1990s SIEMs that are not based on a solid log management platform, the tool will actually suck at the very fundamental level: log collection. The specific issue here is that most of these early tools were designed to only selectively collect what was deemed necessary for real-time security monitoring (vs all log data). In essence, you have a tool with monitoring features (that you don’t use) and with weak collection features (that you can use, but they are weak).
What to do? You have these options:
- Leave it to rot; you can always keep it just to boast to your friends (and PCI QSAs) that “ye own one of ‘em olde SIEMs”
- Blow it away and join the “SIEM doesn’t work” crowd – and maybe buy a simple log management tool later
- Deploy a log management tool to “undergird” your crappy SIEM; you have a choice of buying from the same SIEM vendor (if they have it) or a different vendor
- Built your own log management layer on syslog and open source tools
I have seen people take either of the above four. Personally, I have seen much more success with the option #3 (buy log management) and not infrequently with #4 (built log management) – BTW, this deck might help you choose. You want to move your SIEM setup from “get some logs – ignore all logs” model to “collect all/more logs – review some logs” which is typically much more aligned with your level of maturity. And then grow and solve more problems with your SIEM and demonstrate “quick wins.” While you are at it, review some architecture choices discussed here.
Enjoy …while it lasts.
Possibly related posts on SIEM:
- Top 10 Criteria for a SIEM?
- Algorithmic SIEM "Correlation" Is Back?
- How Do I Get The Best SIEM?
- Log Management->SIEM Graduation Criteria: Violate at Your Own Peril!
- How to Replace a SIEM?
- SIEM Resourcing or How Much the Friggin’ Thing Would REALLY Cost Me?
- How to Write an OK SIEM RFP?
- On Choosing SIEM
- "So, What Should I Want?" or How NOT to Pick a SIEM-III?
- The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
- I Want to Buy Correlation” or How NOT to Pick a SIEM?
- Log Management + SIEM = ?
- On SIEM Complexity
- SIEM Bloggables: SIEM Use Cases and Whitepaper with detailed SIEM use cases
- Log Management / SIEM Users: "Minimalist" vs "Analyst"
- All posts labeled SIEM
