Buy Layers, Not Logos – by Laurent Hausermann

Hello Cyber Builders 🖖

You might be the only security person at your company. Maybe you’re 3 plus the interns. Your boss is worried about AI-driven attacks. Your vulnerability list keeps getting longer. The number of SaaS apps your company uses keeps going up. Your budget stays the same.

So you end up asking the real question: How do I cope?

Over the last 5 years, many organizations have turned to subcontractors to add a key layer of security: true Detection and response capability. An MSSP. Managed Security Service Provider.

I have spent a lot of time writing about what to build. This week, I want to flip things around and look at it from the buyer’s side. I am starting with the very successful MSSP business and analyzing what they cover and what they are missing. Don’t blame me; I am sure there are many different setups, and some MSSPs actually do what I am saying below, while others don’t. I am trying to reflect how I feel the overall market is doing.

Many companies have no large budget. They focus on their core business. Unless they are a bank, an insurance company, a pharma company, or a critical aerospace or defense manufacturer, they don’t run a large security team.

In the 2026 Cybersecurity Buyers’ Guide, I read some interesting stats: almost 50% of the cybersecurity teams (48%) have fewer than 5 people. So they do what makes sense. They turn to a service provider, an MSSP. The same report shows that 33% of the Endpoint Security market is outsourced.

I expect this number would be even higher for companies with fewer than 1,000 people. Most businesses fall into that group. I think they are making a reasonable choice. But I am not sure they always know what they are actually getting. The sales pitches are big, and it can feel like you are buying a lot of security, but you are not.

Moreover, chatting with security pros (helloFede Meiners!), I realized many organizations are also buying accountability. They offload detection problems to a subcontractor that does the heavy lifting, ensures 24/7 monitoring, and can be blamed when needed.

For this post, I want to focus on security operations: the detection and response your MSSP provides. We are not discussing GRC, AppSec, or Awareness here.

Your MSSP almost certainly gives you an EDR. Probably a SIEM. Maybe an XDR. Maybe some threat intel on top.

In plain words: an agent installed on your laptops and servers (the EDR), a central place to collect all the logs (the SIEM), and a team that watches both.

That is a real first layer of security. It watches your endpoints and your servers. If something suspicious shows up, it can tell you an attack has started, lateral movement or exfiltration, and the signs you need to respond to. Picture ransomware starting to run on an employee’s laptop: the EDR recognizes the behavior, an analyst confirms it, and you get a call before it spreads. You could even quarantine the laptop before it does any damage. It works because it detects what is already known: the most common attacks, the ones vendors have already turned into detection rules.

It is a base layer. It watches the core of your infrastructure for attacks everyone sees. It does not know your business. It often doesn’t even collect telemetry, just alerts. It has no custom detection scenarios for what really matters to you or drives your revenue. It also does not protect you from zero-day attacks or spot new threats before they are known. I will come back to this in Layer 3.

Ask a bank what its SOC does. It does not only watch endpoints. It starts by identifying where the most important IT systems for the main business line are. This is often hard to map, but it gives general managers a real understanding of security costs.

How does it work? In four steps:

1. List your business-critical processes (payments, payroll, production, customer data) and assign an owner to each.

2. Map the IT systems that support each process.

3. Document the attack scenarios that would cause harm. Many companies use compliance and risk analysis to do that.

4. Collect the required telemetry, such as corporate Endpoints, CMDB, Directory, network monitoring, or firewalls.

5. Monitor to detect whether one of those scenarios is happening.

That is a different job.

The first layer asks, “Is something suspicious?”

The second asks, “Is something happening that would hurt my company?”

Most MSSPs do not do this by default. A payroll fraud scenario at a mid-sized manufacturer isn’t a known scenario for their analyst. To them, a payroll administrator logging in and changing a bank account number looks like normal activity.

To you, it might be the first step of a fraud. Their talented team focuses on malware detection, the latest campaigns generating high alert volumes, and vulnerabilities that expose your infrastructure. Nobody can bundle a specific threat scenario into a generic detection pack.

