October 6, 2011 by
Risk Management: Context is the Key
This was originally posted on blogger here.
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.