You guys recall my security chasm post from 2014? Because clearly some of you obsessively reread what I wrote 5 years ago … not 🙂
That post basically built on an idea of security “haves” and “have-nots” that some of my industry colleagues created. While many associate the “security have-nots” with small businesses, there are in fact many large organizations with an information security team of ONE and perhaps still a few with a security team of NONE …
However, over the years, I became aware of yet another chasm in the industry. A few recent encounters really made this chasm more visible. Here are two fictitious quotes to explain this chasm:
[I] “We prefer a managed service since we don’t have enough people to INSTALL AND RUN a commercial SIEM.” [this is really not about SIEM, just an example]
[II] “Ah, that’s the tool you sell? Actually, our engineers can WRITE A BETTER TOOL and/or assemble it from open source in time you typically spent to close a large deal.”
Watching presentations at @MITREattack #ATTACKcon reminds me that the spread between high and low efficacy security teams is immense. Top 1% teams do in-house tool dev and embrace and customize open source. Hoping to hear how vendors that serve the 99% can narrow the gap.
— Richard Bejtlich (@taosecurity) October 23, 2018
Naturally, I tend to see a lot more of [I] in my work than [II], but the main point is that these organizations essentially exist in parallel universes. Perhaps this has significant overlap with the other chasm, but IMHO this also has different aspects to it.
We have organizations lacking resources to RUN a well-supported (eh … just say “supported”, Anton…) commercial tool. And by the way, I do mean RUN rather than “run, operationalize and use effectively.” They do not have the people to install a tool and to keep it running. I’ve met people who say they don’t have time to install and configure a basic log management tool! On the other edge of the chasm, we have organizations with resources to WRITE tools superior to many/most commercial tools. They would think nothing of modifying an open source tool to better fit their requirements and, in fact, making it better for others in the process.
What bothers me even more, much of the advice given by the people from the [II] organizations won’t work at all at a [I] organization and will in fact sound condescending, offensive and/or idiotic. “Use more open source” sounds smart to people from the [II] organizations (“Hey, we don’t have to write this code, Kafka does pretty much this already, we just need to tweak it here and over here”), but it sounds like “100X more work than we have people” to a [I] organization. Even “adjust/tune the tool X you already have to do useful things in other areas” advice occasionally falls flat for the same reason: no people, no skills, no time.
What does it mean? As I explore in this post, I suspect that this will eventually boost the chances of quality MSSPs and MDRs, as well as SaaS-delivered security tools (despite this). This also serves as a grim reminder to vendors: most organizations don’t have time for you and your niche tools…
P.S. If you have to ask, this has nothing to do with orcs.
Vaguely related posts:
- Security Chasm Illustrated
- Is Security Just Too Damn Hard? Is Product+Service The Future?
- On Operational Excellence
- On Wild Security Maturity Overestimation
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
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.