security-complianceestablished · high operational burden

Defense in Depth

Also known as: layered-security, swiss-cheese-model

Intent

Layer independent security controls so that the failure of any single control does not lead to compromise.

Problem

Relying on one perimeter control, such as a firewall or login check, turns any bypass into total breach. Attackers chain small weaknesses, and every control eventually has bugs or misconfigurations.

Forces

•No single control is perfect
•Insiders and compromised dependencies are already inside the perimeter
•Each layer adds cost and friction
•Controls must be independent to add real value

Solution

Overview

Defense in depth assumes each control will fail someday and ensures another one stands behind it. It applies the same logic as safety engineering: multiple independent barriers, each with different failure modes.

Use threat modeling to pick layers deliberately: list the likely attack paths, then confirm at least two independent controls interrupt each one. Revisit the model after architecture changes, since new services, vendors and data stores often introduce paths that bypass existing layers.

How it works

Internet
  | edge: DDoS protection, WAF, TLS
  | gateway: authn, rate limits, schema validation
  | service: authz per call, input validation, least-privilege role
  | network: segmentation, deny-by-default egress, mTLS
  | data: encryption, row-level tenant filters, backups
  | detect: audit logs, anomaly alerts, runbooks

A request exploiting one layer, for example an injection that slips through validation, still meets a database account that cannot drop tables and egress rules that block exfiltration.

Pitfalls

Layers that fail together. Two checks relying on the same header or the same library are one layer.
Trusting the internal network. Authenticate service-to-service traffic.
Adding tools without owners; unmaintained rules rot.
Skipping the detect and respond layer, so breaches go unnoticed for months.
Never testing layers independently through penetration tests or game days.

Key takeaways

Use independent controls across network, identity, app, data and detection.
Design every component as if its neighbors are compromised.
Test each layer on its own and review for shared failure points.
Detection and response are layers too.

✓ When to Use

•Any system handling sensitive data
•Internet-facing services
•Environments with multiple teams and third-party code

✗ When Not to Use

•Never skip entirely, but avoid stacking redundant identical controls
•Throwaway sandboxes with no real data
•As an excuse to leave individual layers weak

Pros

+Limits blast radius of any single failure
+Buys time for detection and response
+Raises attacker cost

Cons

−More components to run and tune
−Latency and developer friction
−False sense of security if layers are correlated

Cost Profile

Infrastructure

Medium to high

Operational

High — many controls to maintain

Cognitive

Medium

Failure Modes

Layers share one dependency, such as a single identity provider, so one failure bypasses all
Controls misconfigured and never tested
Alert fatigue hides real signals