Why offsite backups are no longer enough - The Code Spaces case

Yesterday, various news sites covered the case of hosting service Code Spaces, which is shutting down because of a ransom attack. Perhaps this is the time to rethink your backup strategy.

Offsite backup

The Code Spaces case ^

Even though the hack was accompanied by a DDoS attack, I think we should call this a “ransom attack.” Attacks with ransomware such as CryptoLocker are popular, not only on Windows but also on Android and Apple products. For hackers, this has become a nice way to convert their skills into cash.

I think the Code Spaces case demonstrates nicely that offsite backups are no longer enough. The code hosting and software collaboration platform was running in Amazon’s cloud AWS. The attacker somehow gained access to their Amazon account and then extorted a large ransom from the company. When the admins tried to change the passwords, the attacker used backup logins to destroy most of the Code Spaces data. The end result of this ransom attack is that Code Spaces has to shut down. I found this sentence on the Code Spaces site most interesting:

In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted.

I conclude that Code Spaces only had backups in Amazon’s cloud, which I find remarkably careless for a tech company.

Offsite backups in the cloud ^

Formerly, the main purpose of offsite backups was to allow recovery after a physical disaster such as water or fire damage. The idea was to physically separate the backups from the datacenter to protect them from physical disasters. One argument of cloud providers is that offsite backups are now much easier to manage because they offer a complete infrastructure to store your data offsite—that is, in another datacenter of the same provider. I think the argument is valid for risks involving physical dangers.

However, as this case demonstrates, the cloud creates new risks. I guess the Code Spaces admins considered backups that were stored in another AWS availability zone as offsite backups. What they didn't consider is that one of the main characteristics of the cloud is that the location of the data no longer matters. The advantage is that everything can be managed from one central point, and this means that it can also be easily destroyed from a central point.

Thus, in my view, Code Spaces didn’t have any offsite backups, which is the reason their business is now destroyed. The cloud requires to redefine offsite backups. “Offsite” doesn’t just mean “at another physical site” but “at another logical site.” One option for Code Spaces would have been to store their backups at another cloud provider or at least use a second, independent AWS account for the backup storage. Of course, different passwords for the second site are then necessary. You also have to ensure that the backup site only has read access to the source. Otherwise, you run the risk of an attacker gaining access to your backup site and destroying all your data.

Offsite vs. offline backups ^

However, in my view, this configuration is still not enough to secure the vital data of your company. If an attacker is smart enough to gain access to one of your cloud accounts, he might also be able to hack the second account. Thus, offsite backups are no longer good enough. What you need are offline backups.

Of course, offline backups are nothing new. Previously, responsible admins always ensured that the most vital company data is stored in a secure, fireproof safe. The problem is, of course, that today’s data is changing too fast, and the amount of data is too big to be stored in safes. So what can you do?

One solution is to store offsite backups not in the cloud but in an on-premises site that is protected by a firewall that only allows outbound traffic. Thus, in case of disaster recovery, an admin has to physically go to the site to start the recovery process. This is still not 100% secure because an attacker might hack your firewall, but it reduces your attack surface significantly. If your company can afford it, you can work with a dedicated connection to your backup site that is not part of the Internet. In addition, you can store backups on tapes and remove them physically from the tape library after the backup completes.

Ransom attacks ^

Just in case you think you are safe because you don’t store vital data in the public cloud, think again. If your on-premises site is connected to the Internet, all your data is as vulnerable as it is in AWS or Azure. Ransom attacks work for public and private clouds in just the same way. Thus, the new risk doesn’t come from the cloud but from the fact that ransom attacks are becoming more popular. The most common excuse for lax security—“the servers of my company are not interesting enough for hackers and crackers”—is no longer valid. Even individuals are interesting targets for ransom hackers.

What is your backup strategy? Do you work with offsite backups?

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads and for free by becoming a member!


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account