Defense in Depth

Defense in Depth is the practice of layering multiple, independent security controls so that the failure or bypass of any single one does not result in a full compromise. It is a military strategy concept adapted to cybersecurity: defenders build several successive lines, each of which slows down, weakens or stops an attacker and covers the blind spots of the others.

This page is the frame for the rest of the section. It sets out how the layers relate to each other, which tier owns which layer, and how to confirm that the layering works in practice.

Backups as the Last Line of Defense

Backups are often called the last line of defense against unrecoverable data loss. Every other control in an organisation exists to prevent or detect an incident before damage occurs; backups exist for the moment those controls have already failed and production data has been encrypted, deleted, or corrupted.

That gives Defense in Depth two distinct applications, and conflating them is the most common way organisations get this wrong:

  • In the overall security stack, backups are the final layer behind everything else: firewalls, endpoint protection, identity controls and network monitoring. They are what remains if every one of those layers fails.
  • Precisely because of that, the backup infrastructure needs its own Defense in Depth stack, with its own layered network, identity, data and monitoring controls, so that no single failure inside the backup infrastructure is enough to take out the organisation’s last line.

Everything else on this page concerns the second stack. Three consequences follow directly from it:

  • No single layer of backup protection should be a point of total failure. This includes immutability, which is a strong layer that still needs the others around it.
  • Credentials and trust relationships that protect production should not be assumed to also protect backups.
  • Recoverability itself must be actively defended, monitored, and tested. Do not assume recoverability because jobs report success.

A Single Layer Is Never Enough

Attackers are adept at finding and exploiting the one gap in an otherwise strong environment. Each of these real-world failure patterns is a single missing layer, and each links to the page that owns it:

  • A well-hardened backup server that is nonetheless reachable because the surrounding network is flat (see Micro-Segmentation).
  • Strong network segmentation undermined because backup admin credentials are shared with, or reused from, the general Active Directory domain (see Least Privilege Access).
  • Encrypted backups that are still deleted or corrupted because the repository lacked immutability (see Immutability).
  • Effective technical controls bypassed entirely through a successful phishing email against an administrator (see Education & Training).

In each case, a single additional layer would have contained or stopped the attack. Defense in Depth is the discipline of building all of them in from the start.

Apply Hardening at Every Tier

Defense in Depth also means resisting the temptation to harden only the perimeter. Every tier of the backup solution contributes a layer, and each layer is specified elsewhere in this guide:

Tier Layer it contributes Specified in
Backup server / control plane A hardened, minimal platform and a protected configuration database Control Plane Hardening
Administrative access Named accounts, scoped roles, MFA, four-eyes approval Least Privilege Access
Network paths between tiers Trust zones, default-deny communication, air gap Micro-Segmentation
Data movers (proxies, gateways) Minimal privilege and scope; expendable components that grant no onward access Micro-Segmentation
Repositories Immutability, and copies across independent resilience zones Backup Data Hardening
Backup data itself Confidentiality in transit and at rest, and key custody End-to-End Encryption
Monitoring Detection of drift and compromise across all of the above Proactive Validation
People Recognition of and response to social engineering Education & Training

An environment that hardens the console but leaves repositories openly accessible (or the other way around) has only moved the weakest link.

A pre-hardened appliance is one strong layer among several. It does not segment your network, does not put a second copy in another resilience zone, and does not stop an administrator who is entitled to be there. Defense in Depth is measured by what survives once that layer is bypassed.

Combine Controls

The layers above fall into categories, and each category covers risks the others cannot. A resilient backup architecture should combine controls across several categories, rather than concentrating into just one:

  • Network controls: firewalls, segmentation, restricted management interfaces, controlled routing between production and backup.
  • Identity controls: MFA, least-privilege roles, and four-eyes approval, so that no single credential is sufficient to act on backup data. Specified in Least Privilege Access.
  • Data controls: encryption, immutability, and access controls treated as independent safeguards, so that a compromised administrative account still cannot alter or delete data within the retention period.
  • Operational controls: patch management, configuration baselines, and periodic access reviews that keep the other layers from silently degrading.

A strong identity control does not compensate for an unsegmented network, and encryption does not compensate for a lack of immutability. The goal is deliberate redundancy across categories.

Monitoring is the category that watches the others. Every layer above can degrade silently: an immutability setting is changed, an alarm is disabled, a firewall rule is loosened, or a credential stays active after someone changes role. None of these changes announces itself. A layered architecture with no detective layer is a set of controls whose current state nobody actually knows.

Monitoring is therefore a layer of this stack, although this section does not cover it in detail. Baselines and visibility, alarms and continuous monitoring, malware and threat detection, and forwarding backup signals into the SOC are specified in Proactive Validation.

Redundant Copies as the Layer of Last Resort

Every other layer is preventive or detective. Redundant copies are the layer that assumes all of those have failed for at least one copy, while the others remain intact.

The 3-2-1 rule and the copy strategy behind it are specified in System Resilience. What matters here is the containment property: distributing copies across separate resilience zones (distinct administrative, network and sometimes geographic boundaries) keeps the blast radius of a compromised zone to that zone alone.

A resilience zone is a boundary around a copy. It is only doing its job if compromising one gives an attacker no path to the others, which means each needs its own credentials, its own network path, and its own immutable storage.

Zero Trust Data Resilience

Assume that every other control (network segmentation, encryption, monitoring) might eventually fail for at least one copy, while remaining intact for the others. For Defense in Depth specifically, this is what prevents a successful, sophisticated attack from destroying every copy of the data at once. The existence of independently secured, redundant copies across multiple resilience zones is what ultimately guarantees recoverability.

Testing That the Layers Hold

Layering is easy to draw and hard to verify. A diagram showing five controls between an attacker and the backup data says nothing about whether four of them are actually load-bearing. The only way to know is to remove one deliberately and observe what happens.

Work through failures one at a time. Before each test, write down which layer you expect to catch it. A test only proves something if you named the catching layer in advance and confirmed that it was the one that stopped the attempt.

Assume this layer has failed Which layer should catch it What you are confirming
An administrator’s credentials are phished MFA, then four-eyes approval, then immutability That one credential cannot delete backups, and that the deletion attempt is visible
A backup proxy is compromised Segmentation and scoped credentials That the proxy grants no onward path to repositories or to production
A firewall rule is misconfigured Default-deny elsewhere and repository isolation That one wrong rule does not expose the Restricted zone
A repository is reachable and writable Immutability and a copy in another resilience zone That data cannot be altered within retention, and that another zone is untouched
A backup file is exfiltrated Encryption and key custody That the copy is unusable without keys held elsewhere

Run this on a regular schedule, and pair it with red-team or penetration testing to confirm lateral movement paths have not reopened over time. Continuous drift detection complements these tests. Drift detection tells you that a control changed; these tests tell you whether the remaining controls still catch what the changed one used to. That side is specified in Proactive Validation.

References

Back to top

Copyright © 2019 - 2026 Solutions Architects, Veeam Software.
Please note that information provided in this guide is not produced or verified by Veeam R&D but is a result of community effort based on the field observations.