There’s a growing consensus in cybersecurity that AI will render the old platform vs. point product debate moot. That’s wrong, badly wrong, perhaps even perilously wrong. Understanding why is essential, and lays the groundwork for a deeper conversation about what our industry is getting right (and wrong) about AI adoption in general.

AI to the rescue?

The background to the point product vs. platform discussion can be summed up pretty quickly.

The cybersecurity vendor market (and thus, the average security team’s stack) has become unreasonably complex. Purchasing, integrating, and managing dozens of separate cybersecurity point solutions is time-consuming and expensive, not to mention exhausting and unsustainable.

Integrated security platforms offer an end to tool sprawl and integration challenges, along with corresponding gains in efficiency, affordability, and security outcomes. Platforms, and greater integration in general, are undeniably the right approach for the industry moving forward.

But the counterargument to platforms has always been that they can’t do everything they promise, and deliver second-rate capabilities when compared to dedicated point solutions. That critique has merit, considering the half-baked approach to platformization at many large vendors.

Until recently, this seemed like an intractable debate. But then…the great deus ex machina of our time arrived on the scene: generative AI. Swooping in to deliver seamless integration of best-in-class capabilities, GenAI will now give every team the benefits of a unified platform with none of the drawbacks.

MCP servers, the thinking goes, will allow point vendors to offer high-quality, differentiated capabilities in a way that AI can understand and, more importantly, interact with. CLI tools like Claude Code, Gemini CLI, and Codex will give teams easy and reasonably affordable access to AI, helping them leverage point products directly without requiring a human to know how to interact with those tools, understand the intricacies and quirks of each one, or manually integrate them with the rest of the stack.

Sounds great in theory. Breaks down, very, very quickly, in practice.

The four shaky premises of the “AI can fix this” argument

The fundamental problem with the thesis above is that it’s based on several faulty premises. These comprise four mistaken assumptions, both technical and operational:

Assumption #1: Every point product has a mature MCP server.

This one is easily disproven. Take a casual survey of the tools in your stack, and you’ll see that MCP server availability and maturity vary wildly between point products. Some point vendors don’t have an MCP server at all (not even on the roadmap). Many others have MCP servers that are little more than an imperfect, early attempt to help teams leverage AI in their workflows.

Assumption #2: Point product MCP servers support all point product capabilities.

Again, simply not true. Most point solutions expose only a fraction of their capabilities through their MCP servers. Why? Because it takes significant engineering effort, and thus expense, for a point vendor to support a capability through an MCP server. Point products thus offer AI support for only a small subset of their capabilities: usually the bare minimum needed for co-pilot functionality.

Assumption #3: AI will move seamlessly between tools and easily interpret data across point products.

Higher-end generative AI models can translate concepts accurately and consistently. But there is always a cost when models are actually deployed in complex systems. The presence of MCP servers will carry some kind of overhead: e.g., the prompts needed to explain how to translate different concepts or how to move from one system to another. AI effectiveness degrades quickly. Latency creeps in. Context windows are overrun and important data is lost.

Assumption #4: AI allows SecOps teams to maintain and provision point products effortlessly.

Perhaps the most obviously wrong of all. AI does nothing to change one basic fact: namely, that the point products it helps to integrate/manage are still separate products. Every tool still means another tool vendor. Those vendors have to be onboarded individually, and require separate contracts and contract negotiations, regular compliance checks, deployment work, and the like. At best, AI takes some of the pain out of tool sprawl. It doesn’t eliminate the underlying problem.

Back to square one?

Given the current state of things, consider what it would actually mean for a SecOps team to try to solve stack fragmentation challenges using AI.

Many point products in the stack won’t even have well-developed MCP servers. The most likely result is a quasi-platform that offers inconsistent functionality across core capabilities—with numerous unintegrated point products thrown into the mix. Sound familiar?

Best case, even if by some luck all of your point products have functional MCP servers, the stack will incur translation costs, hampering effectiveness and degrading security outcomes. Just as importantly, the “unification” offered by generative AI will only extend over a limited subset of your stack’s functionality, because again, most point products will only expose a small portion of their capabilities through that MCP server.

So when, for example, teams are doing basic alert triage, they will get some relief. Great! But all of that tool sprawl comes in through the back door as soon as it’s time to do anything else with the stack: onboard new organizations, deploy detection rules in multi-tenant environments, engage in proactive threat hunting, create compliance reports, perform remediation work, or any of the other myriad things that SecOps teams need to do with their tools. That hardly sounds like “problem solved” to me.

