Financial Cryptography

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:

3. 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