Security Brutalism: A CISO's Guide to Operational Clarity

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

Enterprise security programs accumulate complexity over time. Overlapping tools, legacy controls, and compliance theater pile up and obscure risk rather than reduce it. The result is a program that is hard to operate, harder to explain, and nearly impossible to measure in terms that mean anything in the boardroom.

Security Brutalism does not reject existing frameworks. It puts them under scrutiny. Every control and process must justify its existence by demonstrating that it reduces real-world risk. The uncomfortable question underneath all of it is simple: if we get hit today, how long do we stay failed?

Recent breaches make the point. Many occurred at organizations with mature programs, compliance certifications, significant tooling investments, and competent teams. They were optimizing for coverage and auditability, which are reasonable goals, but different from survivability. Improvement in one does not automatically improve the other.

Security Brutalism evaluates every control against three questions: does it reduce the paths an attacker can use to reach consequential systems, does it limit what an attacker can do after gaining access, and does it shorten the time between compromise and recovery? Controls that improve none of these add complexity without improving the organization's ability to survive.

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

Know, Harden, See, Recover

Start with a consequence map, a ranked list of which systems, if compromised, would end the company or cause irreversible damage, and which would be painful but recoverable. Without it, hardening and detection default to whatever is loudest rather than whatever actually hurts.

Once you know what you cannot afford to lose, map how an attacker could reach it. The gap between what your architecture diagram shows and what is actually running is almost always larger than expected. Most organizations carry more identities than they realize. From service accounts that outlived their projects, API keys that were temporary two years ago, to OAuth tokens granted to SaaS tools nobody uses anymore. Stolen credentials are the entry point for most consequential breaches because an attacker with valid credentials walks past most controls. The inventory you need is a map of what can authenticate to what, what can reach what, and what data flows where.

Hardening usually gets framed as addition. The brutalist move runs the other direction. For each tool in your stack, ask what specific attack path it prevents, what damage it limits, or what recovery time it improves. When the answer rests only on compliance or habit, that tool is a candidate for removal. The same logic applies to access: every standing permission and long-lived credential that lacks a documented current use deserves revocation.

On detection, hold to one standard: do you know when your consequential systems are being attacked before the attacker reaches their objective? Most programs run alert volumes nobody reads, and teams quietly normalize ignoring alerts once the signal-to-noise ratio drops too low. Deception assets like honeytokens and canary credentials, placed where only an actively exploring attacker would find them, carry low false positive rates and high signal value. Pair them with behavioral baselines on consequential systems.

Detection alone is insufficient if recovery is slow. Most programs have incident response plans and backup policies documented in governance materials, and almost none have measured whether any of it actually works. Run the survivability test, meaning, assume a realistic attacker has access right now. How long before your team understands what's happening? How long to contain it? How long to actually restore from backup, measured in a test environment, not confirmed by checking that the backup exists? The gap between what the plan claims and what actually happens is your real security posture.

The Entropy Problem is a Leadership Problem

Security degrades from the moment a system goes live. Teams change, integrations get added without documentation, exceptions get carved out and never reviewed, and access accumulates silently. Entropy management is the ongoing discipline that determines whether all of the above still holds twelve months later. Quarterly, review every identity and integration against current need. Annually, run a red team exercise scoped to the actual consequence map. Continuously, evaluate every new tool and access grant against the survivability test before approving it.

Two constraints deserve honesty. Compliance requirements are real, and regulated industries require specific controls regardless of their survivability value. Handle them, but keep them separate from security itself. Controls that reduce how bad an incident gets are different from controls that make an auditor comfortable, and conflating them is how budgets get consumed by paperwork while real exposure goes unaddressed. Legacy systems are real too. Some platforms cannot reach the hardening standard your highest-consequence systems deserve. Treat them as accepted risk, contain them as well as possible, and draw clear blast radius boundaries.

The hardest constraint is organizational authority. This approach requires the ability to say no: to block a deployment, revoke access against business pressure, or enforce a control that inconveniences someone powerful. Most security teams do not hold that authority in practice, and without it the architecture exists on paper while getting eroded one exception at a time.

The One Metric

Everything resolves to the same question "how long do we stay failed when something goes wrong?" That number outweighs tool coverage, certification status, and headcount. It comes down to the time from initial access to detection, containment, and restoration to a known-good state.

That number is almost always worse than the incident response plan implies. The programs that survived major incidents were not the ones with more tools. They were the ones that knew how long they could stay failed, and had evidence to back it up.