AI as the right way forward (and the wrong one)

I want to be really, 100% clear about one thing here. This is not an anti-AI-in-cyber post. I firmly believe that some form of AI enablement is the future of the SOC. But what form that will take is another matter. And to be frank, I think that where we are today vis-à-vis AI adoption in our industry is…not great.

I suspect that the problem is more philosophical than technical. It’s the predictable result of tool vendors still not understanding what modern SecOps teams really need: abstraction, interoperability, automation, scalability, flexibility, and control. In the past, we tried to describe a possible solution in terms of a “hyperscaler for cybersecurity.” But today, we’d have to expand the discussion to include the absolutely fundamental need to help teams leverage AI across the full spectrum of security operations.

Unfortunately, legacy vendors and AI startups alike seem to be mired in an outdated conception of tool provisioning and of their own relationship to security teams. Nowhere is this dynamic more apparent than in the current approaches to AI—either the AI bolt-ons offered by the incumbent mega-platforms or the so-called “AI SOCs” being sold by the challengers—both of which are dead ends. But that’s a topic for another post…

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.

I keep coming back to the idea of undifferentiated heavy lifting when trying to communicate to folks what we do at LimaCharlie.

"Undifferentiated heavy lifting" was how Amazon introduced AWS to the world. The other day, I found an old video of Jeff Bezos discussing the idea during a keynote talk at MIT. This was way back in September 2006, when AWS was in its infancy, and EC2 was still in public beta!

It's a fun moment from the history of technology. But what struck me most was how fresh of an idea AWS was back then, and how well Bezos explained its value to his audience of technologists.

He pointed out that a lot of businesses struggled with the infrastructure challenges of developing web-scale computing applications.

He cited technical challenges like server hosting, bandwidth management, and scaling physical growth. He also noted the administrative and managerial overhead that infrastructure tended to produce: buying decisions, contract negotiations, and the challenges of managing a mishmash of hardware and maintaining legacy software.

All of this created an untenable situation in which companies were stuck doing the hard work of infrastructure building and management instead of focusing on their core value and differentiators.

To quote the man himself:

Your major bottleneck in developing your ideas, in developing your successful products and service offerings turns out to be something that is not unique to your business at all. It's completely undifferentiated. And the dirty secret is…that at least 70 percent of your time, energy, and dollars go into this backend heavy-lifting infrastructure.

That's the origin of the term “undifferentiated heavy lifting.” It's undifferentiated because it literally does nothing to differentiate you and your business. But it's heavy lifting because it's both very hard and has to be done very well in order for you to have any hope of success.

The value proposition behind AWS was to take over undifferentiated heavy lifting for companies by offering them what they needed as cloud-based primitives instead. That was the genius of AWS: Foundational services to solve the complex challenges of IT infrastructure and computing—delivered in a way that was independent of physical infrastructure, well-integrated, on-demand, pay-per-use, and completely scalable. In one stroke, Amazon solved many of the infrastructure and technology management challenges holding businesses back.

Nearly 20 years later, we can see that the AWS model has been a massive success in IT and general tech. Now it's time to apply the idea of undifferentiated heavy lifting to the cybersecurity industry as well.

The case for "muck" in cybersecurity

In cybersecurity today, far too many organizations are handling their infrastructure challenges like it's still 2005. Teams tend to take one of two (equally unpalatable) approaches:

Either they collect dozens of point solutions, paid and open-source, and then try to assemble everything into a coherent security stack. Result: tool sprawl, high costs, visibility gaps, and excessive time spent on infrastructure management and integration.

Or they look for an all-in-one platform that promises to solve every problem for every user. Result: vendor lock-in on steroids, lack of customization, and the need to rely on a vendor that is likely competing with you.

To put it mildly, neither of these are good options.

At LimaCharlie, we've been building a better option for cybersecurity teams. We’re attempting to do for our industry what AWS did for IT: offer foundational infrastructure and capabilities via a public cloud provider model.

Bezos’s tongue-in-check expression for all of that stuff, collectively, was “muck.” Our basic thesis is that all cybersecurity teams need access to the same infrastructure muck of security operations (SecOps) to handle their undifferentiated heavy lifting.

There’s no need for them to outsource these capabilities to an endless series of point products or to a monolithic tool vendor. Neither is there any need for teams to reinvent these capabilities themselves every time they need to offer a new service or develop a new product.

So, what does undifferentiated heavy lifting for cybersecurity look like? Here's a representative (though not exhaustive) list of the kinds of capabilities we give teams through our SecOps Cloud Platform (SCP):

