Building a Security Program That Works
Apr 2026
Based on experience, security programs tend to fail often the same way. They pile up tools, policies, and compliance obligations until managing all of it crowds out the real work, and the systems that would actually end the business sit underprotected while teams chase audit findings and dashboards.
Security Brutalism pushes back on that. Every control, tool, or policy has to answer three questions: does it reduce how easily an attacker reaches systems that matter, does it limit the blast radius when compromise happens, and does it shorten how long the organization stays broken after an incident? If it can't answer yes to at least one, with evidence, it's just adding complexity, and complexity isn't free.
Start with what you already have, not a new tool. You can't evaluate risk for a system you don't know exists, so pull from sources that already track your environment. Check the identity provider, the cloud inventories, DNS zone data, certificate transparency logs, and the finance records. Accounts payable usually has a more accurate SaaS list than IT does, since payment approval leaves a paper trail that adoption doesn't. Then talk to five people, the engineering lead, IT lead, product lead, operations lead, and the longest-tenured senior engineer, thirty minutes each, and ask what systems would cause the most damage if compromised. That surfaces institutional knowledge no automated source captures.
The identity inventory is usually the bigger problem. Service accounts, API keys, OAuth tokens, and CI/CD credentials outnumber human users by a factor of three to ten (or more) in most environments, and they pile up and never get revoked. Anything with no recent activity and no documented owner should go before you do anything else.
Once you have a system list and an identity inventory, build a consequence map: a ranked list of systems by what failure actually costs the business, not by probability or maturity scores. Use three tiers. Existential means the realistic worst case is unrecoverable, regulatory action that shuts you down, permanent data loss, financial damage beyond your survival capacity, or a trust collapse you can't repair. High-recoverable means costly but survivable, days or weeks of revenue loss, fines you can absorb, attrition you can manage over time. Low-impact means contained and easily restored. When you're unsure whether something is existential or high-recoverable, call it existential; over-protecting something less critical costs less than under-protecting something that turns out to matter more.
Everything after this runs against the map, highest-consequence first.
Start by revoking anything that can't justify its presence. Every standing permission, long-lived credential, and service account grant touching your top systems needs a documented, current business need, and anything that lacks one gets revoked. This single step can help cut more risk than most tool purchases ever will.
Then harden the structure. No standing access to consequential systems, separation of duties for anything irreversible, and segmentation so that compromising one system doesn't hand over the next. The question to keep asking is: if everything trusted by this system were fully owned by an attacker, what could they do?
Detection should be built around the paths that lead to the top of the map, and the real standard isn't whether you've deployed a SIEM, but whether you'd know your consequential systems were under attack before the attacker reached the objective. Honeytokens and canary credentials, placed where no legitimate user would ever look, give you near-zero false positives with almost no upkeep. A canary sitting in an old backup directory only fires when someone's actively poking around, and when it does, that's a priority investigation, full stop.
Recovery is where most programs become fictional. The usual standard is whether a recovery procedure exists on paper, which satisfies an audit and fails in practice. The real standard should be how long it actually takes to detect compromise, contain it, and restore to a known-good state, measured, not estimated. So test it: pick your highest-consequence system, assume it's compromised right now, and time the response. What usually surfaces is unclear ownership, slow escalation, and communication breakdowns that compound everything once real time pressure hits.
Once you do all this, you can't stop. None of this has a finish line, because security degrades the moment a system goes live. Permissions accumulate, integrations get added without being mapped, which adds more credentials, that go unreviewed, alert volumes grow until people start ignoring them, and the consequence map goes stale. That's just how any live environment behaves under constant change. So build a cadence around it with quarterly entitlement reviews against current business need, quarterly restoration tests on at least one consequential system, and a red team exercise once or twice a year scoped to the real attack paths at the top of your map. Every new tool, integration, or access request gets checked against the three questions before approval, and if it can't justify its contribution, it doesn't get added.
A simple monthly habit helps here too. Pick one consequential system, walk through its current access list, network paths, and detection coverage, and ask what's changed since you last looked. Something always has, and catching that drift while it's small is the whole discipline.
Once the fundamentals are solid, adding active disruption raises the ceiling further. The brutalist program limits blast radius and makes recovery predictable; an offensive capability raises the cost of reaching your hardened systems in the first place. They cover different points on the attack timeline, which is exactly why they combine well.
That's the role Security Unconventional Warfare plays. Small specialist cells running continuously with an offensive mindset, deception technology, active threat hunting, adversary war-gaming. SUW works during reconnaissance and initial access, while the brutalist program takes over at containment and recovery, and the war-gaming it produces tests your detection and response assumptions against real adversary behavior instead of hypotheticals.
One thing to keep in mind, though: active disruption raises the cost of attacking through the front door, but does nothing about a back door that's already open. Most consequential breaches run through credentials already stolen, supply chain access already trusted, or SaaS integrations nobody ever revoked, and an attacker who buys access from an initial access broker is already inside your trust boundary before touching anything built to detect them. That's why the brutalist foundation has to come first. Deception technology dropped into a noisy, undocumented environment loses most of its signal, since canary credentials buried among shadow IT and stale service accounts look no different from ones firing on a real intrusion. The clean baseline from inventory, revocation, and hardening is what makes the deception layer actually work.
So, build the consequence map, harden the crown jewels, establish tested recovery, and revoke everything that can't justify its presence, then layer active disruption and deception onto the attack paths at the top of your list, feeding what those operations find back into your restoration tests and red team exercises. Keep the two programs in their lanes, active disruption owns deception and hunting, the brutalist program owns inventory, hardening, and recovery, and each works better for staying separated.
If capacity is tight, start with five systems. For example, authentication, customer data storage, payment processing if it applies, the production deployment pipeline, and source code. Get the inventory right for those five, map the consequences, test recovery on the highest-consequence one, deploy honeytokens across all five, and revoke every unjustified access grant touching any of them.
A program built around five real systems, in my opinion, beats one built around fifty imaginary ones. The programs that survive are the ones where someone can answer, for any consequential system, how an attacker reaches it, what they can do once inside, and how long it takes to detect and recover. Answered with evidence, tested under real conditions, that's what the whole program exists for.
Continue reading: Survivability Engineering and Security Brutalism Under Real Conditions.