February 02, 2009

Risk is business: why mathematical models will not analyse security

Alex responds:

Risk analysis, like every other measurement undertaking, reaches some point of diminishing return. In fact, I think we could offer that risk analysis that has to do with "econ" reaches that point more quickly than many other disciplines due to the uncertainties in the measurement factors.

Which is one of the central problems with the use of models: it won't work if we plug in bad numbers, something known poetically as garbage-in-garbage-out or GIGO.

What we do know in security is that we lack the metrics to deliver the inputs, to any good extent. That is well understood, and there is a conference called Metricon which looks at this very question, how to turn our terrible collection of bad data into a set of metrics that can actually deliver some conclusions.

But it gets worse! To show this I need to link across to something called net-present-value ("NPV") or capital-asset-pricing-model ("CAPM"). The task of these financial models is to generate a number (approximately called a "value") for each project, to allow comparison between projects. It doesn't tell you how much each project is worth, because we recognise that the model is trying to predict the future, and so mistakes and absences in our current information will not give us that. However, by using it to compare the different projects, we filter out all the mistakes that are in common across projects.

It is therefore the best known tool for comparison of projects. Which makes it ideal for security risk management, because that is all we want to do: analyse many competing ideas, create a "value" for them, and compare those values against each other. We then select the ones with the highest "value".

Which leads us to Alex's other comment:

NPV necessitates some concept of cash flow: Rt/(1+i)^t where Rt is cash flow in.

No, not at all. NPV requires a value. It just happens to use a "cashflow" or dollar value at a time point. It happens to require that the "cashflows" are all calculated the same way, so as to filter out errors and biases for the later comparison phase. It happens to require that all projects be turned into a cashflow view. But it does not require a flow of income to the project.

So where do these "values" come from? Well, the same place as always, by using our experience, some finger-in-the-air guesses, and a pocket calculator.

Risk Analysis, in InfoSec/Engineering at least, is currently based on the Dutch model: probable frequency of loss and probable magnitude of loss (note that ALE is a number of limited value, as risk is a derived number like km/hr).

Right. Financial projects do exactly the same. They take probable frequency of revenues, probable sizes of revenues, multiply them out (or integrate them), reduce them backwards to current time, then sum them all with probable costs treated in the same way. It's called net-present-value, and probable frequency of loss together with probable magnitude of loss is a cashflow to NPV.

So if the point is, risk analysis in security work has failed to incorporated the last phase, then OK, yes, that is understood. Security people also talk about ROI, without understanding why it has been junked already in finance. The sum of it is that current approaches to risk analysis in InfoSec/Engineering are just CAPM done incompletely and badly. So I make the claim that risk analysis in the "econ" sense is CAPM, or should be CAPM.

The problem however is more deep seated than that. Although the analysis of why CAPM works applies fully to security work, to the extent that CAPM dominates ALE, there are some gotchas. And these are in assumptions that only the finance geeks are really going to be able to surface.

  1. CAPM assumes independence of projects. This assumption is not easily acceptable to security work, because we have an active attack scenario. That is, although the attacker doesn't care one way or another, the more we lean on the assumption of independence, the more the attacker will care, and this assumption will turn brittle.
  2. CAPM assumes a market. Not only does it generate its results in a market context (in short, the goal is to achieve the envelope of market risk-reward), it separates out risks and hands some risks to the market, keeping some risks for itself. C.f., diversification. In security world, we don't generally assume a market, nor can we deal with the way CAPM slices and dices those risks.

This is no mild criticism. If we take away those assumptions, CAPM is dead. Totally dead, dead as a dodo, finance has to go back to the 1950s and start again, and Markowitz has to give back his Nobel prize.

So my claim here is that whatever risk analysis and management ends up being in the security field, if it is a mathematical thing, then:

  1. risk management is CAPM, albeit badly and incompletely.
  2. These techniques rely on assumptions that security work does not have.

If we then add the first argument that everyone else is familiar with:

  1. we don't have decent metrics to feed into the models,

we can see why I draw my aggressive conclusion: risk management is dead. At least, if we define risk management as a mathematical model for analysing costs and benefits of different security projects. On the other hand, if we define it like Alex does:

risk management has as much to do with understanding capability as it does with arriving at a state of knowledge. Without that capability component, you'll never achieve a state of wisdom.

Or like the article that Arthur pointed to:

StanCorp manages all those risks in a host of ways, Chadee says, including "sound product design and underwriting; effective claims management; disciplined pricing; distribution expertise; broad diversification of risk by customer geography, industry, size, and occupation; maintenance of a strong financial position; maintenance of reinsurance and risk-pool arrangements...." You get the idea.

Then I've got a better word for it: business. Or, as Gunnar puts it, assets. Or, as Clive puts it, quality. So sure, it's a book about reliability from Daniels Geer & Conway, or marketing:

So security needs to be sold to the consumer business in the same way as quality. That is as a method of improving efficiency by increasing productivity of the work force and reducing cost.

However to do this the "ICT security staff" need to be able to make a business case to the organisational managment using the language that business managment use.

Or an MBA. In short, it's business.

Posted by iang at February 2, 2009 11:12 AM | TrackBack

Well said sir! (Though I must confess I didn't get the whole argument...)

The 'traditional' ability to run a business (any business!) required the ability to gauge risk in the face of incomplete data and take decisions (finger's crossed)... The guys who got this right were known as 'shrewd' businessmen...

Of course now it just needs a fancy degree and a lot of staff who churn out the necessary risk management/ business case studies that bear out the decsision made by the fearless leader based on 'our experience, some finger-in-the-air guesses, and a pocket calculator'...

If the models could predict the correct decisions to make, well then what would all the high-priced managers (note NOT businessmen) do? Oh wait...

Posted by: AC2 at February 3, 2009 05:02 AM


along the lines of "well, you have to talk dollar numbers to get funding, so you have to do it anyway, regardless of the utility of the model."

Posted by: Sprited Defence at February 17, 2009 08:47 AM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.