• Agent: Collect endpoint telemetry from any source and take action on it.

• Automation engine: Automation in the abstract. Gives teams the ability to say: "When X happens, do Y." Bidirectional capabilities make it possible to automate actions on third-party tools and platforms as well.

• Data routing and optimization: The ability to bring in data from any source and route it to any destination. In combination with the automation engine, this data can be transformed, enriched, or pruned in flight to enable better security outcomes and control costs.

• Telemetry retention: Teams can store all telemetry data for the cost of ingestion for one year.

• Extensibility: An ecosystem of adapters and extensions makes it possible to manage third-party tools from within a single platform and using a common data format.

I'd argue that every cybersecurity team needs these things in one form or another. The idea behind LimaCharlie was to build these heavy-lifting capabilities and then make them available to teams through a public cloud provider model (i.e., everything API-first, on-demand, pay-per-use, scale up or down as needed, and so on).

Our mission is to be a pure infrastructure provider for the cybersecurity industry. We want to free teams from tool sprawl, oligarch vendor lock-in, and the need to build infrastructure themselves—and enable them to innovate and differentiate in areas where they can genuinely add value.

Focus on SecOps, not on infrastructure

If you're an MSSP, MDR, cybersecurity builder, or even a top-tier enterprise security group, you know that basing your security operations on an endless series of point solutions is unsustainable.

You also know that you won't differentiate yourself by being the most proficient user of some vendor's product—much less by building the world's latest and greatest endpoint agent!

Your value lies in what you can do that no one else can: in the things that truly differentiate you. When you don’t have to worry so much about the heavy lifting of cybersecurity infrastructure, you can better focus on that core value instead.

And to be clear: This isn't just a vague possibility, or an idealistic vision of the future. We're already seeing the approach work with our SCP users. Blumira, a cloud SIEM provider, took their XDR from concept to GA in just five months by letting the platform take over some of the heavy lifting for them. An MDR provider improved response times and eliminated scaling concerns by using our "muck" instead of struggling with its old DIY stack.

This may be the best way to explain what we're doing at LimaCharlie, and also the difference between our vision of platformization and what PANW and others have been pushing. We're not trying to be a one-stop shop for all teams. Rather, we're taking over the undifferentiated heavy lifting of cybersecurity infrastructure so teams can stay on mission: building better SecOps, taking the fight to the adversary, and keeping organizations and users safe.

When you’re a startup founder, it’s something of an occupational hazard.

You wind up reading piles of books about founding startups.

It’s worth the time and effort, because the best of these books offer invaluable insights from some of the most successful entrepreneurs on the planet.

But one thing I’ve noticed is that cybersecurity startups don’t follow a lot of the most important advice.

If you look at the classics of the genre—Zero to One, The Lean Startup, Rework—a few common themes emerge. Founders are consistently told to:

• Start small and gradually expand into larger markets

• Build a minimum viable product and bring it to market quickly to test assumptions and gather data about the market

• Take an iterative approach to development and pivot rapidly as needed

• Keep the organization’s “mass” low by staying lean and avoiding technology lock-ins and long-term contracts whenever possible

But time and time again, I see startups in cybersecurity:

• Launch at an unsustainable pace or rate of spending, instead of starting small and attempting to scale over time

• Spend an inordinate amount of time and effort on engineering and development work before launching a new product or service

• Purchase tools that would only be appropriate for a far larger business

• Lose agility by accepting lock-in and long-term contracts from their vendors

Cybersecurity Tools as a Drag on Growth

What’s going on here? Are cybersecurity startup founders just not reading the same books as everyone else? Are they constitutionally immune to good advice?

Far from it. If you look at much of the general business counsel found in these books (on hiring, personnel management, funding, and so on), you’ll see founders in cybersecurity applying all of that distilled wisdom—and doing it every bit as well as leaders in other sectors.

In order to understand what’s happening with security startups, we need to acknowledge a fundamental problem in our industry: Cybersecurity teams are burdened with a product marketplace that doesn’t serve their needs. This takes a number of forms, including:

• A cumbersome sales culture full of mandatory meetings with vendor reps and lengthy negotiations

• A billing model that involves long contracts, complex licensing, minimum spending, and termination fees.

• Black-box solutions that are opaque, inflexible, and demand a “just trust us” approach to cybersecurity

• Bundles of tools sold as a single product that are often poorly integrated and come with unwanted or unneeded functionality

These are issues I’ve talked about before in the context of cybersecurity platformization or the trajectory of our industry—but the implications of this situation for builders and startups is particularly problematic.

