The Risk Management Lie

Rumors of information security evolving as a process and an industry is really a mixed bag. On one hand, I’ve seen first hand the benefits of improved governance. This helps to ensure people can’t make adhoc changes to production environments and should those environments change outside of authorised change windows and there is no corresponding change record, the change was unauthorised.

On the other hand we still don’t track risks well. We don’t REALLY understand them. We don’t classify them well. And for those who are able to do this even partially well, their Excel spreadsheets fall far short of the capability of tracking chained exploits and how can lead an enterprise to ruin.

The models we use to track IT security risks are – to my thinking – like soothsaying. It reminds me of witches from centuries past, sacrificing chickens and casting bones in an attempt to augury the future. For all our metrics, for all our “likelikood x impact = risk” crap, we may as well be doing the same.

Is it wrong to use these methods? Well, no. At the end of the day, something is better than nothing. If these methods at least give the organisation you’re working with some sort of awareness of the risk you are taking onboard by choosing not to remediate a finding, then that is a good thing.  Not undertaking a risk assessment is like making a call not to bother getting your car serviced since you were overdue three months ago and the car is still running fine now. Sure, it might SEEM fine, but that’s until the wheels fall off (so to speak).

Three issues I see as being critical to the failure of risk management as a discipline (specific to information security):

1) Inability to track and measure vulnerabilities which can be chained

The lack of organisations to full understand chained exploits and how they can be exploited (and even security professionals might easily miss how someone is able to chain them too I might add) is one of the greatest limiting factor of risk management.

We can talk about a missing patch or an exposed, vulnerable application and explain what is the business impact if that is compromised. What we can’t do well is look at all the other vulnerabilities in the environment and suggest methods how or why that singular event could be triggered by other risks inherent to the environment.

2) Inability to accurately define and measure TRUE risk

I’ve seen discussions over which risk management method is better. I’ve seen FAIR advocates. I’ve seen ORM described as the defacto standard (Ostrich Risk Management for the uninitiated). At the end of the day its all the same. We really don’t know. Risk management is really the art of sticking your finger in the air, applying models that do not translate well to IT risks and taking a quasi-intelligent guess at the risk.

This isn’t a field like say the incident of cancer or natural disasters are tracked for insurance purposes. We don’t know how often SQL injection is exploited globally on a per IP address basis. We have even less data to narrow the field of inquiry down to a geographic region, let alone how often we see a singular enterprise being hit (if you’re one of the few organisations that do track this sort of data, you have my respect). What about risk impact? When someone asks you what is the likelihood that SQL injection will occur on a given server, what are you referring to? The fact that someone uses SQL injection to copy the data and onsell it? Tamper it and hope you won’t notice? Trash the server? Or use it as a bastion host to conduct further attacks? Do you draw up risk assessment for each scenario or only one? Each example given has a highly variable risk, depending on the business purpose of the application that relies on said database. Some organisations (e.g. agencies within government/military) may rely heavily on confidentiality. Others may rely on availability (e.g. banking). Others yet again, integrity (e.g. universities).

3) Ongoing treatment and management of risks

Ultimately I see very little organisations and businesses can do to address the first two points, apart from being aware of the inherent limitations of risk assessment we use today and try to keep an open mind with them. This third point is something you can all do today.

In many instances I’ve seen, risks are often stuffed into spreadsheets with signatures and never again touched. Hey the business accepted the risk – it’s a done deal, right? Well no, not exactly.

Risks can change. You need to review them. In the course of a year the environment may have changed radically. Or perhaps even superficially, but in either case, enough to introduce new risks which could alter the original risk score. This is where an opportunity exists to better understand how chained risks can be introduced into your environment.

Sometimes, all we can do is go back and review the risks that have been formally accepted. If you can go back and see there is a series of risks that could be chained, use those to propel your security program. If you need to, develop a proof of concept. Show the business what these risks can mean to their business and how they can be exploited. Explain who would want to target them that way and why – particularly if the risk warrants it. You don’t want to take this approach with every risk, but if you see that chaining presents a greater aggregate risk than whats on your spreadsheet, then you have an obligation to speak up.

Overall, I wish I had a solution to risk management in an infosec world – but I don’t. I don’t like how the process is governed by auditors who see each vulnerability as a discrete risk without any perspective of the larger whole. All we can do is point out these limitations and try to work with them.

In closing –

Don’t accept risk management will solve your problems. You still need to find the problems first. You still need to understand them, capture them and take ownership of them. Even then, you still need to be mindful that you may have overestimated or underestimated the scope of the problem. And this is why you need to constantly review them.

- J.