There is risk attached to everything that we do. In most everyday situations we attach a value to risk using instinct and judgement based on experience. In business we need to be more precise: we can make judgments based on instinct but when there are the interests of customers and bottom line revenue at stake it’s much better to have a more scientific process.
First, and more importantly we need to ensure that we have identified the risks most applicable to us. Leo Cronin, Reed Elsevier’s Chief Information Security Officer, makes the point that “choosing risks appropriate to the target audience is a key to success.” (see this article from Cybertrust on Justifying Security Spending) . While this is true for ensuring that we can make a good case for justifying where we spend our security dollars it is also essential for building a model on which to perform our analysis that contains relevant risks. Risk is most often expressed as the product of threat multiplied by vulnerability, but for business purposes we bring in additional cost factors. So, even if the vulnerability and the threat can be rated as high, if there is no associated cost then it’s not a risk worth investing our resources in.
Cost is itself the product of three seperate values: operational costs (how much will it cost to fix), reputational cost (how much impact will the event have on our repuation), and revenue cost (bottom line loss of revenue).
The method we use for assessing risk is to consider the various scenarios that might result in the occurance of a particular bad outcome. For example, one particular bad outcome is that of a web product defacement. If the web server is not correctly configured then a scenario to consider is that of an attacker using the mis-configured server to alter web content. It is then possible to rate each of the threat, vulnerability, and potential costs associated with such an event. The resulting risk value is likely to be different for each web product that you consider and policy should take into account different risk profiles.
This is a rather high level description of the processes I use within my role. Many organisations will, of course, not be dealing with hundreds of different web products but be reliant upon one or two of significance. The same principles apply – consider risk in terms of event costs rather than just the likelihood of something happening – but most importantly do consider risk by documenting and discussing scenarios as opposed to making judgements based on instinct.
Finally I shall refer you back to some remarks I made in an earlier blog regarding training and certification and my impending award of a masters degree. I have in fact passed and am now, officially, Stuart King MBA (Tech Mgmt).