Cybersecurity founders, unlike their peers in other sectors, are often unable to do what they should be doing, even when they know what that is. How does a fledgling company avoid lock-in when every vendor requires rigid, long-term contracts? How can you start small and grow when you’re working with bloated, pay-to-play tools that demand massive up-front investment?

At LimaCharlie, we’re building something that offers a different approach to cybersecurity tooling and infrastructure—and a way for security startups to take advantage of the experience and learnings of the successful entrepreneurs who have gone before them.

Solving Startup Problems with the Public Security Cloud

The alternative I’m talking about is a public cloud-like platform for security operations: something like AWS or GCP, but specifically for cybersecurity. In brief, this entails an integrated platform that provides core cybersecurity tools and infrastructure via a public cloud delivery model: pay-per-use, on-demand, API-first, scalable, and automation-friendly.

Our implementation of this approach is the SecOps Cloud Platform (SCP). For builders in cybersecurity, it’s a massive shift, because it enables them to:

• Access enterprise-tier cybersecurity capabilities through a pay-per-use billing model, enabling startups to begin with a small client base and scale their infrastructure spending as their revenue grows

• Build niche products and services around narrow bands of functionality within the SCP—then expand their offerings using the same, well-integrated platform as they grow

• Test and validate new business ideas at minimal cost and iterate rapidly using a platform built to facilitate engineering and customization

• Stay agile and independent by using a platform designed to scale up or down as needed and integrate easily with other tools.

A few years ago, I might have referred to the SCP as an idealistic vision for change. But some of the biggest names in cybersecurity have now embraced the platform approach, and we’ve seen our users successfully leverage the SCP as business enabler and a go-to-market accelerator in real-world scenarios. In short, the SCP represents the direction cybersecurity is already heading—and needs to continue to head if we’re to move into the future.

The SCP offers a better, more efficient way to support cybersecurity operations. But beyond this, the security public cloud will also be a growth engine for the industry, enabling innovators and builders in cybersecurity to apply the business lessons learned by founders working in other areas of technology and in other fields.

Nobody knows how the economy will perform in 2025. For cybersecurity businesses—and managed security service providers (MSSPs) in particular—the unknown looms.

The economy depends on macro factors we don’t get much of a say in: trade wars, actual wars, climate disasters, inflationary pressures, supply chain issues, and political volatility just about everywhere. Economically speaking, the coming year could be as great as the optimists predict, or turn out to be extremely challenging.

So, how can MSSPs and other security businesses get ready for what lies ahead, when the only real certainty is uncertainty?

There’s no magic bullet. But one key is to embrace technologies that improve efficiency, flexibility, and control. For cybersecurity teams, security operations (SecOps) platforms are an excellent way to do this.

How SecOps platforms hedge against the unknown

First, a clarification. When I say “SecOps platforms,” I’m referring specifically to the type of solution we’ve been building at LimaCharlie. I’m not talking about what some vendors try to pass off as cybersecurity platforms: bundles of poorly integrated point products or opaque all-in-one toolsets.

A real SecOps platform must be well-integrated and transparent. It should give teams core cybersecurity capabilities in a manner that supports modern security operations at scale. API-first access, multi-tenancy, automation, and infrastructure as code (IaC) control are table stakes.

A public cloud-like delivery model (everything available on demand, pay-per-use pricing, etc.) is also crucial in this context. Cybersecurity teams need the same flexibility that has driven public cloud adoption in IT—especially in times of uncertainty.

I often talk about SecOps platforms as enablers of better security outcomes. But from a business operations standpoint, they’re also an excellent way for MSSPs to make it through a turbulent period and emerge unscathed, or even stronger than before, on the other side.

This is because SecOps platforms help security businesses:

Adapt

Pay-per-use pricing, on-demand capabilities, and IaC controls help MSSPs respond to shifting market demand for security services.

In a downturn, MSSPs can reduce a deployment without getting stuck paying for licenses they’re no longer using, having to renegotiate contracts, or being dropped into a different pricing tier.

If business is booming, teams can quickly add endpoints or expand a service offering for an existing client—without having to meet with vendor sales teams or enter into protracted negotiations. Multi-tenancy and IaC also make it easier to onboard new clients using pre-configured tenants and reusable code templates.

Consolidate

The integration and consolidation offered by SecOps platforms allow security businesses to optimize infrastructure spending no matter what’s happening in the market.

