Skip to main content

This is part three of three addressing general topics of environmental architecture for backup systems.

In part XVI, we examined considerations for the placement of individual backup components, hardware configuration, and fault tolerance (Point 1 and 2 of the following list of major threats).
In part XVII, we examined considerations for locations and site redundancy (Point 3 to 5 of the list of major threats).

In this part, we address the aspects of ransomware, malware, theft and threats by insiders. These are points 6 to 8 on the list of major threats to backup environments that we identified in the last part.

 

What are the main threats to backup data?

  • Wrong placement of backup environment components
  • Hardware damage to backup systems
  • Power outages or disasters at one location
  • Power outages or disasters at multiple locations
  • External locations for backup data
  • Ransomware attacks
  • Theft of access data and unauthorized access
  • Intentional or unintentional damage by insiders

As with the topics in the last parts, these topics do not apply only to the backup environment. Everything interacts and influences each other. There are specific requirements for backup, but most of the considerations in this text also apply to the production environment. However, I will still refer to the backup environment in this text.

 

 

I will summarize the three topics of this article in one text because they are closely related.

• Ransomware attacks

• Credential theft and unauthorized access

• Intentional or unintentional damage by insiders

 

Ransomware attacks are becoming more frequent every month and affecting more and more companies and organizations. Attack vectors are becoming increasingly sophisticated, and defense against them is becoming increasingly challenging.

 

It is therefore essential that the backup environment keeps pace with the growing threat. Most attackers today look at backups as one of their first steps and attempt to destroy them. This deprives the victim of the opportunity to restore their encrypted production data.

 

For this reason, backup data should be stored on immutable storage, which makes it impossible to delete the data for a defined period of time. Otherwise, your data will simply be deleted or encrypted by the attacker – regardless of whether the storage is on-premises or in the cloud – as schematically illustrated in the following image.

 

 

But even with storage immutability, the data isn't secure.

If access to the administration interfaces of servers, storage systems, or cloud storage accounts isn't secure and an attacker gains access to them, they can simply delete the volumes or buckets from the outside, along with the data they contain, thereby invalidating the immutability.

 

Always use secure passwords for accounts and use different passwords for each account.

Set up MFA for all accounts to make it as difficult as possible for attackers to access the administration interfaces.

 

Place the administration interfaces in a locked-down network to which only authorized people have access, thus preventing easy access. To further complicate access, you can, for example, disable the corresponding ports on the switches. Or unplug the cables if you have someone on-site who can do this and reconnect them if necessary.

 

 

But what if you've taken all the security precautions mentioned above, and the attacker isn't coming from outside, but is based within your company? Perhaps they already have administrative access to the systems and data?

 

In that case, defending against it alone becomes very difficult...

 

One option is to engage a service provider who stores a copy of the data. This is where so-called insider protection can be used. In this case, the data isn't deleted immediately at the service provider's site, but is retained for a defined period of time in a special area to which the customer has no access. If an attack is detected, the service provider can stop the deletion of the data after notification from the customer, and the data remains available for recovery.

 

 

Conclusion

We've seen that defending backup data against internal and external attackers is a difficult undertaking. It's probably impossible to eliminate all threats alone. Working with a service provider significantly increases the likelihood of recovering a copy of the data.

Never feel too secure. Check all settings regularly and train your employees. Implement a detailed monitoring and alerting system to promptly detect any unusual activity.

Great insights, and thank you for sharing ​@JMeixner.  Your blog post is a great reminder that proactive defense and strong partnerships are essential for protecting backups. If you would like to avoid higher cost, one additional way to reduce the risk of insider threats is by using Veeam’s Four Eyes Authorization. This will ensure that critical actions as described below require approval from a second backup administrator, adding an extra layer of security: Four-Eyes Authorization - User Guide for VMware vSphere


Great addition, Christian 😃

This is indeed a good mechanism to protect your environment from malicious administrative actions - at least in the case when an admin has no access to another account...


Great addition, Christian 😃

This is indeed a good mechanism to protect your environment from malicious administrative actions - at least in the case when an admin has no access to another account...

Exactly 😂


Another great article Joe in your series.  Security should always be top of mind.


Great info ​@JMeixner!

Another option to avoid attacks on the storage layer is to use Veeam Data Cloud Vault. Vault is logically-air gapped from the end-user infrastructure since it resides fully within Veeam’s Azure infrastructure. No lateral movement or privilege escalation can occur for an attacker to gain access to the underlying systems for the storage, even if the environment is completely compromised. 


Hello ​@tfewins,

yes, nice addition, that's right. I would take this under usage of a service provider. 😉

And you have to keep your credentials save and secure for this, too.


Great post.

Following 321 rule and having one copy offsite is very important, and nothing can beat an immutable cloud offering here. And according to Zero Trust Data Resilience all copies need to be immutable, unless stated otherwise.

For on-premises environment we still need to try to using the most secure option available, something that will follow Veeam’s ZDTR, without root access, dedicated for backups and with a hardened underlying system, without a possibility of erasing disks, for example. 

Because restore from an immutable cloud offering will work, but how long will it take to restore the entire production back to on-premises?...


As a service provider offering cloud connect, I’ve seen Insider-Protection save customers from ransomware activity multiple times. It’s definitely a very important feature.


Great post.

Following 321 rule and having one copy offsite is very important, and nothing can beat an immutable cloud offering here. And according to Zero Trust Data Resilience all copies need to be immutable, unless stated otherwise.

For on-premises environment we still need to try to using the most secure option available, something that will follow Veeam’s ZDTR, without root access, dedicated for backups and with a hardened underlying system, without a possibility of erasing disks, for example. 

Because restore from an immutable cloud offering will work, but how long will it take to restore the entire production back to on-premises?...

Yes, I am using a mixed approach most of the times. At least one copy on-premises for fast restores and a additional copy in the cloud for security. Both copies imumutable and hardened.


As a service provider offering cloud connect, I’ve seen Insider-Protection save customers from ransomware activity multiple times. It’s definitely a very important feature.

It#s a great tool. It saves cutomer data when everything else has fallen.


Comment