Defence in Depth, and Why Nothing Works Alone

Assume every control you deploy will fail sometimes. Arrange them so that no single failure is fatal.

That is defence in depth, and the reason it matters is that all the alternatives implicitly assume something will work perfectly. Nothing does. Filters miss messages, people click, software has defects, vendors have outages, and configurations drift.

A realistic sequence

Follow one attack through an organisation that has layered properly. An employee receives a convincing message with a link to a fake login page.

1. The mail filter examines it. Today it misses, because the message is well written, sent from a legitimate looking domain, and carries no known malicious signature.
2. The employee reads it. They are busy, it is plausible, and they click. This is the layer everyone focuses on and the least reliable of them all.
3. The password manager does not autofill, because the domain does not match the stored entry. Some people notice this and stop. Many override it, because autofill fails often enough for innocent reasons.
4. Phishing resistant authentication refuses to produce a credential for a domain that is not the real one. The attack fails here, permanently, regardless of how convincing the page was.
5. If authentication were weaker and the attacker got in, monitoring flags a sign in from an unusual location at an unusual hour.
6. If that were missed, least privilege limits the account to the systems its owner actually needs.
7. If data were destroyed, tested backups restore it.

Seven layers, and the attack in this example dies at layer four. In an organisation missing layers three through six, the identical attack reaches layer seven, and layer seven is the one that involves telling your customers.

The question to ask about any control

Not "does it work?" Almost everything works most of the time, which is why demonstrations are always impressive.

Ask instead: what happens when this fails, and what catches it?

This reframing is useful when evaluating products. A vendor claiming 99 percent detection is claiming that one attack in a hundred reaches your staff, which at realistic volumes means several per week. That may be perfectly acceptable, provided you know what stands behind it. It is not acceptable if it was sold to you as the solution and you removed something else to pay for it.

Correlated failure

The subtle way layering goes wrong is when layers that look independent share a hidden dependency, so one event removes several at once.

Some concrete cases.

Backups on the same network with the same credentials. Ransomware operators specifically hunt and encrypt backups first, because they know it converts an inconvenience into a payment. A backup reachable with the same administrative account it is protecting against is not a separate layer.

Your second factor on the same device as your password manager. Convenient, and one compromised phone removes both.

Multiple security tools from a single vendor. Attractive commercially and often sensible operationally, but a serious flaw in that vendor's platform, or an outage, degrades several layers simultaneously.

Every layer depending on the same directory service. If identity infrastructure is compromised, the attacker frequently obtains all the layers built on top of it.

The test is straightforward. For each layer, name the single event that would remove it. If two layers share the same event, you have one layer drawn twice.