Backup Security and Immutable Backup Guide

Backups only help after an attack if the attacker could not reach, delete, encrypt or poison them, and most backup estates are administered with the same identities the attacker has already stolen. Ransomware operators look for backup consoles, snapshots and cloud recovery points early, because destroying them raises the pressure to pay. This guide covers how to design backups that survive: 3-2-1-1-0, immutability and object lock, air gaps and logically isolated vaults, protection of backup administrators and service accounts, encryption keys, malware scanning and restore testing. It is written for infrastructure, cloud and security engineers who run backup platforms and for architects choosing between storage options. Response and recovery once ransomware has hit are covered elsewhere.

Key takeaways

• The backup system is a tier 0 asset. It can read every system it protects and often stores credentials for them, so a compromised backup server is a compromised estate.
• Immutability must be enforced by the storage, not by policy. Use object lock in compliance mode, locked retention policies or locked backup vaults for at least one copy; governance modes can be lifted by anyone with the right permission.
• Separate the identities. Backup administration needs its own identity domain, phishing-resistant MFA and multi-person approval for destructive actions; backup service accounts should be able to write but not delete.
• Keep keys away from the data. Encrypted backups stored next to their keys, or keyed with material the attacker controls, give no protection.
• The zero in 3-2-1-1-0 is the hard part. Only restore tests, including full tier 0 restores, prove a backup works and is clean.

Why backup infrastructure is a target

MITRE ATT&CK T1490 Inhibit System Recovery (Impact) describes how attackers remove the ability to recover before encrypting: vssadmin.exe delete shadows /all /quiet and wmic shadowcopy delete remove volume shadow copies, wbadmin.exe deletes the Windows Backup catalogue, bcdedit.exe and REAgentC.exe disable recovery options, and on ESXi vim-cmd vmsvc/snapshot.removeall deletes every VM snapshot. In cloud environments T1490 notes attackers may "disable versioning and backup policies and delete snapshots, database backups, machine images".

• Backup servers hold the keys to the estate: CVE-2023-27532 in Veeam Backup & Replication (CVSS 3.1 7.5, added to the CISA Known Exploited Vulnerabilities catalogue in August 2023) allowed encrypted credentials stored in the configuration database to be obtained, which "may lead to gaining access to the backup infrastructure hosts".
• Management planes cause the most damage: NIST SP 800-209 notes that access to storage management hosts "provides the attacker with the ability to cause almost unlimited damage".
• Backup providers are targets too: the Commvault Metallic breach exposed customers' Microsoft 365 application secrets held by a SaaS backup service.
• Cloud storage can be ransomed with its own features: T1486 describes attackers using SSE-C (server-side encryption with customer-provided keys) in AWS, as in the Codefinger S3 ransomware campaign, where stolen keys were used to re-encrypt buckets.

3-2-1, 3-2-1-1-0 and what each copy is for

The NCSC describes the common rule as "at least 3 copies, on 2 devices, and 1 offsite", and points out that it does not on its own require any copy to be offline. 3-2-1-1-0 is industry shorthand that adds one offline, air-gapped or immutable copy and zero errors in restore verification. Treat each element as a requirement with a test:

NIST IR 8374 Rev. 1, the ransomware profile of NIST CSF 2.0, interprets PR.DS-11 ("Backups of data are created, protected, maintained, and tested") as needing a copy "stored offline or otherwise in a manner that prevents access to them by the attacker".

Immutability: WORM and object lock

Immutable storage uses a write-once-read-many (WORM) model: NIST SP 800-209 describes it as the ability to "lock data after it has been created, thereby preventing it from alteration or deletion". The difference between products lies in who can lift the lock.

AWS documents Cohasset Associates assessments of S3 Object Lock and Backup Vault Lock against SEC 17a-4, CFTC and FINRA rules, and Microsoft documents the same for Azure immutable blob storage (SEC 17a-4(f), CFTC 1.31(c)-(d), FINRA 4511). These are examples; other platforms and backup appliances offer equivalent locks.

Choosing the mode: use governance or unlocked policies while you tune retention and test restores, then move the protected copy to compliance or locked mode. Use strict mode for the ransomware-resistant copy, because a governance lock protects only against accounts without the bypass permission, and attackers target exactly the accounts that hold it. Set retention longer than your likely detection time, since the restore point must predate the intrusion.

Trade-offs: strict locks cannot be undone, so a misconfigured retention period is paid for in storage cost for its full term. CISA warns to use immutable storage "with caution as it does not meet compliance criteria for certain regulations": data protection erasure duties and minimisation can conflict with long locks, so agree retention with legal and privacy teams first. Some workloads that append to a blob, such as SQL Server Backup to URL, fail on locked Azure containers unless protected append writes are allowed.

Air gaps and logically isolated vaults

