Business ownership involves risk. We all know that, but how much risk is too much risk? One's risk-tolerance is usually expressed, at least initially, as a
qualitative statement about what one's "gut" says; something like "moderate", or "limited". Arguably, such statements are about as useful as a milk-bucket under a bull. So, the
CISSP Common Body of Knowledge proposes a few
quantitative formulas to help us out. Introducing the "Single Loss Expectancy" (SLE) and the "Annualized Loss Expectancy" (ALE).
Simply put, the SLE is the potential cost of a single event, and the ALE is the cost of such an event spread across all the years between events. Such formulas appeal to the executive members of organizations because they give actual numbers that can be used in making "fact-based" decisions. So, the cost of a particular event is
$x, and the event can be reasonably expected to occur every
y years. Your ALE becomes
$x/
y. Nice. Clean. Simple. Now we know what our risk on that given event will cost, and we can factor its management into the budget. Or can we?
Risk Management generally applies one or more of four strategies: Avoidance, Acceptance, Transference, and/or Mitigation.
Avoidance means not doing whatever leads to the event in question. If the event is the loss of the entire executive team in a transportation accident, the risk can be avoided by not allowing the c-suite to travel at the same time. But if the risk is a breach of the computer network, deciding not to use networked computers may not be a viable solution.
Acceptance means what you would expect; yes, there's a risk to the c-suite all traveling together, we acknowledge that risk but will keep doing it. This is an informed decision, no action required.
Transference is making some other arrangement so that the risk is addressed in some other way. Buying what is known as
Key-man Insurance on the entire c-suite would transfer the risk of them all being lost at sea to the insurance company (though I doubt this would be practical). Finally,
mitigation is the handling of the risk. If the executive team never travel together, the risk of an empty c-suite due to a transportation accident is mitigated, though maybe not eliminated. Calculating the SLE of a particular threat is a natural part of the lead-up to a risk management plan. In order to determine a useful SLE however, one had better make sure the scope of the risk is adequately analysed.
As mentioned earlier, identifying the ALE is the process of determining how much a risk might cost over a given number of years. Common wisdom would say don't spend more than that amount trying to manage the risk. Furthermore, the more efficiently and effectively one can manage a risk, the better. The challenge however, is in accurately identifying all the composite parts of the risk event. Obviously, some risks have fewer moving parts than others. In the world of Cyber-security the knock on effects of an event can quickly become bigger than the event itself.
A case-in-point is the story of Danish hearing aid manufacturer Demant. On September 30th,
ZDNet published the story discussing how a ransomware attack on Demant has cost the company $95M in one month. According to the story, Demant announced their trouble on the third of September, and by the publication date had not yet fully recovered. To be fair, I wouldn't begin to suggest that I know all that took place in this story, and admit that I am comfortably playing armchair analyst. However, I will make a few observations here as a thought experiment with the aim to help my readers avoid similar situations.
Of the risk management strategies discussed earlier, there is no way that Demant, or any other organization, could "avoid" a ransomware attack. Doing so would require disconnecting their computers from the internet, and maybe even getting rid of them all together. There is also no reason to suspect that Demant just "accepted" the risk and went about their business with their collective heads in the sand. Quite the opposite in fact. The story makes a couple of key points that illustrate that Demant included in their risk management a transference strategy. This is shown in that they have a $14.6 million cyber insurance policy. That is double the $7.3M required to recover and rebuild their IT infrastructure.
 |
| Demant Stock History (www.demant.com) |
So if they had insurance for double the cost of their IT infrastructure, how did this event cost them $95M? According to the report, about half of that represents lost earnings, while the rest includes missed opportunity to implement a planned expansion. Demant seems to be a significant player in their field, and with stock prices still sitting at ~$25 per share, I would suspect they will rebound. But the question remains, how did this get so out of hand? Without inside knowledge, one is left to posit that the initial calculations of SLE did not take into account the amount of time it would take to restore the IT infrastructure and, by extension, the lost revenue during that time. I would also doubt that the individual calculating the SLE could have known that an expansion would be planned at the very time that the event occurred. It would be my guess that an assumption was made that new equipment would be bought, or existing equipment would be restored to factory defaults, and the back-ups would simply be applied. Done. Easy, right?
My grandfather used to say: "You don't get what you expect, you get what you inspect." While Demant can be credited for their implementation of a transference strategy, this story shows that transference is not necessarily enough. We can see that the risk from a ransomware attack could not be transferred to an insurance company because they only deal with the exchange of funds. In our earlier example, if the insurance company pays out the key-man policies, the company would still have to hire the replacements. Here, it would appear that though there were funds for the infrastructure, the restoration took significantly longer to execute than expected. This could be the result of corrupt back-up media, limited scope of back-ups, or any other number of failure points in the exercise. Unless one actually goes through the motions, and actually tries to restore from back-ups, one is rolling the dice. What would risk mitigation have looked like? Demant should have at least tested their ability to restore from back-ups. Or at an extreme, they could have had a complete segregated IT infrastructure sitting in the wings, ready to go at a moment's notice. While the setup of such an environment may have seemed cost prohibitive at the outset, the events that transpired over the past month show that greater mitigation was in fact warranted.
Photo credit: "Destiny" by Dave Gough (cc-by 2.0)
