The lack of systems built with security in mind
How we can build the future of SecOps with security practitioners as the primary audience.
Whenever something strikes a chord with a large group of people, it can be good to ask why—and what it means.
I recently made a post on LinkedIn that got a ton of responses from my fellow security practitioners…maybe more than anything I’ve ever shared on that platform.
The gist of the post: To our surprise, we found we were able to get Microsoft Defender for Endpoint alerts in our SecOps Cloud Platform (SCP) faster than those alerts appeared within Microsoft’s own product. In other words, from Microsoft to Microsoft, there was about a 5-minute to six-hour lag on those alerts, whereas in the SCP, they showed up in near real-time.
I asked if anyone else had had similarly surprising experiences and received an outpouring of responses. It turns out a lot of folks have noticed strange lags and incomplete telemetry data in various parts of the Microsoft ecosystem—and in other products and platforms as well. Things that, from a security standpoint, seem counterintuitive at best…and downright negligent at worst.
In short, what we found with the Defender for Endpoint alerts is not an isolated issue at all. It highlights a much larger problem faced by security operations (SecOps) teams: the distinct lack of tools and systems built with us in mind.
The question of audience: Optimized for whom?
To be clear: We’ve all experienced integration problems and latency issues with third-party tools. But again, this was Microsoft to Microsoft. One of the largest and most influential tech companies on the planet, operating entirely within its own ecosystem, and still we find these unaccountable endpoint alerting lags and other related issues. So… what’s really going on here?
The answer is twofold.
First, while Microsoft may be a single company, they’re not immune to the issue of siloed product lines and development teams. Microsoft today is essentially a cloud provider with an operating system, that also owns a suite of office software, that also has an endpoint solution, etc. Even though everything is under one umbrella, there will still be problems stitching all of that together and making everything work well.
Second, and I think this is what impacts us the most as cybersecurity practitioners, is the fact that the vast majority of Microsoft products are not built for us. We’re simply not the intended audience. The audience for MS Office is business users. The audience for Microsoft’s cloud computing offerings? IT groups and developers. In other words, out of all of the product lines in the Microsoft family, really only one of them is aimed at (and optimized for) SecOps teams.
Take those two things together—a vast, siloed product ecosystem that needs to be integrated, made up of products that aren’t addressed to security practitioners—and it’s no wonder we end up with suboptimal security outcomes.
Of course, this isn't to pick on Microsoft. As others have noted, there are plenty of other platforms and products that treat the needs of security teams as an afterthought. It's more to the point to say that if even Microsoft has these problems, what hope is there that the rest of the IT industry will build systems and products that give security practitioners what they really need?
A hyperscaler for SecOps
OK, so the needs of SecOps teams differ from those of IT teams and business users. But here's the uncomfortable reality: It’s futile to wish that tech companies would start building products with our needs top of mind. Why? Because we’re a small part of a much larger tech industry. Global cybersecurity spending was something like $200 billion last year. Global IT was north of $5 trillion. We’re simply never going to be the main audience for most of the products in the environments that we defend.
So what’s the answer?
Well, one possible solution, although not a very good one, is to buy an endless array of point products to give us the capabilities we need. Cybersecurity has gone this route for the last decade (mostly for want of a better option). The consensus? It’s unsustainable. Tool sprawl isn’t a solution. It’s a symptom. It’s expensive, hard to scale, and creates massive infrastructure management and integration challenges.
The newer (somewhat better) approach is to turn to an integrated security platform. However, for several reasons—some operational, some business-related—these so-called cybersecurity platforms create as many problems as they solve. For service providers like MSSPs and MDRs, platform products also come with a huge downside: They’re sold by large security vendors that have their own managed security services offerings. Buying your core infrastructure from a direct competitor is a pretty high-risk strategy.
The alternative? What we’re building at LimaCharlie: a hyperscaler for SecOps teams. The idea is to take the best parts of the cloud provider approach and apply it to our industry:
Be a neutral vendor of cybersecurity tools and infrastructure
Deliver core capabilities on demand, via open APIs, and with metered billing
Make the architecture engineering-first, with automation, multi-tenancy, and infrastructure-as-code controls as basic design principles
Optimize and integrate everything in the platform for the needs of security practitioners/the best security outcomes
This model gives SecOps teams their core capabilities via a single, well-integrated platform—but without the drawbacks of the legacy vendor approach to platformization. To give just a couple of examples of what that looks like in practice: Say a team needs a presence on every endpoint in the environment to ingest, analyze, and respond to different sources of log data at wire speed…they now have that via the SCP’s multi-platform agent and detection, automation, and response engine. If they want to parse, prune, and route telemetry data intelligently, without having to send everything to the SIEM and/or risk losing valuable data, they now have that capability natively without being forced to purchase an observability point solution. They just need to define telemetry data handling/routing rules in the SCP and refine them as needed going forward.
The cybersecurity hyperscaler approach is different because it’s built to work as a well-integrated whole, optimized for security practitioners, and delivered in a way that gives security service providers flexibility, scalability, and control. It’s the best way forward for our industry because it offers the exact same benefits that AWS and Azure did for IT—but this time, we’re the audience.