If budgets are strained, a SecOps platform can help MSSPs cut operating costs by eliminating one-off tools from their stack and replacing them with platform capabilities. This lets firms reduce spending without changing their core service offerings. It also makes labor spending more efficient, because skilled team members can focus on higher-value tasks instead of tool management.

In good times, an MSSP can invest engineering resources in more ambitious projects to capitalize on the consolidation offered by SecOps platforms. For example, a firm might take advantage of the opportunity to develop a custom EDR capability, gaining independence from their legacy EDR vendor.

Automate

The automation capabilities offered by SecOps platforms benefit security businesses in almost any climate.

During a hiring freeze, automation can be used eliminate manual workflows, helping team members work more productively without burdening them unfairly.

In a period of growth, platform automation is even more essential, because it enables scalable operations and workflows. Firms can accept new business with confidence knowing that a new client won’t produce a 1:1 increase in workload.

Communicate

SecOps platforms are the antithesis of that “just trust us, you’re safe” attitude so common among legacy cybersecurity vendors. There are no “magic-box” components in a true SecOps platform. Teams can see and control their infrastructure—and thus establish provable security.

The cybersecurity value of that is obvious. But there’s an important business benefit as well, because service providers can use platform transparency and visibility to show customers exactly how they’re protected.

If clients are facing budget woes and thinking about cutting back on their security spending, it’s critical for MSSPs to highlight the value of their services demonstrably and objectively.

In better times, clearly communicating value to clients also makes it easier to justify price increases that improve margins and overall profits.

Deliver

On-demand, pay-per-use capabilities let MSSPs roll out a new service offering without having to take on another vendor or commit to another long-term contract.

In a difficult, highly competitive economy, this means MSSPs can still say “yes” to their customers’ niche requests. They don’t have to worry about the cost and complexity of onboarding a new tool to service a single account.

In a strong economy, on-demand capabilities allow service providers to take advantage of new opportunities more efficiently. SecOps platforms abstract away infrastructure complexity, making it possible to bring a new product or service offering to market quickly without sacrificing quality.

The best way forward, come what may

No one has a crystal ball. But as cybersecurity practitioners, preparing for the unexpected is what we do.

MSSPs need tools that help them to respond to unforeseen challenges…both technological and economic.

SecOps platforms give teams the agility, control, and scalability they need. That’s better for security. It’s better for business. And it’s the best way for service providers to navigate an uncertain future.

Cybersecurity is 10-15 years behind IT.

That may seem like a big claim. But recent events have shown that our industry’s approach to tooling and infrastructure is badly outdated.

The heart of the problem is far too many cybersecurity vendors are selling products that are essentially black boxes. The prevailing mentality among tool providers: “Buy our product, and you’re protected. We’ll keep you safe. You don’t have to worry about how.”

Even things like update management, version control, and change windows become part of that dubious promise—something for vendors to handle so customers feel secure.

But when security vendors treat their solution as if it lives in a bubble, isolated from the rest of tech, it leads to problems. Local security teams can’t see what vendors are doing—and are denied basic control and management of their tools. Vendors don't know how their changes will impact customers.

As we’ve seen, this approach can have unintended, even catastrophic consequences. But despite what LinkedIn influencers and opportunistic marketing teams would have us believe, the problem isn’t limited to a specific security company, it’s industry wide. It’s time for a change.

What cybersecurity can learn from IT

There’s an important lesson for our industry in the recent cybersecurity disruptions, and it mirrors something IT learned long ago. Tech industries are successful when they adopt a practitioner-focused, engineering-centric approach to core tools. For cybersecurity to move forward, we must do the same.

At a high level, we must:

• Stop seeing security tools as products that deliver protection, and focus instead on knowing how we’re protected—what some have described as the shift from promise-based security to evidence-based security.

• Give teams full control of tools and infrastructure so the stack can be observed, tested, validated, and customized to suit their unique needs.

• Offer practitioners API-first access to tools and the ability to manage deployment, configuration, updates, and testing as they see fit.

• Build security tools using the principles and best practices that IT professionals already embrace, e.g., automation, scalability, CI/CD, infrastructure-as-code (IaC), and so forth.

These changes would give teams full visibility and control over their operations—including tool testing, updates, rollouts, and rollbacks. The net effect would be greater stability in production environments and better security outcomes.

Security benefits of an engineering approach

Our industry has some of the most skilled, innovative people in any area of technology—but they’re often stuck working with tools they can’t see into, can’t customize, and can’t control.

The benefits of moving to an engineering-focused approach would be immediate:

• Security teams could create fine-grained detection and response logics much more easily, protecting their environment in ways that aren’t possible using one-size-fits-all tools.

