Ransomware: the backup that holds

When ransomware hits, the only question that matters in the first hours is: does the backup hold? We have seen both answers. The organizations that could say yes did not have more budget than the others. They had three things: a copy the attacker could not reach, a copy the attacker could not modify, and dated proof that restoration worked.

What the official guides say

The Canadian Centre for Cyber Security, in its ITSAP.00.099 sheet on ransomware, is direct: "Ensure your backups are encrypted and stored offline without connection to the Internet or local networks." It explains why: threat actors infect backups connected to production systems to make recovery impossible, and you must create many security barriers between production and backups. It asks you to test the backup process, a condition for a quick and effective recovery, and to analyze backup files before restoration to make sure they are free of malware. It advises against paying the ransom, which guarantees nothing.

Its ITSAP.40.002 sheet on backups adds the 3-2-1 rule: three copies of your information (the original and two backups), on two different media types, with one copy kept off site. It defines offline ("cold") backups as copies that remain unconnected to the organization's systems and are only connected when required, and asks you to test recovery on a routine basis.

CISA's #StopRansomware Guide, updated in September 2023 with MS-ISAC, the NSA and the FBI, says the same thing in one sentence: "Maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario." It specifies that many ransomware variants look for accessible backups and delete or encrypt them. It recommends keeping golden images of systems (preconfigured operating system and applications) to rebuild quickly, and, for cloud environments, immutable storage solutions, noting that they require careful configuration.

Why it matters

Three lessons recur in our engagements. None of them requires new technology.

The online backup is the first target. In the cases where the backup gave way, the scenario is always the same: the backup server was joined to the domain, the attacker obtained an administrator account, and deleted the copies before launching encryption. A backup console reachable with production credentials is a door, not a protection.

Immutable means that nobody, not even you, can delete. The organizations that held had enabled copy locking for a fixed duration, on a repository whose writing account had no delete right. Where immutability was "enabled" but could be disabled by the same administrator, it was useless.

A restoration never tested is a hypothesis. We have seen intact copies that could not be restored in useful time: encryption key lost with the server, missing dependencies, unknown rebuild order. The complete, timed test on a representative system is what separates the backup that exists from the backup that holds.

What we think at Sentrix

In the order we do it with the organizations we support:

1. Isolate the backup from the production identity: repository outside the domain, separate accounts, phishing-resistant MFA on the console, no delete right for the account that writes.
2. Make one copy immutable with a locked retention period, and verify that disabling it requires a separate procedure, not an administrator's click.
3. Keep one copy offline, disconnected except while writing, as the Cyber Centre sheets require, and one copy off site according to the 3-2-1 rule.
4. Test a complete restoration on a fixed date, timed, with the golden images CISA recommends, and keep the report as evidence: that is what ISO 27001 (control 8.13) and SOC 2 (availability) ask for.
5. Plan the scanning of copies before restoration in the recovery plan, and know how far back to go if the intrusion is old.
6. Put the backup in the incident response exercise scenario: the question "which copy do we restore and who has the key" must have an answer before the incident.

Our incident response service always starts with this check, because it decides everything else.

The next step

Do the exercise this week: with your main administrator's credentials, try to delete your most recent backup. If you succeed, an attacker will too. If you cannot, restore a complete system and watch the clock.