One of the common problems I find with risk assessment isn't due to the weaknesses inherent in any particular risk analysis method. The main problem stems from a failure to clearly articulate the risk. But rather than just complaining, here is my proposed solution.
How to write a risk statement
First, don't pluck something scary out of the air and give it a single word or short phrase. "Terrorism" or "War on terror" or "Immigrants are rapists." That may sell newspapers or get politicians elected but it won't help with risk analysis.
Even writing "Cybersecurity" or "The risk of being hacked via a Phishing attack" isn't overly helpful. I was once asked to facilitate a risk workshop for a $100 million IT security project that had been going for several years. I was told that there was a mature risk register but they just needed someone to facilitate a review as the stakeholders were having trouble agreeing on the risks.
When I got there and had my first look at the risk register, my heart sank. It was immediately obvious not only why they were having trouble agreeing on the risk ratings, but also that they would never attain any agreement. The 'register' was an Excel spreadsheet with 300 line items on it. Most of them were one word or a few words long. For example, they included: cost, capability, funding shortfall, lack of resources.
After a fruitless two hour workshop, I suggested to my client that I take the risk register away, aggregate the similar risks, and massage the risk statement into something more specific so that we could reconvene the workshop a week later. Which we did with great success. And CASE is the tool that I used to redefine their risks. So, what is CASE? And why has it evolved to SERCL and REVCOS? Read on.
Tip:
When you're running a risk identification I suggest you provide a short presentation beforehand to explain the CASE methodology, your risk assessment process (eg: ISO31000), and work the stakeholders through a few examples. It will head off a lot of questions and unnecessary debate.
But first to identify the problem
Consider the challenges faced by stakeholders in trying to agree on risk ratings and risk treatments if they want to manage the risk of “Terrorism”. It sounds like a real risk. But in practical terms it’s meaningless.
Everyone has their own concept about what terrorism means so asking a group of 10 people to rate it or treat it is likely to result in 10 different ratings and even more treatments. To achieve a degree of consistency you must at the very least be specific about what type of terrorism you are concerned about before you can hope to assess, much less mitigate it. Let me illustrate by asking you to consider the ‘terrorism’ risks in the following examples:
Religious fundamentalists seeking to inflict maximum loss of life to gain international publicity and leverage for their cause with no fear of sacrificing their own lives?
Environmental activists in inflatable boats seeking maximum media attention through minor acts of sabotage with minimum personal risk and no loss of life?
Local right-wing thugs seeking to incite fear by committing assaults and arson on properties owned by immigrants?
Sarin attacks in the subway by religious sects with unstated objectives?
As you can see from the above examples, the so-called risk of ‘Terrorism’ can actually be multiple different risks with correspondingly different likelihood and consequences.
CASE
So how do we do actually record risk in a way that everyone can reach some sort of agreement on its severity or at least relative priority? There are countless ways to describe risks but the most consistent way I know is to use a method that I call ‘CASE’. The acronym or C.A.S.E. has grown from the need to consider at least the following four characteristics when analyzing a risk:
Consequence – what is the likely impact of this risk?
Asset – what asset(s) are actually at risk?
Source – what are the hazards or threat actors that might lead to the risk manifesting?
Event – what particular type of incident is being considered?
Why do you need these four items to define a risk statement? Consider if you will, the risks of “terrorism”, “climate change” or “compromise of sensitive information”. Each of these are actually multiple risks. It is very difficult if not impossible to analyze and rate these risks if we only have the event and the asset. Or, more particularly it is impossible to achieve consensus on the risks involved because everyone will have their own perception of what ‘terrorism’ or ‘climate change’ means.
By way of example, let’s have a look at the risk “compromise of sensitive information”. It is very difficult to analyze and rate this risk if we only have the event and the asset listed. Consider the different consequences if your organizations information was compromised by:
industrial espionage by competitors
theft by criminals seeking to sell it back to you
espionage by foreign intelligence services
attack by amateur hacker
attack by professional hackers
security access errors by computer user(s)
theft of a briefcase from a car by petty criminals
staff inadvertently releasing sensitive information to the corporate website
premature distribution of a media release
accidental emailing of a sensitive document to the wrong party
Some examples
So how do we do actually record risk in a way that everyone can reach some sort of agreement on its severity or at least relative priority? Here are some examples using the CASE approach:
Failure to protect information (Asset) in transit from theft (Event) by opportunistic criminal elements (Source) resulting in adverse impact on reputation (Consequence).
Compromise of sensitive information (Asset) due to untrained (Source) staff inadvertently posting incorrect files (Event) to the corporate website resulting in a competitive disadvantage, reputation damage or financial loss (Consequence).
Financial loss (Consequence) due to espionage (Event) by competitors (Source) resulting in reduced profits (Asset).
Financial loss (Consequence) associated with the collapse of international property development portfolio (Asset) due to foreign currency fluctuations (Event) as a result of global financial crisis (Source).
These are much easier (and very different) risks to assess using a simple risk matrix and are much easier to define specific countermeasures for. The same structure can be used to describe positive risks:
The business case analysis shows a potential NPV of $1.2 million (Consequence) financial benefit (Asset) if we tender (Event) the facilities management contract in the open market (Source) this year.
Market analysis indicates that opening a branch office (Event) in the European market (Source) has potential to increase profits (Asset) next year by 25% (Consequence).
The internet (Source) marketing campaign (Event) is expected to deliver a 30% (Consequence) return on equity (Asset) within two years.
Another great use for CASE
You can use for CASE is to evaluate someone else’s risk assessment, by testing the quality of risks identified against the CASE criteria. You’ll be able to spot and point out any flawed risk descriptions or shoddy analysis at a speed that will be the envy of your colleagues.
SERCL
SERCL is an evolution of CASE which reflects the use of the word 'resources' rather than 'assets' in ISO31000:2018 Risk Management Standard plus the addition of likelihood as part of the consideration. It is basically the same thing as CASE, just updated to align with ISO31000:2018.
SERCL is an acronym for:
Source(s): Relevant source(s) of risk.
Event: The single key event that might be evident if this threat occurs.
Resource(s): Resources or assets likely to be targeted or impacted.
Consequence(s): Likely effect on Resources and/or Objectives.
Likelihood: The probability that the event will occur.
It may be useful in many circumstances to consider them in the following order:
Resources/Assets at risk
Sources of risk
Events which might occur
Likelihood of attack / event
Consequences (effect on objectives)
Not all sources of risk will involve every resource or risk event, e.g. hackers are unlikely to steal a building; but developing a list for each of S, E, & R then adding likely consequences is a good start.
The following graphic highlights how the five elements of SERCL fit within the ISO31000 Process.
CASE and SERCL are just two ways of identifying risks. Use what works for you but make sure you have a clear risk statement that means the same thing to every stakeholder (yeah, I know; easier said than done) before you even attempt to analyze or prioritize the risks.
I also mentioned REVSCO earlier in the article. It's something I'm working on and I'll post it here as soon as I've got a coherent version of it.
Here's a taster example of my attempt to build a nice causal chain that surpasses CASE via REVSCO.
Loss of availability of information (RESOURCE) due to phishing attack (EVENT) on unpatched vulnerability (VULNERABILITY) by Foreign Intelligence Service (SOURCE) on our network resulting in downtime (CONSEQUENCE) with loss of profits (OBJECTIVES).
But first, I have a book and a website to finish. :-)
Comments