Making a Business Case for the Right SIEM

Let’s admit it — switching to a new SIEM can be tough. And expensive. But even when it isn’t tough or expensive, it’s always scary. “Better the devil you know than the devil you don’t” could easily be changed to “Better the SIEM you know than the SIEM you don’t.”

So, given all the pressures facing the SOC today, sometimes organizations urgently need to upgrade to a next-gen SIEM to give the SOC team the scalability, speed and functionality they need to meet today’s challenges. That may mean having to endure some short-term pain to achieve long-term gain.

And if you’re a SOC leader who has to deal with pushback from the business when you say the organization needs a new SOC, well that doesn’t make it any easier. Often, resistance from the business can become outright opposition to the decision you have made with the best interests of the company and its security in mind.

I’ve been involved in more than a few projects where we awarded the technical win to our preferred vendor — only to have an executive or board member step in at the last minute and select a solution from a different vendor. That can be incredibly frustrating! After all, it’s the SOC team who must live with the consequences of that decision.  

Build a Business Case Based on the Needs of Your SOC

The best way to avoid this situation, or correct it, if necessary, is to know how to create a business case that outlines why your SIEM of choice is not just technically superior, but also the best overall business decision.  This can be tricky, because most people who work in the SOC, including managers, may not be fluent in the language and concepts that executives use — just as most executives are not fluent in the language and concepts that security professionals use. The latest Devo SOC Performance Report^TM shows how SOC leaders and analysts responded to the question of whether SOC objectives are in sync with business needs. The vast majority (78%) said there is little to no alignment. That’s not good.

A very common example is when a company has a cloud-first strategy or initiative that includes choosing a next-gen, cloud native SIEM. So the SOC team spends a lot of time and effort producing RFI’s, sitting through demos, doing detailed POCs and selecting the best tool for the job. Then, at the last minute, an executive might announce something like, “We have an ELA with Microsoft, so we’re going to use their Sentinel SIEM* because it’s included in the ELA.” Not surprisingly, this would be very frustrating for a SOC team that had ruled out Sentinel for a variety of reasons, such as:

1. It’s not good at ingesting non-Microsoft data sources.
2. Data not parsed correctly is discarded, which can leave large gaps in your data.
3. It’s not easy to build automations for non-Microsoft applications.

Now What?

But how do you explain to someone without a technical background the ramifications of non-parsed data being discarded? Their eyes will glaze over and typically they’ll reply with something such as: “Let’s make it work.” You’ve got to talk to them in a language that they can understand. Fortunately, most business executives today are well educated in the language of risk management.  

You need to explain the consequences of their decision using the language of risk management. Addressing the technical points above would result in a response such as:

1. More than 30% of our assets are not Microsoft, which means they may not work with Sentinel and that could expose us to significant risk.
2. Sentinel could result in data gaps that would put us at risk for meeting regulatory and compliance requirements, which would have a significant financial impact on the business.
3. Interoperability issues will lead to longer MTTR for all incidents, increasing the impact of every incident that occurs.

So take a little time to review the “language of risk management.” There are many resources including this one or this podcast. It will be easier for security practitioners to learn the language of risk management than it will for the executives to learn the technical language of security, and everyone will be better off.

*I have nothing against Microsoft Sentinel. I’m only using them as an example. You could replace Sentinel with Google Chronicle or another vendor in the example above. My intent is to show how technology may be “thrown in” during a bulk purchase and SOC teams are forced to use it even when it doesn’t meet their specific needs.