How to Make Your Vulnerability Management Metrics Count
Table of Contents
Software development organizations are investing more and more resources in their vulnerability management programs. According to Gartner’s forecast, in 2021 enterprise security spending was expected to break records and grow 12.4% to reach 150.4 billion. But how do organizations know if they’re spending their security resources wisely? The answer can only be found by crunching the numbers.
Organizations must have solid vulnerability management metrics in place to make sure their vulnerability management strategy is working, and that they can make adjustments when needed.
What is vulnerability management?
Vulnerability management is the process of identifying, assessing, remediating, and reporting on security vulnerabilities in systems and applications running in business operations. A company’s attack surface must be minimized in order to prioritize potential threats.
Vulnerability management needs to run continuously to keep up with the new technologies being added to networks, changes made to systems, and the discovery of new threat windows over time.
Choosing the right vulnerability management metrics
With so many application security testing tools being integrated into the development lifecycle, it’s relatively easy to get the data. However, assessing and measuring everything will just leave us bogged down with endless graphs, charts, and numbers.
Most vulnerability management programs will look at the overall number of vulnerabilities reported each month, and the progression of such a number over time as a metric. However, after a while, you might encounter some of the following deviations:
- Machines and applications that were not scanned in the previous month and that have their total vulnerabilities counted in the current month.
- Machines and applications that were removed between one month and another, and the consequent lack of control over these changes.
- Problems with credentials and intrusive scans that account for fewer vulnerabilities than they should
These deviations can account for issues with inventory updates and processes that are still under development.
Teams that want their vulnerability management plan to efficiently address evolving security threats, should focus their time and attention on the numbers that matter rather than just collecting everything. In addition to ensuring that your organization is one step ahead of the hackers, having the right vulnerability management metrics is also the best way to win over your stakeholders and ensure that your security management plan is getting the resources it needs, showing them a clear picture of how you are working and where there is room for improvement.
10 key vulnerability management metrics
1. Coverage
Clouds, microservices, containers, open source components, proprietary and third-party. At least some of these are likely to make up your organization’s inventory. Today’s development teams rely on many components on multiple layers, and if you’re not keeping track of what your organization is using, how can you determine whether your vulnerability management plan is covering all of your systems?
In order to ensure that you have complete coverage of your assets and applications, you need to be on top of your software bill of materials (SBOM), so that you can successfully track it, and address vulnerabilities as soon as they are in your system. Automated AppSec tools like SAST for proprietary code, and Software Composition Analysis tools for open source components, can easily provide organizations with the data they need for solid vulnerability management metrics about their inventory and vulnerabilities.
It is also essential to understand the type of scanning for any system or application that is business-critical. What type of authentication is offered, for example, username and password or none at all? This provides a qualitative view when selecting asset data, as well as clarifying the scope of risks unknown to the security, development, and DevOps teams.
2. Time to detection
How long does it take you to detect vulnerabilities in your system? Detection is a key phase in the vulnerability management process, and in order to ensure that your organization is doing it right, the average time to detection has to be one of your vulnerability management metrics.
Issue trackers will include data like time of occurrence, time of detection, and the number of vulnerabilities. This data can be retrieved on a monthly or even weekly basis, and ideally, hours will be the measurement metric that you use for your reports. Having the metrics on how long it’s taking your teams to detect vulnerabilities so that you can start figuring out how to minimize the amount of time that security vulnerabilities go unnoticed.
3. Time to remediation
This metric shows the time for an identified vulnerability to be fixed. Today, advanced application security tools offer automated remediation and valuable insights to help security and development teams fix vulnerabilities quickly, early in development. Vulnerability management technologies also keep a record of the date a vulnerability was mitigated, making it easier to generate this type of indicator.
4. Patching rate
This is a more complicated indicator to create, but it measures the work of the team involved in the vulnerability management process. This metric allows teams to see how many patches or corrections were applied in a given timeframe and helps them improve their patch management strategy.
5. Asset risks
How many users have administrative access? Do we have assets that are more prone to security issues, increasing cyber risk? How many appointments are received by geographic location, office, or business unit? These information security metrics tell us which assets have the greatest business impact, to help us prioritize remediation and invest our time and financial resources wisely when dealing with asset risk management.
6. Baseline or golden machine
This metric helps zero in on the machines that are at higher risk. A scan is performed on an ideal machine (golden machine) that has the latest fixes applied and preferably the same conditions as a new machine on the network. A score is determined for that machine based on, for example, the total number of vulnerabilities and their criticality levels. Machines that have deviations above the golden machine score must be fixed.
7. The average number of vulnerabilities over time
The important part of this metric is “over time”. If you don’t measure vulnerabilities for a continuous period, you will incorrectly rely on the scan results, which may not have assessed all the assets during a scan, and will indicate dips that are just simply deviations. In order to avoid verification gaps, you need to continually measure the number of vulnerabilities across your applications and infrastructure.
8. Remediation results against SLAs
How quickly an organization successfully fixes vulnerabilities and the speed at which they occur has a tremendous impact on business objectives. By evaluating the results of the fix against a service level agreement (SLA), you can assess the effectiveness of the fix against the time and resources available.
9. Number of open communication ports
As a general rule, we should avoid allowing incoming traffic for NetBIOS (UDP 137 and 138, TCP 135-139 and 445). We should also comply with the outgoing SSL protocol (TCP 443)—a session that has been active for a long time could be an SSL VPN tunnel that allows two-way traffic. All common ports for protocols that allow remote sessions, such as TCP 22 (SSH), TCP 23 (telnet), TCP 3389 (RDP), and TCP 20 and 21 (FTP), must be monitored.
10. Frequency of review of third-party access
IT administrators often grant access to third parties on their networks to complete a project or activity. It is important to control whether access is canceled at the end of the service provision. Our environment is endangered if the provider decides to go back and extract data or carry out other malicious activity.
More than just a numbers game: Prioritizing vulnerabilities
With the number of known security vulnerabilities continuously rising, organizations racing to resolve every single vulnerability as quickly as possible have no chance of winning at the security game. Vulnerability management metrics that simply provide a count of vulnerabilities and disregard how critical they are, miss the mark, and leave your developers buried under piles of tickets.
In order to get a clear picture and actionable insights on vulnerability management, metrics should focus on the riskiest vulnerabilities, the ones that will have the most impact on an organization’s systems and business. These are the vulnerabilities that need speedy and efficient fixes, and prioritizing them as part of your vulnerability management practices will enable organizations to manage vulnerabilities effectively.
Measuring up: How to get your vulnerability management metrics right
The need to race from one sprint to the next, in order to provide customers with the most innovative solutions, along with the increasing number of known security vulnerabilities, put security and development teams between a rock and a hard place.
Choosing the right vulnerability management metrics can help organizations keep track of their asset and application inventory, the number of vulnerabilities that require immediate attention, and the status of their remediation and patch management processes.
Once you know which numbers need crunching, it’s much easier to pinpoint the places that need improvement, and allocate the resources needed to keep up the pace of development, without compromising on security.
