Assume Compromise: Security Architecture for People Who Expect to Be Breached

Part 0 of a series on building infrastructure that survives its own failures.

Every few months the same story repeats. A public service goes offline, a company discovers attackers have been inside for weeks, virtual machines get encrypted, and — the detail that always tells you everything — the backups turn out to have been reachable with the same credentials that ran production.

Then the post-incident reports arrive, and they read like a template. Flat internal networks. A single VPN that granted reachability to everything. Administrative interfaces exposed to networks that had no business seeing them. Domain admin credentials reused everywhere. Unrestricted outbound internet from servers. MFA on the perimeter and nowhere else.

And somewhere in the executive summary, someone concludes that the organization “needs to invest more in cybersecurity.”

No. The organization needed a different architecture, years earlier. The products were mostly already there. What was missing was the thing you cannot buy with a purchase order: boundaries that hold when something inside them fails.

I have spent years building infrastructure for clients on one working assumption, and it has not failed me yet:

Something will eventually be compromised. Design so that it doesn’t matter very much.

This article is the opening of a series where I’ll walk through that architecture piece by piece — networks, firewalls, administrative access, credentials, backups, recovery — the way I actually build and operate it, not the way it appears in vendor slides. This first part is the map. The rest of the series is the territory.

Security products are not security architecture

Organizations spend serious money on security: firewalls, EDR, SIEM, a SOC contract, vulnerability scanning, penetration tests, an ISO 27001 certificate on the wall. All of these can be useful. None of them answer the only question that matters on the bad day:

When one of these controls fails — and one of them will — what happens next?

A firewall with an “internal: allow” policy behind it is a perimeter, not an architecture. An EDR agent on a server that can reach the hypervisor management network is a witness, not a control. A backup system that trusts production credentials is a countdown timer.

The difference between a security product list and a security architecture is what the environment does after the first control fails. Architecture is the shape of the failure.

The test: I’ll give you the server

Here is the exercise I run against every environment I design, and the one I’d love to run against every environment I read about in incident reports.

I’m not going to exploit anything. No phishing, no zero-day, no clever lateral movement. I will simply hand the attacker root on an internet-facing application server, because sooner or later reality will do exactly that. Now we walk the diagram together and answer, honestly:

• Can this machine open connections to arbitrary hosts on the internet?
• Can it reach other application servers it has no dependency on?
• Can it SSH anywhere?
• Can it see database administration interfaces, or only the one PostgreSQL port on the one host its application actually needs?
• Can it discover or touch hypervisor management?
• Can it reach the firewall management plane? The monitoring stack? The secrets vault?
• Can it see the backup infrastructure — even just to enumerate it?

If the answer keeps coming back “yes, because it’s on the internal network,” the architecture has already failed, and no amount of detection tooling changes that. Detection tells you the house is burning. Segmentation is what decides whether the fire stays in one room.

The goal is not to build an unbreachable environment. That environment does not exist, and anyone selling it to you is selling you the incident report of 2029. The goal is to make a compromise boring: one machine, one small network, one revoked credential, one rebuilt container. An incident, not a crisis.

What this looks like when I build it

None of this is theoretical for me. This is the architecture I design, automate, and operate, and it has a consistent shape:

Small, deliberate networks. Databases live in their own segments. Application servers in theirs. Infrastructure services — DNS, package mirrors, monitoring — in theirs. Nothing gets “database network access”; an application gets a specific path to a specific PostgreSQL endpoint because it has a specific dependency, and that dependency is written down in the firewall policy. East-west traffic is defined with the same rigor as north-south. When someone tells me I have “too many VLANs,” I take it as a compliment.

Management planes that are not part of the network they manage. Hypervisor administration lives in its own security zone. Firewall administration lives in another. An operations zone exists for deployments and maintenance, and it can reach the things operations actually maintains — not the infrastructure underneath them. The systems that control everything are the systems an attacker must never reach by accident, so they are never “just another internal subnet.”

VPN access scoped by target, not by employment. Connecting to a VPN is not a personality trait that grants reachability. Different sensitivity levels get different VPN scopes, and crossing into a more privileged zone means authenticating again. Yes, with a second factor. Yes, again. An attacker who steals one authentication event should not inherit every authorization decision that follows it.

No permanent administrative credentials. SSH and RDP access flows through a vault: authenticate, pass MFA, get authorized for a specific resource, receive a short-lived certificate, do the work, and the credential expires. A credential that no longer exists is remarkably hard to steal next week. Long-lived SSH keys scattered across laptops are how “one stolen laptop” becomes “full infrastructure compromise,” and I simply refuse to build that.

