Security Brutalism
Mar 2025
Security Brutalism: know what you have, make it hard to break, see trouble fast, limit damage and recover.
Security Brutalism represents a shift in security thinking that prioritizes clarity, fundamental strength, and purposeful design over complexity and theater. Most security programs look complete on paper, with tools, dashboards, and compliance reports covering every angle. Attackers still get in through phishing, stolen credentials, and unpatched systems, which is the clearest sign that all that surrounding complexity never protected anything. It produced noise. Security Brutalism strips that noise away and focuses on what actually reduces risk and protects critical assets.
The approach draws on brutalist architecture, where transparency and function sit above everything else. Every control has to justify itself by reducing exposure or limiting damage. A control that does neither still expands the attack surface, because no added complexity stays neutral once it enters the environment.
Guiding principles
Simplicity comes first. Security Brutalism cuts unnecessary tools, interfaces, and settings, which lowers complexity along with the vulnerabilities that come with it, leaving only the simplest and strongest controls once everything else is gone. Transparency grows out of that same instinct. Security mechanisms stay visible and documented, so weaknesses have nowhere to hide. Durability is just as important. Protections built for the long term need to survive sustained attacks and adapt as risk conditions shift around them. Resilience holds the other three together, since hardening and redundancy run through every layer, keeping critical operations running even when individual pieces get compromised.
Underneath all of it sits one assumption: entropy stays constant. Security starts degrading the moment a system goes live, as teams change, integrations pile up, and controls drift out of alignment. A brutalist program treats that drift as the normal condition to design for, not an exception to fix later. That outlook is what the four laws below are built around.
The four laws of Security Brutalism
A brutalist security program rests on four laws that apply regardless of team size or budget. Each one builds on the last, in a continuous loop.
The first law is knowing what you have. A living inventory of every identity, trust relationship, and data flow forms the foundation, because exposure can't be measured without it. The second is making it hard to break. Strong defaults, least privilege, and simple defenses raise the cost of an attack, and that hardened baseline is also what makes reliable detection possible later on. The third is seeing trouble fast. Detection that reveals a compromise while it's still happening counts for more than any claim of a perfect defense, since catching what slips through before it spreads comes down to speed of awareness. The fourth is limiting damage and recovering. Containment comes first, restoration follows, and every recovery becomes practice for the next one, because staying operational depends on how fast a team can pull a system out of a failed state.
In short: know, harden, see, recover.
What it looks like in practice
For an established security organization, this thinking shows up as aggressively streamlining the program and cutting whatever complexity no longer earns its place.
The work starts by stripping operations down to essentials, removing redundant tools, overlapping controls, and policies too complex to offer real protection. Attention then shifts to foundational defenses like strict access controls, timely patching, and strong authentication, treated as non-negotiable rather than aspirational. Attack surface reduction follows the same logic. Unnecessary features and services get removed, a full asset inventory stays current, and whatever remains gets hardened, because less exposed surface leaves less to defend. Incident response runs on strict, pre-planned protocols executed with precision, including harsh containment measures like automated credential revocation or immediate isolation of compromised endpoints. Continuous assessment threads through all of it. Real time monitoring, centralized logging, and regular review keep the environment lean while it adapts to new threats. Interfaces stay utilitarian for the same reason. Simple, information dense tools and clear dashboards do more useful work than a polished design ever could.
Benefits
Transparency, raw function, and straightforward controls make a program more nimble. Detection gets faster, decisions get clearer, and recovery after an incident gets quicker, because unnecessary tools and ambiguous processes stop slowing things down. What's left is a system that stays strong, durable, and straightforward to operate, one built to answer a harder question than whether it satisfies stakeholders on paper: when it gets hit, and it will, does it survive? Strip it down. Lock it down. Test it often. Trust nothing. That is the brutalist approach to security: simple, strong, and survivable.
Note: This is post lives on the Security Brutalism website.