Building a Security Program That Works
Apr 2026
Security programs fail in a predictable way. They accumulate tools, policies, and compliance obligations until managing them crowds out the actual work. Teams chase audit findings and maintain dashboards while the systems that would genuinely end the business sit underprotected and inadequately monitored.
Security Brutalism is a response to that. Every control, tool, or policy has to answer three questions. Does it reduce how easily an attacker can reach systems that matter? Does it limit the blast radius when compromise happens? Does it shorten how long the organization stays failed after an incident? If something cannot answer yes to at least one of those with evidence, it is adding complexity without improving security. And complexity is not free.
The starting point is not a new tool, but knowing what you already have.
You cannot evaluate risk for a system you do not know exists. Pull from sources that already track what lives in your environment: your identity provider, cloud resource inventories, DNS zone data, certificate transparency logs, and finance records. Accounts payable has a more accurate list of SaaS tools than IT does in most organizations, because payment approval creates a paper trail that adoption does not. Then ask five people, namely the engineering lead, IT lead, product lead, operations lead, and the most senior engineer who has been there the longest. Thirty minutes each. What systems, if compromised, would cause the most damage? This surfaces institutional knowledge that no automated source captures.
The identity inventory is usually the larger problem. Service accounts, API keys, OAuth tokens, and CI/CD credentials outnumber human users in most environments by a factor of three to ten. They accumulate and are almost never revoked. Anything with no recent activity and no documented owner gets revoked before anything else happens.
With a working system list and identity inventory, you can build a consequence map, a ranked list of systems ordered by what failure actually costs the business. No probability estimates, no maturity scores.
Three classifications: Existential, high-recoverable, and low-impact. Existential means the realistic worst case produces an unrecoverable outcome. Things like regulatory action that shuts down operations, permanent loss of data the business cannot reconstruct, financial loss that exceeds survival capacity, or compromise that permanently destroys customer trust. High-recoverable means costly but survivable, for example revenue loss measured in days or weeks, absorbable fines, attrition that can be addressed over time. Low-impact means contained, readily restored, minimal business effect. When uncertain between existential and high-recoverable, classify as existential. The cost of over-protecting something less critical is lower than the cost of under-protecting something that turns out to be more critical.
Once you have the map, everything that follows runs against it, highest-consequence first.
Start by revoking everything that cannot justify its presence. Every standing permission, long-lived credential, and service account grant touching your top systems needs a documented current business need. Anything that cannot be justified gets revoked. This single step does more to reduce susceptibility than most tool purchases.
Structural hardening follows. No standing access to consequential systems. Separation of duties for any irreversible action. Every high-consequence system segmented so that full compromise of a neighboring system does not automatically yield access to it. The architecture question to ask is: if everything with a trust relationship to this system is fully owned by an attacker, what can they do?
Detection should be built around the attack paths that lead to the top of the map. The standard is not whether a SIEM is deployed, but rather whether you know when your consequential systems are being attacked before the attacker reaches the objective.
Honeytokens and canary credentials placed where legitimate users would never look produce near-zero false positives and require almost no maintenance. A canary credential in an old backup directory fires only when someone is actively exploring. When any of these activate, it is a priority investigation regardless of other workload.
Recovery is the most commonly fictional part of a security program. The standard is usually centers around whether recovery procedure exists. That's all good for audits, but in reality that fail. We need to make the standard different, with a focus on how long it actually takes to detect compromise, contain it, and restore to a known-good state. Not from a runbook estimate., but from evidence. Test this now. Pick your top-consequence system. Assume it is compromised right now. Time how long it takes. What almost always surfaces is not a technical gap, but problems like unclear ownership, slow escalation, and communication failures that compound everything else under real time pressure.
None of this has a finish line. Security degrades the moment a system goes live. Permissions accumulate. Integrations get added without being mapped. Credentials go unreviewed. Alert volumes grow until teams start ignoring them. The consequence map goes stale. This is not a failure of vigilance, but the natural behavior of any live environment under continuous change pressure. The operational response is a predictable cadence: quarterly entitlement reviews against current business need, quarterly restoration tests on at least one consequential system, and an annual (or better, twice a year) red team exercise scoped to the actual attack paths against the systems at the top of the map. Continuously, every proposed new tool, integration, or access grant gets evaluated against the three questions before it is approved. Anything that cannot justify its contribution does not get added.
Here's a practical monthly check: pick one consequential system and walk through its current access list, its current network paths, and its current detection coverage. Ask what has changed since you last looked. Something always has. The discipline is catching drift while it is still small.
Once the fundamentals are in place, adding an active disruption capability raises the ceiling of the program. The brutalist program limits blast radius and makes recovery deterministic. An offensive capability raises the cost of reaching your hardened systems before damage occurs. They answer different questions across the attack timeline, which is why they combine cleanly.
This is the role Security Unconventional Warfare fills. Small specialist cells operating continuously with an offensive mindset: deception technology, active threat hunting, adversary war-gaming. SUW operates during reconnaissance and initial access; the brutalist program takes over at containment and recovery. The war-gaming it generates tests every assumption about detection and response times against actual adversary behavior rather than hypothetical scenarios.
Be careful, thought, active disruption raises the cost of attacking through the front; it does nothing about the back door that is already open. Most consequential breaches use credentials that were already stolen, supply chain access that was already trusted, or SaaS integrations that were never revoked. An attacker who buys access from an initial access broker is already inside the trust boundary before touching anything you built to detect them. This is why the security brutalist foundation comes first. Deception technology deployed in a noisy, undocumented environment loses most of its signal. Canary credentials buried in shadow IT and stale service accounts are indistinguishable from ones that fire because an attacker found them. The clean baseline that comes from inventory, revocation, and hardening is what makes the deception layer work.
The sequence then is clear: build the consequence map, harden the crown jewels, establish tested recovery, and revoke everything that cannot justify its presence. Only then deploy active disruption and deception against the attack paths at the top of your consequence list, and feed what those operations surface back into your restoration tests and red team exercises. Keep the programs in their lanes. Active disruption owns deception and hunting. The brutalist program owns inventory, hardening, and recovery. Separated, each is more effective than it would be alone.
If capacity is limited, start with five systems: authentication, customer data storage, payment processing if applicable, the production deployment pipeline, and source code. Get the inventory accurate for those five. Map the consequences. Test recovery on the highest-consequence one. Deploy honeytokens on all five. Revoke every unjustified access grant touching any of them.
An honest program built around five systems beats a fictional program built around fifty.
Security programs that survive are the ones where someone can answer, for any consequential system: how does an attacker reach it, what can they do when they get there, and how long does it take to detect and recover? Those three questions, answered with evidence and tested under realistic conditions, are what the program is for.
Continue reading: Survivavility Engineering and Security Brutalism Under Real Conditions.