What is Vulnerability Scanning? + Frequently Asked Questions

Part of achieving and maintaining compliance for frameworks and regulations like SOC 2, HIPAA, and ISO 27001 involves implementing a process for identifying and assessing security weaknesses within your organization. And although penetration testing can provide a thorough assessment of your company’s vulnerabilities and threats, it’s not always necessary or within budget. 

This is where vulnerability scanning can help. Vulnerability scanning can be used as a standalone, high-level assessment of your IT environment or as the first part of a pen test.

In this article, we’ll go over the types of scans you can run, what they help detect, recommended frequencies, and what you need to show your auditor to demonstrate your vulnerability management process. 

What is Vulnerability Scanning? 

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. 

Vulnerability scanning is considered a key control because of the information 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. 

However, there are multiple types of vulnerability scans which can influence the amount and types of vulnerabilities detected.

Types of Vulnerability Scans

There are several ways to categorize vulnerability scans. One is to break them down by where the vulnerability scanner is running from. Using this division, we get internal and external vulnerability scans. 

Another way to divide vulnerability scans is to consider the level of access the vulnerability scanner will run with. In this case, the two types of vulnerability scans include authenticated or unauthenticated scans.

Although there are other types of specialized vulnerability scans, two that are becoming increasingly common 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. Here’s a breakdown of each: 

Internal

Internal vulnerability scans are conducted from a location that 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 your data center, it doesn’t have to pass through your public-facing firewall. And because of this, it 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.

External

An external scan 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!).

Authenticated 

Authenticated scans, sometimes referred to as credentialed scans, give the vulnerability scanner credentials to access the resources it’s scanning. An example of this would be giving the vulnerability scanner an administrator- or 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 with no provisioned access.

Unauthenticated

Unauthenticated scans (or non-credentialed scans) 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’s 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.

Container 

Container scans are 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. It must also be able to 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 

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’s usually a part of your Software Development Lifecycle process, rather than a separate Vulnerability Management process.

Which Type of Scans Should I Run?

The answer to this question depends on which framework or regulation your organization is seeking to comply with. SOC 2, ISO 27001, HIPAA, and even GDPR do not specify the type of scan you should run.

In this case, we recommend rotating the type of scans you run so that you run to cover your bases. For example, if you perform vulnerability scanning on a quarterly basis, you could run the first scan as an authenticated, internal vulnerability scan. The next quarter you can run an unauthenticated, external scan. 

This approach will provide coverage and key information from each type of scan 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. 

On the other hand, ISO 27001 and SOC 2 require a vulnerability scanning process, but don’t specify frequency. With that in mind, it’s best to set a process that is achievable by your organization. 

By default, we recommend quarterly vulnerability scans, however, it may make sense to do them less often. For instance, smaller organizations that don’t have a large amount of changes within the environment might consider bi-annual scans. Whereas larger organizations or those that frequently make changes to infrastructure and applications might benefit from monthly scans.

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 it to your auditor, it’s just important to show that you’re 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.

If you’re ready to automate your journey to compliance for multiple frameworks and regulations—including continuous control monitoring and evidence collection—book some time with our team to get started.