ARN

Ransomware: How to ensure back-ups are ready for a real attack

Avoid paying off ransomware attackers by following these steps to ensure back-ups can restore infected systems

The best way to avoid paying ransom to attackers who have infected business systems with ransomware is to have those systems adequately backed up so users can wipe them and restore them from safe back-ups. Here are several options for making sure those back-ups are up to the task.

In this article, back-up refers to any system that users are going to use to respond to a ransomware attack, including old-school back-up systems, replication systems, and modern hybrid systems that support back-up and disaster recover. For simplicity’s sake, they’ll all be referred to as back-up here.

Back-up everything using the 3-2-1 rule

Before anything else, one idea is paramount: Back up all the things. Investigate a back-up system's ability to automatically include all new systems, filesystems, and databases. This is easiest in the virtualisation world where you can configure your back-up system to automatically back-up all VMs on a host whenever they show up.

This can also be done with tag-based inclusion, where VMs of different types get automatically included based on their “included” tags. This is one of the best uses of automation in a back-up system--automatic inclusion of all the things.

Also make sure to follow the 3-2-1 rule in your back-up system, no matter who tries to tell you it’s old-fashioned. The rule says make at least three copies or versions of data stored on two different media, one of which is off-site.

The big parts here are the two and the one--store back-ups on a different system and in a different location. Don't store your back-ups in the same place as your primary system. Even better, store them on a different operating system and a different physical location, but in the real world that’s not always possible.

There should be some type of automatic reporting by your back-up system so you can be sure the back-ups you think are happening actually are. This should include both success reporting and failure reporting.

A third-party monitoring system is probably best so it can continually look at everything and point out when things are a little off. A reporting system with machine learning would be ideal it can it can notice patterns that indicate problems. This is easier than having to read dozens or hundreds of emails from your back-up system every day just to make sure things are working.

DR security should top the list

Your back-up and DR system should be one of the most secure systems in your computing environment. It should be hard to get to and hard to log into. It should be really hard to login as Administrator or root.

Hopefully, your back-up system supports role-based administration so you can login as yourself and run back-ups as you. You should not have to run your back-ups as root or Administrator. Logging in as those accounts is incredibly dangerous and should be restricted whenever possible.

Your back-up and DR system should also be the most up-to-date system you have. Security patches should be installed there first not last because your back-up and DR system is your last line of defence. Make sure it’s not subject to a security hole that should have been patched weeks ago.

All claims of data integrity and immutability go out the window if you have physical access to a server, so the back-up server should also be very hard to get to physically. Perhaps it's in a different room that requires different physical access, or inside a computer rack that not everybody has the key to. Another great way to do this is to get the back-up system out of your data centre altogether. Put it in the cloud.

Encrypt everything

All back-up communications should be encrypted, so make sure your back-up provider is encrypting traffic between systems. That means if you do get an advanced persistent threat, and it is sniffing the network, it’s not going to identify the back-up servers or what they're up to. This can prevent your back-up systems from being attacked by ransomware.

In addition to encrypting back-up traffic in flight, you should also encrypt all back-up traffic at rest, especially if the data is stored anywhere outside your physical control. This includes tapes that you're going to hand over at any time to anyone, including your own employees.

This also includes data that you’re storing in cloud-provider networks, because even though they are very secure, nothing is perfect. Make sure that your back-up data cannot be used as a way to further investigate your network and attack it.

Build DR based on business needs

A well-tested DR system is the best defence against a ransomware attack. A poorly designed system is the best way to guarantee that you end up paying a ransom.

This should be the case in every area of IT, but the DR system should be built on requirements that come from the business. There should be many meetings where requirements like recovery time objective (RTO) and recovery point objective (RPO) are discussed and agreed to long before you decide how you're going to actually meet those requirements. Once you agree to an RTO and RPO, design a back-up and DR system that satisfies those requirements.

Test like your life depends on it

A recent news article said that the reason Austin, TX, lost its drinking water for so long during a statewide power failure was that no one at the water-treatment plant knew how to turn on the back-up generator. Don't be that company.

Don't be the company that has a perfectly fine back-up and DR system and doesn't know how to use it. There are too many risks to your data today for you to not follow this crucial piece of advice: Frequently test your DR system.

The good news is that most modern back-up and DR systems support frequent testing of the whole system. You can bring up your entire data centre in a sandbox as often as you need to so you can see how it actually works. Do it at least quarterly. It should only take a few hours, and it should be boring because it’s proving that it works. If it's boring when you test it every quarter, it will be easy when you need to actually use it to recover from ransomware.

Each time you run the test, rotate the personnel who run it. They should not be the people who designed the system nor the people that use the system every day. They should have good technical know-how and be provided with good documentation to follow. That is the best way to confirm that both your system and your documentation work.

A ransomware-ready DR system that can bring your entire data centre back online after a ransomware attack is the only way you can avoid paying ransom. Please look into doing this now before your company becomes another statistic.