If you have a small security team, getting to layer 2 is tough. Most of your time goes to compliance, picking and managing your MSSP, incident response, and some special cases like OT security or AppSec. That is why most companies never get to this layer.

The last layer is about anticipating. People call it threat hunting. I think that term is misleading. You are not hunting for fun. You are buying time against attackers who are already active.

To see why that time matters, let’s follow a vulnerability from the first flaw to the detection rule that ends up in your EDR. Most buyers never see this process, so I will walk you through it. Then I will show you where the gap is, and why some attacks still get through even if your EDR is working.

The normal path. It has five steps:

1. A researcher, or the vendor’s own team, finds a flaw and reports it privately.

2. The vendor, or a coordinator, gets a CVE ID reserved for it. CVE Numbering Authorities (CNAs) assign IDs: Microsoft, Oracle, and Red Hat for their own products, and MITRE for everything else. The ID can exist, marked “reserved,” long before anyone can read about the flaw.

3. The vendor builds and tests the fix. In the best case, the patch, advisory, and public CVE record go out together.

4. The NVD adds its scoring and product data, which your scanners rely on. Because NIST now prioritizes enriching CVEs already in CISA’s KEV catalog, many new CVEs wait in the queue.

5. If attackers are seen exploiting the flaw in the wild, CISA adds it to the Known Exploited Vulnerabilities (KEV) catalog.

In this case, you get a patch before attackers have a working exploit, and your detection vendors have time to write rules.

Now let’s flip the order. The attacker finds the flaw first, and nobody else knows about it. This is what negative time-to-exploit means: attackers start exploiting before a patch exists.

Here is an illustration, with a made-up VPN appliance and rounded numbers:

• Weeks before disclosure: the attacker quietly compromises a few carefully chosen targets through the appliance. No CVE, no patch, and no signature.

• Day 0: one victim notices something odd, such as an unexpected admin session or an outbound connection from a device that never calls out. They bring in an incident response team.

• Days 1 to 10: the responders collect evidence, find the malicious activity, and extract indicators such as IP addresses, file hashes, and account names. Then they work backward to the root cause: a flaw in the appliance itself.

• Then: they report it privately to the vendor, who reserves a CVE ID, reproduces the bug, prepares the fix, and tests it.

• Finally: the vendor ships the patch with an advisory. Detection vendors turn the indicators into rules, and, if exploitation is widespread, CISA adds the CVE to KEV.

Only at the very end does anything reach your EDR or your MSSP’s detection pack. Until then, only the victim and the attacker know what is happening.

This is not an edge case. Mandiant’s M-Trends 2026 puts the mean time to exploit at an estimated minus seven days, which means exploitation routinely happens before a patch exists. Exploits were also the most common way in for the sixth year in a row, at 32% of intrusions. And it moved fast: Mandiant measured 63 days in 2018 and 2019, and five days in 2023. In 2023, 12% of the n-day vulnerabilities in its sample, the ones with a patch already available, were exploited within a day.

From the first real signs of a new attack to the time a generic detection is built and running in your MSSP’s tools, you have about five to ten days at best. That is your window.

Hunting is what happens in that window, and it has three steps. Someone reads the latest advisories and incident reports. They turn each one into a specific question about your environment. Then they check if the answer is already in your logs.

For the VPN example, you would ask: which appliances do I have, and has any of them started a session, created an account, or opened an outbound connection I cannot explain? Your EDR will not ask you that. It has no signature to match, and many network appliances have no agent at all. That is why groups target VPNs and routers without EDR telemetry.

When attackers know that third-party tools raise alerts, they stop bringing their own. They use what you already have installed. That is called living off the land. People say it is invisible, but it is not.

Take the Chinese state-sponsored group Volt Typhoon, described in the CISA advisory AA23-144A. It used tools that ship with Windows:

• wmic to query the drives of a machine

• ntdsutil to copy the Active Directory database from a domain controller

• vssadmin to create shadow copies of locked files

• netsh portproxy to forward traffic through a compromised machine

• PowerShell to read logon events

