Chief Security Officers face a challenging quandary at budget-time because the traditional return on investment (ROI) model falls apart when it is applied to security products — but as that is the only language budget-approvers speak, what is a CSO to do?
As Chief Security Officers gather in California for the RSA Security Conference this week, one of the challenges they will face is how to justify purchasing the latest and greatest security products they see. This is because the traditional return-on-investment (ROI) model falls apart when applied to security, and as ROI is the only language budget-approvers speak, what is a CSO to do?
Groups with opposing concerns surround the CSO. There are users that demand uninhibited access to IT resources, new regulators expecting tighter controls of data, and boardroom peers who will only rubber-stamp projects for which a return on their investment is proven.
"The challenge is that ROI calculations usually depend on the quantified predicted benefits of the outcome," agrees IBRS security analyst James Turner.
"This is challenging enough for most IT projects because they can all suffer from garbage input resulting in garbage output. But with security products this gets flipped through ninety degrees as we start to look at all the bad things that should be prevented.
In one corner — the users
Users are demanding uninhibited access to Web 2.0 and 'in the cloud' applications plus remote access to internal systems. This access is not seen as a luxury but rather as the means to remain competitive.
"It is no longer acceptable for a security professional to prevent the adoption of these technologies in the interest of mitigating exposure," says Wayne Neich, country manager for security vendor Blue Coat.
In the opposite corner — the CFO
While the surface area to secure is widening, the financial means to lock it down is getting harder to attain.
In most large organisations, access to budget depends largely on a demonstrated return on investment for a given project. But IT security investments don't satisfy the ROI equation because most tend to be preventative measures.
"So it isn't even good things happening, it's bad things not happening. It starts to sound like IT is trying to sell insurance, or some sort of weird leasing plan with a funeral home asking 'who will take care of your loved ones?'"
A risk-based ROI model The prevailing attitude towards Schneier's theory from within the ranks of the security industry is that ROI calculations are "extremely difficult but not always impossible."
For the sake of simplicity, IT security projects can be seen in two flavours — the first group being those that enable a new business proposition — those with a potential for "hard dollar" returns.
ROI can be measured, for example, on a project that enables a more efficient business process. An authentication system that allows customers to complete self-service functions, eliminating queues at the help desk and thus requiring less staff, would have such a potential.
The other, far more common IT security implementation is for "insurance" technologies — those that are preventative by nature and only provide "soft dollar" returns. The costs of the project are easy to calculate, the returns not so.
Mark Pullen, country manager for security vendor RSA, says nine out of ten security projects fall into this category — be it measures to protect confidential data from leaking out of the company, or viruses and hackers from gaining access from the outside.
Such projects require the CSO to express the ROI in risk management terms, whilst still coming out the other side with a dollar figure.
Typically, the calculation would first involve the identification of information asset such as data, services and infrastructure. One then needs to identify threats and vulnerabilities against those assets.
A threat is anything that causes an unwanted outcome — be it a Web site defacement, the leak of confidential data from a financial application or even a lawsuit. A vulnerability is the absence of the right security to protect a particular asset.
Third, one needs to create a metric that best values those assets. This might be a classification as simple as low, medium and high risk.
In order to produce a figure at the end of the process, this metric may inevitably need to be expressed in dollars. It's here that things get complicated. How much is a customer database worth?
Even with that question answered, one needs next to calculate the cost of an unwanted event occurring. To do this, the asset's value is multiplied by its exposure factor — the proportion of the value of an asset that would be lost in the case of an event — to gain a 'single loss expectancy'.
Flawed as it may be when it comes to security projects, the ROI model is the only one acceptable to executives in control of the purse strings.
In both of the last two steps, inputs and subsequently outputs can vary wildly. There is some guesswork involved. How much is the sensitive financial data of a publicly listed company's CFO worth, should it be leaked to the market prematurely? What affect would it have on the share price? Might the company be fined? The calculation needs to take into account not just the value of the asset, but the cost of fixing the problem after the event and other longer lasting impacts.
If a laptop with sensitive company data is stolen, for example, the cost of the physical asset is minimal. So too is the cost of lost productivity that a given worker would suffer whilst awaiting a replacement system. The higher cost would be the potential impact the loss of that data would have on the company should it wind up in the wrong hands.
Equally, in the case of leaked customer credit card details via a hacked system, one would need to calculate the cost of the data, the cost of contacting customers and replacing their credit cards, the cost of any fraud that may result, the cost of bad publicity should the hack be made public, the cost of fines imposed, and the residual cost of lost business opportunities should those customers and other potential customers take their business elsewhere.
A recent study published by the Ponemon Institute calculated that the average cost of a lost data record in the United States is US$197. But depending on the scale of the event, the overall cost of a data loss was anywhere between a few thousand dollars to tens of millions, averaging US$6.3 million.
"You'll often find vendors waving around statistics like impact of data breaches on share price, cost per record, and so on," says IBRS's Turner. "But these are tricky. They depend on the company, the industry, the outcome of the data breach, what the company did about the breach once it knew and so forth. These numbers should be used to stimulate debate, but not for pricing!"
If I were on a board, and nothing was quantified, I would have no interest in the project.
Brian Brannigan, managing director Agreon Systems
The final step in the process is to multiply the single loss expectancy by the rate of an Annual Rate of Occurrence, again tricky if it is an event that has never occured. The final figure is what can then be held up against the cost of investing in protection for that asset.
For some IT security projects, the necessary inputs can readily be guessed at.
It would be relatively easy, for example, to calculate the ROI on a system that protects the uptime of an e-commerce server for a gambling site. Real dollar figures are available as to how much revenue is usually derived from that site over a given period — downtime caused by a denial of service attack has a direct cost attached to it.
But as Schneier says, it is difficult to find an annualised cost of occurance of an event that has never, or only very rarely, been inflicted on an organisation. In effect, it's garbage input, for garbage output.
No other language spoken Flawed as it may be when it comes to security projects, the ROI model is the only one acceptable to executives in control of the purse strings.
Highlighting the horror stories — the data leakage, the intellectual property theft, the regulatory fines, the reputation damage, is rarely successful.
Wayne Neich, country manager Blue Coat
"I know where [Schneier] is coming from," says Carlo Minassian, founder and CEO of managed security service provider Earthwave. "But those CSOs who are getting bigger budgets still use ROI because that is the language the business understands. You have to walk their walk and talk their talk if you want to survive, and ROI is the only metric they are comfortable with."
"When you are having a conversation about budget," explains Peter Croft, managing director of security vendor Clearswift, "questions are asked in financial terms. There is a great temptation among technical people to say, well this will make us compliant with A, B, C and D. The answer from your peers will be, so what? That isn't an answer! I asked you a financial question!"
"ROI metrics are valued," agrees Brian Brannigan, managing director of identity management specialists Agreon Systems. "If I were on a board, and nothing was quantified, I would have no interest in the project."
Which makes the CSO, more than ever, a risk manager more than a technologist. Many CSOs who come from IT management backgrounds find this a struggle.
"The biggest challenge is finding a common language to communicate to your peers with," says RSA's Pullen. "Here at RSA we talk about information risk management. It is nothing new, but that's how we need to frame the discussion. It comes down to how much risk a business is willing to accept."
RSA recently introduced a new business unit — a 'Risk Advisory' service — which aims to help customers quantify their risk. Pullen says many CSOs need a framework or point of reference to get started on putting dollar values on information risks — for which external help is required.
Compliance isn't an answer unto itself. But you can tell the CFO, this means we can bid for x amount of new work.
Peter Croft, managing director Clearswift
"If you have health records, or billing information, this is likely to be information that drives the business," he says. "In this situation, a security risk is something you can quantify."
The market need for such advice, he says, is strong enough that companies are willing to pay for it — even if it is coming from a security vendor.
"The Risk Advisory is a paid service, because it generates reports about where risks are, information on that risk, and advice on mitigating risk," Pullen says. "Paying for the service gives it value and credence."
Making the security ROI work In the wake of the misfit between the ROI model and IT security needs, Blue Coat's Neich warns CSOs not to adopt a "sky is falling" approach.
"Highlighting the horror stories — the data leakage, the intellectual property theft, the regulatory fines, the reputation damage, is rarely successful," he says.
Instead, they need to find ways to talk about security initiatives in positive terms.
CSOs can quantify the impact of 'insurance'-type technologies like anti-virus and anti-spam, Neich says, by attaching a dollar figure to the productivity gains associated freeing up bandwidth for priority business applications once the unwanted network traffic is removed.
The prioritisation of "safe" applications and removal of unsafe data can optimise the existing network investment and "postpone future investment in network infrastructure," he said.
The ROI argument has to be made and has to be won.
Peter Croft, managing director Clearswift
Equally, gains derived from identity management, e-mail management or network management solutions, says Clearswift's Croft, can be calculated in terms of the "high value individual you no longer need stationed somewhere scanning through network logs." That individual can move on to new, revenue-generating projects. You might be able to quantify it on the basis that new staff don't need to be employed to deal with the problem as it grows. Enabling staff to work from home after business hours via VPN can also be quantified in terms of productivity gains.
Finally, security projects can be quantified if they form a step towards some sort of qualification. An information security code of practice like ISO27002, might be seen as the means by which an organisation can bid for higher value contracts.
"Compliance can't be an answer unto itself," says Croft. "But you can tell the CFO, this means we can bid for x amount of new work. What it means is upstream benefits with an x dollar figure attached to them."
A CSO, says Croft, has to be a 'security activist'.
"They have to advocate for security in their organisation," he says. "And to do that they need to be able to verse in the language of their seniors. That's the language of money. The ROI argument has to be made and has to be won."
