Security Brutalism Under Real Conditions, Part 2: The Framework

With the series Security Brutalism Under Real Conditions introduced, we move to the framework that guides a security program and defines the controls needed to build real resilience. The focus is how a program behaves under pressure and what happens when an attack moves past assumptions into execution.

The programs that got breached recently were mature, with security organizations, compliance certifications, tooling budgets, and audit histories. They were trying, but they were answering a different question than the one that becomes important under pressure.

Most programs measure coverage. They ask whether we have a SIEM, or is MFA deployed. These questions are importnat, but in reality only satisfy an auditor. They sit on a different axis than survivability and optimizing for one doesn't move the other. The important question is simpler and more uncomfortable. Ask: "if we get hit today, how long do we stay failed?"

That reframe anchors how I build security programs, evaluating every control, tool, and policy 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? A control that fails to move any of these adds attack surface without improving the ability to survive.

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

The Consequence Map

Rather than starting with controls, I start with what failure actually costs, ranked. This isn't a traditional risk register with color-coded heat maps. Instead, I map which systems, if compromised, would end the company or create irreversible damage, things like an unrecoverable data breach, a production environment destroyed with no clean backup, or a regulatory violation that triggers criminal liability. Below those sit the systems that are painful but recoverable, and then the low-criticality systems, which still earn a spot on the map since keeping an eye on them stays important.

That ranked list is the consequence map, and it tells me where to spend every subsequent dollar of effort. The inventory, hardening decisions, detection coverage, and recovery testing all get prioritized against it. Without it, security becomes whack-a-mole, hardening what's loudest and detecting what's easiest, regardless of what would actually hurt you.

Know. Harden. See. Recover.

Once I know what's important, I look at what's actually in place, not the architecture diagram but what's running right now. The delta is almost always larger than expected. Every organization I've looked at carries more identities than it thinks, from service accounts that outlived their projects, to API keys that were temporary two years ago and CI/CD pipelines with undocumented production access and OAuth tokens that nobody uses anymore.

Those identities form the real attack surface. Stolen credentials are the entry point for most consequential breaches, and an attacker who buys access from a broker or phishes a service account with standing permissions doesn't need to defeat any control. The front door was already open.

KNOW is the prerequisite for everything else. Exposure can't be measured without knowing what can reach a system, blast radius containment can't be designed without knowing what trusts what, and standing access can't be revoked without knowing it exists. The inventory needed isn't an asset spreadsheet but a map of what authenticates to what, what reaches what, and where data flows, at minimum for the highest-consequence systems. An incomplete but accurate map beats a complete but fictional one.

Next is HARDEN. Usually framed as addition, saying things like deploy this tool or enforce this policy. I start with removal instead. For each tool ask what attack path it prevents, what damage it limits, or what recovery time it improves. An answer that leans only on compliance or habit marks a strong candidate for removal, especially since elevated-privilege tools generate alert volume that dulls sensitivity to real signals and can expand the attack surface rather than shrink it.

The same logic applies to access. Every standing permission and long-lived credential without a documented current use gets revoked, since trust accumulates silently and depreciates fast. That revocation forces structural decisions, and access to consequential systems starts getting scoped to specific tasks and time windows with full audit trails, so blast radius isolation keeps owning one system from handing over the next, and anything irreversible waits on human review before it executes. None of this friction is the enemy on high-consequence paths, since it slows an attacker's propagation and opens up chances to detect them along the way.

Now SEE. The standard is whether I know a consequential system is under attack before the attacker reaches their objective. Most programs have alert volumes nobody reads, usually the results of logs that exist for auditors and signature-based detection that catches yesterday's attacks. Teams normalize ignoring alerts because the signal-to-noise ratio is too low, and that normalization lets real signals disappear.

A high-leverage investment here is deception, with honeytokens, canary credentials, and honeydocuments placed where only an exploring attacker would touch them, producing very low false positive rates. Behavioral baselines on consequential systems are important too, watching for deviation in access patterns, lateral movement, and identity anomalies like first-time access or unusual hours. The lights out test is a useful forcing function. Ask: if all tooling went dark right now, would you know you were being attacked?

Finally RECOVER, which runs on evidence, not assumption. Programs have incident response plans, backup policies, and recovery time objectives, and almost none of them have measured whether any of it works. The survivability test assumes a realistic attacker has access right now. How long before someone understands what's happening, how long to contain it, and how long to actually restore from backup to a test environment, timed rather than assumed?

The delta between what plans say and what measurement shows is almost always large. Backups that haven't been restored in years, kill switches tied to people no longer at the company, or a four-hour recovery objective against a two-day actual restore. That widening gap is the real security posture, not the certifications or the headcount, and the only way to close it is to measure it regularly through restoration tests, chaos exercises against real attack paths, and drills tied to the consequence map rather than generic tabletops. Security built on untested assumptions is documentation, not security.

