Risk Management – it’s not FAIR!

Why is risk management so unfair or should I say not FAIR? No this is not a childish protestation; I want to talk about FAIR (Factor Analysis of Information risk) and why it isn’t more widely adopted. Other risk analysis methods commonly used are ISO 27005, OCTAVE and NIST RMF. Of these FAIR is the only truly quantitative approach to Cyber Risk Quantification (CRQ) risk and yet according to the FAIR Institute, citing a Gartner survey, 80% of respondents relied upon ‘Estimates of Likelihood and Impact in Terms of Ordinal Scales’ (e.g. 3x3 or 5x5 scoring for likelihood and impact).

However, risk assessors frequently speak of the same recurring issues; business owners resisting accountability, disagreement on categories (e.g. impact and likelihood), difficulty communicating technical risks / threats to business stakeholders and difficulty estimating a defensible business impact. 

These problems are directly related to the lack of rigour defining metrics that exists in qualitative methods. In addition, without clear figures to justify the results qualitative risk assessors may introduce bias through the use of security jargon which can induce a sense of FUD (fear, uncertainty and doubt) in an unsuspecting risk owner. Now of course, no GRC pro would admit that they want to scare an executive into a risk reduction decision, but I do think wanting to make an impact and deliver work that drives change can be examples of bias that can find its way into less rigorous analysis methods.

Instead, FAIR advocates a structured, estimation of risk using measurable factors with a clearly defined ontology (relationship to each other). Assessors are able to provide far more detail than the High, Medium and Low categories familiar in qualitative assessments instead detailing minimum, maximum and most likely figures for loss impact (in monetary values) and annualised loss event frequency.

This sounds simple but it’s not. Regardless, the benefits to executive communication and decision making cannot be overstated. Instead of vague (and often inappropriate categories), executives are armed with monetary figures which can justify risk-based funding for projects or even departmental budgets. After all, all security budgets are risk decisions. After running the FAIR factors through a computational model (Monte Carlo simulation), assessors can present results to executives who are then armed with data to make informed, defensible decisions with monetary and probability figures in hand. Just as importantly, by following the methodology risk teams are able to scope assessments to well defined risk scenarios, document assumptions, justify figures and provide clarity on the level or precision.

Given its power you’d think GRC leaders would recognise how FAIR could be the engine of infosec strategy, ensuring information security functions are visibly supporting risk reduction using the language executives understand - money. Reading LinkedIn posts you can be left with the impression that some organisations request budget based on technology projects or latest threat intel ever without communicating risk in real terms – the probability of a loss event. My view is that if leveraged to assess organisational cyber risk FAIR can enable security functions to demonstrate in clear financial terms, how their efforts are protecting the business. Instead, risk assessment is often relegated to being little more than an IT change management function; reviewing ad hoc vendor engagements or IT projects as a service to the business.

So it raises the question why there isn’t greater adoption of the FAIR approach and specifically why GRC functions don’t leverage it to raise the bar for information security governance.  There are a number of operational reasons which inhibit FAIR adoption. Firstly, although the FAIR approach supports data transparency when it comes to uncertainty, there’s still a reliance on obtaining data where possible from subject matter experts in other departments. In my experience, enquiries of this nature may not always be well received. It can create a cascade of work as various departments try to find usable data to inform the risk assessment leading to every CISO’s nemesis – a reputation for slowing down the business. It’s very much dependent on the culture of the organisation and although a ‘help me, help you’ case could be made, it may still represent a significant cultural shift.

In addition, there’s no doubt FAIR requires more training and expertise than qualitative methods. I’ve always had the view that GRC professionals need a solid technical background to effectively advise on compliance and risk in real IT environments. That point stands, but with FAIR, assessors require far more in depth training on the methodology itself compared to the likes of ISO 27005. Training can be difficult to justify for a methodology which is new to an organisation and which may take time to mature and prove its worth.

It’s not just a skills issue for the assessor, FAIR is far more complex than the likes of ISO 27005. Its complexity is a byproduct of its intellectual rigour and specificity. However, that comes at a cost. The output of assessment includes new terminology and doesn’t make it easy to position to executives who may have grown accustomed to 5 x 5 heatmaps and all the qualitative terminology that go along with them.

My view is that, like many areas of information security you have to move at the pace of the businesses. FAIR can’t be imposed, it can only be suggested if it solves a problem. If executives are complaining that they’re not armed with data to make informed decisions, that’s a cue. Conversely if executives are content and familiar with qualitative approaches and they’re able to make effective decisions (including spending where necessary), then there’s no need to fix what isn’t broken. However, if your unfamiliar with FAIR then I’d recommend familiarising yourself with it so that you’re ready when the right opportunities present themselves. In particular I would urge GRC leaders to consider the FAIR  approach to support budget requests for project / department budgets to enable information security to clearly illustrate its value to the business.