No Immutable or Air-Gapped Backup Copy

Every backup copy is modifiable or deletable over the network by anyone holding sufficient privileges: online replication to a reachable second site, write-accessible storage, retention settings adjustable by an administrator. There is no copy whose destruction would require anything beyond stolen privileges — no technical immutability (non-revocable write-lock during the retention period), no genuine air gap.

This is structural: backup is designed against failure and human error — restore fast, restore often — not against an adversary who holds administrative privileges. These are two different threat models that the architecture conflates. The “three copies, two media, one offsite” rule is often satisfied on paper… with all three copies reachable from the same administrative plane.

Against human-operated ransomware, backups are a primary target, dealt with before encryption. If every copy is reachable, restoration capability disappears at the exact moment it becomes necessary.

This is the variable that separates the two outcomes of a mass encryption event: restoration in days, or rebuilding in weeks — with, in between, a negotiation that would not otherwise arise, conducted from a position of maximum weakness since the attacker knows exactly what they destroyed.

Two nuances that prove costly when discovered too late:

• the surviving copy must predate the compromise: an immutable copy of data that was already encrypted or booby-trapped freezes the problem in place, not the solution;
• it must be restorable: a never-tested set, a lost catalog, a restore duration never measured turn the surviving copy into nothing more than a promise.

A one-hour tabletop exercise is enough, provided it is played honestly: grant the hypothetical adversary your own maximum privileges, and enumerate how each backup copy could be destroyed. If every copy falls, the pattern is present.

Specific checks:

• is the immutability lock actually enabled — not merely supported by the product — and does its duration cover a realistic dwell time (weeks)?
• does immutability hold up against the storage administrator themselves, or can a sufficiently privileged account lift it?
• is the “offline” copy genuinely disconnected, or simply “on another network” reachable via pivoting?
• who can reduce the retention period, and can this be done alone, immediately, with no grace period?
• when was the last test restore performed from the protected copy, and how long did it take?

Establish at least one copy that is out of reach of production privileges:

• storage with verified immutability — a non-revocable write-lock for the duration of the retention period, including against the storage administrator — or a genuinely disconnected copy, with a rotation that bounds the acceptable loss window;
• size the immutability duration against dwell time: weeks, not days;
• protect the backup catalog at the same level as the data itself: without it, the data exists but restoration becomes an expedition;
• periodically test restoration from this copy: integrity, completeness, duration — the measured duration becomes an input to the continuity plan, not an incident-time discovery;
• align this with trust-plane separation (see MFL-003): immutability bounds the impact, separation reduces the likelihood. The two complement each other; neither replaces the other.

If the intrusion is detected before impact, the absolute priority is to create what is missing: a copy out of reach of production privileges, now — export to disconnected or locked storage, even partial, starting with irreplaceable data. Every hour counts: backup destruction precedes encryption, and the window is short.

If destruction has already occurred, take inventory before drawing conclusions:

• storage-array-level snapshots, secondary replicas, forgotten historical exports, copies held by third parties, data residing in external services with their own retention;
• check whether the deletion is logical or physical: depending on the solution and the storage, “deleted” sets may remain recoverable, sometimes with the help of the solution vendor’s support;
• collect and preserve what remains before any manipulation of the storage: improvised recovery attempts destroy what they are trying to save.