I just noticed (yes, I’m a bit slow) that about six months ago the OWASP project put up a page on risk rating. I’ve reviewed it and find it quiet usable for many organizations. Of course, it requires some customization, but it is much more applicable to corporate application environments that what is currently available.

In early 2006 while at my previous employer we spent many long hours attempting to create a somewhat more realistic approach to communicating risk. Many (read: most) of the methods available at the time were vendor-centric. They were not usable in corporate environments without a great deal of tweaking and by that time it didn’t look at all like the original method. The problem was that the metrics used by many of these methods artificially inflated the results. Everything turned out to be a high risk. Yes, some things were high risk, but not everything. The reality is that you have to have a sane risk rating system so that the truly high risks actually get fixed. If everything is high risk, then nothing is high risk and no real work will get done.

Anyways, we came up with something a bit similar to what OWASP has done. We took it a bit further and developed about nine, I think, characteristics of a vulnerability that could each receive a rating of 1, 2 or 3. We struggled with the subjectivity of Risk = Likelihood x Impact. To curb the subjectivity we had to identify what elements contributed to making a vulnerability more likely to be exploited. Before this method, it was simply an educated guess that produced a number usually between 1 and 10. While each of the characteristics are still determined by this educated guess, the collection of metrics provides a more balanced result. Breaking the vulnerability’s likelihood into discrete characteristics allows the guesser to treat the elements uniquely and realistically. During our QA sessions with the method we saw many high risk vulnerabilities move to medium risk. The simplistic, single number metric of the old method loads in too many assumptions to be useful.

During the development of our method we found that in a corporate environment there were enough differences between off-the-shelf applications and in-house applications that some of the characteristics did not make sense in both contexts. Having a sane risk rating process is nice too, because developers and architects can also play the game too. Since the characteristics are mostly intelligible it is easy to sit in a room with the project team and rate the identified vulnerabilities together. So, in short, if you don’t have the time like we were fortunate enough to have, use what the OWASP project has provide. If you do have time, trust me here, use the OWASP project’s work and build from there.