We lament that people love to buy single-purpose security tools and then complain about it, but what about buying components of tools? For example, will you buy a normalization engine so that you can later use it to develop your own SIEM [if you for some reason dislike the term SIEM, substitute your own cooler term, like NG-SIEM or security analytics]? Same with acquiring a text search engine, or a message bus (like Kafka).
Now, most people will say “no”, but some will give an enthusiastic “yes.” Admittedly, most mainstream security buyers don’t want to acquire tool components, but some of the elites for sure do, because it saves them time in their endeavors (duh! obvious insight!)
However, this is not the entire truth. What if you only need some parts of what is on sale? The answer may be modularized tools or perhaps buying from a vendor who is building their tool in parallel with your evolving needs. Now, some people think that you spell “modularized” like so: “g-r-e-e-d-y vendor” 🙂 And of course some won’t trust a vendor to build what they will need in 2 years during these same 2 years. So, we are at a minor impasse.
This brings up the specter of a debate of what is a product vs what is a feature/capability. For example, how much of a SIEM you need to build to be considered a SIEM vendor? What if you have 1/3 of a SIEM (based on SIEM Critical Capabilities), but you found enough clients who want your particular 1/3 of SIEM? Naturally, people who want Centralize Log Management (CLM) only, essentially buy a 1/3 of SIEM.
In general, “feature masquerading as a product” is an annoying thing to behold. But sometimes there are just enough buyers for it, no?
At this point, my post flows like a barely-coherent rant, but let me try to crystallize a point. There are circumstances where it is reasonable and prudent to buy a component, an incomplete tool or a combination of features that fill your particular gap.
BTW, as a side note, I received a peculiar comment the other day: despite all the ”AI” whining, SIEM is getting dumber compared to 20 years ago (and rule-based tools sometimes outperform analytics-based tools too). Here is my humorous take on it:
- SIEM vendors in 2002: “no need to know SQL, we have Crystal Reports!”
- SIEM vendors in 2020: “no need to know SQL, you have to learn our special query language …that we just created … don’t worry though … it very very eeeeeeasy”
In essence, some vendors expect the end user to do MORE than the vendors of yesteryear. What does this mean? This thing is ripe for disruption…
- Migrating from Your SIEM to a New One
- Our “How to Operate and Evolve a SIEM Solution” Publishes
- Our “How to Architect and Deploy a SIEM Solution” Publishes
- 2018 Popular SIEM Starter Use Cases
- What Is “SIEM+” Or “Can We Have A Cyber Defense Platform?”
- Can You Do a SIEM-less SOC?
- SIEM Alternatives? What Are They? Do They Exist?
- Let’s Define “SIEM”!
- SIEM or Log Management?
- Is SIEM The Best Threat Detection Technology, Ever?
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.