On SIEM Deployment Evolution

Is your SIEM stuck in the past? Is it “mature”? Is it evolving? Is it solving one problem or many? Is it collecting logs or collecting dust? This post continues our journey into SIEM deployment architecture and SIEM operational processes.

First, if your SIEM architecture was built in, say, 2003, and it has been solving the original problem (e.g. monitoring user access to servers or reducing IDS/IPS “false positives”) successfully, there is absolutely nothing wrong with that. It may not be “evolving," but so what? Hopefully, you are not paying 20% of $1m every year for FP reduction, but other than that a “static” SIEM deployment is not inherently worse than a “dynamic” one. It may be “static” or “in maintenance mode," but if it makes you happy, who am I to argue with that?

However, there seems to be a non-trivial number of SIEM deployments that are stuck in various non-productive stages. Let’s review that.

• Stuck in collection: it often happens when people plan a SIEM project in a “horizontal” manner – all collection first, all analysis later (rather than on a use case by use case basis). The end result of this is a nice log collection system at 10x the price of a nice log collection system.
• Stuck in compliance: it happens when people buy a SIEM “to check the box” and never start using it for anything beyond scaring the auditors. The end result is one REALLY expensive checkbox.
• Stuck at “problem 1 solved, N to go”: it may occur when an organization builds a SIEM deployment, solves the initial problem (as it should), but then something breaks – maybe staff turns over, security team gets downsized, consulting budget runs out – and the deployment focus shifts on maintaining “status quo.” The end result is one of a missed opportunity – and eventual realization “We paid WHAAAAT to get this taken care of?!!!”
• Stuck in investigations: nowhere near as harmful as the previous ones, this happens when a SIEM is mostly used to investigate – rather than detect – incidents since the organization never matures to security monitoring stage. A common end result of such deployments is a SIEM being replaced by a well-known log search tool.

On the other hand, the best path for a SIEM deployment is from success to success, with constant refinement and expansion. There is nothing more motivating than a sequence of “quick wins,” solved problems, value realized, etc. It helps retain security personnel, unlock budget, refine processes, improve collaboration and integration  – and ultimately creates a self-fulfilling prophesy of a successful security monitoring program.  In essence, it works like a bicycle – you are happy only if you pedal and thus move forward.

What is the way to get there? A SIEM program self-health check of some sort. Just as we check for “are the logs flowing in?”, we should check for “is the value being delivered?” AND “what else we can solve next?” If no value is seen, what can we change, add, subtract, refine, improve so that it does show up? (hint: it is rarely the product itself) If no obvious next step comes to mind, ask around the organization. This process (oversimplified here for keeping it blog-sized) will definitely help you “run your SIEM well.”

Related posts:

• On People Running SIEM
• On SIEM Processes/Practices
• On Large-scale SIEM Architecture
• Some of the Big SIEM Questions
• My Upcoming SIEM Research
• All posts tagged  SIEM