Skip to content

CONCEPT Cited by 4 sources

Defense in Depth

Definition

Defense in depth is the security posture of stacking independent protective layers such that no single compromised or misconfigured layer exposes the whole system. Each layer is sized to fail closed on its own; compromising the system requires compromising multiple layers — ideally of different types (authn/authz/crypto/network/audit) that can't all be defeated by the same attacker capability.

Contrast with perimeter security — a single hardened wall around the data — which treats any crossing of the perimeter as total compromise. MongoDB's explicit framing against that model:

"Security isn't a wall you build around your data. It's an assumption you design against from the very beginning. The assumption is simple: in a distributed system, you can't trust the network, you can't trust the hardware, and you certainly can't trust your neighbors."

(Source: sources/2025-09-25-mongodb-carrying-complexity-delivering-agility)

The layers — canonical question framing

Defense in depth is usually articulated via the set of questions it answers at each layer, rather than a fixed checklist of technologies. MongoDB's five-question version:

Question Layer Example primitives
Who are you? Strong authentication SCRAM / AWS IAM / SSO-OIDC / mutual-TLS client certs
What can you do? Fine-grained authorization (RBAC / ABAC) concepts/least-privileged-access, systems/amazon-verified-permissions
What if someone gets in? End-to-end encryption TLS in transit, encryption at rest, Client-Side / Queryable Encryption in use
How do we lock down the roads? Network controls IP access lists, private endpoints, concepts/mutual-tls, patterns/cgroup-scoped-egress-firewall
How do we prove it? Granular auditing Immutable audit logs, SIEM, binary authorization, release attestation

Each layer is independent — an authn bypass doesn't defeat authz, a network misconfiguration doesn't defeat encryption at rest. The point is not to add redundancy; it is to add heterogeneous redundancy so a single class of bug or attacker capability doesn't cascade.

What "independent" really means

Independence is what distinguishes defense-in-depth from layered- but-shared-fate security. Failure modes to watch for:

  • Shared auth backend. If every layer checks the same OIDC token and the OIDC provider is compromised, layer count doesn't help. Fix: bind at least one layer to a different identity root (hardware attestation / network context / time).
  • Shared crypto material. If transport encryption, at-rest encryption, and field-level encryption all use the same KEK, one envelope-leak defeats all three. Fix: separate envelopes with distinct rotation lifecycles.
  • Shared blast-radius boundary. If all layers live in the same VM and VM escape is the threat, the layering is nominal. Fix: push at least one layer into a different blast-radius boundary (host, AZ, account, partition).

Sibling concepts on this wiki

  • concepts/zero-trust-authorization — stronger variant: each operation is authorised on its own merits, not because a previous layer "let you through." Every request is suspect regardless of origin.
  • concepts/detection-in-depth — observability analogue: stack independent detection surfaces (runtime EBPF + audit-log grep + anomaly ML + tripwire canaries) so no single detection gap hides an intrusion.
  • concepts/architectural-isolation — structural cousin: isolate the blast radius first (dedicated cluster / account / VPC), then layer defences inside. MongoDB's post frames the two as complementary — isolation shrinks the attack surface, depth adds layers within what remains.
  • patterns/zero-trust-re-verification — pattern-level enforcement: re-check authorisation at every trust boundary instead of assuming inbound requests are already validated.

Failure modes

  • Wall-only thinking. Investing solely in the perimeter and declaring the interior trusted; the 2016 Mossack Fonseca / Panama Papers leaks, and many classic lateral-movement breaches, exploited flat interiors behind a hardened wall.
  • Layer-count theatre. Adding nominal layers without independence (e.g. five consecutive TLS hops inside the same VPC) — more expense, no more security.
  • Alert fatigue at the audit layer. A granular audit log is only load-bearing if humans or systems read it; the prove-it layer is the one most often degraded to "we have logs somewhere."

Seen in

Last updated · 200 distilled / 1,178 read