Credit: Dreamstime
According to a ransomware survey report released in June by Keeper Security, 49 per cent of companies hit by ransomware paid the ransom -- and another 22 per cent declined to say whether they paid or not. Part of the reason is the lack of back-ups -- specifically, the lack of usable back-ups.
Back-ups must be safe from malware, quick and easy to recover, and include not just important files and databases but also key applications, configurations, and all the technology needed to support an entire business process. Most importantly, back-ups should be well-tested.
Here are eight steps to ensure a successful recovery from back-up after a ransomware attack.
1. Keep the back-ups isolated
According to a survey by Veritas released last fall, only 36 per cent of companies have three or more copies of their data, including at least one off-site. Keeping an "air gap" between the back-ups and the production environment is critical to keep it safe from ransomware -- and other disasters.
"We do see some of our clients that have on-premises back-ups that they run themselves, as well as cloud-based ones," says Jeff Palatt, vice president for technical advisory services at MoxFive, a technical advisory services company. "But ideally, if someone has both, they don't cascade. If the encrypted files get written to the local back-up solution and then get replicated to the cloud, that doesn't do you any good."
Some cloud-based platforms include versioning as part of the product for no additional cost. For example, Office 365, Google Docs, and online back-up systems like iDrive keep all previous versions of files without overwriting them. Even if ransomware strikes, and the encrypted files are backed up, the back-up process just adds a new, corrupted version of the file -- it doesn't overwrite the older back-ups that are already there.
Technology that saves continuous incremental back-ups of files also means that there's no loss of data when ransomware hits. You just go back to the last good version of the file before the attack.
2. Use write-once storage techniques
Another way to protect back-ups is to use storage that can't be written over. Use either physical write-once-read-many (WORM) technology or virtual equivalents that allow data to be written but not changed.
This does increase the cost of back-ups since it requires substantially more storage. Some back-up technologies only save changed and updated files or use other deduplication technology to keep from having multiple copies of the same thing in the archive.
3. Keep multiple types of back-ups
"In many cases, enterprises don't have the storage space or capabilities to keep back-ups for a lengthy period of time," says Palatt. "In one case, our client had three days of back-ups. Two were overwritten, but the third day was still viable." If the ransomware had hit over, say, a long holiday weekend, then all three days of back-ups could have been destroyed. "All of a sudden you come in and all your iterations have been overwritten because we only have three, or four, or five days."
Palatt suggests that companies keep different types of back-ups, such as full back-ups on one schedule combined with incremental back-ups on a more frequent schedule.
4. Protect the back-up catalog
In addition to keeping the back-up files themselves safe from attackers, companies should also ensure that their data catalogs are safe. "Most of the sophisticated ransomware attacks target the back-up catalog and not the actual back-up media, the back-up tapes or disks, as most people think," says Amr Ahmed, EY America's infrastructure and service resiliency leader.
This catalog contains all the metadata for the back-ups, the index, the bar codes of the tapes, the full paths to data content on disks, and so on. "Your back-up media will be unusable without the catalog," Ahmed says. Restoring without one would be extremely hard or impractical. Enterprises need to ensure that they have in place a back-up solution that includes protections for the back-up catalog, such as an air gap.
5. Back up everything that needs to be backed up
When Alaska's Kodiak Island Borough was hit by ransomware in 2016, the municipality had about three dozen servers and 45 employee PCs. All were backed up, says IT supervisor Paul VanDyke, who ran the recovery effort. All servers were backed up, that is, except one. "I missed one server that had assessed property values," he says.
The ransom demand was small by today's standards, just half a Bitcoin, which was then worth US$259. He paid the ransom, but only used the decryption key on that one server, since he didn't trust the integrity of the systems restored with the attackers' help. "I assumed everything was dirty," he says. Today, everything is covered by back-up technology.
Larger organisations also have a problem ensuring that everything that needs to be backed up is actually backed up. According to the Veritas survey, IT professionals estimate that, on average, they wouldn't be able to recover 20 per cent of their data in the event of a complete data loss. It doesn't help that many companies, if not all companies, have a problem with shadow IT.
"People are trying to do their jobs in the most convenient and efficient way possible," says Randy Watkins, CTO at Critical Start. "Oftentimes, that means running under the radar and doing things yourself."
There's only so much companies can do to prevent loss when critical data is sitting on a server in a back closet somewhere, especially if the data is used for internal processes. "When it comes to production, it usually hits the company's radar somewhere," says Watkins. "There's a new application or a new revenue-generating service."
Not all systems can be easily found by IT so that they can be backed up. Ransomware hits, and then suddenly things are no longer working. Watkins recommends that companies do a thorough survey of all their systems and assets. This will usually involve leaders from every function, so that they can ask their people for lists of all critical systems and data that needs to be protected.
Read more on the next page...
