Unlike consultant-led penetration testing, periodic or continual vulnerability scanning programs have to operate harmoniously with a corporation’s perimeter defenses.

Firewalls, intrusion prevention systems, web proxies, dynamic malware analysis systems, and even content delivery networks, are deployed to protect against the continuous probes and exploit attempts of remote adversaries—yet they need to ignore (or at least not escalate) similar probes and tests being launched by the managed security service providers an organization has employed to identify and alert upon any new vulnerabilities within the infrastructure or applications that are to be protected.

Just the other week I was asked by a prospect whether they should whitelist the IP addresses of the systems tasked with continually scanning their Internet accessible servers and web applications, or should they let those scanners be subject to the same defenses and blocking as any other “attacks”?

The simple answer is “Yes—whitelist the source IP addresses and let those scanners uncover all the infrastructure and application flaws they can”. The more verbose answer to the question requires a greater understanding of how both vulnerability scanners and perimeter defenses are developed and what they’re really capable of bringing to the table.

What is the purpose of continual vulnerability scanning?

The primary purpose of continual vulnerability scanning is to quickly identify and alert on any new vulnerabilities uncovered in Internet accessible systems. The scanning isn’t meant to replicate how an attacker would uncover or exploit systems—that’s what penetration tests are for (and why you should also conduct them regularly). Consequently, “defending” against your managed security service providers scans—while it may be pleasant to have reports or management portals with no findings and a clear status—is not only a poor security choice, but most likely to be money down the drain.

Arguably the most important perimeter defense system in common use today are intrusion prevention systems (IPS). Firewalls or any of the “next generation” prefixed versions of firewalls are a close second—but I’d happily argue that current generation IPS encapsulate all the security capabilities of firewalls already. As such, let me use IPS as an example of how scanning and perimeter defenses operate in a contradictory yet harmonious way… from the perspective of someone who spent several years being responsible for the R&D of both IPS and vulnerability scanning technologies at multiple companies.

Every IPS sales person and vendor will tell you that their IPS appliance, software, or cloud service, is designed to stop all attacks. “All” is clearly an optimistic statement, yet IPS technologies are pretty reliable at detecting vulnerability scanners, out-of-the-box commercial exploit products, and non-obfuscated exploit techniques. For specific classes of threats or well documented networking protocols, IPS can and do often offer basic zero-day exploit detection on occasion (which will be clearly documented and time-lined in any PowerPoint presentation the vendor sales team can hope to get in front of you). In many cases you’ll also hear the term “virtual patch” being used; i.e. the vendor has a detection signature or algorithm that will block “all” exploit vectors for a particular vulnerability, giving the organization time to roll out the real software patch to all physical servers.

If that’s how IPS are supposed to work, what’s the contradictory story?

IPS are designed to protect network-based attacks, vulnerability scanners are designed to identify vulnerabilities, and scanning vendors have gone out of their way to ensure that the methods they use to reliably detect a vulnerability does not contain exploit material or leave a targeted system or service in an unusable state. Therefore, by that very definition, the scans launched by a vulnerability scanner are neither exploits nor attacks, and any IPS raising an attack alert must be a false positive.

From an IPS vendor’s perspective, they’re damned if they do and damned if they don’t. At some point in time every organization with a deployed IPS will run a vulnerability scanner against the systems it’s supposed to protect. If the scanner finds any vulnerabilities, the organization will chastise the vendor for not “protecting” against the scan—whether or not they successfully argue the difference between a vulnerability test and an exploitation of a vulnerability. As such, every commercial IPS vendor buys every other commercial vulnerability scanner and runs them repeatedly against their IPS products—adding new signatures or alerts for pretty-much every test those scanners can run. If you have deployed IPS systems to protect your organization and a vulnerability scanner has identified vulnerabilities in the infrastructure it’s supposed to be protecting, then there’s a highly probably your fault (i.e. someone has misconfigured your IPS or hasn’t turned on the relevant alerting functions).

In that context, if you’ve subscribed to a continual vulnerability scanning service and have deployed appropriate perimeter defenses, the vulnerability scanners should not find any vulnerabilities. Unfortunately, not finding vulnerabilities is not nearly the same as not having exploitable vulnerabilities.

Traditional perimeter defenses

Traditional perimeter defenses are good at finding the “known knowns”, yet struggle or fail with “unknown knowns” and customized exploits. While an IPS may be good enough to detect and block a vulnerability scanners test of a “protected” vulnerability, too often it will not prevail and instead be circumvented with a customized or non-generic versions of an exploit; which incidentally is getting easier and easier for attackers to do

Finally, this leads me to the “harmonious” part of the story…

By whitelisting the source IP addresses of the managed security services continually scanning web applications and infrastructure, an organization can observe the true state of their Internet accessible services and work on mitigating the underlying threat—while employing IPS and other perimeter defenses to buffer in-bound attacks and enumerating the source of real attackers.

If that symbiotic harmonization between IPS and vulnerability scanning isn’t enough, then I’ll leave you with one last reason why blocking legitimate vulnerability scanning is unlikely to be in your organizations best interest—HTTPS. In almost all cases encrypted network traffic will pass uninspected by an organizations perimeter defenses. If your web application provides services over HTTPS any attacks against the application over HTTPS will be undetectable by your network-based (and likely host-based) IPS. So, let those vulnerability scanners do their work for you and identify the vulnerabilities you need to fix.