When you've been in the security business as long as I have, you see lots of cycles and become a firm believer in the pendulum. For a long time, security was the "cool kid" in class. Everyone wanted to be its friend; the venture capitalists were throwing money at the market and new-fangled "security officers" were the new power brokers in IT land.
Then CFOs started questioning all this "investment" in security. CEOs wondered why their companies weren't more secure now than five years ago. If anything, they felt less secure. We, as an industry, became enamored with the technology and forgot to focus on how security affects the organization. Ultimately any impact we have as security professionals has to be about money: we either make money or we spend money..
Now the pendulum is swinging toward risk. We don't focus on eliminating vulnerabilities or threats; we are all about mitigating risk. Why? Because risk is an economic metric, and as I mentioned before, to executives, it's all about the money.
The CFO and other moneymen (and women) justifiably want to see quantification. We say we have "reduced" risk, but what exactly does that mean? How do you speak the language of risk? Ultimately it gets back to perhaps the hardest thing we as security and risk professionals need to do, and that's to quantify what we do.
Traditionally, the risk equation was "Risk = Loss * Threat * Frequency" where:
Some risk modelers maintain that it makes sense to assess the risk on key assets and work to reduce the threat or the frequency of the attack happening. A number of frameworks have been built to help model and quantify risk, including OCTAVE and FAIR:
However, spending considerable resources to build a risk model may not be the best use of an organization's time. The reality is that nearly all risk-modeling approaches force you to make estimates based on assumptions that are in turn based on estimates. It's kind of like building a hotel in a swamp. You n
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
eed to understand the numbers are just numbers. Seriously, the risk number could be 42 or it could be 142,000, it doesn't matter. What matters is that is whether the security organization can track a consistently derived metric and show improvement over time. There is no real precision in a risk quantification; it's all about measuring the relative risk.
A lot of risk bigots believe that it is possible to gather enough data to get a good feel for frequency and threat numbers. They figure the insurance guys do it, so why not us? Actuaries know that I'll get into 3.7 car accidents over my lifetime based on where I drive, what kind of car I have and my general demographics. Security pros, however, just don't have that level of data, nor is it cost effective to try to gather it.
The real point here is that risk is a means to an end. The focus should be on why you are actually calculating your risk. Is it to get money for new initiatives? Is it to set a baseline that the organization can manage against? I recommend doing the least amount of modeling in order to achieve your goals and then get on with things. Calculating risk to the Nth degree doesn't keep attackers at bay.
What security managers should strive to do is get a relative idea of the risk to each major business system that keeps the business operating. And any kind of security person worth his or her salt should already know what major systems are most important and what the potential risks to those systems are.
Thus the risk model provides the security group and management alike a common metaphor to discuss the investments needed to avoid the risks. Period. Talk in business terms, saying, "If we make the following investment, we can reduce the likelihood of a bunch of bad stuff." The executives will scrutinize your numbers and if they believe you, then you'll get the money.
Do not, however, fall into the trap of thinking that risk management and quantification is a silver bullet to solve any of your ills. It allows security to be discussed in a language management understands, and there is definite value there. But we as security professionals are still on the hook to get our jobs done, and no risk score is going to help us do that.
About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com's expert-in-residence on information security management. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via email at mike.rothman (at) securityincite (dot) com.
