Security Brutalism: A CISO's Guide to Operational Clarity

This is the second post in a series exploring the concept of Security Brutalism and its real-world applications. It focuses on helping CISOs grasp the significance of Brutalist Security and communicate its value effectively to executive leadership to gain buy-in.

Cutting Through the Complexity

Today's enterprise security landscape is paralyzed by complexity. It is bloated with overlapping tools, legacy controls, and compliance theater that distract from true risk reduction. For CISOs and security leaders, the result is a program that's difficult to manage, harder to explain, and nearly impossible to measure in terms that matter to the boardroom.

Security Brutalism is a response, not a rebellion. It doesn't throw out frameworks or maturity models, but it demands they be subordinate to effect. It's a strategic mindset for CISOs who want their security programs to be lean, fast, and outcome-driven.

The programs that got breached were mature. That's what doesn't get said enough. Recent breaches happened in companies that weren't understaffed startups running on good intentions. They had security organizations, compliance certifications, tooling budgets, audit histories. The breach didn't happen because nobody was trying. They were trying to answer a different question than the one that matters under pressure.

Most security programs measure coverage. Do we have a SIEM? Is MFA deployed? Are we certified? These are reasonable things to track if the goal is satisfying an auditor. They operate on a different axis than survivability. Coverage and survivability are different questions, and optimizing for one doesn't move the other.

The question that matters is simpler and more uncomfortable: if we get hit today, how long do we stay failed?

That reframe is the core of Security Brutalism. Every control, tool, and policy gets evaluated against three dimensions: does it reduce the realistic paths an attacker can use to reach consequential systems? Does it limit what an attacker can do once inside? Does it shorten the time between compromise and recovery? If a control doesn't move at least one of these, it adds attack surface without improving the ability to survive.

The shorthand is four words: Know. Harden. See. Recover.

Start with Consequences, not Controls.

Before anything else, build a consequence map. Not a risk register with probability scores and color-coded heat maps. A ranked list. Which systems, if compromised, would end the company or create irreversible damage? Which are painful but recoverable? That ranked list tells you where to spend every subsequent dollar of effort. Without it, security becomes whack-a-mole. You harden what's loudest, detect what's easiest to detect, and recover the systems that were easiest to test. Those may have nothing to do with what would actually hurt you.

Know what you actually have

The gap between what your architecture diagram shows and what is actually running right now is almost always larger than anyone expects. Every organization has more identities than they think: service accounts that outlived the projects that created them, API keys that were "temporary" two years ago, CI/CD pipelines with production access nobody documented, OAuth tokens granted to SaaS tools nobody uses anymore. Those identities are the attack surface. Stolen credentials are the entry point for most consequential breaches. An attacker who buys access from an initial access broker, or phishes a service account with standing production permissions, doesn't need to defeat any control. They're already inside the trust boundary. The inventory you need isn't an asset management spreadsheet. It's a map of what can authenticate to what, what can reach what, and what data flows where, prioritized around the consequence map.

Harden by subtraction

Hardening is usually framed as addition: deploy this tool, enforce this policy, add this control. The brutalist move is the opposite. For each tool in your security stack, ask what specific attack path it prevents, what damage it limits, or what recovery time it improves. If the answer leans only on "compliance" or "we've always had it," that tool is a candidate for removal. Some of these tools run with elevated privileges, integrate widely across systems, and generate alert volumes that reduce sensitivity to meaningful signals. They can expand your attack surface rather than reduce it. Apply the same logic to access. Every standing permission, every long-lived credential, every integration without a documented current use: revoke it. Trust is a liability that accumulates silently and depreciates quickly.

Detect genuine compromise, not auditor-friendly coverage

The standard to hold detection to is this: do you know when any of your consequential systems are being attacked, before the attacker reaches their objective? Not whether you have a SIEM. Not whether you have full log coverage. Whether your detection produces a signal about actual adversary behavior before damage occurs. Most programs have high alert volumes that nobody reads, and teams normalize ignoring alerts because the signal-to-noise ratio is too low to act on. That normalization is the most dangerous thing in your detection stack. A high-leverage investment is deception assets: honeytokens, canary credentials, and honeydocuments placed where only an actively exploring attacker is likely to find and use them. These tend to have very low false positive rates. Pair them with behavioral baselines on consequential systems and detection for lateral movement, not just arrival at the final target.

Recover with evidence, not assumption

This is where most programs become disconnected from reality. They have incident response plans, backup policies, and recovery time objectives documented in governance documents. Almost none of them have measured whether any of it works. The survivability test: assume a realistic attacker has access right now. How long before your team understands what's happening? How long to revoke access and contain the system? How long to actually restore from backup, not verify the backup exists, but restore it to a test environment and time it? The gap between what incident response plans say and what actually happens when you measure it is almost always large. That gap is your real security posture. The only way to close it is to measure it regularly: quarterly restoration tests, chaos engineering exercises against actual attack paths, incident response drilled on realistic scenarios tied to the consequence map.

The Entropy Problem is a Leadership Problem

Security degrades the moment a system goes live. Teams change and institutional knowledge walks out. Engineers add integrations that don't get documented. Exceptions get carved out and never reviewed. Access grants accumulate. Entropy management is the ongoing discipline that determines whether the work above still means anything in twelve months. Quarterly: every identity reviewed against current need, every integration reviewed against current use. Annually: a red team exercise scoped to the actual consequence map, not CVE hunting, but attack path simulation against the things that would actually hurt. Continuously: every new tool, integration, and access grant evaluated against the survivability test before it's approved.

Be honest about constraints.

Compliance requirements are real. Regulated industries, public companies, and most enterprise customer relationships require specific controls regardless of their survivability value. The right position is not to ignore them. It's to do them separately and never confuse them with security. There are two categories of controls: ones that reduce how bad it gets or how long you stay failed, and ones that make an auditor comfortable. Both can be valid reasons to do something. They are not the same reason. Conflating them is how security budgets get consumed by paperwork while actual exposure goes unaddressed.

Legacy systems are real. Acquired platforms and decade-old dependencies can't always be hardened to the standard your highest-consequence systems deserve. The answer isn't to pretend otherwise. Be honest that these represent accepted risk, contain them as well as possible, and establish clear blast radius boundaries around what can be hardened.

Organizational authority is the hardest constraint and the least discussed. This approach requires the ability to say no, to block a deployment, revoke access against business pressure, enforce a control that inconveniences someone powerful. Most security teams don't have that authority in practice. Without it, the architecture exists on paper and gets eroded one exception at a time. Building that authority is a multi-year effort, and pretending you have it when you don't is its own form of theater.

The One Metric That Matters

Everything resolves to the same question: how long do we stay failed when something goes wrong? Not tool coverage. Not certification status. Not headcount. The time from the moment an attacker gains access to a consequential system to the moment you detect what's happening, contain the damage, and restore to a known-good state.

That number is almost always worse than the incident response plan implies. Testing it exposes more about actual security posture than any audit. Closing the gap is what survivability engineering is for.

The programs that got breached were mature. The ones that survived weren't the ones with more tools. They were the ones that knew how long they could stay failed, and had evidence to back it up.