Ransomware, like most other technologies, continues to evolve and become more effective for its nefarious purveyors. At its advent, ransomware merely encrypted your data and charged a ransom to un-encrypt it. Ransomware has now progressed to the point where the bad guys not only encrypt your data, but also render parts or all of your systems inoperable. What can one do to protect against such transgressions?
The answer is to treat a ransomware attack like a natural disaster. In fact, there is not much different from a hurricane versus a ransomware attack if your system goes down. You need a disaster recovery plan.
While the types of disasters may have changed, the process by which a disaster recovery plan is devised has no changed. A good disaster recovery plan takes into account the business needs of the organization first. Toward that end, all of the critical and important systems of the organization need to be defined. This must include representatives of business units; it cannot be a task done by IT folks alone.
Then for each system, two factors need to be defined. The first is the amount of time the organization can tolerate before the system needs to be up and running. The fancy name for this is the recovery time objective (abbreviated as RTO since we love our acronyms). For example, how long can our accounting system be down? How long can we go without access to email?
The second factor is called recovery point objective (RPO). In plain English, RPO is that point in time to which you can effectively restore your system. Typically, this will be the date and time of your last good backup.
One can see how these two factors go together. Just as an example, if our RTO is four hours and our RPO is 24 hours, that means that we’ll be OK if the system comes up in four hours, with data that is a day old.
In this scenario, maintaining a backup system at a different location from the main system is required. The backup system could be in the cloud or at a separate physical location from the primary system. In a reverse twist from just a few years ago, systems with primary locations in the cloud often have their backup system in your office.
What if you need something better than that? After all, with folks working from home, and systems potentially being accessed by customers 24/7, being down for a few hours could be costly.
Enter high availability. HA basically involves redundancy of system hardware, software and data. Generally speaking, your data is continuously copied over to the HA site, which, like disaster recovery, is in a separate location.
HA is a proactive approach, focused on preventing issues before they lead to actual downtime. Disaster recovery is more reactive, and kicks in after an outage. Even with HA a disaster recovery plan must be in place.
Neither HA nor disaster recovery is a “set it and forget it” solution. Both require regular testing to ensure that they will be effective in case of a system outage. HA in particular typically requires regular “care and feeding” to ensure an effective solution. Be sure that you can commit the resources needed to maintain an HA solution before going down that road.
———
John Agsalud is an IT expert with more than 25 years of information technology experience in Hawaii and around the world. He can be reached at jagsalud@live.com.
