Risk Management: Context is the Key

Thursday, October 06, 2011

Gabriel Bassett



I feel it’s time for me to comment on risk management a bit.  I have a good amount of history with security risk management, most of it done poorly, (much of it done poorly by me). 

Ultimately, a Christmas to New Years Eve week of brain storming led to an answer; but let’s talk about the problem first.

There is a core problem in risk management stemming from the history of those who implement it.  They are either technical people or traditional risk/management people. 

Technical people tend towards the “every security risk is important enough to fix” mantra, focusing on technical details and over-rating risks. 

Management/traditional risk people are used to much more tolerant definitions of likelihood (70% chance of happening is a 3 on the 5x5?) and impact quantifiable in dollars.

So what do we do?

The answer is context.  And context is captured through narrative.  For our purposes, a narrative describes how a vulnerability or vulnerabilities would be used to realize a risk and what the impact of the realization of the risk would be.

The narrative will still capture likelihood, but instead of a simple percentage, we’ll establish its context.  We want to establish the steps required for our threat to realize the risk. 

The steps, at the minimum, should include:

  • Means
  • Motive
  • Opportunity
  • Execution
  • Egress

We then give each step a 1-5 rating on how likely it is.  The words used for the numbers don’t matter.  It’s 1-5 whether it’s “can’t happen” to “certainty” or “really really unlikely” to “really really likely”. At the end, we’ll see which of the attacker’s steps are the ones preventing them from realizing our security risk.

The narrative also needs to capture the impact of realizing the risk.  This requires first a frank discussion of what would really happen to the company’s business should the risk be realized. 

The discussion should consider how the compromising the company’s confidentiality, integrity, and availability would affect business operations.  All the discussions should be in the context of the company’s core functions rather than a simple host. 

A remote root is not necessarily a high risk unless compromise of that system affects core business functions.

After the context is established, we can make a subjective assessment of the risk’s location on a normal 5x5 chart.  This gives us the ability to put the risk where we think it goes while forcing us to be able to justify our rating through the narrative.

By documenting the narrative, a security analyst establishes a single context of the risk for everyone.  Based on that context, all risk assessments should be fairly repeatable. 

While they may be a little different here and there, a shared context provides a reproducible risk assessment, even when done subjectively. 

And when you take this in front of the CIO, it should be very clear to him what stands between him and the threat and just what the consequences of not addressing it are.

Possibly Related Articles:
Enterprise Security
Information Security
Management Risk Management Probability Information Security Risk Appetite Context
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.