In many ransomware attacks, the attacker stays in the network for a while before encrypting servers, gains administrator access and goes after the backup console. They delete or encrypt the backups first, then the servers. The company loses both its primary data and its backups, and is left with very few options.
Immutable backups are designed for exactly this scenario.
What does immutable mean?
An immutable backup is a copy that, once written, can be neither changed nor deleted until a defined period ends, even if someone logs in with the backup software’s administrator account. The concept is also known as WORM (write once, read many).
The difference from a “regular backup with a strong password” is that protection is enforced at the storage layer, not just at the user access level. If the admin account is compromised, a strong password no longer helps, but the immutable lock stays in place.
Common implementation methods
- Hardened Linux repository: Software such as Veeam can lock backup files on a Linux server for a set period. This server should run the minimum number of services, and SSH access should be closed after setup.
- Object Storage with Object Lock: S3-compatible storage that supports Object Lock does not allow data to be deleted before the retention period ends. In Compliance mode, not even the account administrator can remove the lock; in Governance mode, users with special permission can.
- Storage with lockable snapshots: Some NAS devices and storage arrays create snapshots that cannot be deleted for a set period. How strong this protection really is depends on the device model and firmware version.
- Offline media: Tape or disk that is disconnected after the backup and stored in a safe place. This is not immutable in the technical sense, but because it cannot be reached over the network, it serves the same purpose.
Immutable does not replace your other backups. You usually keep a fast, regular copy for everyday restores and an immutable copy as your lifeline.
Key points when implementing
- Choose the lock period carefully. Ransomware may be discovered late. Pick a period that keeps at least a few clean copies from before a possible breach; for many companies, a few weeks is a reasonable starting point.
- Plan your storage capacity. Locked copies cannot be deleted early; if the storage fills up, new backups will fail.
- Secure the server itself. Don’t join the repository server to the domain, create separate accounts with two-factor authentication, and restrict hardware management access such as iLO or IPMI. Anyone who reaches the hardware console may be able to wipe the disks.
- Protect the server clock. Time-based locks depend on the system clock. Use a trusted NTP source and restrict the ability to change the time.
- Test restores from the immutable copy. This copy is meant for the day of a crisis, and you must be sure it actually works.
Common mistakes
- Setting up the immutable repository on the same server that also runs the backup software, the domain or other services.
- Choosing a lock period that is too short, such as a few days, which in practice expires before the attack is discovered.
- Assuming that a regular VM snapshot or the storage Recycle Bin is the same as immutable.
- Not monitoring repository space and losing new backups because the storage filled up.
Checklist
- At least one copy of your backups is immutable or offline.
- The lock period matches the likely time to discover an attack.
- The repository server is separate from the domain and its management access is restricted.
- The repository server’s time source is controlled.
- Repository space is monitored and has room for data growth.
- A restore from the immutable copy has been tested in the last few months.
Immutable backup is one of the most effective measures against ransomware, provided it is designed correctly. ITPlus724 engineers can design and deploy an immutable repository that fits your company’s current infrastructure.