Attackers now go after backups first. How to build a backup architecture that actually holds up against ransomware, with the 3-2-1-1-0 rule, immutable storage, separated identity management and regular restore testing.
The classic ransomware playbook has changed. After getting in, attackers no longer encrypt files straight away. They first find the backup infrastructure, delete or encrypt the backups, and only then move to production. A company left without backups must choose between paying the ransom and a rebuild that can take months. So "we have backups" is not enough; the question is whether those backups will survive the attacker.
What Is an Immutable Backup?
An immutable backup cannot be deleted, encrypted or overwritten by anyone until its retention period expires. "Anyone" includes administrator accounts. Even if an attacker takes over the most privileged account, they cannot touch these backups. This approach is also known as WORM (Write Once, Read Many).
Ways to Achieve Immutability
- Object lock (S3 Object Lock): on S3-compatible storage, each object is given a retention period. In "compliance" mode nobody can delete the object before the period ends; in "governance" mode specially privileged accounts can. For ransomware scenarios, compliance mode is the right choice.
- Hardened Linux repository: a dedicated repository server that uses the backup software's immutability feature, with SSH disabled and single-use credentials (Veeam Hardened Repository is a common example).
- Offline copy (air gap): tape or media physically disconnected from the network. Slow, but out of reach of an attacker on the network.
- Managed off-site backup: a copy of your backups held immutably by a provider, independent of your own identity infrastructure.
The 3-2-1-1-0 Rule
The classic 3-2-1 rule has been extended with two more items for the ransomware era:
- 3 copies of data (including production)
- 2 different storage media
- 1 copy in a different location
- 1 copy immutable or offline
- 0 errors: backups with verified restores
Identity Separation: The Most Overlooked Step
If the backup server is joined to the company's Active Directory, an attacker who takes over a domain admin account gets into the backup console as well. Therefore:
- Keep backup infrastructure out of the domain; use separate local accounts.
- Enforce multi-factor authentication for the backup console and repository access.
- Put the backup network in a separate segment; make the console unreachable from the internet.
- Require a second approval (four-eyes rule) for actions such as deleting backups or shortening retention.
Choose the Right Retention Period
Attackers often spend days or even weeks in an environment before encrypting. If your immutable retention is shorter than that, you may not find a clean restore point. A practical starting point: at least 30 days of immutable retention for daily backups, plus weekly and monthly copies on top. Longer retention means higher storage cost; strike a balance by setting longer periods for critical systems and shorter ones for the rest.
No Restore Test, No Backup
- Run a full restore test for critical systems at least once a quarter and measure the time it takes.
- Scan backups for malware before restoring; you don't want to restore a backdoor planted before encryption.
- Document which system is restored in which order (identity and DNS first, then databases, then applications).
Common Mistakes
- Keeping backups on the same storage system or network share as production
- Treating snapshots as backups
- Not patching the backup software and repository operating system
- Nobody following up on failed backup alerts
- No clear plan for who does what during an attack
CloudRUX Backup as a Service (BaaS)
With CloudRUX BaaS you can keep a copy of your backups in data centres in Turkey, independent of your own environment and identity infrastructure. Our engineers can help you design the immutable retention period, restore tests and a ransomware recovery plan. Contact us at info@cloudrux.com for an assessment.