Ransomware readiness 3 of 3: Recovery

How to deal with a ransomware attack is currently a matter of some debate.

There is a school of thought that paying the ransom is a bad idea because it rewards the criminal and can be used to fund further attacks, possibly even on the same organisation.  Many organisations run a counter argument which suggests that to get systems and data back up quickly and resume services, paying the ransom is the cheapest way out of a bad situation.

There is an increasing number of stakeholders in this decision which complicates the matter enormously.

Firstly, there are increasing moves by government and regulators to report ransom payments or even make them illegal altogether.  This fits well with an international desire to stamp out this type of transnational crime. It may, however, create existential considerations for some seriously affected organisations. Some insurers, like AXA SA, are now refusing to write policies that reimburse ransoms paid by their customers in France, so, in the absence of de-encryption keys, re-instatement efforts and the likelihood of a return to BAU look unlikely for many victims.

Secondly, there is the assumption that the decryption key or system the ransom pays for will, in fact, work.  It probably will (although not always) however in the case of Colonial Pipeline Co, the decryption process was so slow that they had to switch to backups anyway.

Thirdly, and briefly returning to insurers’ roles in supporting commercial cyber risk management efforts, the increasing prevalence of ransomware is resulting in underwriters seeking more and more evidence of the use of security controls in the organisations they insure. It is of concern that in the absence of such controls, and in the event of a ransomware attack, insurers may refuse to pay either the claim or the ransom money.

The “best two” ‘til last

The measure of success of any recovery from a ransomware attack is your ability to resume BAU as quickly and painlessly as possible. Again, there is no silver bullet but the successful management of these “best two” controls will significantly increase your likelihood of successfully reinstating your business and data systems. As a result, these controls will limit disruption and your potential losses as well as, hopefully, the need to pay a ransom.

1)      Backups, please have backups

With ransomware being the topic of international summits, the insurance industry in such flux and future regulatory challenges to be resolved it would seem smart to have a backup plan – how your business could survive in the event of the worst possible set of circumstances.

Regular, comprehensive, tested and accessible backups that can form the basis of the reinstatement of your business.  Obviously they need to be secured and safely isolated from the rest of the networks and systems, but also they need to be sufficiently accessible to enable the restoration of the business systems and data to ensure a timely return to BAU.

This includes backups of servers, file stores, workstations and in particular, systems where the integrity of the platform itself is vital – like domain controllers.  Losing one of those can result in a massive amount of re-work.  Don’t assume, for example, that because systems are resilient or mirrored that you will be OK.  The ransomware might spread to all nodes in a cluster, or encrypted data could be replicated across all the same technologies you believed would save you.

Regular and comprehensive, reliable backups of every data store and enterprise system is still the best remedy for large-scale data loss or corruption. Having a secure and tested set of business systems and data back-ups is the best form of insurance you can have.

2)      Incident response plan, please have an incident response plan

Assume that you have the ransom money (and are allowed to pay it) OR a good set of backups.  Is that all you need?

In short, no.

A ransomware outbreak requires solid management just like any other cyber security incident.  Reinstating your business systems and data to support BAU without impacting your business operations and stakeholders is not easy.

There will be the effects of disruption to manage, systems affected by the malware itself and those which have been disconnected to protect them.  There will be communications to customers, stakeholders, regulators, law enforcement, insurers and governments to manage.  If paying a ransom, who will negotiate with the attacker, and who has the sign off for a multi-million-dollar payment? These are not routine activities.

The vulnerability or security weakness that was exploited will require investigation so it can be fixed, patched or corrected to avoid further infections.  Infected systems must be isolated from the network so they don’t infect systems that have not yet been affected, or re-infect the ones you are gradually restoring and bringing back on line.

Planning for how the incident will be managed is essential, and as with any other plan, identify who’s in charge, practice it, establish the pre-requisites and dependencies.  Test it again. It all takes time, but if the plan works it sets the platform for a successful re-instatement of BAU whether you pay the ransom or not.

Summary

The recovery from a ransomware attack has a number of moving parts.  But you will need backups.  They might save you; they might be the only thing that does.  Especially, if you can’t pay the ransom, or the decryption solution isn’t workable.

The wider implications of a malware-infested environment, of disruption and losses of service, of needing to communicate and to arrange rapid access to funds, forensic teams or consultants all mean having a sound, and tested, incident management plan.

As we said in the first two blogs in this series (see here and here) – having controls and safeguards is important; making sure they all work effectively is equally vital.  It’s too late to test your incident management plan and system and data backups after the fact.

Download the Top 10 Ransomware Questions for Executives & Directors

Leave a Comment:

All fields with “*” are required

Leave a Comment:

All fields with “*” are required