There are many reasons to pen test, but the financial reasons tend to get ignored.

Nabil Hannan, Managing Director at NetSPI

July 9, 2020

5 Min Read

Google "pen testing return on investment (ROI)" and you will find a lot of repetitive advice on how to best communicate the value of a pen-testing engagement. Evaluate the costs of noncompliance penalties, measure the impact of a breach against the cost of a pen-test engagement, reduce time to remediation, to name a few. While all of these measurements are important, pen testing provides value beyond compliance and breach prevention, even through a financial lens. Let's explore the critical steps to successfully define and communicate ROI for security testing.

First, understand the role of pen testing as it pertains to security program maturity: Defining the ROI of pen testing has its nuances, as there are seemingly no tangible results that come directly from the investment. When implementing a pen-testing strategy, you're actively avoiding a breach that could cost your organization money. But the cost of a breach is the most obvious data point for measuring ROI, and those estimates vary widely. My advice? Work toward maturing your security program to a point where the engagement with pen testers is focused on ensuring the effectiveness of existing controls and security touchpoints in your development life cycle — not solely to check a compliance box or single-handedly prevent a breach. Leveraging pen testing throughout the development life cycle can help identify issues in development before deployment rather than the costly discovery of vulnerabilities at a later date.

Second, identify metrics, not measurements: Business decisions are often made using measurements, instead of metrics. But in most cases, driving decisions based on measurements (or raw data) can be misleading and end up with business leaders focusing time, effort, and budget on the wrong activities. Metrics, on the other hand, are an aggregation of multiple measurements that answer specific business questions, typically in a ratio or percentage format to help teams track progress.

As a starting point, here are five metrics that security teams should tap into to translate pentesting ROI to leadership teams:

  • Vulnerability density trends: Historical data on vulnerabilities is instrumental for business and risk insight. Review the top vulnerabilities found in an application and compare historical data to determine if there are certain patterns over time that show the probability of multiple vulnerabilities if a single one is discovered. If these metrics start to trend down, it's a clear indicator that you're gaining better control over your systems and now have the information available to learn how to eradicate two or more vulnerabilities at a time.

  • Pen-testing coverage: Cybersecurity teams often categorize vulnerabilities in terms of high-, medium-, or low-risk metrics. They naturally focus security efforts on the highest risk, causing medium- and low- risk applications to lack attention while attackers look to exploit whatever is most vulnerable. Tracking all levels of risk allows pen-testing teams to determine what exactly is missing focus from a security perspective. This will highlight areas that are being neglected or missing security investment. Proper coverage across your portfolio also forces organizations to keep proper inventory of your assets — invaluable capital for an organization.

  • Ratio of open:remediated vulnerabilities: This metric shows how fast and effective an organization is at fixing security issues. You cannot simply test applications to be secure — you have to remediate. The open:remediated vulnerability ratio metric helps determine which of your issues are being remediated and which are not. It can also determine specific areas where training is needed to help boost remediation efforts. With an effective pen-testing strategy, organizations should see the number of remediated vulnerabilities gaining or exceeding the open vulnerabilities.

  • Costs related to remediation efforts: Once a vulnerability is identified, a critical metric is quantifying the cost of how much effort is going into remediation. Keep in mind: If remediation goes beyond the line of code being changed, the cycle requires more time and effort. For example, if vulnerabilities are found in code in production, someone has to change it, perform regression testing on the software, test to make sure nothing else is broken, push through a QA environment, do an additional test to ensure it was fixed correctly, and then push the updated code to production. Costly, no? Tracking these cost metrics (personnel costs multiplied by the hours spent) allows you to determine if you're gaining efficiency in remediation and will enable you to answer the question, "What does it really cost me to build security into my applications?"

  • Costs of building a secure application: It's important to monitor the cost metrics of other security activities that factor into application development. This includes building in security requirements before your application is even coded, supporting code review during the development cycles, and tooling that is integrated into continuous integration/continuous delivery/continuous deployment (CI/CD) pipeline as your software is promoted from one environment to another and more. Auditing the application development process for vulnerabilities will in turn create efficiencies in building security into an application. 

An opportunity lost 
From my experience, those in security leadership roles do not work as closely with the CFO as they should. Ultimately, pre-emptive cybersecurity activities have many benefits, and potentially make your organization more money in the long run by giving customers peace of mind, preventing attacks, and developing better software overall. Most of the above metrics will make collaboration with the C-suite mandatory and require teams to work closely with the CFO and finance teams to keep track of the metrics that matter. In the end, you will have tangible ROI for pen testing and broader security programs.

Related Content:

 

 

 

 

Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really bad day" in cybersecurity. Click for more information and to register for this On-Demand event. 

 

 

About the Author(s)

Nabil Hannan

Managing Director at NetSPI

Nabil Hannan is a Managing Director at NetSPI. He leads the company's consulting practice, focusing on helping clients solve their cybersecurity assessment and threat & vulnerability management needs. Nabil has over 13 years of experience in cybersecurity consulting from his tenure at Cigital/Synopsys Software Integrity Group, where he built and improved effective software security projects, such as risk analysis, pen testing, secure code review, vulnerability remediation among others. Prior to NetSPI and Synopsys, he worked as a Product Manager at Research In Motion/BlackBerry and has managed several flagship initiatives and projects through the full software development life cycle.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights