The FAIR method for assessing the magnitude of cybersecurity is described in detail in “Measuring and managing information risk: a FAIR approach”: Freund J and Jones J (2015). The method can be summarized in the following diagram:

*Figure 1**: The basic components of FAIR (numbers are referred to later in the text)*

In this article I will:

- Show you how to perform the FAIR quantitative risk analysis (using Excel + the ModelRisk add-in)
- Demonstrate why FAIR is in fact a very simple idea that is easily understood with a bowtie analysis

## 1. The risk analysis model

The simulation model that follows the FAIR methodology written in Excel is small and easy to understand. If you want to follow along, you can download a free trial copy of ModelRisk here, and download the example model here. I’ve used the same values as RiskLens does in their example to help you compare:

*Figure 2**: The FAIR-style spreadsheet model you can download*

The RiskLens approach described in Freund & Jones (2015) uses PERT distributions to represent uncertain variables. These are shown in the input table at the top, where the green cells can be changed. Column H in this table are random samples from the distributions. Click on a cell, then click on the View Function icon in the ModelRisk ribbon and an interface will pop up drawing the function.

The vulnerability calculation is the only unusual bit. It uses the VoseIntegrate function to calculate:

This is the probability that the threat capability (*TCap*) is greater than the Difficulty (*Diff*). These are rather esoteric terms I’ll explain at the end, but mathematically the formula is calculating the joint probability that *TCap* is at some value *x* and at the same time *Diff* is a lower value, and then summing these joint probabilities over all possible values of *x* (which by the definition of *TCap* and *Diff* is between 0 and 1).

To follow the rest, you just have to understand what a Poisson distribution and a Binomial distribution are, and how the VoseAggregate function is summing independent random variables.

The simulation results look like this:

*Figure 3**: Simulation results from the spreadsheet model*

On the left-hand side is a histogram of what is called the ‘annualized loss exposure’ (ALE). You can see from the model that this equates to a sort of annual average calculation. ALE should be a single value – the distribution does not actually mean anything because it is the result of multiplying samples from the distribution of *individual* losses (not the average loss) with samples of the uncertainty about expected rates of loss events. The only potentially useful part is the location of the mean (shown) which you could compare against the insurance premium one might pay to cover the potential loss.

However, the distribution on the right *does* mean something – it is the actual loss that might be experienced within the next year. It’s lumpy because you may have 0, 1, 2, … loss events. The dilemma is that the graph on the left means nothing but is easy to ‘understand’, whilst the graph on the right means something but is trickier.

[Note that you could duplicate the sheet in the model, put in data for other cyber risks, create an output cell that sums all these loss distributions and then run a simulation to see the aggregate loss distribution.]

## 2. A bowtie analysis of FAIR

The diagram of Figure 1 is intended to be read from the bottom upwards – on the left we estimate how often a cybersecurity breach occurs and on the right we estimate how much it will cost each time, so they come together at the top to give us a [Probability x Impact] kind of evaluation of the risk. The components make sense, but the order doesn’t. It is more logical to read the diagram clockwise from the bottom left because then it tells a story:

- Your system is attacked with a certain Threat Event Frequency
- There is some chance that your system is not sufficiently robust to overcome the attack
- 1 & 2 together determine how often your system is attacked successfully, i.e. the risk event occurs
- Now you start to experience losses. The primary loss comes from the direct cost of the disruption, etc. of the breach.
- But there may also be secondary losses like increased insurance premiums, regulatory fines, etc.

We can represent this sequence of scenarios more intuitively as a bowtie diagram which is read from left to right:

*Figure 4**: Bowtie representation of a FAIR risk*

With a bowtie analysis, the mystery of the FAIR ‘ontology’ is peeled away revealing a rather simplistic risk assessment. A more thorough cybersecurity risk assessment would consider multiple, ** explicit** controls to protect the system against the risk event ever happening, and the effect of mitigations to reduce any impacts should the risk event occur:

