Crosspost: Living with Multiple SIEMs

This was originally posted at Anton on Security. So, if you already read it there, don't read this :-)

In a perfect world, nobody will run two SIEM tools in the same environment. Because if you dream of a single pane of glass, two is not better than one. Especially if one or both have broken glass. In fact, when researching this post, I found an old joke about it that made in 2006 (!) — see slide 14 in my ancient presentation.

On a more serious note, in the last 15+ years I’ve kept encountering the organizations with 2, 3, 4 or more than 4 (!) SIEMs. So, how do you live in a “multi-SIEM” environment, if you have to do it?

Before we go there, however, please make sure to refresh how SIEM is defined. Otherwise, you can be one of those embarrassing people who think that raw log search is the same as SIEM (it is not!). In light of this, combining a SIEM tool with a standalone User and Entity Behavior Analytics (UEBA, usually downstream or alongside the SIEM) or a central log manager (CLM, usually upstream or alongside the SIEM) is perfectly logical. Well, if you want to nitpick, as SIEM and UEBA merge together into a single solution type, combining a SIEM with a separate UEBA will become less common. Another logical case is to mix/match SIEM components.

OK, so now, how about a case where you have SIEM and SIEM (or: SIEM and SIEM and SIEM), rather than SIEM and CLM? Is there a sensible multi-SIEM strategy? I’d still say not as such (because there are no technical merits for multiple SIEMs, in my learned opinion), but it is very possible that this is a daily life in your SOC.

So, what to do if you are getting into a situation where you’d actively use two similar SIEM tools? Is that perhaps a transition state, from A to A+B to B? Or, are there legitimate reasons to have that as a long-term solution?

Let’s talk about this — and to make this real, I will use an example that is very loosely based on something I may have encountered recently.

Caption: SIEMs to be friendly … but will it SOAR?

The above setup is actually two setup choices (tagged with [1] and [2]) — either SIEM 1 talks to SIEM 2 (choice 1), or SOAR talks to both SIEM 1 and 2 (choice 2). So, what are the strengths and weaknesses of this setup?

The main weakness is:

• Complexity and hence fragility of the multi-system setup (due to both data flow integration needs and detection content organization). Complexity kills security. In fact, complexity kills.

There are many strengths, however:

• Cost savings due to license, hardware and maintenance costs of reduced data volumes flowing into a pricier SIEM (SIEM 1 above) — some reported cases I’ve seen involved savings of up to 90% of SIEM 1 cost.
• Speed of some searches goes up without a corresponding cost increase (mostly searches over large volumes of data flowing into SIEM 2 such as searching 1 year of EDR data).
• Boost to security visibility due to EDR and other data being collected and analyzed; a new capability to run detection content on EDR (and/or sysmon) data as well as hunt over many months of such data.
• Unified view of events mostly survives, the situation reminds me of “1.5 panes of glass.” You may well have one UI that you like such as from SIEM 1 and so use that pane of glass for many (but not all) tasks. The goal here is to reduce nasty swivel-chair syndrome that kills the performance and increases analyst burnout.
• (this strength is Chronicle-specific if used as SIEM 2 in the above picture) Threat intelligence matching improves especially retroactive matching of intel vs security telemetry.

The above list is not here to convince you that “two is better than one”, because philosophically this is not really true. However, it is here to convince you that if you have trouble with scaling and otherwise utilizing your SIEM, the answer may in fact be in getting another that works better for some tasks.

There are also a few prerequisites for this to work somewhat well in real life:

• Robust APIs in both products. You do want your products working somewhat together here and this means APIs to enable cross query capabilities.
• (if SOAR is used) Correct APIs in both SIEM tools are supported by a SOAR product.
• Data access API calls do not destroy the performance of either SIEM 1 or SIEM 2.
• Compatible data model — now, “compatible” is a weak word, but this really asks for lack of gross data model mismatches that cannot be bridged.
• Detection content for the right log types is enabled in the correct products.

Admittedly, for many practical implementations of this setup — especially those for both detection and investigation — making detection content work on such “dual SIEM” setup is not easy. A trivial thing — for a SIEM in 2003! — a cross-device correlation rule running on normalized data will be either hard or impossible on this setup for some use cases.

Conclusion: if you have challenges with your SIEM, especially related to cost and/or pricing model, it is very possible that your short term answer is augmentation and not replacement. However, I’d stop short of calling this “a multi-SIEM” strategy, because, strategically speaking, you do not need more than one SIEM…

P.S. To quote and quip my former colleague Neil, “security is becoming a big data problem” but you are the one paying for it in many cases :-)