7 Things Your Ransomware Response Playbook Is Likely Missing
Incident response experts share their secrets for success when it comes to creating a professional-grade ransomware response playbook. Are you ready for the worst?
April 11, 2023
![sports playbook concept art with hand making notes sports playbook concept art with hand making notes](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt5c01a0afd83d6612/64f171661dce688cdf8f10ae/crop_playbook_Panther_Media_GmbH_Alamy.png?width=700&auto=webp&quality=80&disable=upscale)
Source: Panther Media GmbH via Alamy Stock Photo
The moment a cybersecurity incident is discovered is a terrible time to come up with a response plan. Organizations need to create, practice, and constantly update a ransomware response playbook that can bring clarity to the incident response chaos and be prepared to deploy the right resources for a quick recovery.
Incident response experts Roselle Safran, founder and CEO of KeyCaliber, and LeeAnne Pelzer, a director with Palo Alto Networks' Unit 42, recently sat down with Dark Reading to discuss the right way to build an organization's ransomware response playbook, how to run a successful incident response, and, more importantly, how to get the organization quickly on the road to recovery.
Based on their expert advice, here are seven elements that are commonly overlooked, but necessary, for a well-conceived ransomware-response playbook. For more, check out their full remarks on ransomware response playbooks, on-demand.
In this slideshow:
Who initiates the incident response? What's next? These questions need to be clearly defined down to what Palo Alto Network's Pelzer calls "granular tasks during the triage process." Otherwise, security teams could waste precious moments figuring out who does what instead of reacting effectively.
In her role at PAN, Pelzer often serves as the "incident commander," she explained during the webinar. The designated incident commander can be internal, or brought in from the outside specifically to manage incident response when something happens. Often, external commanders like Pelzer are called on to relieve exhausted internal teams so they can sleep, shower, and see their families.
The need for that kind of 24-hour, 7-day-a-week coverage is another important consideration when building out ransomware response playbooks, she advised.
From the CFO setting up a Bitcoin ransomware payment to looping in human resources on potentially compromised employee data, making decisions in the heat of an incident needs to be a streamlined, practiced process, Pelzer and KeyCaliber's Safran stressed during the webinar.
A list of key contacts and their phone numbers — kept updated, of course — is critical for keeping the incident response running smoothly. It may seem obvious, but at many businesses, this list doesn't exist.
Likewise, there needs to be a final decision-maker on hand to react to the evolving situation, Pelzer added.
Safran detailed a list of technical stakeholders to identify, including managed security services providers (MSSP), system owners, and potentially cloud service providers.
Beyond the technical, non-technical contacts might include the legal team, the communications teams, compliance, regulatory agencies, and law enforcement.
No one should engage with, or respond to, any ransomware demands themselves, according to Pelzer. She adamantly advocates for calling in a professional negotiator trained to grind out a ransomware settlement that's as low as possible.
"The stakes are extremely high when it comes to ransomware negotiation — one wrong move or uncalculated interaction can have a devastating impact," Pelzer tells Dark Reading. "Professional negotiators have received specialized training when it comes to winning favor with threat actors and (hopefully) achieving the most favorable outcome for the victim organization."
Pelzer adds that there's a good chance the negotiator has already worked with the ransomware group in previous incidents.
Besides negotiating the best ransom deal, pro ransomware negotiators understand which tactics, techniques, and procedures (TTPs) are specific to which group, know the reputations of major ransomware players, can help organizations improve backup strategies for recovery in advance of a cyberattack, and much more.
"In any negotiation, experience is an advantage," Safran explains to Dark Reading. "It is likely that the incident will not be the first for the attacker, so you don't want to be the rookie in the negotiation. You need someone on your side who knows what to expect and has an understanding of what works and what doesn't work."
Cybersecurity insurance providers will often provide customers with a ransomware negotiator in the event of a compromise. There is also an array of incident response service providers available with negotiators that can help in the event of a lack of cybersecurity insurance, according to Pelzer and Safran.
In many instances cybersecurity insurers lack basic ransomware coverage, so it's important to check that out well in advance of any cybersecurity event or incident.
Once a breach has occurred, an organization must assess the situation and clearly communicate with any other organizations up and down its software supply chain that might be vulnerable to follow-on attacks.
Safran recommended during the webinar including a list of every vendor who needs to be notified in the ransomware-response playbook.
"Often these details are stipulated in the contracts with the supply chain vendors," Safran tells Dark Reading. "Besides service-level agreements, organizations need to consider regulatory obligations to avoid future lawsuits," Pelzer warns.
Importantly, all vendor contact details need to be kept up to date.
"Incident response playbooks should always be tactical and action-oriented,” Pelzer explains to Dark Reading. "Supply chain incident playbooks should include the steps necessary to quickly access direct, accurate contact information for all parties involved within the compromised supply chain."
From SolarWinds to Fortra's GoAnywhere zero-day exploit, there's no shortage of examples of how quickly and catastrophically software supply chain attacks can spread.
Safran strongly recommends that teams come up with a predetermined cadence for releasing communications on the status of an incident, so that all stakeholders know exactly when to expect the next update. Whether it's hourly or daily, the frequency should be appropriate for the organization and the type of incident itself.
"When determining an appropriate incident communications cadence, organizations should consider a few unique factors, such as mission and core objectives, the involvement level of business leaders, and the incident's impact on crown jewels," Pelzer tells Dark Reading.
"Rough guidelines regarding communications cadence should be defined and practiced during routine incident response training and stakeholder roundtables," she adds.
More specifically, each role should correspond with the RACI (responsible, accountable, consulted, and informed) matrix, Safran explains.
"Generally speaking, those who are responsible or accountable need to be updated more frequently than those who are consulted or informed," Safran tells Dark Reading. "However, in the case of senior leadership or the board, they need to be informed at the frequency that they consider sufficient."
Whatever the expectations for communications within the organization, they should be clearly defined, in advance, in the ransomware response playbook, according to Safran.
"You don't want to be in the situation where you're figuring out reporting on the fly during an incident," Safran says.
Keep it simple, she urges, and with each scheduled update answer four specific questions — what we know, what we don't know, what we are investigating, and what we finished.
Is this an incident or an event? Sometimes it can be hard to tell whether it's just a threat of compromise or a full-on security breach.
For guidance, Pelzer recommends using the NIST framework but cautions that each individual organization should have their own set of more nuanced parameters that take into full consideration how close each event or incident is to their individual data “crown jewels.”
"An 'event' is typically any anomalous activity — or any deviation from the normal day-to-day activity within an organization's cybersecurity ecosystem," Pelzer tells Dark Reading. "An 'incident' is an occurrence that requires a response effort due to imminent danger, threat, or impact to an organization's operations. Additionally, it is important to note that not all events are incidents, but all incidents are events."
But, Pelzer adds, each individual organization should have its own set of more nuanced parameters that take into full consideration how close each event or incident is to its individual sensitive data stores, such as customer PII, intellectual property, financial documents, and more.
Safran suggests applying the the NIST framework in the early "identify" stage of pinpointing the organization's most valuable data.
"In the identify stage of NIST CSF, you determine your crown jewels," Safran says. "Those include all the cyber assets that are critical to operations, and can include key data and users as well. Then in the detect stage, you check to see if the detection/alert directly impacts crown jewels, or can easily spread via lateral movement to a crown jewel. If a crown jewel is or easily can be affected, that is an incident."
Once the proverbial dust settles, its tempting to just get back to business as usual. But Safran stresses the importance of reviewing incident documentation, holding a post-mortem meeting, and critically, going back and updating the ransomware response playbook for the next time it's needed.
That process should also be defined in the ransomware response playbook.
Projects like the Verica Open Incident Database (VOID) are trying to collect incident data across hundreds of organizations over time to share information and find patterns that can be used to defend against future cyberattacks.
Internally, nuances, details, and lessons learned from each response might seem unforgettable in the wake of an event, but they are often forgotten over time.
"You might think you'll never forget these things," Safran cautioned during the webinar, "but it happens."
Once the proverbial dust settles, its tempting to just get back to business as usual. But Safran stresses the importance of reviewing incident documentation, holding a post-mortem meeting, and critically, going back and updating the ransomware response playbook for the next time it's needed.
That process should also be defined in the ransomware response playbook.
Projects like the Verica Open Incident Database (VOID) are trying to collect incident data across hundreds of organizations over time to share information and find patterns that can be used to defend against future cyberattacks.
Internally, nuances, details, and lessons learned from each response might seem unforgettable in the wake of an event, but they are often forgotten over time.
"You might think you'll never forget these things," Safran cautioned during the webinar, "but it happens."
The moment a cybersecurity incident is discovered is a terrible time to come up with a response plan. Organizations need to create, practice, and constantly update a ransomware response playbook that can bring clarity to the incident response chaos and be prepared to deploy the right resources for a quick recovery.
Incident response experts Roselle Safran, founder and CEO of KeyCaliber, and LeeAnne Pelzer, a director with Palo Alto Networks' Unit 42, recently sat down with Dark Reading to discuss the right way to build an organization's ransomware response playbook, how to run a successful incident response, and, more importantly, how to get the organization quickly on the road to recovery.
Based on their expert advice, here are seven elements that are commonly overlooked, but necessary, for a well-conceived ransomware-response playbook. For more, check out their full remarks on ransomware response playbooks, on-demand.
In this slideshow:
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024