*Figure 5**: Bowtie representation of a single cybersecurity risk*

The risk can be quantified using probability modelling. The controls and mitigations are explicitly defined (e.g. maintenance of up-to-date antimalware software) so costs can be assigned to them (one-off, periodic, etc.) which then make it possible to evaluate the cost-benefit of each individual control. By explicitly defining controls, they can be shared across several risk management strategies which in turn allows the automatic assessment of the aggregate benefit of a control across several different cybersecurity risks.

Using a bowtie diagram one can also includes an activity monitoring component so one can see which controls are in place and working (green), which are overdue (orange), not working (red), under consideration (grey), and rejected as useful (black). It means that the bowtie shows at a glance the health of your cybersecurity risk management strategy.

Bowties offer a lot of extra capability too. For example, in Figure 5 one can see that there is a possible **reputational consequence** alongside the financial consequences. There could be others – particularly Strategic consequences, or health and safety consequences, which it is not easy or appropriate to convert to a monetary loss.

One risk event may make others possible in a chain reaction:

*Figure 6**: Bowtie representation of a chain of risks*

Some consequences (like a GDPR fine) may result from a number of different risks, so it is very helpful to be able to map and evaluate the aggregate probability. Conversely, a threat actor might enter a computer system leading to a range of risk events – from destroying data to altering them to making them public or selling to a competitor. Ideally one should be able to map all these types of interactions:

*Figure 7**: Bowtie mapping from either threat (left) or consequence (right)*

When evaluated as a complete system, it is then possible using automated Monte Carlo algorithms to view the exposure to the whole enterprise:

*Figure 8**: a top risks report for the NetGrid entity. Each dot represents a possible consequence that arises from cybersecurity risk*

*Figure 9**: the aggregate loss distribution for the Netgrid entity, where all potential losses are from cybersecurity risk*

## 3. Summary

At its heart, the FAIR methodology is an application and simplification of the Loss Distribution Approach (LDA) that has been used in operational risk analysis in the banking world very widely for many years. It is unnecessary to give branded names to each component of a modelling approach known to every actuary and call it an ‘ontology’.

FAIR started off as an attempt to get people to move towards a more quantitative, rationally-based approach to evaluating cybersecurity risk – which was good. It applied some discipline to the factors that should be considered – frequency of loss attacks, consideration of whether an attack would succeed, and the distribution of losses (first and second level) that would result – which was also good.

But it also wrapped the ideas up into what it called an ‘ontology’ that separated FAIR from other types of risk analysis and turned it into a marketing tool for CXOWARE which became RiskLens, which then morphed from a marketing tool to an industry standard. The ‘ontology’ makes the whole risk assessment process more of a recipe (necessary if one is selling a software tool in which one fills in template forms) than a tool to help one think – and that isn’t good.

The Vulnerability concept is far too abstract in my view. For example, the scale changes – what was extremely difficult to crack five years ago and would score 95% is probably easy compared to what we would score as 95% today. There must also be a different scale from one type of security system to another. There is no way of measuring or calibrating the estimates of *TCap* and *Diff*, so the vulnerability estimate cannot be validated whereas a simple probability estimate for *Vuln* could be.

But the real Achilles’ heel of the FAIR process is that the FAIR ‘ontology’ creates an artificial separation between cybersecurity and other types of enterprise risk. Turning to a bowtie viewpoint, we see that all risk consequences from strategic to health and safety, financial to cybersecurity form part of a larger whole ** that can be evaluated using the same methods**. Understanding this allows us to figure out where the most threatening risks really lie and to apportion resources in the most efficient manner possible to deal with them – which is the proper goal of risk management.

## About Pelican

Screencaps of bowties and dashboards are taken from Pelican, the ERM system from Vose Software. Pelican is a fully-quantitative, web-based enterprise risk management system from Vose Software. You can request a demo here.