As we are preparing for a project to update our famed SIEM and SOC guidance documents, let’s have a quick discussion of so-called “SIEM alternatives.”
If you recall my funny post “Is SIEM The Best Threat Detection Technology, Ever?”, I opined that “all told, log-centric monitoring is probably the best starting point for most [but not all] circumstances.”
So, when I think of narrowly-defined “SIEM alternatives”, I think of some other technology that collects and analyzes logs – for security purposes. These do of course exist! Of course, this covers vanilla central log management (CLM) and UEBA (which pretty much merged with SIEM anyway). It may also cover some other analytics-based (loosely defined) tech that can analyze some logs for some purposes. Note that DIY projects around big data analytics of log data fit here as well – however, some of them eventually end up building a SIEM (oops! as in “we spend 5 years and built a SIEM circa 2002 – but on top of Hadoop! Ours scales – but does not do much!”)
Now, you can also think of broadly-defined “SIEM alternatives.” This, IMHO, would be some technology that delivers on the same mission as that of a SIEM, but perhaps without substantially relying on log analysis. NTA and EDR vendors occasionally flirt with presenting themselves as “SIEM alternatives” … with various degrees of success. BTW, what are SIEM’s missions today? For sure, they still include threat detection, compliance reporting, alert centralization and perhaps enabling some secops workflows. Can one tech do all that and not be a SIEM? Exactly, no!
Finally, an alternative to deploying a SIEM may be signing up with an MSSP or an MDR, that collects and analyzes your logs. The provider may be using their own SIEM-like platform or even a commercial SIEM. Hence, this may not be a SIEM alternative at all, but an alternative to owning it.
Now, how about “fake alternatives”? You knew hilarity was coming, right?! To me, the technology that is “better than SIEM,” but only for ONE or a few of SIEM use cases is not an alternative. IMHO, no ONE threat detection technology can replace a SIEM or serve as a credible overall alternative, but many exceed SIEM for specific use cases. A better wheel is not a car alternative, to use a broken analogy here.
Furthermore, “totally-not-a-SIEM-because-we-have-ML/AI-but-yes-we-collect-logs” is of course NOT an alternative. It is just a SIEM! Perhaps – if you are an optimist – a better SIEM. Realistically, rules are the right answer to many questions, and sad attempts to fit ML to every problem have generated plenty of FAIL – and of course hilarity too! If you are a vendor, who thinks that “SIEM = rules”, please sign up for the re-education summer camp….or read our SIEM papers.
Now, Gartner may or may not define “an NG SIEM” soon (generally, we try to avoid 4 letter acronyms, abhor 5 letter acronyms and absolutely hate 6 letter acronyms). However, I think a future SIEM is very much a SIEM (unlike this view). Why? Because if you create a tool to do what SIEM is intended to accomplish, you will end up with a SIEM. I admit that this is debatable, but I am happy to debate it – especially now, before we update our papers….
Some of the related posts about SIEM:
- Next Research: SOC, SIEM, and Again Overall Detection and Response
- Let’s Define “SIEM”!
- Is SIEM The Best Threat Detection Technology, Ever?
- The Coming UBA / UEBA – SIEM War!
- UEBA Shines Where SIEM Whines?
- SIEM or Log Management?
- SIEM Future: A UEBA Path or An MDR Way?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.