The InfoSec Blog
19May/10

The Classical Risk Equation

What we had drilled into us when I worked in Internal Audit and when I was preparing for the CISA exam was the following


RISK is the
PROBABILITY that a
THREAT will exploit a
VULNERABILITY to cause harm to an
ASSET

R = f(T, V, A)

Why do you think they are called "TVAs"?

More sensibly the risk is the sum over all the various ..

This isn't just me sounding off. Richard Bejtlich says much the same thing and defends it from various sources. I can't do better that he has.

Now some people such as Pete Lindstrom believe that you can put hard and fast number in to that "Classical Risk Equation" while others think that its like the comment about planning for battle - its the planning that counts - and identifying the assets and vulnerabilities is what is important.

You'll note that the Classical Risk Equation doesn't mention controls.
Various apologists say that its the precursor that lets you identify where controls are needed, but that begs the question of how you measure the risk after the controls and so demonstrate improvement.
Others say that the control is there since a control will alter the probability or will remove the vulnerability. This upsets the mathematical orthogonality of the equation.

There is the also the issue of cardinality.

Risk can be either "risk of what?" or it can be a scalar value such as you might present to the Board of Governors - who, lets face it, aren't going to want to wade though lots of technical IT details.

But threats, vulnerabilities and assets are vector quantities, not least of all since a threat can exploit more than one vulnerability and cause harm to more than one asset. Further, these are not static values.
They are not static in time and they may alter as a result of control you put n place[1]

Treating the p(T, V, A) n this way makes it an exercise in matrix multiplication - think APL.

Other expressions of the risk equation such as

Risk = probability * Impact

while not incorrect, are not as useful as the Classical Risk Equation.
The CRE allows - or is it 'requires'? - one to identify the assets, which is a valuable exercise in its own right, and to consider the specific threats that face the business.

There are many critics of the risk model, from the extreme such as Donn Parker who takes a very business-management-oriented view, to the more moderate such as myself who are concerned about the practicalities.

My criticism fall into two categories

1. Enumerability and Knowability
2. Basis for Probability

1. Enumerability and Knowability

If we consider vulnerabilities for a moment and just look at the subset to do with software vulnerabilities[2], then we are faced with "Cantor's Hotel" - there's always room for not just one more but an infinite number more[3].

To put it this way, you never know when the last vulnerability has been uncovered and addressed. You can _never_ know.

Not only can you never know, you can never know what it is that you don't even know about. Donald Rumsfeld put this very well in his February 12, 2002 Department of Defense news briefing :-

As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

2. Basis for Probability

When working with risk, especially when using it as a basis for budgeting controls and mitigation, InfoSec practitioners often point to how insurance companies model risk.

This is grossly unfair. The core business[4] of the insurance companies is based on large volumes evidence on which they base their calculations. There are laws in most countries that enforce the collection of those statistics. Not only that, but the basic parameters (T, V, A) are not changing rapidly.

This is in direct contrast to the InfoSec world where there is no enforcement of collection of data and no 'normal' basis for such data. Without such data any statistical assertions are going to range from personal feelings and prejudices through to Wild-Assed-Guesses. And of course everything changes in InfoSec quite rapidly, most certainly with every release of a new product or a software update.

I'm saddened that ISO-27000 and other security standards, guidelines and methodologies place so much emphasis on RISK and TVA. I'm saddened not only because of the limits and shortcomings I've mentioned, but because of the obsessional behaviour I have seen it engender.

One of Donn Parker's counterpoints to the RISK approach is to engage in good practice. Since I have seen managers (at the project level and at the CXO level) say "its not in the risk model so we don' have to worry about it", and dismiss not only emerging threats, new vulnerabilities and new assets (since the world and business changes), but also dismiss established controls that weren't mentioned in the Risk Analysis that one of the BigN-1 supplied, I favour using Donn's approach _first_.

After all, if you leave your house to go on vacation there are things you will prudently do _beforehand_ such as making sure the gas is turned off, the post and papers are redirected, the windows and doors are closed. You do these baseline prudent measures _before_ you walk around the house testing. These are sensible measures that you should do, regardless; you don't need to run a risk analysis to determine or justify them.

After the baseline is in place, then you can ask "now what?" and start considering probabilities[5].


[11 Consider a system that has been hacked and used to store warez.
The hacker will want to keep the system running well, so if you find
out its been hacked and put controls in to rectify that the hacker
may be angered and use another exploit (or back door he inserted)
to take revenge and harm your system.

[2] A bug may or may not be a vulnerability. Also a vulnerability may
not be a bug but may be part of the design and the correct operation
of the software.

[3] See http://diveintomark.org/archives/2003/12/04/infinite-hotel
The issue of how you can have an infinite number of vulnerabilities
in a finite amount of software is essentially that of "infinite
surface area in a finite volume" and is an old problem in
mathematics known as Gabriel's Horn or Torricelli's trumpet

In more modern terms it can be though of as a fractal surface

[4] Life, fire, auto, theft. All areas where statistics are collected
by the state and there is a legal enforcement behind collecting
those statistics.

[5] Considering the increasing number of and severity of storms,
would you rebuild New Orleans in the highly vulnerable position
it was sited?

Reblog this post [with Zemanta]

Posted by Anton Aylward