• Manual workflows and processes could be automated, freeing skilled team members to focus on higher-value tasks.

• Practitioners would be better able to implement mature, proactive security practices like detection-as-code (DaC).

• An organization’s security posture could be tested, empirically and regularly, with greater rigor and assurance than current solutions allow.

Clearly, this transformation won’t be accomplished by any one company. It’s going to have to be an all-hands effort.

The good news is that forward-looking cybersecurity vendors are already making strides in the right direction. See, for example, Red Canary’s Atomic Red Team for testable security, Sublime Security’s open, engineering-based approach to email security, and the MSSP Soteria’s extensive work on DaC, just to name a few.

For many of us in cybersecurity, it can be hard to hear that we need to play catch-up with IT. I’m sure that some won’t want to hear this message. But the sooner we, as an industry, adopt the successful practices that revolutionized IT, the better. Cybersecurity teams need the same benefits that transparency, scalability, and automation deliver to other technology professionals. Because then, instead of being hamstrung by our tools, we will be empowered by them.

Some proponents of cybersecurity platformization claim that an effective security platform must be built from “best-of-breed” or “best-in-class” solutions. The idea is that a perfect cybersecurity platform is possible, just as long as it comprises the correct bundle of point products. But this notion is based on an outdated understanding of security practitioners’ needs—and a misguided vision for the future of our industry.

Unpacking the “best-in-class” claim

It’s not hard to understand why a vendor would insist that everything in their platform is “best in class.”

The case for cybersecurity platformization rests on simplifying security tooling and infrastructure. The goal is to reduce complexity, integration challenges, and costs—and deliver better security outcomes. A comprehensive platform, therefore, promises to replace many point solutions that organizations are currently using. But because of this, vendors feel compelled to reassure potential adopters that they won’t be sacrificing capabilities.

For example, Lee Klarich, Chief Product Officer at Palo Alto Networks (PANW), a major advocate of security platformization, recently told investors:

Prior attempts to [build a comprehensive security platform] generally required a tradeoff for the customer…the capabilities that were delivered on their attempts to do a platform were not industry-leading. And so, the customer had to make a tradeoff between…worse capabilities, but in one place, or best-in-class capabilities. And that’s a hard tradeoff in cybersecurity. That is one thing that we’re not asking our customers to do. We’re making sure that everything we do is industry-leading on its own.

CEO Nikesh Arora has made similar remarks:

What we want is best-of-breed products, so we decided we’re going to do both. We’re going to have phenomenal success in best-of-breed categories. In addition, we’re going to make sure our best-of-breed products were integrated.

The implication seems to be that if a vendor assembles a platform from the best SIEM solution it can acquire, the very best EDR tool, the best automation products, etc., then customers will get something like the platonic ideal of a security platform.

But despite the ostensible newness, this approach betrays a fundamentally conservative view of the security industry.

For Klarich and Arora, there’s an unspoken assumption at work here: Security teams must get the capabilities they need from a product—ideally, one with the right or “best” set of features.

But this is nothing new at all. Whether the capabilities come from multiple point tools, or from a platform made up of acquired, repackaged, and bundled “best-of-breed” security products, the basic model is the same. You buy a product. You get features that give you capabilities.

Product features != capabilities

LimaCharlie was founded to challenge this assumption. We began with a simple question: What if core cybersecurity capabilities and infrastructure could be delivered, not as features of some vendor’s product, but directly through a public cloud-like environment instead?

The SecOps Cloud Platform (SCP) is the realization of this vision. It gives security teams capabilities in the same way that AWS or GCP does for IT: as interoperable, cloud-native primitives, available on-demand and priced pay-per-use.

Think, for example, of the capabilities currently offered by security information and event management (SIEM) products. SIEMs ingest, standardize, and centralize log and other telemetry data; they enable real-time monitoring and coordination of event information; and so on.

But these capabilities don’t have to be delivered as product features. It’s perfectly possible to provide those same capabilities directly and abstractly*—*which is precisely what the SecOps Cloud Platform does. The SCP makes it possible to ingest logs and file types from any source, standardize all telemetry data to a common JSON format, and run everything through a detection, automation, and response engine for correlation, analysis, and alerting. The kind of mature, well-integrated capabilities that were once only obtainable through SIEM products are now available via a public cloud for security.

This change offers enormous benefits. Because it is a public cloud, the SCP enables security teams to utilize platform capabilities as much or as little as they want, and in exactly the way that they want. They also avoid the downsides of legacy security products like integration difficulties, vendor lock-in, rigid long-term contracts, and unpredictable costs.

