What it means to be risk-driven

Since ISO27k is [information] risk-driven, poor quality risk management is a practical as well as a theoretical problem. 

In practical terms, misunderstanding the nature of [information] risk, particularly the ‘vulnerability’ aspect, leads to errors and omissions in the identification, analysis and hence treatment of [information] risks. The most common issue I see is people equating ‘lack of a control’ with ‘vulnerability’. To me, the presence or absence of a control is quite distinct from the vulnerability, in that vulnerability is an inherent weakness or flaw in something e.g. an IT system, an app, a process, a relationship, contract or whatever. Even controls have vulnerabilities, yet we tend to neglect the fact that controls aren’t perfect: they can and do fail in practice, with several information risk management implications. 

Think about it: when was the last time you seriously considered the possibility that a control might fail? Did you identify, evaluate and treat that secondary risk, in a systematic and formal manner … or did you simply get on with things informally? Have you ever done a risk analysis on your “key controls”? 

Do you actually know which of your organization’s controls are “key”, and why? 

That's a bigger ask than you may think. Try it and you'll soon find out, especially if you ask your colleagues for their inputs.

In theoretical terms, risk is all about possibilities and uncertainties i.e. probability. Using simplified models with defined values, it may be technically possible to calculate a precise probability for a given situation under laboratory conditions, but that doesn’t work so well in the real world which is more complex and variable, involving factors that are partially unknown and uncontrolled. We have the capability to model groups of events, populations of threat actors, types of incident etc. but accurately predicting specific events and individual items is much harder, verging on impossible in practice. So even extremely careful, painstaking risk analysis still doesn’t generate absolute certainty. It reduces the problem space to a smaller area (which is good!), but not to a pinpoint dot (such precision that we would know what we are dealing with, hence we can do precisely the right things). What’s more, ‘extremely careful’ and ‘painstaking’ implies slow and costly, hence the approach is generally infeasible for the kinds of real-world situations that concern us. Our risk management resources are finite, while the problem space is large and unbounded. The sky is awash with risk clouds, and they are all moving!

Complicating things still further, we are generally talking about ‘systems’ involving human beings (individuals and organizations, teams, gangs, cabals and so on), not [just] robots and deterministic machines. Worse, some of the humans are actively looking to find and exploit vulnerabilities, to break or bypass our lovely controls, to increase rather than decrease our risk. The real-world environment or situation within which information risks exist is not just inherently uncertain but, in part, hostile. 

So, in the face of all that complexity, there is obviously a desire/need to simplify things, to take short cuts, to make assumptions and guesses, to do the best we can with the information, time, tools and other resources at our disposal. We are forced to deal with priorities and pressures, some self-imposed and some imposed upon us. ISO27k attempts to deal with that by offering ‘good practices’ and ‘suggested controls’. One of the ‘good practices’ is to identify, evaluate and treat [information] risks systematically within the real-world context of an organization that has business objectives, priorities and constraints. We do the best we can, measure how well we’re doing, and seek to improve over time.

At the same time, despite the flaws, I believe risk management is better than specified lists of controls. The idea of a [cut down] list of information security controls for SMEs is not new e.g. “key controls” were specifically identified with little key icons in the initial version of BS7799 I think, or possibly the code of practice that preceded it. That approach was soon dropped because what is key to one organization may not be key to another, so instead today’s ISO27k standards promote the idea of each organization managing its own [information] risks. The same concerns apply to other lists of ‘recommended’ controls such as those produced by CIS, SANS, CSA and others, plus those required by PCI-DSS, privacy laws and other laws, regs and rulesets including various contracts and agreements. They are all (including ISO27k) well-meaning but inherently flawed. Better than nothing, but imperfect. Good practice, not best practice.

The difference is that ISO27k provides a sound governance framework to address the flaws systematically. It’s context-dependent, an adaptive rather than fixed model. I value that flexibility.