Immutable Backups Aren’t What You Think

When I first heard the term “immutable backups”, it gave me such a warm glow. Backups that cannot be altered and, therefore, cannot be compromised in an incident that encrypts data and holds decryption keys hostage for a cyber ransom – this concept is beautiful and has obvious value in the fight to survive a potential attack. While I still love immutable backups and what they have to offer, the truth is that no single action or item is by itself sufficient. I’m going to go in to some of the potential fatal flaws of relying on immutable backups as your strategy for protection against a cyber-attack.

The first concern with immutable backups is that immutable does not equal indestructible. In Veeam, as an example of a popular and common backup vendor, while you can’t change or delete immutable data from the GUI, you can do it from the CLI. Let’s assume that an environment is in the lurking phase of an incident before anything visibly exciting happens. The lurkers obtain credentials for the Veeam console. They login and throw scripted commands targeting Veeam immutable backups for deletion and manage to delete at least a subset of the files from those immutable backups. Ouch.

Now, maybe you’ve got backups of your backups on different systems, possibly in different locations. Maybe you’ve followed best practice for a Veeam hardened repository and the console isn’t connected to the LAN except when it’s done deliberately for specific tasks – and then it is immediately disconnected, significantly limiting the surface of attack against it. (That does have some assumptions that do not always play out in real life and some potential vulnerabilities in a typical customer datacenter – however, I’m not going to go down that rabbit hole. Just say no to the rabbit hole!) Recognize that all the items in this paragraph are ADDITIONAL measures that you would need to take to make sure those immutable backups are truly safe. Otherwise, you’re one compromised credential away from potential disaster.

The second concern with immutable backups is that those backups sit on SOMETHING. If those backups are sent to a local repository, that repository sits on hardware. If access to that hardware is compromised, then bad actors have a whole world of additional nasty options: erase storage, format a disk, delete partition tables. Many backup systems are, under the hood, Linux systems with a lot of proprietary software loaded on top. Once someone has access to the underlying system, it doesn’t take a ton of special magic to make a big mess that renders immutable backups into unusable backups.

Do immutable backups have a place? Absolutely, they really do. Are immutable backups the magic special sauce that can help protect you? They just might be. Just remember that you don’t make a meal out of sauce; figure out what the main dish and side dishes are going to be as part of your strategy. Otherwise, you just may end up eating – crow.