Defence in Depth: Layered Security That Survives Failure

The Colonial Pipeline attack in May 2021 shut down the largest fuel pipeline in the United States for six days. The entry point, according to the company's own testimony to the US Senate, was a single compromised password for a VPN account that did not have multi-factor authentication. One password. One missing control. The company paid a ransom of roughly 4.4 million dollars and the eastern seaboard queued for petrol.

The lesson people draw is "turn on MFA", and they should. But the deeper lesson is architectural: a system in which one password stands between the internet and the ability to halt operations is a system with no depth. The password was always going to fail eventually; passwords do. What should have been true is that failing it didn't matter much.

Defence in depth is the principle that security should be layered, so that when — not if — one layer fails, the others still hold. It's borrowed from military engineering, where a fortress has walls, a moat, a keep and a garrison rather than one very good wall. It is the foundation that turns individual controls into a system.

Part 7 of 10 · Foundations of Infosec. Previous: Cryptography Basics. Next: Social Engineering.

Key takeaways

Defence in depth means no single control failing — a password, a patch, a click — is enough to lose everything.
Layers: perimeter, network, endpoint, application, data, people — each producing detection signals.
Real depth needs diversity, independence, fail-secure defaults and a small attack surface.
Against ransomware, an offline or immutable backup is the layer that decides whether you survive.

Why single controls always fail

Every control has a failure mode, usually several:

A firewall rule is misconfigured during an emergency change.
A patch is delayed because the vendor's fix breaks something.
An employee, tired, on their phone, clicks the link.
A vendor is breached and their credentials to your systems go with them.
A control is silently disabled by an administrator troubleshooting an unrelated problem and never re-enabled.

None of these are exotic. All of them happen in ordinary organisations every week. A security design that assumes any single control will hold indefinitely is not a design; it's a hope. The realistic assumption — the one zero trust formalises as "assume breach" — is that some layer is compromised right now, and the architecture should make that survivable.

The layers of defence in depth

The traditional picture is concentric rings. It's simplistic but it's a useful checklist.

Perimeter. Firewalls, DDoS protection, web application firewalls, email filtering. The perimeter is thinner than it used to be, with cloud services and remote work, but it still exists at every point where your systems meet the internet. Its job is to keep out the noise — the automated scanning and bulk phishing that make up most hostile traffic — so the inner layers deal only with what gets through.

Network. Segmentation: dividing the internal network so that compromise of one segment doesn't grant access to all. The point-of-sale terminals shouldn't be able to reach the HR database. The guest Wi-Fi shouldn't see the servers. In cloud environments this is VPCs, security groups and private subnets; on-premises it's VLANs and internal firewalls. Lateral movement — an attacker going from the machine they landed on to the ones they actually want — is how nearly every serious intrusion progresses, and segmentation is what slows it.

Endpoint. The laptops, phones and servers themselves. Keep them patched, run endpoint detection and response (EDR) tooling, turn on disk encryption and the host firewall, remove local admin rights from daily users, and allow-list applications where practical. The endpoint is where the phish lands, so it's where the first chance to catch it lives.

Application. Secure development: input validation, output encoding, parameterised queries, authorisation checks on every request, dependency scanning, secure defaults. OWASP's Application Security Verification Standard is the checklist for this layer. Even a perfectly segmented network won't help if the application cheerfully hands any logged-in user any other user's data.

Data. Encryption at rest and in transit, classification, data-loss prevention, backups. This is the last ring: the assumption that everything outside it has failed and the data itself must still be protected.

People and process. Not a ring in the diagram but present in every one: training, clear procedures, separation of duties, and a culture where reporting a mistake is safe. I'll return to this in a later post.

Principles that make depth real

Layers alone aren't enough; you can stack five weak layers and still fall in one push. Some design principles distinguish genuine depth from the appearance of it.

Diversity. Layers should fail differently. Two firewalls from the same vendor with the same bug are one layer. An email filter and endpoint detection and user training catch different phishing emails.

Independence. A failure in one layer shouldn't disable another. If your logging depends on the same credentials the attacker just stole, they'll turn off the logging. Backups reachable with the same admin account as production will be encrypted along with production — the ransomware groups check for this specifically.

Fail secure. When a control breaks, the default should be to deny, not allow. An authentication service that's down should block logins, not wave everyone through. This is uncomfortable — it means availability suffers — but the alternative is that every outage is a security hole.

Minimise attack surface. Every open port, running service, installed package and exposed API is somewhere a flaw can be. The cheapest hardening is removal: turn off what you don't use. The CIS Benchmarks give per-platform checklists for doing exactly this on operating systems, databases and cloud services.

