Requirements For SIEM as a Service

Earlier Today I was discussing with Anton the different requirements for SIEM and MSS, eventually talking about SIEM SaaS too (by the way, he has a very good blog post on that). We noticed an interesting fact on how things are perceived by organizations choosing an acquisition model for their SIEM needs.

First we need to understand the differences between the many services and products out there. In general, we can describe the different options like:

MSS > SIEM SaaS/Managed SIEM > SIEM

While on an MSS model the service provider is responsible for running and operating the tool, the organization deploying its own SIEM will have to do those things by itself. The fun (let’s see if I’ll use “fun” as much as that other GTP analyst…) part is that middle piece covering many different definitions, such as “SIEM in the cloud”, SIEM SaaS, Managed SIEM, “hybrid”, and others. It is fun because adopting one of those options forces the organization to think in a very structured way about the resources and processes involved in using a SIEM.

The requirements that drive an organization towards those models are usually related to cost, resources, skills, culture and strategy. For example, an organization may have as its strategy to leverage service providers for its security capabilities. On that case the MSS model makes sense, as the service provided is the security process itself, not the tool to provide it. That organization, however, should be aware of the differences between the MSS and the other service offers. You can get a tool as a service, but on that case you MUST HAVE people and processes in place to use that tool. Just think about renting a car vs. hiring a taxi. If you don’t know how to drive there’s no point in renting a car, as you will need to hire a driver as well. Some tool as a service vendors will try to sell it to clients looking for the full service, what will often work as some organizations don’t fully understand the difference between the full capability (tech + process + people) and the tool (tech only).

There are also organizations in a very different situation. They may have opted to run their security processes but don’t want to worry about the IT ops aspects of a tool like a SIEM, which is just another piece of IT.  For those organizations it makes a lot of sense to adopt a Managed SIEM / SaaS approach, as long as it is well understood that someone will have to drive that car. Using the same analogy, an organization with a mobile sales force may want to have that team driving to their clients, but without buying and maintaining a vehicle fleet. On that case, getting the services of a car fleet management company, while keeping the ability to drive the cars, is the ideal solution for them.

The key message here is to be careful when considering intermediate solutions between full MSS and your own SIEM; the requirements that would normally suggest outsourcing should be considered from at least two dimensions, running and maintaining SIEM as a piece of IT and the security monitoring capabilities that leverage this class of tools. Different organizations can be in completely different sides of the spectrum for each one of those and that will definitely point them to completely different solutions or vendors.

There is a nice paper from Anton (GTP Access required) that includes this discussion about SIEM sourcing options:

SIEM Technology Assessment and Select Vendor Profiles