We all know ransomware is big business. Some estimate that a company is hit with ransomware every 12 seconds with the clean-up costing an average total of $4.5 million dollars (IBM). There are a lot of contradictory statistics, but most people agree that ransomware is a billion-dollar cash cow for cyber criminals. Any organisation can be a victim, and it’s happening all the time.
Part of the way you can attempt to mitigate this risk is by preparing a plan – a ransomware playbook – for what might happen IF you were attacked.
The majority of our clients come to us with either no specific ransomware playbook or one that needs a fair amount of development.
Regardless of whether you are building one for the first time or developing an existing one, the good thing is if you are reading this you recognise the pressing need to have a robust playbook to cover a ransomware incident.
This guidance follows the NIST Cyber Security Framework’s 5 functions minus “protect” as this is purely about handling the worst when it happens. Hopefully this blog will give you some clear ideas of things to consider and develop in your ransomware playbooks.
Identify
One of the first key things to identify in your playbook are all the various stakeholders that need to be notified or who will be actively involved in the handling of a ransomware incident. These will include internal and external stakeholders.
Internally these will include your crisis management team who will likely include senior leadership roles, GC, HR, Comms, Facilities management and others. Outside of the CMT you will also want to include your SOC and other cyber security and IT and engineering teams. Make sure that their roles and responsibilities are clearly defined. This can’t just be a high-level description but needs to actually detail the actual way they are expected to execute granular tasks in this scenario. We find that running a cyber crisis exercise is a great way to iron out the details of this.
Externally key stakeholders will likely include MSSPs, suppliers, external legal support, DFIR firm, regulators and insurers.
Document who these people are, how you would make contact with them in a ransomware incident and in what time frame would you need to do that.
Distribute the list and keep an offline copy. Set a task for a periodic review to ensure it is kept up to date.
Detect
How are you going to detect a ransomware attack has occurred? How will you know the severity of it and the likely risk posed to business-critical systems?
Some of the questions you should give some thought to addressing are:
- How do we know if it is an incident or an event?
- How do we assess the severity of what happened?
- At what frequency do we have to reassess what is happening, knowing that things change?
- How will we assess and triage the systems that have been impacted? What is the order of priority we need to do this in?
One of the key things that I see often left out of the “detect” part of a playbook is how it will all be documented and by whom. It is absolutely vital to document everything you do, everything you identify and timestamp it all. This gives you a clear log of events and decisions which you may need to later rely on in legal proceedings, to report to your regulator, or just for learning lessons in the future. Our memories as human beings tend to be really bad under pressure or in stressful situations. There has been a lot of research done into this area, especially in the criminal law area of eyewitness testimony, and the inaccuracies noted are alarming. So have a process for how this will all be logged.
DETECT: Potential indicators
- Unusual invoices or other business emails, possibly with malicious attachments or links.
- Employees report that they cannot access systems.
- A large number of files are modified within a short amount of time.
- Unusually large amounts of data transferred across the network.
- System analysis shows unidentifiable encryption types.
- Ransomware messages; on screen, in files, in email.
- Unusual network traffic or web browsing activity, e.g., example TOR traffic.Dark web monitoring shows announcement of attack on ransomware group blog.
Respond
The response cycle needs to be clearly laid out in your ransomware playbook. Containment is always the first order of business. The first thing has to be to stop the bleeding.
Contain the problem. Detail the steps you would take to contain or quarantine the threat. You may want to list a suite of options you could take, ranging in severity.
Collect evidence correctly. Make sure that the logs and data you collect as evidence follow an appropriate procedure, and chain of custody is followed throughout. This is where your insurer will likely dictate how this is to be done and with what third party support.
Investigate. How will you discover who “patient zero” was? How will you identify all the compromised systems and check for evidence of data exfiltration?
Prepare comms. In a cyber-attack, and especially a ransomware attack, good comms playbooks are key. Crisis communication planning ensures that you already have clear ideas about what to say and when, before an incident occurs. Make sure you work with your comms team and brief them on what a ransomware attack would look like, the impact, the escalating issues and then work with them to draft a set of comms templates you can adapt in a live incident
Another part to the “respond” part of the playbook is the tricky issue of handling the attackers and the ransom demand. Keeping the academic discussion of ransom payments out of this for the purposes of playbook development there are a few key things that should be worked out.
If you were to pay, how would you do it?
- Will your insurer handle this?
- If not, and you were to pay, who would handle the negotiation process? How will that firm or individual get hired?
- If your insurer isn’t handling this, who in your organisation makes the final call to pay? What things should the CMT consider before they make that decision?
- How would you acquire cryptocurrency as an entity in order to pay?
You can read a full discussion on all the nuances and considerations around paying here https://red-goat.com/preparing-for-a-ransomware-attack-payment/
It is not recommended that you document what amount you would be willing to pay and in what circumstances. Ransomware groups search through your files to find your insurance, banking and other documents using keywords to help them determine how high to set the ransom. So, documenting all the circumstances where the Board has approved that you pay would be unwise. You should certainly have this conversation with the Board, but give careful consideration to anything you actually document.
However, this should not put you off planning for an incident and documenting questions relating to logistics and practicalities!
RESPOND: Potential actions:
- Disconnect compromised systems from the network (but don’t turn off).
- Consider disconnecting at risk unaffected network infrastructure, external devices.
- Collect relevant log files.
- Deactivate potentially compromised accounts.
- Submit any potential malware/domains to appropriate third parties.
- Reset admin passwords/authentication methods & check MFA has not been disabled.
- Consider blocking network traffic to trusted third parties to prevent potential downstream supply chain infection.
- Block traffic to potential C2 servers.
- Delete malicious binaries.
Recover
It is sensible to split this part of the ransomware playbook into two scenarios: with and without the decryption key. As you don’t know how things will play out with payment of ransoms, or the strain you may get hit with, it is best to consider and document the steps for both situations.
5 recovery questions:
- How will you go about rebuilding?
- In what order of priority will you rebuild impacted systems or devices? Which departments need to be back on line first – this will likely change month by month depending on projects and deadlines so detail how you will assess who needs access back first.
- How will you test the decryption key if you get one? Attackers actually usually recommend, post payment of ransom, that you test the key first on non-critical systems and make sure it performs as you expect.
- How will you ensure the backups are clean?
- How and in what order of priority will you patch and configure things appropriately and to what benchmarks?
Then you also need to consider the aftermath in the recovery plan. This includes adding the observed IOCs to the technologies you have, holding debriefs with the Gold, Silver and Bronze response teams (see more on how to set these teams up here) and then update the plans and playbooks you have with the lessons learned.
RECOVER: Potential actions
- Scan backups before restoring.
- Rebuild from secure, uncompromised backups.
- Scan quarantined data and remove any malware.
- Review and correct config settings that may have been altered by attackers.
- Monitor the network for signs of continuing abnormal behaviour.
- Update any outdated software and systems.
- In the event that decryption or recovery fails, store a copy of the encrypted data for possible future recovery.
Conclusion
This may sound like a huge piece of work to undertake for just one attack scenario. If you are unsure where to begin start by just jotting down a checklist of things in the above categories you would expect people to work through. Then, I often advise clients, run an exercise with your Gold and Silver teams. Listen to the troubles they have, the questions they ask and the feedback they have on how to handle the scenario more effectively. This feedback can then also be injected into the playbook and slowly through this process it develops. The reason this process works so well is that it yields a ransomware playbook that isn’t forged from a textbook but is instead grounded in reality for your specific teams, assets and organisational structure. It then works far better. Usability is key under pressure.
When you have a playbook you are happy with, run a training session with your Gold, Silver and Bronze teams where you provide a briefing on the playbooks, where to find them, how to use them and why they are important. We want to set our teams up for success not failure so these sessions are just as important as the exercises.
Every step you take will make you more resilient. The perfect ransomware playbook doesn’t exist, but any playbook is better than relying on coffee and improvisation skills!
