Select Page

If your ransomware prevention plan relies only on perimeter security, you may be in for a nasty surprise.

Legacy approaches to system protection are modeled on the outdated concept of perimeter security that is not only inadequate but also provides no resolution in the case of a ransomware attack.

The CIO has the responsibility to ensure business processes are operational even in contingencies where bad actors have managed to breach the perimeter and executed a ransomware attack.

Ransomware is one of the most crippling kinds of IT breaches because it can quickly affect not just a single endpoint but an entire network. With data volume predicted to increase over tenfold over the next five years (Source: IDC), devastating ransomware attacks run the specter of locking the target business out of its most vital resource – the system itself. To further complicate the scenario, there has been an 8X increase in ransomware attacks since 2011.

CIOs need to consider a holistic approach for system protection that factors in scenarios arising out of ransomware attacks both in terms of perimeter security and a recovery plan. In the case of ransomware-triggered system lockout, the challenge is to ensure business processes continue unaffected. Fortunately, businesses can leverage Disaster Recovery solutions for this.

Using Disaster Protection for recovery:

In a typical ransomware or malware attack, users lose the ability to either use the application or the system itself. Now to recover from this scenario, a Disaster Recovery solution can be used. One option is to roll back the state of the application or the system itself in time to a point when the state of the system was clean, allowing the applications to become operational. The second option is to failover to the secondary site (assuming the primary site is unavailable, like in a disaster situation), so your business continues as you work to clean the primary site. Disaster Protection and a good business continuity solution are more challenging on cloud-native platforms as data and applications are dynamic and need to be protected together to recover successfully. Fortunately, there is now a way to accomplish this reliably using Kubesafe.

Steps for building a DR plan for ransomware

A disaster recovery plan should evolve as your business does. Ransomware is a significant threat today, but what threats will tomorrow bring? A disaster recovery plan needs to consider how far the organization is willing to go back in time to recover and how long it will take them to recover, considering the impact of system state loss and business downtime. The following steps are a part of a planning cycle that will help protect your business from whatever threats appear down the road.

DR plan starts with a set of recovery goals and objectives in the following two areas:

Recovery point objectives: How much data and state loss business can tolerate. Every business would like to have zero data loss, but a tradeoff has to be made as a smaller RPO requires a higher cost of implementation and infrastructure. Enterprises typically have an RPO from few minutes to a day.
Recovery time objectives: How quickly the business would like to get back to a functioning state. A zero RTO requires a higher cost on infrastructure. Enterprises typically have an RTO from zero to a few hours, depending on applications’ business-critical nature.
Above two will decide how to go about implementing such a strategy. Further, on a cloud-native platform, it is critical to think beyond data; disaster recovery needs to include applications and their state to ensure recovery. Kubesafe, a data protection software for the Kubernetes platform, allows users to define these SLAs. Kubesafe captures the state end to end to ensure recovery can be done both locally or remotely.

Frequently Test, Evaluate, and Review

Test your plan so you’re not caught off guard when ransomware comes swinging by simulating such stacks and ensuring your strategy is robust and backups are good. We suggest the following

  • Create a schedule for application restore or failover testing
  • Monitor backups to ensure that they’re taken successfully
  • Validate the recovery points by using them for test recoveries

Further, these SLA’s should be reviewed and evaluated regularly against the business criticality of the application, the data, and the new threats. This can mean reviewing the following regularly-

  • Applications that have a large RPO or not protected at all
  • New Applications that may have been added and may require additional protection.
  • Any errors in infrastructure that can prevent proper recovery