Risk Versus Severity When In A Panic

Risk isn’t the only thing to consider when planning a decision tree.

Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .

During tuning, we’re sometimes asked, as we help our MSSP Clients establish a detailed decision tree (modify our default to their own situation), “are these based on risk?”

The answer is, simply, no.

No?

You like our Clients may find this answer surprising, because after all, we are a Technology Risk Management Company that happens to watch networks.  Ask us any question, and we seem to twist the answer to be around the subject of risk.  Heck, ask me what time it is, and I’ll reply with the risk of the clock not being on time. (Because there is a substantial likelihood.  After all, it has happened to me twice in the past  year.  The severity may not be that great, for this particular grandfather clock is not used during business, but the likelihood on a scale of 1 to . . . . you get the point.)

But we can’t prioritize incident response at the detection level by risk.  The reason is because risk looks at severity COMBINED with likelihood COMBINED with volume¹.  But when we see something in the network traffic or event logs . . . when we see actions that MAY indicate certain behaviors, the likelihood is already a ten on a scale of one to ten, even if the “risk rating” may see the likelihood as a 4, or a 5.

Thus, we prioritize incidents . . . at the network monitoring RE-ACTIVE level, by severity.  Your risk assessments should still consider likelihood and volume, but know that we are in place as a backstop for those incidents that we always thought would be low likelihood.

I like to use the BP Gulf Disaster as an example of a black swan incident.  Nobody believed an oil rig could blow up.  But it did.  You should see your MSSP as being the fire station, ambulance, and hospital that has been built on a floating platform, right in the midst of the oil rigs.  They are there IN CASE SOMETHING HAPPENS.  But we should still try to prevent that something from happening (ahem, awareness training is 9/11’s of the battle.)

¹ Possibly combined with control, if you are measuring risk related to cloud applications.  See what we mean about being a Technology Risk Management company?

Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”