This article is structured around four complementary approaches aimed at strengthening end‑to‑end backup security. After addressing, in Part 1, backup usability (1) and the security of the backup infrastructure (2), this second part focuses on the last two approaches: protecting backups against logical destruction (3) and identifying the residual risks associated with the measures implemented (4).
3. Protecting backups against logical destruction
As part of a defense‑in‑depth approach to backup protection, and in light of the threat landscape observed, the assumption of an illegitimate takeover of components within the storage and backup infrastructure must be considered.
More generally, in order to effectively reduce the risk of data loss, best practice dictates ensuring that backups are not exposed to the same risks (cyber or otherwise) as the stored data. This approach is notably based on diversifying backup media, implementing physical or logical segregation, and maintaining at least one isolated copy that is both offline and off‑site.
The use of mechanisms designed to prevent the alteration or deletion of backed‑up data,even in the event of a successful attack on the storage and backup infrastructure, should therefore be considered.
Immutability and air gapping represent the two main approaches in this area. While these concepts are widely promoted by vendors, the solutions available and the residual risks associated with their implementation vary. It is therefore essential to fully understand the underlying mechanisms of these solutions in order to select the one that best addresses the required risk coverage.
According to the Cyber Benchmark conducted by Wavestone, nearly 65% of organizations implement immutability or air‑gapping mechanisms, at least for critical functions, and 21% apply them across all of their backups.
Backup Immutability, an Increasingly Adopted Technique
“Data immutability means that data can be written but cannot be modified or deleted” (NIST).
Far from being uniform, its implementation relies on a variety of technical approaches whose robustness varies depending on whether they are based on hardware or software mechanisms.
a. Purely Hardware-Based Mechanisms
- LTO WORM cartridges (with compatible hardware/firmware)
These magnetic tape cartridges allow data to be written once, preventing any subsequent modification or deletion, provided that the hardware and firmware support WORM (Write Once, Read Many) mode.
For more specific use cases :
- Blu‑ray jukeboxes
This robotic system uses WORM Blu‑ray discs to permanently store data, rendering it physically unalterable once written. - Flash storage with WORM controller (firmware / e‑Fuse bit)
Some flash storage devices incorporate a controller with dedicated firmware or hardware mechanisms such as e‑Fuse bits, enabling data to be permanently locked after being written.
b. Software-Based Mechanisms, Embedded or Appliance-Based
- Hardware appliance with local management
This is a backup‑dedicated appliance, locally configured to enforce immutability policies, often through software locks or non‑modifiable retention periods. - Hardware appliance with online management
This type of appliance enables remote management, sometimes via an out‑of‑band channel, ensuring that immutability policies cannot be altered even if the primary network is compromised. - Software installed on the organization’s operating systems
Some software solutions allow immutability rules to be defined directly at the operating system level. However, this approach may be less robust, as it can be vulnerable if the host system is compromised. - Cloud capabilities (e.g., Amazon S3 Glacier / Azure Blob Storage)
Cloud storage services offer immutability features through retention policies or WORM locks, ensuring that stored objects cannot be modified or deleted for a defined period.
It should be noted that the level of immutability can be adjusted based on the nature of the data concerned, in order to optimize the balance between security requirements and operational constraints.
Immutability is increasingly observed as a mechanism deployed within backup protection strategies and remains more commonly implemented than air gapping.
Backup Air Gapping : A Technique Observed but Less Optimized
An air gap4 is defined as “an interface between two systems in which (a) the systems are not physically connected and (b) any logical connection is not automated (i.e., data is transferred across the interface only manually, under human control).”
Like immutability, air gapping can be implemented in various ways, including:
Physical implementations :
- Offline, protected tape storage (primarily at a remote site)
Magnetic tapes are removed from the active backup system and stored in a physically separate location, preventing any network or automated access. - Tapes stored in a backup robot
Although physically connected, certain backup robot configurations allow tapes to be logically disconnected when not in use, thereby limiting the risk of unauthorized access. - Other removable storage media such as disks (stored offline)
Hard drives or SSDs can be used to transfer data, then physically disconnected and stored in a secure environment, ensuring full isolation. - Optical data diode transfer gateways
These devices enable one‑way data transfer, physically preventing any return flow of information or commands to the source system and providing a certain level of separation. When native support is not provided by backup software vendors, third‑party software agents enabling unidirectional transfer must be used in addition.
Logical Air‑Gap Implementations (Departing from Physical Isolation) :
- “Saloon door” network ports opened only during synchronization
Network connections are temporarily enabled to allow data synchronization and then automatically disabled, thereby limiting the exposure window and requiring strict controls to ensure that only legitimate replication traffic is authorized. - Isolation through access control and encryption capabilities
Strict access control mechanisms combined with encryption make it possible to restrict access to backups to precisely defined users and time windows. - Backup as a Service (isolated private cloud / third‑party cloud)
Some externalized backup offerings provide full logical isolation by segregating customer environments and limiting network interactions to strictly controlled channels. However, the risk of compromise is not null, as illustrated by a successful attack in 2025 against an online backup service targeting firewall configurations.
Subject to a risk analysis, particularly when relying on logical solutions, implementing data immutability should generally be prioritized over air gapping.
While immutability and air gapping constitute effective safeguards to preserve the integrity, and even the confidentiality, of traditional backups against risks of modification or exfiltration, other approaches that are more focused on operational optimization also warrant consideration.
In this context, the objective is no longer to secure full data copies, but rather to rely on alternative mechanisms enabling rapid and large‑scale restoration, often at the cost of certain trade‑offs. This is notably the case with snapshots, which have emerged as a preferred technical solution in environments where recovery performance takes precedence over backup completeness or robustness.
Snapshots: A Fast Recovery Solution, but Not a Full-Fledged Backup
To better understand what the concept of a snapshot technically entails, it is useful to refer to the definition provided by NIST: “A record of the state of a running image, typically captured as the differences between a reference image and the current state.”
In other words, a snapshot represents an instantaneous capture of the state of a file system or data volume at a given point in time. Unlike a full backup, it records only the blocks or files that have changed since the reference state. This mechanism, which is fast and resource‑efficient, is particularly well suited to environments where rapid recovery is a priority. It is therefore widely used in virtualized and cloud infrastructures.
However, this operational efficiency comes with notable trade‑offs in terms of backup quality. Snapshots do not constitute independent copies of data; they depend on the integrity of the host system. In the event of corruption of the primary volume, snapshots may become unusable. In addition, their lifecycle management (rotation, retention, application consistency) requires particular rigor to avoid operational drift.
While effective in accelerating business recovery, snapshots cannot replace a true backup strategy. They should be considered as a complement to more robust mechanisms that ensure long‑term data durability and integrity.
Whether dealing with snapshots or traditional backups, their integration into a protection architecture requires a thorough risk analysis, including the identification of residual vulnerabilities.
4. Risk-Based approach and identification of residual risks
Given the stakes associated with irreversible data loss and/or prolonged disruption of critical business activities, risk analysis applied to backup mechanisms is not an optional step but rather a fundamental pillar of a consistent and well‑controlled backup strategy.
Embedding Risk Analysis at the Core of Backup Management
Whether or not it is part of a formal certification or authorization process, conducting a risk analysis of backup mechanisms aims to ensure that the controls in place are aligned with identified threats and business continuity requirements.
In this context, a risk analysis applied to backups, based, for example, on the EBIOS Risk Manager (EBIOS‑RM) methodology proposed by ANSSI, makes it possible to assess existing controls, identify plausible attack scenarios such as compromise of the backup server or data tampering, and evaluate their likelihood. This approach helps prioritize security measures according to their potential impact on business activities, while ensuring that residual risks remain acceptable with regard to business objectives.
Monitoring residual risks, those that persist despite the implementation of protection measures, is a natural extension of the risk analysis process. It is therefore essential to identify, document, and integrate them into an ongoing security risk management strategy. By way of illustration, such residual risks may include:
- Insider threat : A malicious administrator or an employee with privileged access may intentionally alter or delete backups.
- Compromise of the cloud backup service provider : A compromise of the cloud provider, for example through the exploitation of non‑public vulnerabilities, could allow an attacker to access or manipulate backups while bypassing customer‑side security mechanisms.
- Compromise of customer (tenant) accounts : Unauthorized access to customer accounts may result in loss of control over backups, including their deletion or alteration.
- Destruction of backup solution assets : If the backup infrastructure is destroyed (physically or logically), restoring backups may become difficult or even impossible in the event of the loss of critical resources such as:
- Backup catalogs / backup tool databases
- Secrets such as decryption keys
- Technical compromise of the backup tool : An attacker may render backups unusable by exploiting technical vulnerabilities in the backup software or the host system, including via low‑level out‑of‑band access mechanisms such as iLO or iDRAC.
- Compromise of administrative accounts : Even with immutability mechanisms in place, functional compromise of administrative accounts may allow an attacker to disable or bypass protections before, and in some cases after, data is written (retention periods, time‑management mechanisms, etc.).
- Compromise of the backup tool’s cybersecurity controls : If an attacker tampers with backup protection settings, such as encryption parameters (e.g., encryption_secret), backups may remain unusable.
Once a secure backup solution is implemented, complement the analysis with periodic audits, Including Red Team Exercises
In addition to theoretical risk analysis and residual risk monitoring, periodic audits help identify vulnerabilities related to the implementation of the backup solution. Among the possible audit types, Red Team exercises aim to reproduce the behavior of an attacker seeking to destroy backups. These exercises also serve to test the effectiveness of the technical and human measures in place for protection, detection, and response to an attack.
Conclusion
Protecting backups against ransomware relies on a holistic approach rather than a purely “product‑based” one :
- Continuously verifying the reliability of backups to ensure effective reconstruction of the information system;
- Securing the backup infrastructure by reducing its attack surface;
- Protecting backed‑up data, with immutability as a priority;
- Adopting a cross‑functional, risk‑driven approach to security management.
The level of rigor required for backup security will continue to increase as attackers refine their techniques and strengthen their capabilities.
Continuous vigilance and adaptation to the evolving threat landscape therefore remain the strongest allies of a resilient backup strategy.