The Entropy Problem

Little of this stays complete in practice. Security degrades the moment a system goes live, as teams change, integrations go undocumented, exceptions go unreviewed, and enforced controls drift into theoretical ones. Entropy management is the ongoing discipline that decides whether this work still counts in twelve months, reviewing every identity and integration quarterly, running a red team exercise against the actual consequence map annually, and evaluating every new tool or access grant against the survivability test continuously. A control that can't answer what it reduces doesn't belong in the program.

Of course compliance requirements are a must have in many cases, but the right move is to handle them separately rather than confuse them with security, since a control that satisfies an auditor and a control that improves survivability are different things even when they're both valid to pursue. Legacy systems can't always reach the standard the highest-consequence systems deserve, so the best move is to treat them as accepted risk, contain them the best we can but removing access and solidifying network segmentations, and monitor what can't be fixed. Organizational authority is the hardest constraint, since this approach requires the power to say no and block a deployment against business pressure, and most security teams don't have that authority yet.

Don't Forget Offense and Disruption

Once the foundation sits in place with a consequence map, a more realistic inventory, hardened systems, and tested recovery, a natural extension to this follows, operating actively outside your own perimeter. Security Unconventional Warfare runs small specialist cells of three to five people with an offensive orientation, deception technology, active threat hunting, counter-intelligence, and continuous war-gaming, operating in the space an attacker occupies before intrusion rather than waiting behind walls.

This needs the foundation first because deception assets only produce clean signal against a clean baseline. An environment full of undocumented service accounts buries deception intelligence in noise, and intelligence never gets used if the operations team is oriented toward satisfying auditors instead of responding to real signals.

The offensive layer raises the cost of reaching the hardened environment and compresses detection time, while the brutalist architecture bounds what happens if something gets through and keeps recovery deterministic. They share almost no functional overlap, which is why they combine cleanly. Sophisticated, well-resourced attackers can still absorb higher costs, so disruption deters opportunistic activity without acting as a backstop against a patient adversary. One caveat, though, legal exposure around counter-intelligence scope needs resolution before deployment, not after. It's a tricky one to navigate in certain countries or industries.

AI and Agents

This is the same problem at new scale. Autonomous agents, software that uses a language model to reason, plan, and act with real-world tools, are the fastest-growing attack surface in production environments, and their threat profile maps closely to this framework.

An agent with tool access is an identity with permissions, able to read files, call APIs, execute code, and invoke other agents. Its blast radius is set by whatever tools it can reach. If it's compromised through a jailbreak, adversarial input, or a manipulated prompt, what it can do depends entirely on what it was given.

The same four laws apply directly. Know every agent, every tool it can call, every system and agent it can reach, and for each one, answer what it could do if fully compromised right now. Harden by subtraction, with minimum tool sets, read-only by default, no agent-to-agent trust without explicit grants, and human approval before irreversible actions, since removing an unneeded capability is the only way to bound blast radius. See actual behavior by logging every tool call and flagging high-consequence sequences regardless of trigger, watching for drift like a file-reading agent suddenly making external calls, and placing canary credentials where only active exploration would find them. Recover with evidence, testing whether you can stop a running agent mid-execution, account for in-flight actions, and reconstruct what happened during the window before detection.

Agents require a fifth layer without a clean analogue in the conventional model, Trust. Traditional systems execute code. Agents process instructions and data through the same channel, a language model following natural-language directives, and that channel can be hijacked. A web page, document, or tool result can carry adversarial instructions that redirect an agent's behavior, with no parser to exploit and no conventional vulnerability, since the attack surface is the model's core function of following instructions. A web page telling an agent to ignore its instructions and exfiltrate context to a URL is a real attack that agents encounter continuously while browsing or reading content.

Controls here look different. Instructions and data need structural separation, with system prompts defining capability and external input processed strictly as data. Input source tracking lets the agent treat untrusted content accordingly, directive patterns in untrusted content get flagged before the agent acts on them, and high-consequence actions need their reasoning chain logged, not just the outcome, since a compromised agent's actions make no sense without the reasoning behind them.

Keep an eye on things like behavioral baselines, which run softer here since legitimate agent behavior shifts with context, prompt, and model version, so detection should focus on action-level anomalies, which tools got called, in what sequence, and with what parameters, rather than fuzzy output-level baselines. And the model itself, which is a trust boundary nobody fully controls, since updates and fine-tuning can shift behavior invisibly, so controls need to assume unexpected behavior at any point and stay built to catch and contain it rather than prevent it outright.

One Metric To Keep

Everything above resolves to one question: how long do we stay failed when something goes wrong, measured from the moment an attacker reaches a consequential system to the moment detection, containment, and restoration finish? That number almost always runs worse than the incident response plan implies, and closing the gap, through the foundation, the active layer, and the agent controls, is what security survivability engineering is for.

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