Blog
Attack surface management

Attack surface management vs vulnerability management

James Harrison
Author
James Harrison
Senior Content Writer

Key Points

Attack surface management (ASM) and vulnerability management (VM) are often confused, and while they overlap, they’re not the same. The main difference between attack surface management and vulnerability management is in their scope: vulnerability management checks a list of known assets, while attack surface management assumes you have unknown assets and so begins with discovery. Let’s look at both in more detail.

What is vulnerability management?

Vulnerability management is, at the simplest level, the use of automated tools to identify, prioritize and report on security issues and vulnerabilities in your digital infrastructure.  

Vulnerability management uses automated scanners to run regular, scheduled scans on assets within a known IP range to detect established and new vulnerabilities, so you can apply patches, remove vulnerabilities or mitigate any potential risks. These vulnerabilities tend to use a risk score or scale – such as CVSS (Common Vulnerability Scoring System) – and risk calculations.  

Vulnerability scanners often have many thousands of automated checks at their disposal, and by probing and gathering information about your systems, they can identify security gaps which could be used by attackers to steal sensitive information, gain unauthorized access to your systems, or disrupt your business. Armed with this knowledge, you can protect your organization and prevent potential attacks.

What does vulnerability scanning check for?

Most vulnerability scanners offer a list of security issues that the scanner checks for. This can be a good way to help you decide which scanner is right for you. Here are some broad classes of vulnerability which a modern vulnerability scanner should be able to check for:

  • Vulnerable software: this class of vulnerabilities is the biggest category, as it includes checks for known weaknesses in all kinds of 3rd party software and hardware. These are weaknesses discovered by security researchers in certain versions of a particular technology.  
  • Web application vulnerabilities: there’s a wide range of weaknesses which could be used to gain unauthorized access to information, compromise the web server or attack web application users such as SQL injection, cross-site scripting and directory traversal weaknesses.
  • Mistakes and misconfigurations: these include identifying software which has been incorrectly configured, common mistakes, and best practices which aren’t being followed.
  • Encryption weaknesses: a wide range of weaknesses in the encryption configurations used to protect data in transit between your users and servers can be identified by vulnerability scanners. These should include checks for weaknesses in SSL/TLS implementations, such as use of weak encryption ciphers, weak encryption protocols, SSL certificate misconfigurations, and use of unencrypted services such as FTP.
  • Information disclosure: this class of 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 these, and the number and quality of checks vary too. Some scanners are focused on one particular class of vulnerabilities - for example, web application vulnerabilities. A web application focused scanner wouldn’t necessarily check for infrastructure-level flaws, such as known vulnerabilities in the web server in use.

If you’re only using one scanner, it’s worth making sure it can handle all of the above, so there aren’t any gaps in your coverage. You can learn more about vulnerability scanning for Windows and Linux specifically in our dedicated guides.

What is the vulnerability management process?

  1. Performing a vulnerability scan
  2. Assessing your vulnerability risk
  3. Prioritizing and fixing vulnerabilities
  4. Monitoring continuously  

Read our guide on how to build a vulnerability management program for more detail.

What is attack surface management?

The main difference between vulnerability management and attack surface management is the scope. Attack surface management (ASM) includes asset discovery – helping you to find all your digital assets and services and then reducing or minimizing their exposure to prevent hackers exploiting them.

With ASM, all known or unknown assets (on-premises, cloud, subsidiary, third-party, or partner environments) are detected from the attacker’s perspective from outside the organization. If you don’t know what you’ve got, how can you protect it?  

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 tomorrow – when it becomes a significant risk. If you monitor and reduce your attack surface, regardless of vulnerabilities, you become harder to attack.

So, a significant part of attack surface management is reducing exposure to possible future vulnerabilities by removing unnecessary services and assets from the internet. But to do this, first you need to know what’s there.

What is the attack surface management process?

  1. Discover and map all your digital assets
  2. Ensure visibility and create a record of what exists
  3. Run a vulnerability scan to identify any weaknesses
  4. Automate so everyone who creates infrastructure can do so securely
  5. Continuously monitor as new infrastructure and services are spun up  

How does attack surface management differ from vulnerability management?

Vulnerability management is the process of identifying and prioritizing vulnerabilities in your IT infrastructure and applications. Attack surface management goes a step further by identifying and analyzing your attack surface – all the devices, entry points and exposed services that an attacker could potentially use to gain access to your systems or data.  

Can you combine Attack Surface Management and Vulnerability Management?

While ASM and VM may have different scopes and objectives, they’re not mutually exclusive. Used in combination, they create a much more holistic, robust and comprehensive cyber security posture. By identifying your assets and vulnerabilities, you can prioritize your security efforts and allocate resources more effectively – which will help you reduce the likelihood of a successful attack and any potential impact.

How Intruder can help with ASM and VM

Ultimately, you want to leave no stone unturned when it comes to cyber security. Modern VM and ASM solutions like Intruder can detect vulnerabilities affecting your organization. It gives you greater visibility and control over your attack surface, monitors network changes and SSL/TLS certificate expiry dates, helps you stay on top of your cloud infrastructure, and you only pay for active targets. Why not see for yourself with a free 14-day trial?

Get our free

Ultimate Guide to Vulnerability Scanning

Learn everything you need to get started with vulnerability scanning and how to get the most out of your chosen product with our free PDF guide.

Sign up for your free 14-day trial

7 days free trial
With so many solutions on the market, it’s important to understand the differences between attack surface management and vulnerability management.
back to BLOG

Attack surface management vs vulnerability management

James Harrison

Attack surface management (ASM) and vulnerability management (VM) are often confused, and while they overlap, they’re not the same. The main difference between attack surface management and vulnerability management is in their scope: vulnerability management checks a list of known assets, while attack surface management assumes you have unknown assets and so begins with discovery. Let’s look at both in more detail.

