Getting value from your security tools

It is easy to spend significant time and effort deploying a security product, only to find that it is difficult to prove the value delivered. In this two-part blog post, elevenM Senior Project Manager Mike Wood explores how to extract and sustain value from security products.


The true uplift value from any security tool comes from the context in which it is used, rather than the capabilities of the tool itself.

Consider a Web Application Firewall (WAF), which filters and blocks web traffic. A WAF is only as effective as the rules it follows and how alerts are responded to. How WAF rules are set and maintained over time, and the level of automation you use in responding to alerts, will affect the protection effectiveness of your WAF.

You could pay the SaaS vendor to do this for you, but is that good value for money? Does the vendor know your business, its context and the threats you face as well as your own people do?  Would handing this over to the vendor also mean you miss out on building knowledge among your team?

Another example is code scanning; it is only as effective as the vulnerability management process that acts on the outcomes from the scans. If you find vulnerabilities using a sophisticated tool, but don’t act on them (or you report them, but they don’t get remediated by development teams) then it’s hard to gain true value from such tools.

When tools are evaluated not just in a risk context but also in terms of people and process, value can be shown.  A good way to start is by asking yourself questions such as:

As a result of this tool or its outputs …

  • What manual security work will be automated?
  • What actions does the tool require and what processes and people capabilities need to be built to support it?
  • Are we delivering more effective security risk mitigations for the same level of effort or funding?
  • What is the contribution to overall reduction in risk? [an easy one to measure is financial impact, such as value of fraud prevented or reduction in cost spent recovering from successful attacks]
  • Are security processes running faster / is there a positive impact to velocity?
  • What is the tool’s contribution to NIST maturity and regulatory or other such obligations? [this is best measured by independent reviews]
  • What data and insights do we have that we didn’t have before and what valuable activities and outcomes have these enabled? [for example, anti-automation/bot protection tools can show you the bad automated traffic that’s hitting your assets, informing your understanding of attack vectors you’re susceptible to and how to address them. Anti-automation tooling may be enough, but to meet the objective of layered security you may also identify code changes.  Data and insights are crucial to being able to analyse, prepare, risk-assess and make such decisions.]

Another important contextual consideration is the impact to teams outside of security.  To gauge how they value security, ask questions such as:

As a result of this tool or its outputs …

  • Is security awareness increasing as a result of this tool or its outputs (measured, for example, by increased proactive engagement with the security team)?
  • Is the security team perceived differently – for eg, as less ‘disruptive’ by developers?
  • Have we freed up our security teams (typically scarce resources in the market) to focus on exceptions, forensics and strategic improvements, by empowering non-security teams to run repeatable security activities that we can then monitor and advise on?

To truly realise the value of security products, we need to have a clear view on their broader context.

In the next part of this series, we explore how to sustain and build on the value delivered by security tools over time.

Leave a Reply