top of page

Ransomware Revisited — Response and Recovery

Updated: Apr 18, 2019

In part one of this series, we covered the basics of ransomware including its cyclic nature, recent resurgence, and possible evolution paths. In this post we'll go into more detail on the possible attack responses with consideration of business continuity and disaster recovery (BC/DR).

Once the ransomware attack and associated threats are detected, contained, and neutralized, the transition from cybersecurity response to BC/DR begins. Businesses are frequently caught off guard by the speed of the transitions in these incidents. The attacked systems are taken offline and quarantined while they are evaluated to determine the right recovery path including cleansing or rebuilding. This is effectively the transition to BC/DR where your primary goal is to quickly and safely get the data and capabilities restored for the users. There will be a lot of pressure on multiple fronts to accomplish this goal ASAP. Move too slow, and you risk losing customers, damaging your brand, or violating SLAs and contracts resulting in potential legal actions. [Noting that your legal resources should be involved from the start of any incident.] However, move too fast, and you risk corrupting data, damaging systems, or not fully neutralizing the malware resulting in a replay attack. If you have proven BC/DR procedures and practices in place, you will have fewer difficult, time-sensitive decisions to make and recovery will be much easier and faster.

Here lies the million bitcoin question... Do you pay the ransom? The answer for your situation for each strain of ransomware may be a bit different - there is no "stock" answer. As we said in a previous post, even if you pay the ransom, you still may not get your data back. Also, malware and the ransom path aren't always well designed or "fair". If it was designed to have a different encryption key per target (and a ransom for each), this can make paying and applying the keys prohibitively expensive, complex, and time consuming. Even if you decide to pay, how do you do it? Most businesses don't have cyber-currency readily available nor the processes to approve that transaction. Paying the ransom may put you on an unintended path to disclosure with business, financial, and legal implications. It may also make you a more attractive target for new or replay attacks. The attacker's goal is to profit from the attack, so they will try to make it as easy as possible and price it so that you will pay. They don't want you to have too long to weigh your options, so most ransomware incorporates a count-down clock. It's best to build some urgency and timelines into your BC/DR plan. You may have a favorable situation in terms of the price, payment, and recovery, so paying should be a consideration. Our recommendation is to invest in BC/DR and not pay ransoms, but if you do pay, be very careful and discreet in that process.

The second important question (that we won't answer)... Do you involve law enforcement? We really don't want to flirt with this question outside of a direct engagement, but informing law enforcement may be required for some regulated businesses or public entities. Law enforcement wants to be involved with the goal of collecting data and forensics to help prevent future attacks and prosecute attackers if they are caught. Their goals likely won't align with your goals especially in the short-term. Like paying the ransom, involving law enforcement may put you on an unintended path to disclosure.

The third important questions - final for this post and one we also can't answer... Do you disclose the incident either internally or externally? First and foremost with any cybersecurity incident, we recommend discretion, confidentiality, and containment via compartmentalization or "tenting". This is to protect the business and employees, but also help you in the process to prevent leaking information which could work against your goals or taint forensics. Premature or inadvertent disclosure can force your hand causing investor or client panic, attackers to change the rules or increase the ransom, or the perpetrators to "cover their tracks" (including if there was an insider involved). We recommend that you acknowledge any outages, but only disclose what is required, when/if it is required.

The above difficult questions will come into play throughout your handling of the incident, but the next step after neutralizing the threat is recovery (noting that you can't lose sight of containment and neutralization as you move forward). The safest but most heavy-handed approach is "nuke and pave", then rebuild and restore. You don't have to worry about remnants of the attack or damaging the existing deployments and configurations. However, this is rarely possible in older systems and requires some forethought even in the most advanced architectures and designs. Typically, any recovery process is easier in "cloud" or Software-as-a-Service (SaaS) architectures. Much easier in a public cloud (e.g. Azure or AWS) since these platforms are designed for redundancy and scale with BC/DR components and capabilities "built-in" (e.g. sovereign, but geographically separated back-ups and replication). Regardless of the platforms and implementation, if you have redundancy (master/slave, active/passive, etc.), partitioning of environments, systems, applications, and data, and data/configuration backups (hot/recent or cold/older), your path to recovery will be much shorter. Systems that are designed for low downtime deployments and scaling with some degree of offline capabilities will help reduce the disruption to your business and your users. Merge and sync capabilities which are common in mobile platforms can have high value in any offline scenario.

In the end, a ransomware attack is like any catastrophic failure of infrastructure or networking components whether due to software or hardware failure, natural disaster (fire, flood, earthquake, power outage, etc.), or outright loss or theft. You must be prepared to respond to these events including a fast transition to BC/DR allowing your users to operate in some capacity while you recover and restore your full capabilities.

65 views0 comments

Recent Posts

See All


bottom of page