What is vulnerability management?

Vulnerability management is, at the simplest level, the use of automated tools to identify, prioritize and report on security issues and vulnerabilities in your digital infrastructure.  

Vulnerability management uses automated scanners to run regular, scheduled scans on assets within a known IP range to detect established and new vulnerabilities, so you can apply patches, remove vulnerabilities or mitigate any potential risks. These vulnerabilities tend to use a risk score or scale – such as CVSS (Common Vulnerability Scoring System) – and risk calculations.  

Vulnerability scanners often have many thousands of automated checks at their disposal, and by probing and gathering information about your systems, they can identify security gaps which could be used by attackers to steal sensitive information, gain unauthorized access to your systems, or disrupt your business. Armed with this knowledge, you can protect your organization and prevent potential attacks.

What does vulnerability scanning check for?

Most vulnerability scanners offer a list of security issues that the scanner checks for. This can be a good way to help you decide which scanner is right for you. Here are some broad classes of vulnerability which a modern vulnerability scanner should be able to check for:

  • Vulnerable software: this class of vulnerabilities is the biggest category, as it includes checks for known weaknesses in all kinds of 3rd party software and hardware. These are weaknesses discovered by security researchers in certain versions of a particular technology.  
  • Web application vulnerabilities: there’s a wide range of weaknesses which could be used to gain unauthorized access to information, compromise the web server or attack web application users such as SQL injection, cross-site scripting and directory traversal weaknesses.
  • Mistakes and misconfigurations: these include identifying software which has been incorrectly configured, common mistakes, and best practices which aren’t being followed.
  • Encryption weaknesses: a wide range of weaknesses in the encryption configurations used to protect data in transit between your users and servers can be identified by vulnerability scanners. These should include checks for weaknesses in SSL/TLS implementations, such as use of weak encryption ciphers, weak encryption protocols, SSL certificate misconfigurations, and use of unencrypted services such as FTP.
  • Information disclosure: this class of 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 these, and the number and quality of checks vary too. Some scanners are focused on one particular class of vulnerabilities - for example, web application vulnerabilities. A web application focused scanner wouldn’t necessarily check for infrastructure-level flaws, such as known vulnerabilities in the web server in use.

If you’re only using one scanner, it’s worth making sure it can handle all of the above, so there aren’t any gaps in your coverage. You can learn more about vulnerability scanning for Windows and Linux specifically in our dedicated guides.

What is the vulnerability management process?

  1. Performing a vulnerability scan
  2. Assessing your vulnerability risk
  3. Prioritizing and fixing vulnerabilities
  4. Monitoring continuously  

Read our guide on how to build a vulnerability management program for more detail.

What is attack surface management?

The main difference between vulnerability management and attack surface management is the scope. Attack surface management (ASM) includes asset discovery – helping you to find all your digital assets and services and then reducing or minimizing their exposure to prevent hackers exploiting them.

With ASM, all known or unknown assets (on-premises, cloud, subsidiary, third-party, or partner environments) are detected from the attacker’s perspective from outside the organization. If you don’t know what you’ve got, how can you protect it?  

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 tomorrow – when it becomes a significant risk. If you monitor and reduce your attack surface, regardless of vulnerabilities, you become harder to attack.

So, a significant part of attack surface management is reducing exposure to possible future vulnerabilities by removing unnecessary services and assets from the internet. But to do this, first you need to know what’s there.

What is the attack surface management process?

  1. Discover and map all your digital assets
  2. Ensure visibility and create a record of what exists
  3. Run a vulnerability scan to identify any weaknesses
  4. Automate so everyone who creates infrastructure can do so securely
  5. Continuously monitor as new infrastructure and services are spun up  

How does attack surface management differ from vulnerability management?

Vulnerability management is the process of identifying and prioritizing vulnerabilities in your IT infrastructure and applications. Attack surface management goes a step further by identifying and analyzing your attack surface – all the devices, entry points and exposed services that an attacker could potentially use to gain access to your systems or data.  

Can you combine Attack Surface Management and Vulnerability Management?

While ASM and VM may have different scopes and objectives, they’re not mutually exclusive. Used in combination, they create a much more holistic, robust and comprehensive cyber security posture. By identifying your assets and vulnerabilities, you can prioritize your security efforts and allocate resources more effectively – which will help you reduce the likelihood of a successful attack and any potential impact.

How Intruder can help with ASM and VM

Ultimately, you want to leave no stone unturned when it comes to cyber security. Modern VM and ASM solutions like Intruder can detect vulnerabilities affecting your organization. It gives you greater visibility and control over your attack surface, monitors network changes and SSL/TLS certificate expiry dates, helps you stay on top of your cloud infrastructure, and you only pay for active targets. Why not see for yourself with a free 14-day trial?

Release Date
Level of Ideal
Comments
Before CVE details are published
🥳
Limited public information is available about the vulnerability.

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%.
Day of CVE publish
😊
Vulnerability information is publicly accessible.

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%.
First week since CVE publish
😐
Vulnerability information has been publicly available for up to 1 week.

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%.
Between 1 week and 1 month since CVE publish
🥺
Vulnerability information has been publicly available for up to 1 month, and some very clever people have had time to craft an exploit.

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%.
After 1 month since CVE publish
😨
Information has been publicly available for more than 31 days.

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.

Figure 10: Absolute numbers of critical CVEs with a remote check release date from the date a CVE is published

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.

Figure 11: Percentage chance of delay for critical vulnerabilities

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.
Figure 12: Release delay year-on-year (lower is better)

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.

Written by

James Harrison

Recommended articles

Ready to get started with your 14-day trial?
try for free