Skip to main content

Today I want to talk about backups, and the importance of encrypting them, everywhere. When people think of encrypted backups, the usual first thoughts are around portable backups such as tape and USB or backups outside of your trust domain such as cloud storage.

This is a great starting point, and if you’re not currently encrypting these I urge you to do so as these are normally your highest risk backups. But here’s a an emerging scenario to consider.

Security is a constant battle of escalations, attempting to out-do the efforts of each other. Whilst we’re seeing an industry reacting to ransomware threats with immutability, these malicious actors have also moved on from just encrypting your data. Now these bad actors are attempting to steal your data and extort a ransom to prevent leaking the data.

Scary stuff right? It’s for this reason and more that backups are being targeted for data exfiltration. Consider the positives a good backup meets.

 

Storage and Bandwidth Efficiency

 

Now malicious actors are after copies of our data, wouldn’t it make their life so much easier if a copy of all the victim’s data was compressed and deduplicated to ensure they could retrieve the data as fast as possible… oh wait, that’s our backups!

To ensure we can retain more data, we actively attempt to make it consume the minimal required space, but this makes our backup data a better target for malicious actors as they are able to:

  • Send the backup over a lower throughput connection faster
  • More easily ingest a copy of the victim’s data
  • Have a higher chance of avoiding triggering any monitoring alerts

Application Aware Processing

 

Sometimes the victim’s data isn’t structured as traditional files on a share but stored within databases. If ransomware encrypted the production database and logs, can we be sure they’ll actually recover? If the criminals were competent in your database technology they could trigger a manual backup but that’s more likely to draw attention.

A properly configured backup job will have already interacted with the necessary applications to ensure the data is recoverable, bypassing all of the complications above. This means a backed up database with application aware processing enabled is more likely to give a good set of data to share during extortion, allowing the bad actors to interrogate the database and find sensitive information.

 

Server Configurations

 

Important during a reconnaissance phase of an attack is gaining as much information as possible about the environment. If a backup has been extracted and egressed to a remote location, it would be possible to run an isolated copy of every workload protected by the backup. This enables the exploration of attack vectors without triggering any security systems of the victim and potentially even allowing for partial or full automation of a cyber attack in the production environment, hitting all security weak points in rapid succession or in parallel to cripple the victim completely.

 

What if I use data encryption at rest on my backup repository?

 

Encrypting the data at rest in this manner will protect against the physical theft of the storage or if someone managed to compromise a system’s remote management platform such as iDRAC or iLO and booted a different platform via an ISO, as they wouldn’t necessarily have the key to read the data (though such a foothold would make this be easier to circumvent).

However whilst your repository is online during a “business as usual” scenario, the data needs to be readable by Veeam, which therefore means anyone else with the appropriate security permissions to access the repository can also by extension, access the data, without needing the decryption keys for the any data encrypted at rest.

 

Before you enable Backup Encryption on all of your backup jobs, read this.

 

If you’ve already got backup jobs configured without encryption enabled, you should know that by enabling encryption, your next backup will be a full backup and this could increase your storage requirements considerably, especially if you rely on reverse incremental to avoid storing multiple backup chains.

If you rely on ReFS/XFS based fast clone this still applies, as the blocks can’t be shared due to them not being identical anymore, due to one version of the block being encrypted and one version unencrypted. After your first encrypted backup you’ll be able to leverage this technology for subsequent backups however.

Lastly should you leverage data duplication storage repositories from Veeam’s partners or even Microsoft’s built in Data Duplication service within Windows Server, Veeam will encrypt the data before it is made visible to the storage appliance during the write operation, this will negatively impact deduplication. You can find an example of Veeam explicitly stating this here under the encryption subheading.

Instead encryption can still be achieved to protect against physical storage theft by enabling native encryption at rest on supported devices directly. Extra care should then be given to minimize allowed connectivity to these devices to prevent data theft due to the previously highlighted concerns around relying solely on encryption at rest.

Different vendors will have varying feature support within their deduplicating storage devices so be sure to validate that data encryption is a supported scenario for your device first.

Nice article @MicoolPaul , thank you.

We are encrypting all of our backups - except some test backups … It did take some time, because we didn’t encrypt in the first time, so, we had to switch on encryption on one job after another.

But in the meantime all jobs use encryption and all is working fine - including ReFS Block cloning, deduplication, etc.


Great article as encryption is important in helping add that extra layer of protection.


Great guide @MicoolPaul, data encryption is one of the 2021 Cyber Security Threat. Unfortunately, some businesses still do not encrypt their backup.  


Thanks @Chris.Childerhose @chris_eromosele & @JMeixner for the positive feedback :grinning:

 

I think @JMeixner has described the symptom perfectly here, encryption not being enabled when the backup job was first created, about 90% of my health checks/remedial reports I carry out I find a lack of encryption on some jobs, probably just under half of them don’t have any encryption on any jobs.


We normally encrypt all backups which leave the backup server, like backup copy or tape jobs, but we don’t regularly encrypt the backups on the backup server itself. You do have some good and valid points, thanks for bringing this to me/our attention :blush:


Comment