Background:
Vulnerability scanning is a key control within most security control frameworks like SOC 2, ISO 27001, NIST 800-53, and can even be a key part of privacy-centric frameworks such as GDPR. The reason vulnerability scanning is considered a key control is because of the information these scans provide. The ultimate goal of a vulnerability scan is to identify possible vulnerabilities within a system such as a known exploit in a software library, unpatched operating systems, misconfigured applications, and more. But there are also multiple types of vulnerability scans which can affect the amount and types of vulnerabilities that can be detected.
What is a Vulnerability Scanner?:
Without getting too in-depth about vulnerability scanners, a vulnerability scanner is just an application that automatically tries to collect information about the devices it interacts with. Vulnerability scanners do this by trying to communicate with any device they are targeted at whether that is a single device or an entire network. These applications communicate with these devices and then pull in information about them based on the responses they receive. An example of this operating system identification. Each operating system will respond to packets sent to them in a slightly different way, and using these differences, the vulnerability scanner can then profile those devices. If a vulnerability scanner is scanning your network it should be able to detect which devices are running Windows and which are running a Linux Distribution.
The vulnerability scanner then takes this information and compares the information it was able to collect, such as operating system, operating system version, open ports, running services, etc. and compares this information with a database or multiple databases which contain known vulnerabilities. So if a device on your network is running an outdated version of Apache, the vulnerability scanner will list out the vulnerabilities that are known for that version of Apache.
Types of Vulnerability Scans
One way to divide vulnerability scans is to break scans down by where the vulnerability scanner is running from. Using this division, there are 2 main types of scans: Internal vulnerability scans and external vulnerability scans.
Internal vulnerability scans are conducted from a location which has access to your internal network or resources. An example of this for a traditional network would be conducting a vulnerability scan from within your data center. When you run a vulnerability scan from within your data center, it does not have to pass through your public-facing firewall and because of this, has direct access to the computing devices within your network. In a non-traditional network (such as your cloud environment) an example would be running the vulnerability scan from within the same Virtual Private Cloud (VPC) as the resources that are being scanned. Internal vulnerability scans are better at detecting the patch level of the systems being scanned for example.
An external scan is the other type of vulnerability scan, and it is conducted from a location outside of your internal network. Any communication between the vulnerability scanner and your internal resources will have to pass through your public-facing firewall and any other security devices before it can reach your internal resources. External vulnerability scans are a bit more realistic in that they will detect the vulnerabilities that an external attacker to your organization would be able to detect (because many times, cyber attacks begin by conducting a vulnerability scan!).
The second way to divide vulnerability scans is to consider the level of access the vulnerability scanner will run with. The two types of vulnerability scans in this category are: Authenticated or unauthenticated scans.
Authenticated scans give the vulnerability scanner credentials (which is why they are sometimes referred to as credentialed scans) which give the scanner access to the resources it is scanning. An example of this would be giving the vulnerability scanner an administrator level account or a user level account to a server it is scanning. While providing your vulnerability scanner with administrative privileges could present a security concern if those credentials fell into the wrong hands, this is usually done because an authenticated scan can detect more information than a scan run with no provisioned access.
Unauthenticated scans (or non-credentialed scans as they are sometimes called) are scans where the vulnerability scanner was not provisioned any access to the systems it is scanning. This type of scan is run because, like an external vulnerability scan, it is more realistic in showing the information that an attacker would have access to. Likely, as an initial attempt at breaking into your systems, the attacker will not have access to user credentials on your systems.
There are also additional, more specific types of scans, such as web application vulnerability scans, which focus solely on web applications. But just using the criteria from above, we already have four types of vulnerability scans: Authenticated Internal Scans, Unauthenticated Internal Scans, Authenticated External Scans, and Unauthenticated External Scans.
But two types of specialized vulnerability scans which are becoming increasingly common. They are container vulnerability scans and code security scans. These require specialized types of scanning as well as specific vulnerability databases to pull potential vulnerabilities from.
Container scans are however closely related to both traditional vulnerability scans and code security scans. Oftentimes, such as if your organization is using Docker for container deployment, containers are defined as code. But that code actually creates a container which takes part of an Operating System, application runtimes, software libraries, etc. and deploys a container to execute an application. Because of this, a container vulnerability scan has to be able to read the code used to define the container, but also trace the results of the execution of that code to scan the relevant pieces of an Operating System, application runtimes, software libraries, etc. and scan those pieces for vulnerabilities as well.
Code security scanning is a type of security scanning, part of which can include vulnerability scanning. However, code security scanning could encompass an entirely separate article. For the purpose of this article, code security scanning will seek to identify vulnerabilities within developed code either before compile/execution and then during execution/runtime. These can cover things like logic errors, security issues in software libraries, broken authentication, etc. Code security scanning will differ from traditional vulnerability scanning in that it is usually a part of your Software Development Lifecycle process, rather than a separate Vulnerability Management process.
Types of Vulnerability Scanners:
In addition to the types of vulnerability scans which can be conducted, there are also different types of vulnerability scanners. The two main types of vulnerability scanners are: Server-based vulnerability scanners and agent-based vulnerability scanners.
Server or network-based vulnerability scanners run vulnerability scans from a single device or host. In this configuration, a single device attempts to communicate with all the devices it is set to scan. The benefit of this type of configuration is that most of the processing and resource utilization is limited to a single device on the network. The downside is that these types of scans can be slower and have the potential to overwhelm the resources provision to that single device.
Agent-based scans are scans which require an agent to run on each device in the network (or in-scope for your vulnerability scans). These agents will scan the device they run on, and then send information to a central server or other device to be aggregated to generate a report. The benefit to this type of configuration is that no device within the network will be overwhelmed because scanning is spread across devices. The downside is that a small part of the resources on every device in the network will be consumed by running this agent and require more configuration. Additionally, agent-based scans have the potential to consume more bandwidth on the network than server-based scans.
Which Type of Scans Should I Run?:
The answer to this question depends on which framework your organization is seeking to comply with. SOC 2, ISO 27001, HIPAA, and even GDPR do not specify the type of scan which should be run. In these cases, we recommend changing the type of scan you run so that you run different types of scans. For example, if you perform vulnerability scanning on a quarterly basis, you could run the first scan as an Authenticated, Internal Vulnerability Scan, and run the next quarterly scan as an Unauthenticated, External Scan. This approach will provide coverage for the different types of scans and the information which can be determined from different types of scans without overwhelming your Security team. In a heavily containerized environment, it might make sense to rely on container scans rather than dedicated internal or external scans.
How Often Should I Conduct Vulnerability Scans?:
The answer to this question will again depend on the standard your organization is looking to complete. SOC 2, ISO, HIPAA, and GDPR do not define a set frequency in which to perform vulnerability scans. Strictly speaking, HIPAA and GDPR don’t require vulnerability scans at all, however, implementing vulnerability scans can help to fulfill the security requirements of both. ISO 27001 and SOC 2 however will require a vulnerability scanning process, but don’t specify frequency. With that in mind, it is best to set a process that is achievable by your organization. Drata by default looks for quarterly vulnerability scans, this however can be edited. It may make sense to do them less often, such as bi-annually for smaller organizations who don’t have a large amount of changes within the environment, or more often such as monthly for organizations which are larger or frequently make changes to infrastructure and applications.
What Vulnerability Scanner Should I Use?:
This will depend on your organization, the type of scan you want to run, the familiarity of your team with specific software, and other factors. But we have listed some of the most common options below:
Nessus/Tenable.io/Tenable.sc - These are considered some of the most comprehensive vulnerability scanners around. All three products are made by Tenable. Nessus is a downloadable vulnerability scanner that runs like a traditional application. Tenable.io is a cloud-based scanner which fulfills the same purpose. Tenable.sc is a scanner that puts multiple scanning agents across your network and performs scans using those instead of a single scanner. Overall, these three pieces of software are industry gold-standard vulnerability management software with easy to use interfaces, however, they have the potential to cost more than other tools due to the features they provide.
AWS Inspector - AWS Inspector is an Amazon Web Services service which can be enabled within your AWS environment and is a good option for those organizations who are cloud native and would prefer to utilize services built into AWS. It is a paid service and is not as feature rich as other options, but is easy to use.
Azure Defender for Cloud - Azure Defender for Cloud is the equivalent of AWS Inspector for AWS. It does come with more features than AWS Inspector does, but for the purpose of this article, it does include vulnerability scanning. It has roughly the same profile as AWS Inspector in that it is good for organizations in Azure who would prefer to stay within Azure services and is easy to use.
GCP Security Command Center - GCP’s Security Command Center is GCP’s version of AWS Inspector and Azure Defender for Cloud. GCP Security Command Center is closer to Azure Defender for Cloud, in that it also includes additional features not related to vulnerability scanning. But like the offering from AWS and Azure, has the same profile, it is good for companies who want to stay within the GCP environment and is easy to use.
Intruder.io - Intruder.io is a highly comprehensive vulnerability scanner with a focus on prioritizing the highest risk vulnerabilities. Intruder is a good solution for integrating with cloud platforms natively and may make sense if your organization uses multiple cloud platforms simultaneously and wants to scan all platforms using a single tool. Intruder.io is a paid service which can perform both internal and external scans as well as more specific scan types such as web application scanning.
Qualys - Qualys is another popular vulnerability scanning solution, and was actually the first vulnerability scanner to be delivered using the Software-as-a-Service (SaaS) distribution model. Qualys is great for performing internal scans on large or complex internal networks as well as scanning cloud environments. It also provides an easy to use dashboard for tracking the results of scans. Qualys is a paid service and is comparable to the Tenable suite of products in terms of cost.
Nexpose - Nexpose is another industry standard vulnerability scanner sold by Rapid7. Nexpose has a feature set comparable to Tenable’s offerings or Qualys, but one area in which Nexpose shines is through its ability to scan mobile devices for vulnerabilities. If mobile device scanning is important to your organization, Nexpose may be the solution to choose.
OpenVAS - OpenVAS is actually an open-source fork of Nessus. When Nessus (which started as an open source product) was made into a proprietary, closed-source application, a team of developers opted to fork the open-source code prior to the change and continued development. OpenVAS is a completely free product with features comparable to Nessus, however, one thing to note is that as a free product, it does require more configuration than the packaged products listed above.
Nikto - Nikto is another open-source, command line vulnerability scanner which is completely free. Nikto is designed primarily to perform web application/web server vulnerability scans. If you are looking for a free tool for web application vulnerability scanning, Nikto is a tool to consider.
OWASP ZAP - OWASP’s ZAP tool is the final tool mentioned directly in this list. It is a free and open-source tool for web application vulnerability/security scanning, created and maintained by OWASP. If your organization is looking for a free tool for web application security/vulnerability scanning, ZAP is another option to consider.
Snyk - Snyk is a vulnerability scanning tool which is focused on code security scanning as well as container vulnerability scanning. Snyk is good if you want to focus on those two types of scanning, or want to focus on scanning infrastructure-as-code. Snyk integrates with a wide range of tools both on the code side, such as scanning code automatically within your IDE and integrating with Docker deployments to automatically scan containers as they are deployed. Snyk is a commercial/paid tool is but is easy to use and integrate with your technology stack as well as providing easy to understand reports to help manage vulnerabilities which other platforms might miss.
Other Tools - Other tools can of course be used, as long as they perform vulnerability scanning. Some commonly used tools like this are NMAP or Burp Suite. These were not included in this list, as NMAP is primarily a network mapping tool, which does offer some level of vulnerability scanning. If you plan to use NMAP, you should clear it with your auditor first. Burp Suite is actually a very comprehensive tool which includes a vulnerability scanning application. However, the product itself includes multiple tools which extend far beyond just vulnerability scanning. You can easily use Burp Suite’s vulnerability scanner, but the full suite of tools may be too much to pay for if you only need a vulnerability scanner.
What do I Need to Show the Auditor?:
There are two important pieces of information to provide to demonstrate your organization’s vulnerability management process. The first piece is the actual vulnerability scan report. The second piece of information to provide is any documentation showing that the identified vulnerabilities were remediated, or documentation that your organization has elected to accept some of the vulnerabilities and not remediate them. These two pieces of evidence work together to show that your organization has an effective vulnerability management process. It isn’t required to have a clean vulnerability scan report before showing your auditor, it is just important to show that you are working to identify and remediate vulnerabilities if they present a risk. New vulnerabilities are being discovered (and introduced) all the time and no organization can continuously address all vulnerabilities present, all the time. But by performing vulnerability scans and working to remediate the findings, you are demonstrating your organization’s efforts to get ahead of vulnerabilities before they can be exploited.