Which Camp Are You In? Prevention or Operations

I've been making a mistake

I recently realized I'd been getting something wrong.

I sat down with a security team to explain AI SOC. I showed real attacks against Microsoft 365, some of them brand new. Then I showed how an AI SOC responds when those attacks succeed. I thought that this made the presentation more grounded in reality.

The team heard something else. They didn't ask what happens when things fail, which is what AI SOC is about. They asked why the failure happened, and the answer was always the same: "We don't have that problem." Every attack had a prevention fix: a setting they already had, or one they could add.

We were looking at the same problem and seeing two different solutions. They saw a prevention gap to close. I saw a need to find and resolve prevention failures.

I reflected on this presentation with my buddy Dave. (Yes, his name really is Dave.) He's spent years selling security to large enterprises. "Chris," he said, "this is our industry. We hire people who don't understand operations. They understand IT. They understand buying products and deploying them to fix problems."

Operations exists because prevention fails

I believe in a simple mantra: security operations exists when prevention fails. Otherwise, it's just IT.

If your controls never failed, you wouldn't need anyone to review data, read logs or check that things are working. You'd install the product, make it run and move on. That's IT work, and it's honest work. But it isn't operations.

Operations starts from the opposite assumption: something will get through. A setting will drift, a fallback will be left on, a vendor will make a mistake, a user will approve the wrong prompt. Operations is the discipline of finding out when that happens, and fast.

Seatbelts and airbags

Prevention matters. We want to stop every attack we can, and good prevention is hard, careful work. But think about how a car is designed. Brakes, lane assist and collision warnings are there to stop the crash. Seatbelts and airbags are there because the crash will happen anyway.

Nearly every security product talks about the brakes: how the product blocks attacks and stops bad things from happening. That's worth having. But running a SOC isn't patching the world with products that prevent. The CISO's job is to design a system that protects the company when those products fail: detect the failure, decide the response, and actually carry it out.

So the conversation has to start with an agreement: things fail. Once we agree on that, we can talk about how an AI SOC finds the failure and responds to it. If you don't believe things fail, an AI SOC gains you nothing.

Two camps

Most security leaders fall into one of two camps. It comes down to one question: do you believe prevention will stop everything, or do you believe you need a SOC?

The prevention camp isn't lazy. Often it's the opposite: proud of what it has built. That pride is what makes it hard to see the flaw.

Why the prevention belief is dangerous

Security is built to prevent attacks. But prevention is more than guarding against accidents. Prevention is up against attackers who deliberately work around the controls and keep adjusting their tactics.

Vendors will eventually fix the attacks I show today. Until each fix ships, two things happen. Attackers keep exploiting the gap. And attackers start working out how to get around the new fix.

Take passkeys. Microsoft and Google are rolling out passkeys, and passkeys are excellent. We don't need to debate their specific weaknesses. However good passkeys are, the technology will have imperfections. Attackers also aren't waiting for every organization to switch. Attacker-in-the-middle proxies and device code phishing still work against organizations on older sign-in methods. Meanwhile, we're already seeing attacks aimed at trusted devices and passkey sign-in.

Most people miss this: attackers progress too, and not only with zero days. Attackers go after the structure and implementation of the defenses themselves.

Security is a tombstone business. Defenders make changes based on the dead bodies.

Passwords are the clearest example. Attackers stole and guessed passwords, so defenders added multi-factor authentication by SMS. Attackers learned to intercept SMS codes, so defenders moved to authenticator apps. Attackers learned to spam approval prompts and steal sessions through phishing proxies, so defenders are now moving to passkeys. Each new defense worked until attackers adjusted.

That cycle never ends. Defenders come up with new solutions, and attackers come up with new attacks. That is the reality of security.

However good prevention is, prevention will fail. So we still need the ability to detect when prevention fails, and processes to recover from that failure. The idea that "we won't fail" is the dangerous belief.

That belief assumes you will outsmart the criminal, as if the threat were a static problem. The threat is not static. Attackers change their methods in response to what you do. This is a question of strategy, not engineering.

A tale of two hospitals

Neither camp, preventions and operations, is a perfect answer. But I've watched how the two camps play out, and the history is interesting.

I worked with two hospitals, one in Kansas and one in Dallas. The Kansas hospital did work on prevention, but put significant time and money into detection and response: looking for issues to resolve. The Dallas hospital focused completely on prevention.

Month to month, Kansas looked worse. The Kansas team found issue after issue that needed resolving. One phishing campaign convinced hundreds of employees to redirect their paychecks to a foreign country. The Kansas team detected the campaign while the campaign was running and kept most people from being affected. The campaign still caused damage, and the Kansas team still had to clean it up.

Dallas, meanwhile, didn't have a single issue for nine months. The antivirus was killing threats. The firewall was working like a champ. On paper, the Dallas engineers were outperforming the Kansas team.

Then Dallas got ransomware and had to shut down hospital facilities. Attackers had been inside for months, stealing data. When the attackers had taken as much value out of the hospital as they could, they encrypted everything. Dallas never knew its opponent was there until the ransomware started locking systems down.

Both hospitals had problems. Kansas had problems all the time, and saw them. When Dallas had a problem, Dallas had no way to see it, because prevention kept reporting that everything was working. The problem festered and grew until the hospital broke.

That's the difference between the two camps. Day to day, the prevention camp looks better. The operations camp sees the outages and the issues, so the operations team is fixing problems constantly. Maybe the operations team misses a data feed for a couple of weeks. The prevention team never had the data feed in the first place.

Industry breach reports keep putting the time to identify a breach at around 200 days. That number exists because prevention-focused companies don't see the breach until the breach surfaces as ransomware or an outage. By then the damage is massive, because nobody caught the problem early.

Look at the camp you built

Asking "which camp are you in?" doesn't work. You already know what this article argues, and you'll shape your answers to match. A more honest test is to stop asking and look at what you've built: how you spend money, and how your people operate.

Start with your SIEM. Is the SIEM there for compliance and reporting, or for detection and response?

Then look at your people. Many security teams are organized to cover themselves. When something fails, the team that built the control says someone else implemented the control wrong. How well the control was implemented doesn't matter. The control will still fail eventually.

A SIEM, the basis of a SOC, is a decision-making tool. A SIEM should highlight the issues that need decisions: find gaps, surface problems, and help the team understand an issue and resolve it. That is dynamic defense, and a team built around dynamic defense is in the detect-and-respond camp.

If your focus is configuration, patching and confidence that you won't have a problem, you've built the prevention camp.

Be honest about your answer

There's no shame in being in the prevention camp. Good prevention is the foundation, and a lot of it is hard, careful work. The danger is believing prevention is the whole job.

If you're in that camp, you don't need a SOC, AI or otherwise. Install it, make it run, and good luck. But be honest that you're running IT, not security operations.

When I was brought in to fix the DoD CERT, Mark Ruchie had been running the operations and stayed on to run the floor. Mark had the right insight. Every morning he walked in asking himself one question: "What did I miss?"

Mark never assumed everything was fine. He believed there was always a problem he wasn't seeing yet, so every day he went looking for it. With that mindset, Mark was well ahead of the curve on what a security operations lead should be.

If you've read this far nodding, you're probably already in Mark's camp. You assume you're wrong somewhere, and you want to find out before an attacker does. Those are the people I like talking talk with.