Backup – Your Last Line of Defense

Unfortunately, this is not an uncommon scenario for small to mid-sized companies. In such situations, one of the most important questions is: Did the backup survive? And equally important: Was everything critical actually backed up?

While there is a lot you can do to secure your systems, most measures only reduce the risk of being hit by a cyberattack. If you operate in a modern, connected environment, you cannot reach a state of zero risk. In the event of a full encryption ransomware attack, your backup is the last resource you have to get back to business.

The 3-2-1-1-(0) Rule

For some time, the 3-2-1-1 “rule” for backups has been a good starting point:

3: Three copies of your data
This includes your original production copy and two backup copies.

2: Two different media types
The data should be stored on two different types of media (e.g., disk, tape, cloud storage).

1: One copy off-site
One backup copy should be stored at a different physical location than the others.

1: One offline or immutable copy
One backup must be offline or immutable, so a digital attack cannot wipe it. Even administrators must not be able to delete this copy, ensuring that if an attacker gains their credentials, they cannot do so either.

There’s one last part that needs to be added:

0: Zero errors on verification
You need to test your backups to ensure the restore is usable.

The key elements in a ransomware attack are the last two points. Attackers will almost always try to wipe backups before encrypting systems, knowing you’re more likely to pay if all your data is gone. Having an immutable backup is critical when all your systems have been compromised.

An important corollary: How long will it take you to get back to business? How much data needs to be restored for your company to function again? How fast can you restore from your backup?

This is especially relevant when restoring a 15TB file server from a tape library and your backup solution only allows one restore stream. Or when you try to download that amount from a cloud backup.

You must also consider whether your backups work and cover all business-critical systems. (Don’t forget the new ERP system you migrated to three months ago but haven’t had time to check the backups for!) Again and again, we encounter customers during incidents who discover that a new system wasn’t added to the backup, or the backup wasn’t verified and a crucial data drive is missing.

Before putting any system into production, ensure there is a clear decision for ‘rebuild’ or ‘restore.’ If it’s ‘restore,’ make sure the system is fully backed up and the restore test is successful. ‘Rebuild’ is only an option if the system itself does not store state information. And during a crisis, like a ransomware incident, you don’t want to also have to rebuild servers that are complicated to setup.

Another crucial aspect: Can you recover the backup server itself? Do you have the encryption keys for your backups?

Nothing is more harrowing than having backups but realizing you don’t know the encryption password. Make sure this information is stored securely (with your other break-glass accounts for cloud services, etc.), and regularly verify that the password hasn’t changed (mount a backup on a backup server that isn’t your primary one to test a restore).

Keeping Your Backup Secure

Having an immutable copy, tape backup, or off-site/cloud WORM backup is important, but your recovery will be even smoother if the attacker never gained access to your backups in the first place.

To achieve this, it’s crucial to treat your backup environment as a highest-security tier and segregate them within your infrastructure. Anyone with access to your backups has access to all your data. Backup systems should not be reachable from regular servers, definitely not from general office PCs or from the internet.

Authentication to these systems should always have a distinct personal account, that is not used anywhere else in the environment. It should not be the administrator’s normal user account (or even their admin account), and they should never be integrated into your office Active Directory. Making it harder for attackers to access your backups will increase the likelihood they give up before compromising them.

• Separate your backup servers on a network segment where they can reach all systems they need to back up, but no system can reach them.
• Use servers that are not integrated with central authentication systems (e.g., Active Directory).
• Use an endpoint monitoring solution to detect unusual behavior on these servers.
• Ensure administrators with access to these systems use unique passwords for this environment.

Many backup systems recommend using a shared Active Directory account with admin rights on all servers (Domain Admin). Under no circumstances should you do this. These accounts are highly valued by attackers, as they allow unrestricted movement through your environment. Instead use local agents with secure connections back to the backup server (or backup proxy). For Active Directory, use the built-in backup for a system state backup, then use your backup tool to protect these files.

For virtual environments, back up from the hypervisor side so you don’t need agents on every system. (Your hypervisor management interfaces should be network segmented and not connected to AD, in the same manner as the backup servers!) If you need an agent for backup consistency (like for SQL servers), use a local account for the agent service with only the required access rights, if possible. Take a look at your backup vendors documentation, how to set up the account using the least amount of privileges.

Conclusion

It is extremely important to have a good and functional backup that you don’t lose when you’re attacked. It will be your last line of defense and a major factor in how quickly you can return to operations.

If you get hit by ransomware and have a backup, read this article to know why you shouldn’t just restore everything and move on: Restore Alone Is Never Enough – Avoid Common Pitfalls During Recovery