It’s a fact of life that most IT shops have, to one degree or another, a “security products graveyard” – i.e. security technology that’s past its prime, performing poorly, or that otherwise represents a drain on the security program.
Note that by this, I’m not talking about technologies that have served their useful purpose and have subsequently been decommissioned — like everything else, security technologies have a natural lifespan: they move from planning, to investment, to use, and ultimately to decommissioning and removal.
What I’m referring to instead is what happens when that lifecycle gets interrupted. When the organization invests in a security technology and continues to invest (either in hard dollars or staff time) even long after the technology has stopped providing value or when that value is reduced to miniscule amounts.
This can happen in a number of different ways. Most obviously, there’s “shelfware:” purchased technology that isn’t fully deployed. Shelfware is usually pretty obvious when it happens, but there are subtler situations that can happen too.
For example, security technology can be “overcome by events.” For example, consider what happens when a change to the environment happens that renders a technology less relevant than it used to be (commercial war-dialing tools might fit into this category in many shops) or when a “compensating control” persists even after the underlying issue (i.e., what it was compensating for) has been resolved.
It could also happen as a result of changes in staffing. For example, a reduction in headcount that leaves insufficient staff to operate a tool effectively.
Why It Matters
Now, obviously spending time, money, and energy on something that’s not being used is never a great situation, security related or otherwise. But with security specifically, it’s particularly problematic. Why? Because underutilized security technology is simultaneously a more difficult situation to resolve and more impactful to the organization as a whole.
It’s more difficult to resolve than other areas because there’s a natural disincentive to decommissioning security technology. Firstly, it takes courage to remove security controls – even when they’re not performing well.
This is human nature: after all, who wants to be the person responsible for removing a security control if there’s even a remote chance that it could be useful in preventing an attack? The problem with this mentality though is that utility is seldom binary – instead, usually it’s a spectrum. Meaning, a control might not be “100% useless,” but it might be so much less useful that it’s not worth what you’re spending. So waiting for the time when a control because “useless beyond a shadow of a doubt” means chances are good it’ll stay there forever.
Secondly, the detrimental impact of this situation is worse with security technology. Clearly, there are budget implications in any situation where you’re spending more than the value you’re getting. However, with security technology, the “opportunity cost” isn’t just wasted dollars – it’s wasted dollars and risk. What I mean by that is that continuing to invest in underperforming technology means you’re not investing in something else that could reduce even more risk.
Breaking the Cycle
Given these dynamics, it’s obviously important that we take steps to address the situation. The goal should be clear: remove underperforming controls or replace them with something more useful. But how do you know? Is the control as valueless as you think? You need some way to test that before you go start yanking wires. Also, it’s not always easy to figure out what’s less useful in the first place. To know this, you need some way to separate the wheat from the chaff.
Unless yours is an organization that does some kind of documented, ongoing risk assessment process, chances are good that getting to a level of understanding about the value of the controls will take some effort. This is why it can be helpful to specifically revisit all of your controls and canvass them to determine how well they’re operating: for example, by making a list of what controls you have in place, their purpose, and (ideally) how well they’re performing.
In fact, it can be helpful to do this periodically, for example as part of your annual budget planning, to ensure that there’s a mechanism to validate the performance of controls – so that if technologies or assumptions change, you’ll know.
Note that “how well they’re performing” can also be difficult to assess. This requires that you understand both how it performs technically (i.e. how well does it meet the goal for which it was deployed) as well as what resources are required to operate it.
This is where risk management really shines but if you’re not doing that, you’ll want to do some “quick and dirty” vetting to help you get to a short list of candidates that might be underperforming. If you go that route, note that the goal is not necessarily to get to a perfect understanding – instead, you’re just looking to shake out a short list to do a more systematic analysis.
Once you have a starting point in hand (i.e. controls to scrutinize further), the next step is to evaluate those more systematically. How do they perform? How much are you spending on them? What could you be doing instead?
A good litmus test for this is the “would you buy it again” test. Meaning, if you suddenly changed jobs and went to an environment that was identical in every respect save one – not having that tool – would you buy it again? If not, what would you buy instead? Answering that can help shake out those tools you’ll want to look at that one more carefully and can help lead you to where you might want to reinvest.
Once you do identify candidates for removal, the next step is to prepare your business case. Yes, I said business case. Since most security shops are already strapped for resources, removing controls isn’t (or at least, I’d argue, shouldn’t be) an exercise in cost saving; instead it’s about maximizing risk mitigation value per dollar spent.
This in turn means that almost always you’ll want to reinvest dollars saved in other areas. And just like you’d need to prepare a business case for a brand new technology investment, you’ll also want to justify the reallocation of existing spending. Lay out – clearly, and in language understandable to all – the value and costs associated with the dollars you wish to reallocate so that you can demonstrate to management why it’s a better deal – and also for posterity, so that if (heaven forbid) something bad does happen, that you’ve documented exactly why you made the decision you did.
It’s not a guarantee that every shop will have underperforming controls, but you’d be surprised how often this happens. By thinking it through systematically and putting in a bit of legwork though, opportunities abound to more efficiently use your security resources. And “trimming the fat” on underperforming controls is a good place to start.
Ed Moyle is Director of Emerging Business and Technology for ISACA. Prior to joining ISACA, Ed was a founding partner of the analyst firm Security Curve. In his more than 15 years in information security, Ed has held numerous practitioner and analyst positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers, and senior security analyst with Trintech. Ed is co-author of Cryptographic Libraries for Developers and a frequent contributor to the Information Security industry as author, public speaker, and analyst.