Immutability stops alteration; isolation stops access. The NCSC recommends "never having all backups connected (or 'hot') at the same time", and that an offline backup not in use must also be "digitally disconnected".

• Physical air gap: tape or removable media taken offline and offsite. Strongest isolation, slowest restore; suits a last-resort copy of tier 0 and critical data.
• Logically air-gapped vault: a managed vault in a separate control plane. AWS Backup's logically air-gapped vault is always locked in compliance mode, stores backups in an AWS Backup service owned account, can be shared through AWS RAM to named recovery accounts for restore, and integrates with Multi-party approval so backups can be recovered even if the owning account is inaccessible.
• Separate account or tenant: copy backups to a dedicated recovery account, subscription or tenant with no trust from production identities. This is only as isolated as its identity configuration.
• Same-platform snapshots: fast but not isolated. SP 800-209 notes that if source data is unavailable, "the snapshots will not be usable as well", and they share the production administrative plane.

Small vs large organisations: a small organisation can meet the requirement with a cloud backup service that offers locked retention, plus one locked copy in a separate account. A large organisation should run a dedicated cyber recovery vault for tier 0 and critical data, with its own identity, network and restore tooling, sized for recovery time objectives agreed in the business impact analysis (NIST SP 800-34 defines recovery time and recovery point objectives there).

Where identity fits: backup admins and service accounts

Most backup deletions use valid credentials. The defence is to make the backup plane a separate identity domain whose destructive actions need more than one person.

• Separate identity domain: do not join backup servers or consoles to the production Active Directory, and do not administer them with domain admin accounts. Use a dedicated directory, a separate cloud account or tenant, and privileged access workstations.
• Backup Operators group: Microsoft notes its members "can back up and restore all files on a computer, regardless of the permissions", can sign in to domain controllers and can replace files there, so "they're considered to be service administrators". Keep it empty unless needed and monitor membership (SID S-1-5-32-551). See the Active Directory and Entra ID Hardening Guide.
• Phishing-resistant MFA and just-in-time access: require it for every backup console and cloud backup role, and elevate only when needed. See the Privileged Access Management Guide.
• Multi-person approval: Azure Backup multi-user authorisation (MUA) gates critical operations through a Resource Guard owned by a different security admin; disabling soft delete and removing MUA are always protected, and deleting backup data, reducing retention and disabling immutability can be. Microsoft says the backup admin must have no permissions on the Resource Guard and that placing it in a different tenant gives maximum isolation. AWS offers Multi-party approval for logically air-gapped vaults.
• Write-only service accounts: the NCSC advises that clients should only be able to create or append backups, because ransomware with "privilege to only create new data cannot overwrite your existing backups", and that cloud backup clients "should not have valid credentials while your cloud storage is not in use".
• Guardrails above the account: ATT&CK mitigation M1018 suggests AWS Service Control Policies to restrict deletion of backups, snapshots and images, for example denying backup:DeleteRecoveryPoint and ec2:DeleteSnapshot outside an approved break-glass role.
• Backup API keys and agent credentials: backup software stores credentials for hypervisors, databases and SaaS tenants (the Veeam CVE above shows why). Vault them, scope them, rotate them and alert on use from outside the backup servers. Static cloud keys with delete rights on backup buckets are the Codefinger pattern. See the Service Account Security Guide and the Secrets Management Guide.

Encryption and key management

• Encrypt backups at rest and in transit: NIST SP 800-53 CP-9(8) asks for cryptographic protection of backup information. CISA's baseline is "offline, encrypted backups of critical data".
• Store keys separately: backups and their keys in the same account, vault or admin domain fall together. The GoTo breach involved stolen encrypted backups together with an encryption key for a portion of them, and the LastPass breach used stolen DevOps secrets to reach cloud backups.
• Back up the keys out of band: the NCSC's cloud backup principles call for "robust key management" and an out-of-band key backup, for example a master key on paper or as a QR code stored securely.
• Use a recovery-owned key: AWS recommends AWS owned keys for logically air-gapped vaults, or a customer-managed key "from another account in a secondary organization dedicated to recovery". A key the attacker can schedule for deletion is a ransom lever.

See the Cryptographic Key Management Guide.

Malware scanning and restore testing

NIST CSF 2.0 RC.RP-03 requires that "the integrity of backups and other restoration assets is verified before using them for restoration". A backup taken during an attacker's dwell time is intact but infected.

• Scan on a schedule and before restore: scan backup content with current signatures and incident indicators in an isolated environment.
• Retain by time, not count: the NCSC asks providers to keep backups for a fixed period rather than a fixed number of copies, so a burst of corrupted backups cannot push good ones out, and to keep a version history.
• Test restores regularly: CISA says to "regularly test the availability and integrity of backups in a disaster recovery scenario". Test file, application and full-system restores, and at least once a year restore tier 0 (directory, DNS, PKI, IdP configuration) into an isolated network.
• Measure against objectives: a test passes only if it meets the recovery time objective and the restored system works.

