Ransomware Readiness Part 2 – What Does it Really Mean to be Ready?
We’ve all been asked at some point in our lives – “Are you ready?”. That usually strikes me as a somewhat loaded question, “ready for what?”. Chances are that if you’re being asked “are you ready”, it’s because it’s something you haven’t done before, or because that thing that you are supposed to be ready for is really challenging. A client asked me recently to help them understand if they are ready for a Ransomware Incident…then stressed “I mean REALLY ready”. That got me to thinking, what does it really mean to be ready to manage a ransomware incident?
There are all types of leading practices and frameworks out there to help you generally prepare for and manage ransomware incidents. In helping the client who originally asked me the question, and to inform a helpful blog, I thought we would look at the core concepts of ransomware response, through the lens of real-world experiences and lessons learned.
In our last ransomware post, we discussed one of the key and often overlooked decisions regarding this challenge, which is determining whether or not your organization would pay a ransom in the event of a compromise. While that is a critical determination to make ahead of time, we’re going to focus on some other elements of ransomware readiness.
Cyber Insurance and Incident Response Retainers
Cyber insurance and incident response retainers are more and more commonplace in today’s environment. Organizations have become increasingly aware of the fact that, given the prevalence of attacks, having this insurance is now the cost of doing business. While having insurance is a great start, there are some things that often get overlooked, so in order to truly be ready here are a few things to consider:
Agreed upon response times – Not all response times are created equal. Do you know exactly what your vendor is contractually obligated to provide for a response; how quickly and what is provided initially? I’ve worked with a lot of clients who had made assumptions about how quickly a vendor will respond, but upon further inspection of the contract, the agreed upon time was something along the lines of “best-effort”. What vendors will often do, is sell the “best-effort” SLA and say things like “well, we’ve never had a situation where it has taken us longer than 8 hours to respond with support”. That might be OK in your situation, but it’s critical to know exactly when and with what type of support your provider is “required” to respond.
Criteria for receiving reimbursements. If you do have cyber insurance, it’s important to fully understand not only the total coverage amounts, but also the stipulations for what that dollar amount covers (types of reimbursements) and also requirements that may need to be met in order to receive reimbursement. In some cases, you may find it challenging to actually receive reimbursements if it’s determined after the incident that certain criteria were not met.
Requirements for using outside support. You may have preferred partners (for incident response and forensics for example), but they may not be approved for use by your insurance provider. Ensure that your preferred partners are on their approved list (if your policy has one) and if not, you may be able to work with the insurance provider to have them added. In the event of an incident, if you were to use a provider for assistance, that is not on the approved list, it's possible you will not receive reimbursement from the insurance provider. There may also be other stipulations about how and when to engage even those providers on the list, which can potentially cause challenges with reimbursement.
Incident Response Plan / Team
There are plenty of publicly available resources/templates to help you document your Incident Response Plan. They generally follow a similar approach to tackling the problem, but also can lack the specifics needed to be meaningful to your organization or in relation to managing a Ransomware attack specifically. The pitfalls we have observed generally fall into the following categories:
Documenting the plan (step by step). Policies, standards, procedures, job-aids, plans, runbooks….oh my! I’m not exactly sure why, but for some reason it seems that organizations get tripped up with their incident response documentation needs, often more than they do with other processes. I often hear “Oh, we have an IR Plan (or IR Runbook)” that covers our needs, but upon inspection, the documentation is largely generic and describes the general approach and requirements needed for the organization to respond.
The documentation is generally what I would consider to be academic in nature and really does not assist with the most critical aspects of responding to an incident. A general Incident Response Plan can be helpful for providing the foundation for organizational response, but there needs to be step-by-step response guidance for personnel managing an incident. I have found this to typically be the most challenging part to document, as it requires time and effort to walk through each part of a response and ask “OK, what exactly do we do if this happens? Then what is the next step?” and so on. It’s sometimes uncomfortable, especially if we don’t know all the answers, but it must be done and it must be done well in advance of an incident. Don’t get too hung up on terminology, focus more on asking the right questions about the step-by-step manner in which you are going to respond and then ensure its documented and communicated (think Visio process diagrams and decision matrices).
Find and replace. If I had a dollar for every time that I have seen a client download a template, perform a “find and replace” to add their company name and then consider the problem solved…well, I might not be able to retire, but I would be pretty well off. This approach does not solve any problem beyond a compliance checkbox that there is a “documented plan in place” and may even create more problems and confusion than existed before. An existing template may provide a good starting point for your IR Plan and Procedures, but it should be only that: a starting point. It’s imperative to review and modify templates in a way that will align with your current environment and that the documentation is then clearly communicated and incorporated into everyday operations in a meaningful way. Plans and procedures are definitely not one size-fits-all, so “find and replace” is a poor approach; especially for a process for which documentation is so critical as it is with incident response.
Reviewing and testing the plan. A key part of making sure that your response plans are meeting their intent is to periodically review and test with the appropriate stakeholders. It’s important to remember that testing the plan likely requires tests with different focus for different personnel who are part of the response process. For example, having one test (commonly referred to as a table-top-exercise) for the organization’s leadership but then also having more technical, specific tests for the more tactical response elements is recommended.
Skillsets of existing team members. In addition to documenting, testing, and updating your IR Plan one often overlooked component to response is ensuring that the right expertise and skill sets exist within the organization. Do you have the right personnel, with the right skills and training, in the right positions to manage the response as expected? Simply having “people” assigned to tasks is not a good approach for something as critical as managing an incident.
Tools
One thing I’ve found many organizations seem to excel at is buying new toys, err I mean tools. Acquiring security technologies that are designed to be a silver-security-bullet and then not using them to their potential seems to almost be the gold standard. Buying security tools is very necessary, but if you are not considering the following caveats, they are not likely to help you be any more prepared for a ransomware incident:
Coverage of the technology - It’s important to have a clear understanding of your security tool coverage and how those tools support your incident response capabilities. When purchasing tools, it’s important to consider “what problem are we trying to solve?”
Product strategy and roadmap - Understanding how your security tool stack works together and having a strategy to manage all the different pieces in the near and long term.
Ownership of technology and the output – Now that you have the technology, how is it going to be used? What type of data outputs are you expecting and who is going to use the data and how?
Security Information and Event Management
In line with technology, there are generally challenges to consider when it comes to how these tools are used and what value the data is providing.
Data aggregation and correlation – Your organization’s logging and monitoring tools typically generate a lot of data. It’s important to consider how that data is going to be aggregated in a way to make it useful and to correlate that data with other tools and capabilities. Do you have the right skillsets on staff, or external support to make sure log data is useful?
Alerting – One common challenge with logging/monitoring tools is alert fatigue. It’s imperative to make sure that alerts that are generated are meaningful and useful to analysts. Too many alerts of poor quality only increase your chances of missing the important ones. Does your organization have a well-managed SoC, or relationship with an external partner to ensure 24x7 monitoring of alerts in the environment?
Responding – Once meaningful alerts are generated be sure that you have the capability to respond to those alerts with people who have the appropriate skillsets and know their role in the response process.
In summary, thinking your organization is ready to manage a Ransomware incident because you have a few things documented and a few tools implemented is a lot different than “really being ready”. Don’t be afraid to communicate across the organization, ask tough questions, seek feedback across all of the key stakeholders (including the IT support staff that will be involved in implementing the step-by-step plans), and most importantly test your plans and make adjustments as needed. If you would like more information, or assistance with really being ready to manage a Ransomware incident, please reach out to the Risk and Advisory team via the Contact form at Atredis Partners. We have a great team of experienced consultants who are happy to provide your organization with guidance in all of these areas.