Demonstrating Value in an Information Security Program

Demonstrating value is key in a corporate setting for running an effective information security program.  If your management team doesn’t clearly understand what benefit they all derive from security, the program will suffer over time.

Demonstrating some value is easy if you have historical metrics.  Metrics being a whole ‘nother topic.  Without them, illustrating value becomes much more difficult, but only for routine items, the kind that don’t really demonstrate the clear value of a security program.

Security people should keep track of proactive fixes and calculate value saved.  If your marketing department nearly sent out a virus laden PDF, can you estimate what that would have cost the company?  Value demonstrated.  If a computer worm affects other companies but not you, can you trace back to why you were unscathed, and if its not just a lucky dodge, you can point to it as value demonstrated.  Every time someone deletes a file and you’re able to recover it with FTK, that’s value.  And it adds up.

While hard metrics like firewall alerts and phishing rejection are nice, they usually are only good for incremental improvements, and are likely to be marginalized because “everyone” does that.  So your program is nothing special.

Whereas if you’re providing security input on a $3M project and suffer no security lapses, that’s personal to at least one manager, and probably meaningful to all of upper management.  They know how much a delay in that project would cost, if they’re doing project management.  That delay you didn’t have to take should be put in the security win column.  You did your job and carried the project without any glitches.  That’s value, perceived, measured, and quantifiable.

Meanwhile, normal security metrics, like password complexity, lock outs, alerts, and blocked access how a steady foundational reward.  But management doesn’t really see those, so despite being concrete, they appear abstract and fuzzy.  Far more real are the items like smooth deployments of non-security services and products that have a security component.

If you have a DDOS attack and thanks to your preparations, the Internet remains open fro business, that’s demonstrated value.  Any business that relies on the Internet knows how much disruption costs.  That difference is a benefit of the security program and should be acknowledged as such.

Usually nobody’s going to blow your horn for you, though, so you need to keep track of these things and get the word out.  In every company newsletter place a brief summary of what’s gone on and how much it saved the company.

At the end of the year, you can quantify the entire period and compare that to the expense of running the program.  If the program is still a cost center and not a profit center, you’re probably doing something wrong.

Stay away from fuzzy representation, like value, if you don’t have hard numbers to back up the claim.  Brand reputation is a very real resource, but without actual measurable damage, and some sort of benchmark, it’s going to look soft.  If you can show a similar incident had a specific effect, and that translates to your situation, it is possible to use it, but usually not.

Occasionally, you’ll be able to use a security program as a cost savings indicator, but most of them will not work well.  This is because security is the only department with contact with the security device/application.  If management as a whole doesn’t feel the direct benefit, the success loses value.  If a new security device/process streamlines an existing process, it can be argued that the first problem was security to begin with, so all that’s happened is a fix has been put in for  a problem, and that’s not value add, that’s value recovered.  Increased efficiency is a soft win.  List it, but don’t count on it getting you a bonus.

Imagine some of the possibilities:

  • You’re data loss prevention program catches the secret formula for your key product leaving for a competitor.
  • Neubot.war worm takes down half the Internet, and you are unscathed because of white-listing run-time applications.
  • A hostile employee tries to sabotage the plant chemistry mix, but can’t because provisioning denied access.

Fighting for ROI using metrics is an uphill battle, but demonstrating value using particular high profile incidents like these makes it much easier, but you have to watch for them.

Do use standard business practices and ROI for budgetary purposes, but its the risk management program that will contribute most to finding new ways to demonstrate value, because it is proactive and not responsive.  If they beneficial system/process isn’t in place prior to the incident, any benefit derived is simply soft response value, and not the hard value that clearly shows value.