All insights

Public-Sector CISO

The Security Theater You Built and Can't Stop Performing

Most security programs don't fail during attacks. They fail during audits they pass. Here's why looking secure is more dangerous than being vulnerable.

Jason Walker

.6 min read

Here is the scenario I keep running into: an agency passes its annual security audit with a clean report. Green dashboards, completed checklists, signed-off controls. Everyone shakes hands. Three weeks later, a simulated attack path cuts straight through the organization in under an hour.

The audit wasn't wrong, exactly. The controls existed. They just didn't work.

This is the core rot in enterprise cybersecurity, and most practitioners won't say it out loud because it implicates too many decisions they made themselves. We have built an industry around looking secure instead of being secure. And the difference between those two things is not a matter of degree. It is a different religion entirely.

I run enterprise cybersecurity at the state level, covering dozens of agencies, hundreds of thousands of devices, and workforces that span every function of government. The scale is not the hard part. The hard part is the same problem every security leader faces, just multiplied until it becomes unavoidable: control debt.

Control debt is what happens when you add faster than you remove. Every security program does it. A new threat emerges, you add a control. A new regulation lands, you add a process. An auditor flags something, you add a layer. Nobody ever asks what that control costs in behavior change, in friction, in the workarounds people invent when the approved path is too slow. And nobody ever comes back twelve months later to ask whether the original threat still justifies the overhead.

The result is a security program that looks, on paper, like a fortified position. In practice, it is a maze that only the attackers know how to navigate, because the defenders are too busy managing the maze to run drills inside it.

Inertia explains most of this. Removing a control carries visible risk. If you eliminate a process and then something goes wrong, the question is immediate: why did you remove that? Keeping a useless control is almost always invisible risk. Nobody asks why it's still there. Nobody calculates what it costs in alert fatigue, in staff time, in the cultural message it sends that security is about procedure rather than outcome.

That asymmetry between visible and invisible risk is where programs go wrong. It is also where leadership matters most.

Nuclear power plant operations run on a discipline called configuration control. You do not change the system without a formal process that asks: what does this change affect, what does it cost, and what happens when we remove it? The instinct in cybersecurity is the opposite. Adding a control feels like action. It feels like response. Removing one feels like exposure. But the discipline cuts both ways. A control that does not reduce meaningful risk is not neutral. It consumes attention that could be spent on a control that does.

I use natural forcing functions to do this work. When a new team member arrives, I put them in front of our control inventory before they learn to see it the way we do. New eyes find the things that institutional familiarity has made invisible. When a technology shift hits, I treat it as a review trigger. Artificial intelligence is doing this right now. Half the controls built around perimeter assumptions do not translate cleanly to an environment where the edge is everywhere. That creates a legitimate reason to go through the inventory and ask: does this still hold its weight?

The harder discipline is doing it without a forcing function. Scheduling a control review when nothing is on fire, when the audit is clean, when the dashboards are green. That is when it matters most, and that is when almost nobody does it.

Vendor research does not help here, and I want to name that directly. The security industry produces a constant stream of commissioned reports designed to tell you that the threat you are facing is the one the commissioning vendor sells a product to address. Three quarters of CISOs are concerned about some particular attack vector. Whatever it is. The report exists to create pressure, not to inform. I do not read those. They are noise with a logo on it.

What does help is impartial data that does not have a product at the end of the hallway. The Verizon Data Breach Investigations Report is the clearest example in this industry. It tells you what is actually happening across real breaches, without steering you toward a buying decision. That is the kind of signal worth building a program around, not the statistical theater that validates the investment you already made.

The honest version of a security program review asks one question about each control: does this meaningfully reduce risk or improve outcomes? Not: does this satisfy the auditor? Not: did we add this after an incident and feel safer for it? Not: will removing this look bad if something happens?

Does it reduce real risk or improve real outcomes?

Most programs cannot answer that question for a significant portion of their control inventory. Not because the practitioners are incompetent, but because the question was never built into the process of adding controls in the first place. You cannot audit your way out of a failure to ask the right questions at the beginning.

The path forward is not complexity. It is discipline applied backward through what you have already built. Run the audit in reverse. Take your control inventory and simulate what an attacker actually does with it. Find out what the green dashboard is hiding. Then have the harder conversation: not what should we add, but what should we eliminate because it is costing more than it protects.

Looking secure is a performance. Performing it well enough passes audits and satisfies reporting requirements. It does not stop breaches. At the scale I operate, the gap between those two things is not a rounding error. It is the difference between a program that holds and one that collapses the first time someone stops performing and starts attacking.

The measurement that matters is not what your dashboard says. It is what survives contact with a real threat.

Start there.

Keep reading

Weekly writing from inside the work.

Practitioner-researcher essays four times a week. No spam, unsubscribe in one click.

Subscribe

Weekly writing from inside the work.

Field observations and framework critiques from a practitioner-researcher running cybersecurity at scale. AI in operations, FAIR risk research, and the leadership patterns that hold both together. No spam. Unsubscribe in one click.