Survivability Engineering, Part 6: Surviving Reality
Mar 2026
Survivability engineering assumes real systems will get compromised, and works from that assumption to understand what breaks, how badly it breaks, and how quickly it can be restored.
Security starts degrading the moment a system goes live. Entropy builds through access, integrations, exceptions, and time. Permissions expand because people need to get work done, systems connect because the business demands it, and controls drift because nobody maintains perfect alignment between design and operation. What you believe about a system and what's actually true separate slowly, then all at once, and that separation creates attack paths.
Abstract models can't carry you through that condition. Systems don't behave cleanly under stress, attackers don't follow assumptions, and people don't act the way policies expect. Survivability engineering keeps modeling grounded in reality and moves the focus toward something that holds under pressure. Assume compromise, then ask what happens next.
Anchor on consequence. Why does this system exist, and what stops when it fails? Survivability engineering centers on outcomes rather than components. If a system goes down and nothing meaningful breaks, the risk stays low. If it halts revenue, operations, or trust, the risk becomes clear, and that clarity sets the boundary for everything that follows.
From there, move to susceptibility. How does an attacker realistically reach this system? What identities can touch it, what data flows into it, what systems influence it, and where do trust boundaries exist in theory but not in practice? Trace the path step by step and show how something small turns into something significant.
Modern systems increase susceptibility faster than most teams recognize. AI agents, automation, and integrations act with speed and scope that traditional controls never accounted for, taking input, interpreting it, and acting on it, which turns influence into a primary attack vector. The question becomes how a system can be pushed to behave in a way that creates damage.
After susceptibility, force the question that most people avoid. Assume the attacker succeeded. What actually happens? Not categories or labels but specifics. Can they move money, access sensitive data, create persistence, or disrupt operations? Specificity is important here, since vague impact hides real risk.
Then define recovery time. How long does the system stay degraded, how quickly does anyone notice, and how quickly can access be revoked, systems isolated, and operations restored? This is where most assumptions collapse. Backups exist but nobody tested restoration. Logs exist but nobody watches them in time. Access controls exist but exceptions override them. Recovery that depends on things never exercised under stress through chaos and adversarial simulation stays theoretical.
Susceptibility, damage, and recovery time form the core model. The model works because it stays tied to outcomes and gives engineers and leadership a shared way to reason about risk.
Entropy pushes against all three. Susceptibility grows as access and integrations expand, damage increases as systems become more interconnected and privileges accumulate, and recovery time stretches as complexity obscures ownership and response paths. Security keeps degrading unless someone actively pushes back.
If it doesn't reduce risk, it's attack surface.
Every control, every integration, every feature has to justify itself against susceptibility, damage, or recovery time. If it doesn't make compromise harder, limit the impact, or speed up restoration, it adds exposure. Complexity without purpose accelerates entropy.
Security Brutalism aligns directly with this model. It strips away decoration and forces systems to show how they behave under stress, exposing real paths, real dependencies, and real failure modes, so systems get designed so compromise doesn't cascade, damage stays contained, and recovery remains achievable.
Strong security survives contact with reality. Credentials get stolen, systems get accessed, controls get bypassed, and what follows depends on the design in place. Does the attacker move freely or hit resistance? Does the system fail completely or in contained ways? Does recovery depend on guesswork or on practiced execution?
Survivability engineering returns security to fundamentals. Start with a real system, assume compromise, trace the path, define the damage, measure the recovery, test the assumptions, and remove what doesn't reduce risk. Repeat as the system changes, since that loop holds because it reflects how systems actually behave over time.
Build for the breach. Build for recovery. Everything else is attack surface.
Originally posted on The Security Brutalist blog.