Access with context. Privileged logins are correlated with the ticketing system. Someone opens a session on a production database with no corresponding ticket — incident, change, deployment — and an alert fires. Not because I assume malice, but because privileged access without a documented reason is exactly what an intrusion looks like, and it’s also exactly what undisciplined operations look like. Both deserve a conversation.

Everything as code. Network layout, firewall policy, server configuration, monitoring — versioned, reviewed, reproducible. This is not a convenience. It is a security control and a recovery control: undocumented state is where attackers hide and where recovery plans die.

Individually, none of these ideas is exotic. Every one of them appears in some framework somewhere. The difference is that here they form one coherent shape, and the shape is the point: every boundary exists to answer the question “and then what?” one more time.

Why this gets rejected — and why the objections are wrong

I have presented variants of this architecture many times, and I have watched it lose to proposals that amount to “redundant firewalls, EDR, MFA on the VPN, nightly backups.” I understand why, and it still stings.

Good architecture is invisible when it works. Five uneventful years look identical from the outside whether they were produced by engineering or by luck — nobody sees the ransomware that couldn’t reach the hypervisors or the stolen credential that expired before it was used. Meanwhile every boundary I propose has a visible cost today: another rule to maintain, another authentication step, another “why can’t the server just have internet access?” conversation. Bad infrastructure looks cheaper right up until the day it becomes the most expensive thing the organization has ever owned.

And checkbox compliance flattens the difference. “MFA: yes” is the same checkbox whether it means one prompt at the VPN or independent authentication at every trust boundary. “Backups: yes” is the same checkbox whether the backups have their own identity domain or can be deleted with a production admin account. The audit passes either way. Only the incident distinguishes them.

I’ll dedicate a full article later in this series to what I think procurement and regulation should actually test — spoiler: hand the bidder a compromised server and start the clock — because that argument deserves more than a paragraph of frustration.

The honest counterargument

Before anyone accuses me of building cathedrals: complexity is a real risk, and I’d rather name it myself.

An architecture that only its author understands is a vulnerability with excellent intentions. If five competent engineers cannot operate the environment safely at 3 a.m. while the architect is asleep, the design has replaced one single point of failure with another — the architect. This is why the automation and documentation aren’t decoration on top of the architecture; they are the architecture. Standardized network patterns, policy in version control, repeatable deployment, tested recovery procedures.

The objective was never maximum segmentation. It is the smallest architecture that maintains the required trust boundaries — and not one firewall rule more. Where that line sits depends on what you’re protecting; a three-person company and a national registry do not need the same number of zones. But they both need the boundaries they have to actually hold.

The series

Each of the pieces above deserves its own detailed treatment, with the implementation reality included — the routing, the policy structure, the failure modes, the operational cost. Here is where we’re going:

1. Design for the attacker who is already inside — trust zones from first principles, and why “trusted LAN” is the wrong abstraction.
2. One firewall is a perimeter, three layers is an architecture — edge, perimeter, and internal enforcement, and what each layer is actually for.
3. East-west is where networks get interesting — building internal policy from application dependencies instead of subnet convenience.
4. The application server is rooted. Now what? — a complete assume-breach walkthrough of a segmented environment.
5. Your servers don’t need the internet — outbound filtering, package mirrors, and why “HTTPS outbound: allow” quietly deletes a security boundary.
6. The management plane matters more than production — hypervisors, switches, firewall admin, out-of-band interfaces, and why they get their own world.
7. One VPN should not rule them all — access scoped by target sensitivity, and MFA as a boundary rather than a checkbox.
8. Kill the permanent administrator credential — vault-issued short-lived certificates for SSH and RDP, end to end: issuance, TTLs, logging, revocation, emergency access.
9. Why are you logging into production? — correlating privileged access with tickets, and turning logs into evidence instead of storage.
10. Assume Active Directory is gone — what the corporate identity system must not be allowed to control.
11. Backups must survive the people who run production — separate identities, immutable storage, and recovery that doesn’t depend on the thing that just died.
12. Destroy the datacenter — the recovery exercise: rebuilding identity, network, virtualization, secrets, and applications, in order, from nothing.

The only question that matters

When someone shows me a “secure architecture,” I no longer ask what products are in it. I ask one thing:

What are you willing to give the attacker?

A workstation? Fine. A password? Fine. A whole application server, with root? Fine.

Now show me where they stop.

That boundary — not the logo count on the diagram — is where your security architecture begins. Everything before it is shopping.

Next in the series: designing the network for the attacker who is already inside.