Backups are attack surface too

Backups were designed for the failures operations teams expect: a disk dies, a job double-loads a table, an analyst drops the wrong schema on a Thursday. Against those, a snapshot in the same account is perfect, because the person restoring is the same person who owns the account and nobody is trying to stop them.

An attacker changes the shape of the failure. The person who deleted the tables also holds the login that owns the snapshots, and their first move after reaching admin is to remove anything that would let you undo their second move. A backup that survives that is a different object from a backup that survives a disk failure, and most estates have only the second kind.

• Time travel - a warehouse feature that lets you query a table as it was some hours or days ago. Lives inside the account. Purged by whoever administers the account.
• Snapshot - a point-in-time copy the platform keeps for you, usually in the same account and region. Same owner, same fate.
• Retention window - how long time travel and snapshots are kept. A setting, which means an admin can change it, which means an attacker with admin can set it to nothing.
• Immutable copy - a backup written somewhere the reading account has no delete permission, usually a separate account with object lock or a legal-hold style retention that no login in the warehouse account can shorten.
• Restore drill - actually bringing a table back from the copy, on a known date, by a named person, in a measured time. The only evidence that a backup exists.

Time travel is a table setting. The snapshot schedule is an account setting. The retention window is a number in a configuration screen. All three are administered by the same role that creates and drops tables, because the platform reasonably assumes that the administrator is on the company's side. The moment the administrator's login belongs to somebody else, so do the settings, and a retention window of thirty days becomes a retention window of nothing in one action.

This is why the professional norm draws the line where it does. A copy counts as a backup only if the account that reads the warehouse has no permission to delete it. Not "is unlikely to", not "would need a second approval to": no permission, enforced by a different account with a different set of logins, ideally with an object lock or retention hold that nobody in the warehouse account can shorten. Anything else is a convenience feature that happens to look like a backup on a slide.

Ransomware against a warehouse does not need to encrypt anything, because a warehouse already gives an administrator everything needed to make the data unreachable. The pattern has three moves and only the third one is visible to the business.

• Make the data unreachable. Drop the tables, or overwrite them, or in some estates encrypt the underlying files. On a warehouse the drop is enough; there are twelve tables at Ironwood and dropping them is twelve statements.
• Remove the recovery window. Shorten time travel to zero, delete the snapshots, cancel the schedule. This move is the whole reason the attack works, and it is only possible because the recovery features live in the account the attacker now holds.
• Ask for money. The note arrives after the first two moves are complete, so by the time anyone knows there is an incident the question of whether a backup exists has already been answered.

Ironwood's control ladder from session 1 has a third column that nobody looked at until tonight: how many of the twelve tables survive an attacker who reaches the admin login. It reads zero at the baseline. It reads zero after MFA takes the paths from nine to six. It reads zero after key rotation, after the private bucket, after pinned dependencies, and it still reads zero at the rung where every one of those prevention controls is on and query logging has taken the undetected count to nothing: three paths, zero unseen, zero recoverable.

Then one control, immutable and restore-tested backups, moves it from 0 to 12. The path count does not change; it stays at 3. The undetected count does not change; it stays at 0. Nothing about how the attacker gets in has altered. The only thing that has changed is what they can take away when they do, and that is the whole point of the rung: a control can matter completely without touching the headline number.

The most common single security purchase, a perimeter allowlist on the warehouse, leaves Ironwood at seven paths, seven unseen, and zero recoverable tables. It does nothing for the backups for the same reason it does little for the paths: a phished admin logs in from their own laptop, inside the allowlist, and once inside they hold every setting the account has. Where a credential may be used from is a different question from what the credential may do once it is used, and the backup question lives entirely in the second.

Three things go wrong between a copy and a restore, and none of them shows up on a storage dashboard. The copy turns out to be incomplete, because the job that writes it silently skipped a table after a schema change eight months ago. The restore takes far longer than anyone assumed, because nobody had ever measured it and the crown-jewel table is four hundred million rows. And the one person who knew the sequence of steps left in the spring, and the runbook they wrote refers to a console that has since been redesigned.

A restore drill is the only instrument that detects all three. It is a scheduled event, quarterly at most estates, in which a named person restores the crown-jewel table from the immutable copy into a scratch environment, compares row counts against production, and writes down the date and the elapsed time. The write-down is the point: the date is the evidence that the backup exists, and the time is the number the incident plan is allowed to promise.

An immutable copy protects the data from the attacker by protecting it from everybody, including you. A table loaded with the wrong rows sits in the immutable copy until the retention period expires. A dataset that should never have been retained, or that a customer has a right to have erased, is held for as long as the lock says. You cannot delete your own mistakes either, and that is not a flaw in the control; it is the control.

This turns the retention window from a storage setting into a governance decision. How long the immutable copy is held, what may be written into it, and how erasure duties are met while it exists are questions for the people who own data policy, not the people who own the platform. The governance course owns the erasure duty itself; what belongs here is the recognition that immutability makes the retention number a decision with two sides, and that somebody senior has to sign it.

NIST CSF 2.0, published on 26 February 2024, names six functions: Govern, Identify, Protect, Detect, Respond, Recover. Session 2 put all six onto the estate. Recover is the one that restores assets and operations after an incident, and across most security budgets it is the function funded last, because it produces nothing on a good day and its whole value is realised on a day everyone hopes never comes.

On the day it does come, Recover is needed first. Every other function has already had its turn by the time the ransom note arrives: Protect did or did not stop the login, Detect did or did not see the drop. The only question left is whether there is a copy outside the attacker's reach and whether somebody knows how to bring it back. That is the whole of Recover, and it costs a separate account, an object lock and a quarterly afternoon.

The question a board or a customer is really asking, underneath "is the data backed up", is this: if somebody gets the admin login tonight, do we have Monday? It has a yes or no answer, and the answer is only credible with the date of the last successful restore next to it. A yes with no date is a hope. A no is uncomfortable and is also the most useful sentence a leader can put in front of a budget committee, because it names a specific thing to fund and the thing is not expensive.

• The separate account gets the same admins. For convenience, the platform team is given administrative rights on the backup account too. The two accounts are now one account with two names, and a phished platform admin reaches both. The backup account needs its own logins, held by fewer people, with its own MFA.
• The lock has an off switch in the warehouse account. Some retention holds can be released by whoever created them. If the releasing role lives in the warehouse account, the copy is deletable in two steps instead of one, which an attacker will not mind.
• The copy job stops and nobody notices. A credential expires, the job fails, the immutable copy is faithfully preserving data from six weeks ago. The restore drill catches this by comparing dates and row counts; a storage dashboard showing a healthy bucket does not.