On SIEM Processes/Practices

Security monitoring (whether centered around a SIEM tool or broadly defined) is not something you can actually buy. A software or an appliance – purchased and racked in your data center – does not a capability make. It sounds boring and even trite, but SIEM, in particular, and security monitoring, in general, MUST include technology, processes and people.

In my current research project, I promised to shed some light on SIEM technology architecture as well as related processes – and I neglected to highlight people. Many of the conversations I’ve had so far highlighted the need to also include a discussion about roles, skills, FTE counts and other people aspects of running a successful SIEM (which I will do in one of the later blog posts). For now, this is one more of my “thinking aloud” posts (the previous was on SIEM architecture) – and it focuses on SIEM processes and practices.

Let’s think about this together: what is the MINIMAL set of processes necessary to push the SIEM project from the “land of FAIL” into the realm of success? Note that we are not thinking about anything super complex and heavy-weight, like running a real enterprise SOC. We are only thinking about getting the value out of your SIEM purchase.

First, let me take one possible answer out of the way: if there is no process whatsoever, your SIEM purchase amount is wasted. It has been like this with the “1st generation”, late 1990s SIEM tools, and it is the case with current 2010s SIEM tools. In this regard, nothing changed and nothing will.

In any case, let me list a few low-hanging fruits (how DOES the “process fruit” taste?) – please add your ideas in comments:

• If you don’t have an incident response process that outlines what will happen if there is a security incident, don’t bother procuring a SIEM (in fact “75% of chief information security officers (CISOs) who experience publicly disclosed security breaches and lack documented, tested response plans will be fired” – see this for more details).
• If you don’t have some kind of suspicious indicator triage process that tasks somebody with deciding that an incident should be declared OR that some rule in SIEM should be adjusted (see next item), is also very unlikely that your SIEM effort will succeed. I am tempted to merge the report review process in this item as well, even though some would say that it is different.
• Finally, if you don’t have some tuning (initial and ongoing!) process to adapt your SIEM to your changing environment, the chances of you getting the value equivalent to your purchase price are miniscule. “Off the shelf” SIEM content , while somewhat useful, needs to be customized and adjusted to solve tougher problems for which modern SIEMs are built.

(by the way, this is conceptually similar to what I called “graduation criteria” for SIEM in my old consulting days).

Finally, I’ve seen more than a few organizations that have fallen in a very interesting “SIEM rut” in this regard: they know they need to have the above processes run by skilled people, but they blew their entire budget on the actual tool … Ooops!

Related posts:

• On Large-scale SIEM Architecture
• Some of the Big SIEM Questions
• My Upcoming SIEM Research
• All posts tagged  SIEM