In the case of SIEM-like capabilities, this means users can reduce reliance on one of their highest-cost tools, customize event management workflows more flexibly than ever before, and take unprecedented control of their security infrastructure.

The SCP offers similar benefits across the spectrum of security operations. Capabilities that any SOC or MSSP would require for endpoint detection and response, historical threat hunting, observability, security automation, and more are now available through a unified public cloud platform that integrates seamlessly with the rest of the stack.

In short, although PANW and others say that they’re building security platforms, there’s a massive difference between their approach and the cloud provider model that the SCP embraces.

Practitioners over products

There are many ways to describe the difference between the SecOps Cloud Platform and the version of platformization pushed by traditional product vendors. But the most essential is this: The SCP prioritizes empowering security practitioners rather than the products they use.

Given the challenges facing security teams, we believe that this approach is the only one that makes sense.

Nearly everyone working in cybersecurity acknowledges that solution sprawl is a serious issue; feels that tooling and infrastructure have become complex to the point of unmanageability. But there’s a good reason for all of that complexity. Modern security operations are inherently complex. Organizations all have different security needs, and those needs are constantly changing and evolving. There is no “best” product—or suite of products—that will fix that problem. The future of security lies in human intelligence, automation, and customization, not in any one vendor’s product.

Platform vendors are correct when they say that simplification and consolidation are necessary. But they’re mistaken if they think a bundle of point solutions masquerading as a platform can ever accomplish that—let alone meet the bigger challenges in our industry.

The way forward is to give security teams direct access to mature, integrated capabilities, allowing them to fully operationalize their knowledge and expertise.

The perfect cybersecurity platform doesn’t exist. But not all platforms are created equal. The future of cybersecurity belongs to platforms that empower practitioners to build the stack and SecOps program they need to ensure the best possible security outcomes.

How cybersecurity can move beyond an old dilemma

Many cybersecurity teams struggle with a common question: Do we buy security tools and infrastructure from a vendor, or build what we need in-house? But what’s often overlooked is that this issue has already been solved in many other areas of general tech—with our industry lagging behind.

The buy–build conundrum in cybersecurity

Security practitioners need high-quality tooling and infrastructure. Until now, there have only been two real ways to meet this need—each with advantages and disadvantages.

Organizations that buy security solutions get:

• Robust, proven technologies (+)

• Less development and maintenance work (+)

• Scalable solutions and workflows (+)

But they must contend with:

• Hard-to-customize solutions, making tailored implementations difficult (-)

• Black-box tools that make it impossible to achieve provable security (-)

• Increased costs and vendor lock-in (-)

In short, though the quality of purchased solutions is generally sound, this route carries serious operational and business risks. Lack of control over the stack places limitations on an organization’s security operations and internal workflows. And over time, the total cost of ownership (TCO) of vendor-supplied tools can become excessive. For managed security service providers and startups, infrastructure costs may even threaten profitability.

For this reason, many security teams opt to build some capabilities internally (whether that means assembling what they need from open-source components or literally coding custom solutions themselves).

This approach offers undeniable benefits:

• Full control of and ownership over mission-critical solutions (+)

• The ability to customize stack, operations, and workflows for optimal security outcomes (+)

• Cost savings and access to capabilities that might otherwise be unobtainable (+)

But the trade-offs here can be significant:

• Skilled team members must spend substantial time and effort on building solutions (-)

• The hidden, long-term cost of ongoing infrastructure maintenance (-)

• Increased complexity in the stack and problems integrating with other tools (-)

Thus, while the savings and control are attractive at first, this approach carries other kinds of costs over time. Teams overwhelmed by the challenges of maintaining in-house tools may lose focus on security operations. Managed security services providers frequently encounter problems when they try to scale a business built on a DIY stack.

Often, there is no clear right answer to the buy or build dilemma, and security leaders may feel forced to pick the “least bad” alternative. And that’s why it’s time for a better option.

The public cloud for cybersecurity

The irony of our situation is that these problems have already been solved in other areas of technology. For example, consider the case of a large retail pharmacy chain looking to deploy a prescription provisioning and point-of-sale system. In the past, they would either have had to conduct an extensive search to identify a vendor with an ideal solution, or hunt for an open-source stack to meet their needs. But today, they would simply assemble the required compute, storage, queueing, databasing, and so on from public-cloud components offered by AWS, Microsoft Azure, Google Cloud Platform, or another provider.

