What is vulnerability management?
When it comes to protecting your IT environment, what you don’t know can certainly hurt you. Finding where you’re vulnerable is critical for every business today because cyberattacks can affect anyone – approximately 15M data records were exposed through data breaches in 2022 and Gartner has predicted that 45% of organizations will have experienced attacks on their software supply chains by 2025.
45% of organizations will have experienced attacks on their software supply chains by 2025
These attacks aren’t cheap either. The average cost of a data breach was $9.44M in the United States in 2022. And this doesn’t include the frustration, lost productivity and impact on your reputation. Vulnerability scanning and vulnerability management are tried and trusted ways to protect yourself against these threats - they’re often used interchangeably but they’re not the same.
What is vulnerability management?
Vulnerability management is the continuous process of identifying, prioritizing, and managing cybersecurity vulnerabilities. With new vulnerabilities appearing every day, quarterly scanning and remediation is no longer enough - continuous vulnerability management has become business critical.
What’s the difference between vulnerability management and scanning?
Vulnerability scanning is, at the simplest level, the use of software tools to identify and report on security flaws (known as vulnerabilities) in your IT systems. Scanners run many thousands of tests by probing and gathering information about your systems. These are designed to identify holes which could be used to steal sensitive information, gain unauthorized access to your digital systems, or disrupt your business.
Here are some of the common types of vulnerability which a scanner will check for:
- Vulnerable software – such as a weak version of a Nginx web server, a vulnerable FTP service, or weaknesses in a Cisco router or VPN.
- Web Application vulnerabilities – such as SQL injection, cross-site scripting (XSS) or directory traversal weaknesses.
- Misconfigurations – including software which has been incorrectly configured, commonly made mistakes, and security best practices which aren’t being followed such as exposed SVN/git repositories, open email relays, and or a web server configured to reveal sensitive information.
- Encryption weaknesses – such as use of weak encryption ciphers, weak encryption protocols, SSL certificate misconfigurations, and use of unencrypted services such as FTP.
- Attack surface reduction – exposed databases, administrative interfaces, and sensitive services such as SMB.
- Information leakage – these checks report on areas where your systems are reporting information to end-users which should remain private.
Not all vulnerability scanners check for all of the above, and the number and quality of checks vary too – for a deeper dive into vulnerability scanning, check out our ultimate guide. Ideally, a scanner will also prioritize any discovered risks by severity, so you know which ones to fix first.
Armed with this knowledge, you can look to protect yourself and take action to fix the vulnerabilities that are discovered. This overall ongoing process of identifying and fixing your weaknesses is known as vulnerability management.
Whilst a vulnerability scan is a software process with a definite start and end time, vulnerability management is the overarching process that continuously identifies, prioritizes and manages cybersecurity vulnerabilities. Vulnerability scanning is therefore just one crucial part of a vulnerability management program.
Where scanning identifies flaws and classifies risks, vulnerability management includes decisions on whether to fix, mitigate, or accept the risks alongside continuous monitoring, and on which vulnerabilities to fix first.
Do all vulnerabilities pose the same risk?
Not all vulnerabilities are the same or pose the same risk to your business. The Common Vulnerability Scoring System (CVSS) is a free and open industry standard that many cyber security vendors use to assess and prioritize the severity of vulnerabilities.
The CVSS Base Score ranges from 0.0 to 10.0, and The National Vulnerability Database (NVD) adds a severity rating for CVSS scores. NVD also provides a library of common vulnerabilities and exposures (CVEs) from the not-for-profit MITRE Corporation. Below is one way to interpret CVSS scores:
A CVSS score isn’t the be-all-and-end-all of vulnerabilities though. It gives a good indication of the risk to your business, but there are many other factors that can affect the seriousness of a weakness, such as:
- The sensitivity of the data on the system affected
- Whether a public exploit has been distributed or not
- Intelligence on whether attackers are actively exploiting the weakness
What is the vulnerability management process?
While there are different ways to define each stage in the vulnerability management process, the cycle is generally the same, even if the terminology varies. A good place to start is Gartner’s Vulnerability Management Guidance Framework which includes several “pre-work” steps to help define the scope of the program and identify gaps before you begin:
- Which assets will you measure for vulnerabilities?
- Which assets or hosts are most critical to protect?
- Who will be managing this program?
- How long will you have to fix any vulnerabilities?
- What tools will you need to scan and monitor?
- What assets do you plan to cover?
Armed with this info, you’re ready to build a robust and effective vulnerability management program...
What are the 4 steps of a vulnerability management program?
It’s important to remember that the ultimate point of your vulnerability management program is to fix any flaws, so one of your KPIs should be how many critical vulnerabilities are fixed or mitigated as quickly as possible to minimize the window of opportunity for hackers. When you know what you need to monitor – asset discovery and inventory of your IT infrastructure should precede any vulnerability management program – you should follow these four steps:
- Find: find any vulnerabilities through scanning and testing
- Prioritize: understand which pose the most significant risk
- Fix: patch, block, remove or snooze vulnerabilities
- Monitor: keep on scanning for new or returning vulnerabilities
If you’re just starting out on your vulnerability management program journey or want to build a more rigorous program, check out our step-by-step guide here, or find out which vulnerability management metrics you should measure.
Do I need a vulnerability management program?
Vulnerability management should be a core foundation of your overall security strategy. You simply can’t afford to ignore the risks in your IT infrastructure. As networks grow more complex and dispersed, IT teams struggle to maintain visibility across their ever-expanding attack surface. Hackers know this and risks and attacks often go unnoticed until they've caused damage at considerable cost.
But vulnerability management has benefits beyond security. Regularly checking your network, systems, devices and applications can help you identify legacy technology and unpatched devices. This will not only keep improve your security but also optimize your systems performance.
Vulnerability management can also help you meet compliance. Regular scans, continuous monitoring and quicker remediation can help you stay ahead of compliance requirements and demonstrate your cyber hygiene to stakeholders, regulators and customers.
What’s the difference between vulnerability management (VM) and attack surface management (ASM)?
Attack surface management is the process of discovering your assets and services, scanning them for vulnerabilities, fixing any flaws, and then reducing or minimizing their exposure to prevent hackers exploiting them.
Exposure in the context of ASM usually means reducing total surface that can easily be attacked. For example, a Remote Desktop service exposed to the internet is naturally easier to attack than one which is layered behind a VPN. In the latter scenario, an attacker first has to compromise or authenticate to the VPN, before attacking the Remote Desktop service.
Take the example of an admin interface like cPanel or a firewall administration page – these may be secure against all known current attacks today, but a vulnerability could be discovered in the software tomorrow – when it immediately becomes a significant risk.
By reducing the exposure of your assets, and limiting which hosts can access them, this risk is reduced. This is because when a new vulnerability in the product is released, they cannot be remotely attacked by attackers over the internet.
So, a significant part of ASM is reducing exposure to possible future vulnerabilities by removing unnecessary services and assets from the internet. This what led to the Deloitte breach and what distinguishes it from traditional vulnerability management. You can read more about ASM here.
What to look for in a vulnerability management solution
Less can be more. You no longer need a complicated set of security tools and solutions that require people with specialized skills to manage vulnerabilities. Instead, you can now rely on a powerful, automated platform like Intruder to continuously monitor your internal and external attack surface including your web applications and APIs.
Whether you’re just getting started on your vulnerability management journey or looking to optimize your cyber security to meet compliance in an increasingly complex threat landscape, Intruder has the vulnerability management solutions to get you there faster. Why not try it for free for 14-days and kickstart your own vulnerability management program today?
- Raw CVE Coverage
- Risk Rating Coverage
- Remote Check Types
- Check Publication Lead Time
- Local/Authenticated vs Remote Check Prioritisation
- Software Vendor & Package Coverage
- Headline Vulnerabilities of 2021 Coverage
- Analysis Decisions
Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.
Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.
Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
The likelihood that exploitation in the wild is going to be happening is steadily increasing.
Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
We’re starting to lose some of the benefit of rapid, automated vulnerability detection.
Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
Any detection released a month after the details are publicly available is decreasing in value for me.
Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.
With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:
- Have CVSSv2 rating of 10
- Are exploitable over the network
- Require no user interaction
These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.
We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.
In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.
While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.
So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.
I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.
What can we take away from Figure 12?
- We can see that between 2011 and 2014 Greenbone’s release delay was better than that of Tenable, by between 5 and 10 days.
- In 2015 things reverse and for 3 years Tenable is considerably ahead of Greenbone by a matter of weeks.
- But, then in 2019 things get much closer and Greenbone seem to be releasing on average about a day earlier than Tenable.
- For both the trendline over an 11-year period is very close, with Tenable marginally beating Greenbone.
- We have yet to have any data for 2021 for OpenVAS checks for critical show-stopper CVEs.
With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.
The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.