Secure by default. New systems should start locked down and be opened as needed, not start open and be locked down as time permits — because time never permits. Cloud providers have moved this direction (S3 buckets now block public access by default; new databases aren't publicly reachable), largely because the opposite defaults caused a decade of accidental exposure.

Detect at every layer. Prevention fails silently unless something is watching. Each layer should produce signals — firewall logs, EDR alerts, application audit trails, database access logs — that flow somewhere they'll be seen. Depth without detection means the attacker works through your layers at leisure.

Hardening: the unglamorous core

Between the diagram and reality is hardening — the systematic reduction of weaknesses in each component. It's tedious, it's well documented, and it's where a great deal of practical security comes from.

For servers and workstations: apply the CIS Benchmark or the vendor's security baseline. Remove unneeded software and services. Enforce patching with a defined window — critical vulnerabilities in internet-facing systems within days, not months; CISA's Known Exploited Vulnerabilities catalogue tells you which ones are being actively used. Disable legacy protocols, enable host firewalls and centralise logging.

For cloud accounts: enforce MFA on the root and every console user. Use roles with scoped permissions rather than long-lived access keys. Enable the provider's audit logging (CloudTrail, Azure Activity Log, GCP Audit Logs) and its posture-management service. Block public storage by default, and separate production from development accounts entirely.

For applications: keep dependencies current — most application vulnerabilities come from third-party components, which is what "software supply chain" means in practice. Run static analysis and dependency scanning in the build. Set security headers, use a secrets manager, and never expose debug endpoints.

For networks: default-deny between segments; no direct internet access from servers that don't need it; administrative interfaces reachable only from a management network or through a bastion with MFA.

None of these is difficult. The difficulty is doing all of them, consistently, and keeping them done as the environment changes. That's a process problem, which is why configuration management, infrastructure-as-code and automated compliance checks matter so much: they turn hardening from a one-off project into a state that's continuously enforced.

Depth against ransomware, specifically

Ransomware is the threat most organisations actually face, and it's a useful test of whether your depth is real. Walk the attack:

Initial access — usually phishing, a stolen credential, or an exposed service (RDP, VPN, a vulnerable web app). Layers: email filtering, MFA, patching, attack-surface reduction.
Execution and persistence — malware runs on the endpoint and establishes a foothold. Layers: EDR, removal of local admin, application control.
Privilege escalation and lateral movement — the attacker hunts for admin credentials and spreads. Layers: tiered admin accounts, segmentation, credential hygiene, detection of unusual authentication.
Exfiltration — modern groups steal data before encrypting, for double extortion. Layers: egress filtering, data-loss prevention, anomaly detection on outbound traffic.
Impact — encryption of systems and backups. Layers: offline or immutable backups, tested restores, segmentation limiting the blast radius.

An organisation with all five layers can lose the first three and still walk away with a bad week rather than a bad year. An organisation with a good perimeter and nothing behind it loses everything at step one. The 3-2-1 backup rule — three copies, two media, one offline or immutable — is the single layer that most directly determines whether ransomware is survivable, and it's the one I check first.

Depth is not "buy more products"

A caution. Defence in depth is frequently mis-sold as "add another tool". Tool sprawl is itself a risk: each product is a thing to configure, patch and monitor, and an unmonitored tool is a false sense of security with a subscription fee. Depth comes from different kinds of control at different points of an attack, not from a longer invoice.

Some of the strongest layers are free. Remove admin rights. Segment the network you already have. Turn on the audit logging your cloud provider includes. Keep an offline backup. Teach people to report suspicious emails. If you have budget for one product, make it EDR with someone watching it; if you have budget for two, add a proper email security layer. Beyond that, most organisations gain more from operating what they have well than from adding to it.

A sketch for a small organisation

To make this concrete, here's what defence in depth looks like for a company of thirty people on cloud services with a couple of servers:

Identity: single sign-on with MFA on everything; phishing-resistant MFA for admins; offboarding same-day.
Email: the provider's advanced phishing protection turned on; external-sender tagging; a one-click "report phishing" button.
Endpoints: managed laptops with disk encryption, EDR, automatic patching, no local admin.
Network: guest Wi-Fi isolated; servers on their own segment reachable only over VPN with MFA; no RDP or database ports on the internet.
Servers and cloud: CIS baselines applied; patch window defined; cloud audit logs on; storage private by default.
Applications: dependency scanning in CI; secrets in a manager; security headers; authorisation tested.
Data: classified; encrypted at rest; backups nightly, one copy immutable, restore tested quarterly.
Detection: logs from all of the above into one place; alerts on admin logins, new devices, mass file changes, disabled security tools; someone named to look at them.
Response: a one-page incident plan with phone numbers, rehearsed once a year.

Ten lines. Any one of them can fail — several probably will — and the organisation survives. That's the whole idea.

Further reading

NSA, Defense in Depth: A practical strategy for achieving Information Assurance (2000s-era, still cited)
CIS Benchmarks and CIS Critical Security Controls v8 — cisecurity.org
CISA Known Exploited Vulnerabilities Catalog
OWASP Application Security Verification Standard (ASVS)
US Senate Committee on Homeland Security, hearing on the Colonial Pipeline cyberattack (June 2021)
NIST SP 800-123 — Guide to General Server Security

This series