When communicating ransomware risk to executives or nontechnical audiences, it’s important to avoid technical complexities. Instead, focus on the elements the
business leaders care about and present the risk in terms they understand and are accustomed to. This piece provides best practice strategies for communicating ransomware risk, as well as guidance for translating that risk into a formal business impact
assessment (BIA).
Know Your Audience and Its Expectations
As with many social-technical issues, discussing technical risk is difficult due to conflicting assumptions. For example, the term “ransomware” may seem unambiguous, but the concept of “malware that charges a ransom” can mean a
very different thing to a nontechnical audience, because its conception of “malware” is seldom more advanced than “an annoying virus” and its conception of “ransom” is informed largely by movies and television.
This means that, absent further explanation, your audience may know nothing of malware cartel groups, the economics driving ransomware activity, the geopolitical situation or any of the factors that affect likelihood and impact of ransomware risk.
Fundamentally, each item of concern must be recontextualized in terms the audience can be expected to understand, and the analysis path should be made clear. Where issues of information sensitivity do not apply, it can help to pull individuals from elsewhere
in the organization to preview the communication prior to the presentation to verify that likely areas of misunderstanding are addressed.
Explaining Data Loss to Executives
Typically, the concept of data loss should be reframed in three ways:
- Punitive fines from regulatory bodies: Avoid direct discussion of what the fine could be and instead focus on what real-world fines have been.
- Data breach management costs: Focus on real-world numbers, not hypotheticals, even if you have to pull from insurance deductibles and companies not in your industry. Attempting to use numbers from industry research groups will typically derail the discussion
into a numbers-validity discussion. Using published costs does not.
- How a malicious actor could misuse the data to the organization’s detriment: Show examples of real-world misuse and then create an attacker persona (as commonly used in agile development) to represent what the attacker would do with your organization’s
data and why they're interested in it. Avoid numbers here, because any costs in this context would be more hypothetical and, therefore, vulnerable to challenge. Instead, focus on how the event would impact the brand, the type of work needed to address
the impact and how refocusing resources in that way would hamper the organization’s ability to execute other business-critical tasks.
Discussing the Concept of System Disruption
When discussing system disruption, avoid all complexity considerations. Even though looking at the details of a disruption from component and network adjacency concerns is useful from a technical perspective, it is a good way to lose a nontechnical audience.
Instead, focus on how a system disruption would be experienced by customers, prospects, partners, workers and management. Discuss any costs that might be incurred from an SLA perspective, because that is a measurable form of customer commitment. However,
avoid hypothesizing worst-case scenarios. The point of the discussion is to identify real-world risk and determine response.
READ: How to Respond to Ransomware Attacks
Discussing Ransomware Recovery
Ransomware recovery concerns can take many forms, and there is no standard approach. Instead, it is important to first establish a meeting standard of “no blame, shame or guilt” and make
sure everyone involved in the discussion is there to understand and help address the concerns that may exist around recovery.
Where possible, discuss real-world timelines, as discovered from testing, and avoid hypotheticals. By the time the issue rises to a risk committee, the technical issues should be fully understood so the discussion can focus on addressing or accepting
the risks themselves.
How to Create a Formal BIA
Collecting all this information together into a formal BIA can be done in as many different ways as there are businesses. Typically, you should strive to avoid outlandish unlikely risks, as well as commonplace de-facto accepted risks. In ransomware terms,
this means avoiding nightmare scenarios like a foreign nation targeting data to put pressure on specific individuals to commit treason, as well as costs like the everyday running of the incident response team. This approach is not because such attacks
can’t happen, and such costs don’t matter; it’s because adding all possible factors does not improve the value of the assessment and will derail the process of actually addressing the risk.
Your BIA should clearly list the scenarios under consideration, as well as identify the classes of scenarios that were disregarded and why. Similarly, the BIA should list the financial numbers involved in the analysis, where they came from and, in more
mature organizations, the confidence level around the estimates.
Critically, unlike the specific discussions earlier, the use of estimation in the BIA is unavoidable. The analysis should make it clear which numbers are known and which are estimated, and how the estimation could affect the final recommendations.
Once the assessment is done and available as a standard format document, the key points should be extracted into a presentation to be given to the risk committee. There are many different ways to structure such a presentation but, generally speaking,
keeping the slide count and word count low while keeping the picture count high is the best way to go. Details, of course, will depend on the type of presentation the committee is accustomed to receiving.
DOWNLOAD: Ransomware Prep Toolkit
Communicating Risk to Executives
Ransomware is an adaptive threat. While there are patterns, as soon as enough organizations adapt to the patterns, ransomware groups change their tactics, their technologies and their overall strategy. When looking at the situation from a risk committee
view, a solid ransomware approach requires improvements in prevention, detection and recovery practices. The critical element centers around communication. To ensure you communicate the risks
effectively:
- Keep your audience in mind: Nontechnical audiences do not need to understand the technology. Give them enough information to do their jobs and let them ask if they need more.
- Avoid arguments: Expect any claims that can be challenged to be challenged. Be able to defend your numbers, and where you make assumptions, be open about those and why they were made.
- Avoid distraction: By keeping the level of detail to a minimum, you can avoid solutioning at the committee level. Ideally, the BIA will include a recommendation and a backup recommendation. If neither recommendation is acceptable, the committee should
provide direction to adjust the analysis and re-present at the next meeting.
Finally, know that more data does not always produce better results. Work to identify when you have sufficient data to present your recommendations and move forward. The primary risk from ransomware is that you will be breached if your analysis takes
too long, and your organization is not adequately prepared. Smaller, faster steps will allow your organization to be successful and adaptable as well.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.