We take this for granted these days. The public cloud model has been so successful that some of the problems that used to face engineering, development, and IT groups now seem almost quaint. For our colleagues in other technical fields, there’s no longer a need to buy certain solutions outright, or build them independently, because core IT capabilities already exist on demand—ready and waiting to be consumed, with pricing based on usage.

LimaCharlie’s basic premise is that this is exactly what’s missing in cybersecurity. The SecOps Cloud Platform (SCP) is our vision for the future of the industry.

The meaning of “core capabilities on demand”

To be clear, when we talk about access to core cybersecurity capabilities, we’re not implying that there is a one-size-fits-all solution that can meet all needs, or suggesting a rip-and-replace approach to security infrastructure.

We’re making a far more modest claim: Namely, that the foundational capabilities required to secure and monitor any organization are now well-understood enough to be delivered via a public cloud. This would include things like deploying bi-directional endpoint capabilities through a multiplatform agent; alerting and correlating log telemetry regardless of source; automating real-time analysis and response in any environment; observing, transforming, and routing telemetry data regardless of source or destination; and more.

Note that these are not esoteric capabilities. In 2024, they’re simply table stakes for modern SecOps. There’s no need for teams to reinvent the wheel by attempting to develop them independently. Nor is there any reason to rely on legacy vendors when these capabilities are available as mature, integrated, cloud-native primitives—on-demand, API-first, and pay-per-use.

Benefits of the SecOps Cloud Platform

When foundational security capabilities are made available through a SecOps Cloud Platform, tremendous benefits emerge:

• Teams can assemble the stack they need, customize it as much as they want, and manage everything from a single, scalable, well-integrated platform—without getting bogged down in development work and infrastructure maintenance.

• Organizations of every size, from large enterprises to managed security service providers and startups, can eliminate tool sprawl, free themselves from vendor lock-in, and reduce costs.

• Pay-per-use pricing makes it possible to scale usage up or down as needed. There are no mandatory long-term contracts, fixed minimums, or capacity planning as there are with traditional vendors.

• Modular, on-demand capabilities allow organizations to use only those elements of the platform that they truly need (or that they are currently ready for). The SecOps Public Cloud can be adapted and integrated into a team’s operations safely and gradually.

• MSSPs and MDRs are able to work with mature tools that they control—and are not forced to rely on vendors who are also competitors.

• Security teams in every kind of organization can focus on their true mission: improving security operations and delivering better security outcomes for stakeholders.

The future of our industry

We believe that cybersecurity practitioners will one day join their peers in IT and reap the benefits of the public cloud model. This is still an idealistic vision—but one that’s gaining momentum with each passing year.

I recently had an enlightening chat with Tyler Shields, and a question I've often been asked came up: "Why did you start LimaCharlie?" Though I've always had an answer, only recently did I realize it's not just about "what tools did I wish I had", but also what we want to leave for the next generation.

As someone who's been in the security industry for a long time, starting in Intelligence, then Crowdstrike, Google, and Chronicle, I've seen history repeat itself. I've witnessed old solutions get rebranded as new and the same patterns keep repeating.

While some patterns are great, like new people learning about security and picking up the mission, others aren't as nice. Truthfully, they're patterns the security industry shouldn't be proud of.

So, when I think about my time in security and look to the future, I ask myself: What do I want the next generation of security professionals to live with? How do I want them to think about the challenges they're facing?

One answer is clear to me: I want them to live in a world where they're enabled by tools to create new solutions. I don't want them to feel like they're fire-fighting from one technology to the next, trusting on blind faith in an all-mighty vendor.

I refuse to let a future where security professionals have a "choice" between three vendors, each with their opaque walled gardens, claiming to stop breaches better than the next.

What I want for the future generation is simple and has been done elsewhere. What I want for them is not rocket science. We just haven't done it in security yet.

Throughout my career, I've wanted incredibly easy access to powerful tools that put me in the driver's seat, and now that I'm in a position to impact the future, that's what I want to the next generation.

Our cousins in the general tech world have had this for a while now — it's called a Cloud Provider. These Cloud Providers have opened up a world of powerful solutions, innovation, and velocity that the tech world could never have had if it had remained subservient to "boxed software" vendors. These Cloud Providers give tools ("primitives") to professionals, get out of the way and don't force their users into complex bundles. A Cloud Provider gives you the keys, you're not just a passenger.

A Cloud Provider for Cybersecurity might sound weird at first, but it makes so much sense that I haven't been able to shake it off since starting LimaCharlie.

That is why I started LimaCharlie. Every time I get tired at the end of the day, I think of that alternative future and refuse to let the next generation down.