« Return to Blog Listing

Two Criteria You Must Consider When Planning Risk Analyses

by Isaiah McGowan on May 26, 2016 11:15:00 AM
Two_Criteria_You_Must_Consider_When_Planning_Risk_Analyses.jpg
Spending the right amount of time for risk analyses?
 
You're either spending too much or not enough time on risk analyses. If you aren’t sure that you are right-sizing your analysis efforts, then you may not be factoring in the right criteria. How much data needs to be provided to support the decision at hand? Will I go deep into the weeds, or can I stay at a high level? These are just two of the questions I always have in mind when planning analysis efforts. They are rooted in two key criteria: 
  1. The magnitude of the decision the analysis will support
  2. The granularity of the risk landscape in scope for analysis
What decision are you supporting?
 
When planning to conduct risk analyses, always begin with the end in mind. The breadth and depth of any analysis should correlate with the size of the decision it is supporting. As analysts, we regularly have multiple requests on our plate. They might look like the following:
  1. How bad is Ransomware for us?
  2. We have a control exception for open ports on a web server. How quickly should we fix it?
  3. Can we change our risk by implementing new application security procedures?
Each analysis above supports a different decision. The first one is informative in nature. Business leaders want to wrap their heads around the risk of a specific problem before they determine if they should, or even can, address the risk. Further analyses on this risk would compare treatment options like the ones below:
  • Train security staff to better handle Ransomware
  • Hire additional incident responders
  • Purchase a new Ransomware mitigation product
This sort of analysis bears more weight because of the spending decisions involved. It should receive more attention than control conditions, but probably not as much as changing application security procedures.
 
The second analysis, a control condition, may determine if existing plans should be reprioritized. There is no capital spending involved. Likely, this analysis is a result of some previous, larger decision. These sorts of issues are very common and can be completed in short order. Of the three, this one supports the smallest decision.
 
The third analysis is similar to the first because it involves a major shift in resources. Implementing new processes for application security involves everything from training to retooling for the application developers. Additionally, the decision affects the security posture of all applications in the portfolio. This analysis would support the biggest decision of the three.
 
How much are you analyzing at one time?
 
Let’s switch gears. Along with considering the decision we’re making, we also need to consider the breadth of the analysis scope. There are three key elements in the scope of any analysis:
  1. The threats (external, internal)
  2. The assets (applications, servers, devices)
  3. The way an organization experiences loss (data breach, sabotage, outage)
The time investment grows as more elements are included. Let’s look at our list and consider this concept. The first analysis, Ransomware, primarily targets workstations and is commonly associated with organized cyber criminals. We’re looking at an analysis with one threat community, one asset, and one type of loss. This is a straightforward analysis in its scope. We are looking at a population of assets but, that adds little complexity to our problem.
 
The control condition analysis is even more straightforward than our Ransomware analysis. It involves a single system and the analysis hinges on a control condition we already know about. Not much left to investigate in this analysis. The last analysis is broad and deep. At the highest level, we would have several types of applications within our analysis. We also would need to include multiple threat communities. This is the most complex analysis. 
 
Which one takes more time?
 
How do these stack up? Which one should take the longest, and which the shortest? Here is the ordered list, from shortest to longest:
  1. Control condition
  2. Ransomware
  3. Application security procedures
The control condition reflects the lowest investment in treatment. It also has the smallest scope of all the analyses. The Ransomware issue is more complex. We need to learn more about the problem, meaning it has a bigger scope than the control condition analysis. It may also support capital spending initiatives in the future. The analysis over application security procedures is the biggest on both fronts. Changes in procedures of this magnitude involve training, retooling, and tremendous time investments. Because the changes will affect dozens or hundreds of applications, we would need to include those applications in our scope; resulting in the largest scope of the three analyses. 
 
Using these two criteria, we can determine which analyses will take longer than others. We can confidently determine which should get more scrutiny and take longer than the other. Next, we can align our analyses to the correct tool and identify how long the analysis will take; but, that's a topic for a future post.
 
Subscribe to RiskLens' blog for more articles like this one
This post was written by Isaiah McGowan

Isaiah McGowan is a Senior Risk Consultant on Customer Success

Connect with Isaiah