Defense in Depth

Defense in depth combines barriers so that failure or bypass of one need not expose an asset. NIST describes an information-security strategy integrating people, technology, and operational capabilities across multiple layers. The goal is to reduce reliance on any one defense for the threats in scope, while identifying dependencies that could defeat several defenses together.

Layers need not all be technical. A review that detects an unsafe permission change and a response process that contains misuse can complement an enforced access restriction. Their value depends on coverage, timing, authority, and operation. Different labels or technologies do not establish independent failure behavior, and a critical remaining dependency should be made explicit.

Identify shared failure causes

Three rules evaluated by one policy engine and using one identity claim share possible failure causes. Compromise of the engine or a forged claim accepted by all three could defeat them together. They may still restrict different actions under other conditions. Shared dependence therefore limits protection against specified failures without making the rules identical in every scenario.

For each pair of barriers, ask what event or failed assumption could disable both, and under what conditions. Then ask which other barriers remain. The following are examples to investigate, not a ranking of incident frequency:

• A shared identity source. Controls accepting the same provider’s claims may share exposure to forged or compromised identities. A non-interactive credential that bypasses the provider is a separate authentication route; trace the controls that actually evaluate it rather than assuming it inherits the provider’s judgment.
• A shared secret store. Unauthorized access to a common vault path can expose credentials for several services. The resulting reach depends on which secrets are readable, their permissions, and any additional checks the services enforce.
• A shared operator. A person or automation account authorized to alter multiple barriers can create a common compromise path. Assess whether independent approvals, immutable configuration, or other restrictions limit that authority in the scenario being modeled.
• A shared implementation. A vulnerable library, base image, or sidecar can expose several controls, depending on the versions, configuration, and reachable behavior. Shared code identifies a dependency to investigate; it does not establish identical exploitability everywhere.
• A shared premise about location. Any set of controls that treats traffic inside a perimeter as legitimate shares one assumption, however many devices implement it.

As with reliability failure domains, independence needs evidence within a stated scenario. The term blast radius describes the reach of a compromise. Assessing the barriers that remain helps explain what limits that reach.

More layers is not monotonically safer

Layers add configuration and operational work, which can introduce mistakes. A design with more components can provide less protection if its extra complexity leaves a relevant path exposed. Compare the protection gained, shared dependencies, and the team’s ability to maintain the design rather than assuming that adding another layer necessarily improves it.

So the question to ask before adding a layer is not whether it would help in principle. It is which specific path it cuts, what it assumes, and whether the team can keep it correct. An unverified layer carries uncertainty. Record what evidence is missing rather than assuming the layer either works or provides no protection.

The other boundary is about scope rather than depth. Barriers around a production database do not establish protection of a separate analytics copy or mailbox extract; assess the controls covering those copies as well. Depth answers what if this control fails; it does not answer where else does this data exist, which is why isolation and least privilege belong in the same conversation as depth rather than after it.

Record protection by scenario

Alongside the threat model, list the barriers on each path, their dependencies, and the compromise scenarios under which they fail. Do not reduce the result to a count of shared-assumption groups. For example, suppose A depends on X, B on X and Y, and C on Y. Grouping all barriers connected through a shared dependency gives one group, yet an X failure leaves C and a Y failure leaves A. The grouping alone does not describe the remaining protection.

For each relevant scenario, identify which barriers are defeated, which remain, and whether those remaining barriers can prevent, detect, or contain the harm in time. If one compromise defeats every barrier on a path, record that common failure explicitly. This produces a scenario-based assessment rather than a universal depth score. Different control types and their evidence fit into the asset-and-path analysis in The Control Everyone Passed.

References

• NIST Computer Security Resource Center Glossary, defense in depth