« Return to Blog Listing

How To Scope A Risk Analysis Using FAIR

How To Scope A Risk Analysis Using FAIR

by Cody Whelan on Jan 27, 2017 12:00:00 PM

How To Scope A Risk Analysis Using FAIR.jpgThere is nothing finer than a well-constructed and thought-out risk scenario, bar none. The scenario unto itself represents the culmination of an individual’s, or better yet, a group’s understanding of the problem at hand (i.e. how loss will materialize). If this sensation is unfamiliar to you as a risk analyst, I apologize for your loss, as you truly are missing out on the most important and rewarding aspects of your chosen profession. As you see, the work ahead hinges on this one aspect of the risk analysis process. When done well, identifying and gathering the data for an analysis is straightforward, stress-free and produces a result that meets the expectations of your stakeholders. On the other hand, when done poorly, ill-conceived assumptions and rushed thinking lead to additional work and ultimately a subpar analysis.  

To ensure more of my colleagues partake in this experience, I’d like to take this opportunity to walk us through the scoping process we teach here at RiskLens as part of our training:

Purpose

We start the scoping process by trying to answer the following question, written in various forms:

  • “What is the purpose of our analysis?”  
  • “What is the reason for, or what decision are we trying to inform?”  
  • "Is the analysis more strategic, (e.x. what are the organization’s top 10 risks) or more tactical in nature (e.x. what is the ROI on X security initiative)?"  

Having these answers will let us know how broad or granular our approach should be going forward.

Asset(s)

Once we have solidified the purpose of the analysis, our next move is identifying the asset(s) for the analysis. For a tactical analysis, this answer is relatively straight forward. Yet for a strategic analysis, this may take some additional thought as multiple scenarios covering multiple assets may be required to sufficiently inform stakeholder decisions. In either case, we need to know:

  • “What asset(s) should be included?” If the ultimate asset is a data type (PII, PHI, PCI, etc.) 
  • “What and where is the data contained in (i.e. laptop, server, etc.)?”  

It also doesn’t hurt to get an understanding of the volume, or amount of information contained therein. 

Threat(s)

Now that we've identified the purpose of the analysis, and the assets to be included, whom from the threat landscape should we be concerned with? Is the asset, or assets we identified most susceptible to attacks from malicious external actors (i.e. Cyber Criminals, General Hackers, Nation States, etc.) and/or internal actors (i.e. Privileged Insiders, both from a malicious or accidental perspective)? It's important to keep in mind that you can scope all threat actors under the sun, but here we want to leverage the concept of possibility vs probability. If the industry that you're in, and the asset your scoping is of no concern or value to Nation States, you end up providing little to no value to your stakeholders by gathering data and providing results that prove just that. Focus on the probable threat actors to affect the scenario your scoping; your stakeholders will thank you (smile).  

Loss Type(s)

Now that we have a good understanding of the probable threat landscape that is of most concern to our analysis, how does the loss actually manifest itself? For this purpose, we leverage the C-I-A triad to identify whether the loss type is a release of sensitive information (i.e. Confidentiality), an alteration or information reliability concern (i.e. Integrity) and/or an inability to access or outage issue (i.e. Availability). Identifying how the loss will manifest itself will often aid in identifying which subject matter experts to leverage when gathering the data for an analysis (i.e. Is this a Privacy related concern, or should we reach out to our Disaster Recovery team?).

Loss Event

The last component, identifying how the loss will actually take place, is probably the most critical component of them all. To a novice, this may sound like an obvious or insignificant aspect, but it will and should inform the entire analysis. An example: If conducting a DDoS analysis on a company’s primary retail website, what represents the loss event?:

  • Is it the inability to access the website? 
  • Is it some form of degradation?  

The answer to these questions should dictate a lot, from:

  • How frequently these types of losses are experienced? 
  • What controls are in place to reduce/mitigate the loss? 
  • What’s the resulting impact if it does occur?

There you have it. By identifying and critically thinking through each of these components, you will drastically increase your odds of scoping an analysis that meets needs of your stakeholders, while also achieving one of the finer aspects of the risk analysis process. We look forward to working with you in the future.

 

Contact Us
This post was written by Cody Whelan

Cody Whelan is a Risk Consultant for RiskLens

Connect with Cody