Talking about risk

The information security business is a bit like the world of 1970s French movies. At the time, these films had a reputation for being racy, of containing a lot of delicious naughtiness that was nevertheless somehow culturally uplifting. When you actually sat through them you found there was a lot of talking and very little action.

In the infosec domain I hear a lot about risk. Companies understand risk - or at least, go to great trouble to convince themselves they do. They have risk managers, risk metrics, godzillabytes of data measuring, delineating and analysing their risk posture so that they can decide on their risk appetite.

Of course, it all turns to shit the second they get to their IT systems. When it comes to the risk of flood, fire, market downturns or zombie invasions, risk managers can show you graphs and tables that would convince anyone the firm is doing all it can reasonably be expected to do. With IT, well, it’s anybody’s guess, right?

There are some attempts at improving this situation with IT. The Common Vulnerability Scoring System (CVSS), for example, is one effort to put a number against some of the risks firms face with their technology. But understanding how much danger you actually face as a result of, say, the software you have installed is very tricky.

It’s not that people don’t want to understand this stuff - they just don’t know how and, even if they did, might not want to expend the necessary money and effort.

I wrote a piece on software insecurity for a Guardian supplement recently and the one refrain I heard over and over from the experts I talked to is that enterprises aren’t looking at their software infrastructure from a risk perspective. 

Small wonder: analysing vulnerabilities in software is hard enough. People like OWASP are doing great work in trying to get developers and the people who pay them to make security an intrinsic part of the development process, but firms don’t want to pay for the extra effort needed and don’t like what it does to schedules. They want their software now. And as for existing code, yes you can run some automated pentests against it, but how much is that really going to tell you? Analysing vulnerabilities in existing code takes considerable skill - read: money.

And, of course, knowing that vulnerabilities exist is one thing. Analysing that in terms of risk is another.

Then there’s another worrying aspect to all this. Even if you can understand your vulnerabilities and can translate that into a meaningful risk metric, is that going to do any good?

When enterprises do all this risk analysis, are they really tasking themselves with fixing the problems? Or are they merely concerned with covering their asses when it comes to due diligence and compliance?

“Oh yes, we got hacked and all our customers’ information is now in the hands of heartless cyber-criminals. But not to worry: according to the regulatory requirements we did everything we could be expected to do given the risk.”

I’d like to suggest an addition to regulatory requirements. If you’re the CEO of an enterprise that is hacked using standard Metasploit modules or basic SQL injections, you go straight to jail.