Many organisations hit by ransomware had backups. The problem was that the backups were encrypted along with everything else, or that nobody had ever tried restoring from them.

The reason is simple. Before running the ransomware, the attacker spends days or weeks inside the network. In that time they find the backup server and, with the administrator access they already hold, delete or encrypt the backups first. While recovery is possible, a ransom is hard to collect.

The 3-2-1-1-0 rule

The old 3-2-1 rule was designed for disk failures and fires. Against ransomware it needs two more numbers:

  • 3 copies of the data: the original and two backups
  • 2 different kinds of media, such as disk and tape, or two separate storage systems
  • 1 copy off site
  • 1 copy offline or immutable, which cannot be deleted over the network
  • 0 errors in restore tests

The last two are the ones most organisations are missing.

What immutable means

A copy that not even a system administrator can delete or overwrite until a set period has passed. Common ways to get one:

  • Object storage with Object Lock, in the mode where not even an administrator can lift the lock
  • Tape or a disk that is disconnected after the backup and kept somewhere else
  • A backup repository that only allows additions, where deleting requires a delay and a separate approval

Mistakes that defeat the backup

  1. The backup server is joined to the domain. An attacker who becomes domain admin reaches the backup server too. The backup system needs its own accounts and its own passwords.
  2. The backup target is an open network share. Any server that can write to it can have its ransomware write to it.
  3. Snapshots live on the same storage. Snapshots are great for bringing back one file, but if the attacker holds the storage console, the snapshots go too.
  4. Only data is backed up, not configuration. Restoring without the configuration of the firewall, Active Directory and the virtualisation platform takes days.
  5. The backup encryption key sits on the same server. Keep it apart; an encrypted backup without its key is worthless.

Test the restore

A backup whose restore has never been tested is only a hope. At least once a quarter:

  1. Restore a whole server from scratch in an isolated environment, not just one file.
  2. Time the whole job and compare it with the outage the organisation can tolerate (RTO).
  3. Check how old the last good copy is, and how much data would be lost (RPO).
  4. Write down the result, even when everything went well.
Don't do your first full restore on the day of the incident. That day should be the second time, or the tenth.

In summary

Ask yourself: if an attacker became domain admin today, could they delete the backups? If the answer is "yes" or "I don't know", an offline or immutable copy and one full restore test are your two jobs this month. And if you don't know how long an attacker could have been inside, centralised logging is the first place to find out.