Microsoft signs all of these binaries. Every command is something a real admin might run, like when backing up a domain controller. That is why a signature cannot match, and why a single command does not prove anything.

But here is the myth: your EDR does see these processes. It lacks the context to know whether this specific process is an attack.ntdsutil, launched through wmicIf it happens at 3 a.m. on a domain controller by an account that has never done it before, that could be an attack. In many environments, default logging doesn’t even record the command line because you have to turn on process-creation auditing, WMI logging, and deep PowerShell logging.

Today, many live-off-the-land campaigns are far from perfect. Attackers need more tools, run enumeration, or create persistence hooks that the EDR/XDR finally catches. I expect that with AI capacities – “Help me make this more stealth and test it against my lab” – Attackers will not ring bells here.

So the answer is not a smarter signature. You need a baseline of what your admins normally do, logging that captures it, and someone who asks the right questions about the exceptions. That is layer 2—what matters in your business—combined with layer 3—what attackers are doing right now.

Now let’s talk about AI.

The conversation today is about the AI SOC, and most of what is sold under that name is alert triage and enrichment. That is real progress, and I don’t dismiss it: a survey the research firm SACR cites in its AI SOC market landscape found about 960 alerts per day per organization, 40% never investigated, and an average of 70 minutes to investigate one. Cutting that is valuable.

But look at where the value lands. Triage and enrichment make the analyst faster at layer 1, which mostly increases the MSSP’s margin. SACR’s 2026 report goes in the same direction: vendors’ summaries suggest investigation has become common across the market, and the open problem is the “action gap” between a validated incident and a safe, verified response. As SACR notes, AI SOC platforms aren’t detection engines on their own; they analyze alerts other tools generate.

So the real question for you as a buyer is not “does my provider use AI?” It is “what does AI actually change in each layer, and what does it not?”

Layer 1: faster, not deeper. AI is good at pulling facts from your EDR and identity systems, summarizing alerts, and closing obvious false positives. This makes analysts more productive and should lower the base layer’s price. But it does not give you any new detections.

Layer 2: only as good as your business context. This is where AI can help the most, and also where it fails most often. Filip Stojkovski in his SecOps Unpacked post, Your Basics Still Matter, he makes the point clearly: AI can turn messy documents into structured context and learn from analyst feedback, but it cannot tell who owns a system, how critical it is, or how a service account should behave. That knowledge usually lives in an unmaintained CMDB, a spreadsheet, or someone’s head. His rule is simple: no good asset and identity context, no AI SOC magic. So AI can help you write and maintain your scenarios faster, but a human who knows the business still has to say what matters.

Layer 3: a good assistant, not an oracle. AI can help a hunter turn an advisory into queries across your logs, which is exactly what a five-to-ten-day job looks like. But language models don’t know about threats not in their training data, and anomaly detection only works if you have built a baseline. The intelligence has to come from somewhere.

If you remember one thing, remember this: an MSSP with an EDR and a SIEM gives you a solid layer 1. That is a good choice for a small team. The mistake is thinking it also gives you layers 2 and 3.

Before you renew or sign, ask your provider four questions, and listen carefully to the answers:

1. What do you monitor for my business-critical processes, beyond my endpoints?

2. Who wrote my attack scenarios, and when were they last updated?

3. What do you do about attacks that aren’t yet in a CVE or KEV, and how quickly do new advisories become checks in my environment? What metrics do you track for this?

4. Where do you use AI: to cut costs, or to improve coverage in layers 2 and 3?

The answers will tell you which layers you are really getting. Then you can decide which ones you cover yourself, which ones you ask for, and which ones you are willing to leave open for now.

But as a customer, get ready to pay more for Layer 2 and Layer 3. If you want to distinguish marketing pitches from real security value, there is probably a cost. No magic wand or tools can do this for free.

If you build security products or services, focus on layers 2 and 3. Layer 1 is crowded and bundled. Layers 2 and 3 are where mid-sized companies lack answers. This is where AI, combined with real business context and fresh threat intelligence, can finally change the economics for companies that will never run their own bank-grade SOC.

This is yet to happen

Laurent 💚