SecureState Blog

Read SecureState's award winning blog.

Do vendors request whitelisting just to inflate numbers?

I have been performing Vulnerability Assessments for many years and I still hear the same objection almost every time I tell the client that they need to whitelist our scanner’s IP addresses in their Intrusion Prevention System (IPS) before running the scan! The objection is something like “If I whitelist these IP addresses, then I will not get an accurate view of my current security posture.”

The logic goes something like this:

1.)  The vulnerability scanner looks for vulnerabilities on the devices on the client’s network.
2.)  An attacker looks for vulnerabilities on the devices on the client’s network.
3.)  If the IPS identified and stopped the vulnerability scanner from completing its scan
a.) Then the IPS would also stop an attacker.
4.) Thus, if the IPS stops the scanner
a.) Then I am also safe from an attacker.

There are many problems with this logic! In this blog, I will address the major problems.


The Sleeper That Was Never Found

The IPS may block the scanner’s IP address before it has the opportunity to discover some of the more severe vulnerabilities in a particular device. This may occur because of the way that vulnerability scanners work. Vulnerability scanners work by sending specifically crafted traffic to a device on the network and then looking for specific patterns in the way the device responds. For example, the scanner may place a single quote in a form field of a web application and then analyze the way the web application responds to the request. If the web application is vulnerable to error based SQL Injection in an MS-SQL database, the web application may respond with a web page that contains the words “ODBC” somewhere in the response. When the scanner parses through the response and identifies this pattern, it will probably flag the application as being vulnerable toSQL Injection. Now, a vulnerability scanner cannot check for all vulnerabilities at the same time. It has to spread all of its vulnerability checks out over a period of time. Suppose that the vulnerability scanner is just looking for open ports (which many vulnerability scanners do as a first step in order to know which checks to perform) and the IPS recognizes the pattern of a port scan and blocks the IP address of the vulnerability scanner, before it has the opportunity to look for any particular vulnerabilities. However, this does not mean that the web application is safe from being compromised. Suppose that an attacker is just browsing a company’s website without performing a port scan of the server. The attacker sees a login field and places a single quote in the username field. The website then responds with a SQL error message. In many cases SQL Injection can lead to a full compromise of the server that the database is running on. If the IPS is not fine-tuned to look for certain SQL Injection attacks, or if the attacker is able to obfuscate the attack in such a way as to bypass the IPS, then the attacker may be able to compromise the underlying operating system of the vulnerable server. In this case, there is a good chance that the vulnerability scanner would have identified and alerted on this vulnerability, had the IPS not interfered with the vulnerability scanner. Thus, it is more beneficial to allow the web application scanner to run all of its vulnerability checks rather than blocking the scanner from finding these vulnerabilities.

There is an important distinction between a real attacker and the vulnerability scanner that must not be missed. Most attacks are going to be as stealthy as possible. They may spread their attacks out over a period of months in order to try and bypass the organization’s IPS. The vulnerability scanner is noisy because it is trying lots of attacks over a small period of time, thus the scanner is more likely to trigger a response from the IPS. Thus, while a scanner may get blocked before identifying a particular vulnerability this may not be the case when it comes to an actual attacker.

Screenshot of host scanned with Qualys’ vulnerability scanner


The Machine That Was Never Scanned

The second problem with the client’s logic is closely tied to the first. Most vulnerability scanners can be configured to scan an organization’s entire external presence. In many cases it scans only a few of these devices at a time before moving on to other devices on the network. Suppose that the organization has one device that is locked down like Fort Knox and a second server that contains more security holes than Swiss cheese. Now, suppose the IPS sees a bunch of what appear to be attempts to exploit the more securely configured server and responds by blocking all traffic from the scanner. In this case, the IPS blocks the scanner before it is ever even able to scan the more vulnerable server. Now, suppose that an attacker does some Google searches for the sites that the organization owns. The attacker connects to the more vulnerable site without ever even touching the securely configured server. In this scenario, although the IPS stops the vulnerability scanner from ever even having a chance to scan the more vulnerable device, the attacker has no problems directly connecting to the more vulnerable site because it never touches the less securely configured device. Thus, equating the way an attacker works with the way a vulnerability scanner works quickly breaks down.

Defense In Depth

The truth is a vulnerability scanner’s main goal is not to test the configuration of an IPS. It is important to test the IPS’ configuration, but that is not the primary purpose of a vulnerability scanner. The scanner’s main purpose is to identify misconfigurations, missing patches, vulnerable services, etc. It is important to know the vulnerabilities on the devices within the organization’s network so that the organization can remediate these vulnerabilities. Ideally, the organization has both locked down their devices as well as implemented an IPS. If the IPS fails to perform its function, then perhaps the locked down device is able to withstand the attack and vice versa. By layering controls, a single control failure may not result in a total compromise of the device on the network. The IPS may not always catch attempts to identify and/or exploit specific vulnerabilities on a particular device. When the IPS fails it is vital that secondary controls are able to prevent a successful compromise of a particular device on the network.


In all actuality, the main purpose behind a vulnerability scan of an organization should be to audit existing security controls. These controls include change managementpatch management and system hardening. Vulnerabilities are normally the result of breakdowns in existing programs, or testify to the fact that the organization is lacking the security programs which should already be in place. However, although a vulnerability scanner may be used to test some of the capabilities of an IPS, its main purpose lies outside of this function.