In general, risk tends to be hard to quantify. Before I jump into the million or so things you could quantify, it's important to understand a bit about risk, especially within the context of security. Back in my TruSecure (now CyberTrust) days, CTO Peter Tippett defined risk via a simple equation:
Risk = Threat x Vulnerability x Cost
Threat is the frequency of adverse events. Vulnerability is the likelihood that a particular attack will be successful, and cost is the total economic impact of a successful attack. A lot of folks have different ways to quantify risk -- investors, actuaries and security professionals all have different opinions -- but this definition is sufficiently simple for a rock head like me, so let's go with it.
You need to quantify your security environment (which is threats and vulnerabilities) and then calculate the cost to derive your risk exposure. In reality, you can spend a lifetime trying to build a sophisticated, PhD-level model and still be wrong. Basically, you are making assumptions on top of assumptions on top of assumptions.
I'm a fan of simplicity, and I suggest folks take a more qualitative approach to quantifying anything related to security. Much of this is laid out in my book, The Pragmatic CSO, but here is the abridged version.
To start, figure out what's important, focusing on cost. What business systems are most critical to your organization? Who uses them? What is their time worth? Once you have an idea of the most critical systems, then figure out the most likely threats to those systems. Are they vulnerable to cross-site scripting attacks? Or a brute force DDoS assault? Use these findings to develop a realistic estimate of how likely it is that such attacks, if successful, could take down those critical systems.
Ultimately, try to establish if it makes sense to implement a new process or install a new product, and figure out which knobs that specific product will affect. Will installing a Web application firewall reduce the likelihood of a XSS attack on your critical application? If yes, to what degree? Take a guess. Will that affect the frequency of the attack? (Nope. The only way to do that is to take the system offline, so that number stays the same in this case.) This approach will allow you to get an "apples-to-apples" comparison of different options and figure out what will yield the greatest reduction in risk.
I am not a big fan of simply counting things. The taxonomy I described will allow you to weigh certain decisions against others by using the only metric that's important: the risk to your critical business systems.