Snapshots, databases and SaaS

• Snapshots: useful for fast operational recovery but never the only copy. Copy them to a separate account and lock the copies.
• Databases: native dumps and log backups often land on a file share writable by the database service account. Send them to locked storage, protect transaction log chains and encrypt with keys the DBA account cannot delete.
• SaaS: native retention and recycle-bin features in Microsoft 365, Google Workspace or CRM platforms sit under the same tenant admins an attacker may hold, so they are not an independent copy. If you use a SaaS backup service, its OAuth app holds broad read access to the tenant; govern it as a high-privilege NHI. See the SaaS and OAuth App Governance Guide.

Implementation: a phased approach

1. Inventory and classify: list every backup system, vault, bucket, snapshot policy and the identities that administer them, and map critical systems to their copies and recovery objectives.
2. Separate identity first: move backup administration out of the production domain, enforce phishing-resistant MFA, remove standing admin rights and empty Backup Operators.
3. Restrict service accounts: convert backup clients to create or append only, vault their credentials and remove delete permissions.
4. Pilot immutability in flexible mode: enable governance mode or an unlocked policy on one workload, confirm backup jobs, append patterns and restores work, and size storage cost for the retention period.
5. Lock one copy: move the ransomware-resistant copy to compliance or locked mode in a separate account or logically air-gapped vault. Rollback is only possible before locking or during grace time, so review retention values with a second person first.
6. Add multi-person approval and guardrails: MUA or Multi-party approval, deny policies on deletion APIs, and alerts.
7. Test: attempt to delete a locked backup with an admin account (it must fail), then run restore tests, including tier 0, and record results.

Detection and measurement

The NCSC's fifth cloud backup principle lists the events to alert on, successful or not: mass deletions, backups stopping, changes to global retention or encryption policies and changes to administrator accounts. Alerts must reach owners through a channel that survives a compromised corporate tenant. Also watch for:

• Process creation of vssadmin, wbadmin, bcdedit, wmic shadowcopy, diskshadow and REAgentC on servers (ATT&CK detection DET0329 covers these patterns).
• Cloud API calls that disable versioning, backup plans or snapshot schedules followed by deletes, and object lock or vault lock configuration changes.
• Backup console logins from outside admin workstations, new backup admins and Backup Operators changes.

Metrics that show the programme works:

• Immutable coverage: percentage of critical systems with at least one locked or offline copy.
• Restore test success: percentage of scheduled restore tests that met RTO and passed validation.
• Tier 0 restore time: measured end to end in the last test.
• Backup admin hygiene: number of standing backup admins and of backup service accounts with delete rights (target near zero).
• Retention versus dwell time: oldest clean restore point compared with the detection time assumed in the risk assessment.

Common failure patterns

• Backups in the production domain: the backup server is joined to Active Directory and deleted with the same domain admin account used to deploy ransomware.
• Governance mode treated as immutable: an attacker with the bypass permission removes the lock.
• Long-lived cloud keys with delete rights: stolen keys erase or re-encrypt storage, as in the Codefinger campaign.
• Keys stored with the backups: an attacker who takes the backups also takes what decrypts them.
• Restores never tested at scale: jobs report success, but nobody has rebuilt a domain controller or core application from them.
• Retention shorter than dwell time: every surviving restore point already contains the attacker's tools.

Framework mapping

Practitioner checklist

• Treat backup servers, consoles and vaults as tier 0 and remove them from the production domain.
• Keep at least one copy of every critical system in compliance-mode, locked or offline storage.
• Set retention longer than your assumed attacker dwell time.
• Require phishing-resistant MFA, just-in-time access and multi-person approval for destructive backup actions.
• Make backup service accounts create or append only, vault their credentials and rotate them.
• Deny deletion of backups and snapshots with organisation-level policy outside a break-glass role.
• Store encryption keys in a separate recovery account and keep an out-of-band key backup.
• Alert on mass deletion, stopped jobs, retention and encryption changes and backup admin changes.
• Scan backups and run restore tests, including a yearly tier 0 restore into an isolated network.

Standards and references

• NCSC: Principles for ransomware-resistant cloud backups
• CISA: #StopRansomware Guide
• NIST: SP 800-209, Security Guidelines for Storage Infrastructure
• NIST: SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
• MITRE ATT&CK: T1490 Inhibit System Recovery
• AWS: Locking objects with Object Lock
• Microsoft Learn: Immutable storage for Azure Blob Storage
• Microsoft Learn: Multi-user authorization for Azure Backup

Related NHI Mgmt Group resources: Ransomware Prevention Guide · Incident Response Guide · Service Account Security Guide · Secrets Management Guide · Cryptographic Key Management Guide