What are the advantages of Distributed Vulnerability Scanning?

Organizations with large networks can enhance their vulnerability scanning efforts by deploying multiple Nessus vulnerability scanners. This blog entry discusses the advantages of using multiple scanners for both Nessus users and Security Center operators.

Scanning Very Large Networks

Tenable customers use distributed scanning to scan networks that were either once out of reach due to size or to really minimize their scan time. A typical large enterprise customer may have 6-10 Nessus scanners targeting more than live 50,000 hosts across multiple Class B addresses spaces. Some of our customers who deploy one scanner per "customer" (like an MSP), or one scanner per state or business unit can have 25 or more scanners.

Our customers who perform scanning with the Security Center get a "hosts scanned per minute" value for each vulnerability scan completed. We don't publish raw numbers because there are dramatic differences between performing different types of scans such as a ping vs. a full port scan, host enumeration time-outs, the amount of "live" hosts on a given network and so on. Having said that, we have some customers who scan more than 5000 IP addresses in a minute as part of scanning many times more than that.

Having this baseline for scan performance can really help detect scan time changes when more Nessus scanners are added, when scan policies (such as different maximum hosts and maximum checks per scan) change or when new hardware is used for the scanners.   

Decreased Scan Time

Using more than one scanner can be much faster than a single scanner. There are a few concepts to consider though.

For manual scanning of large networks, it is much more efficient to break the target lists up into smaller scan jobs. This way you won't have a Nessus scanner sit idle if it finishes its task early. If your Security Center is managing the scan jobs, then it does this automatically for you. 

Adding more scanners with much less CPU or memory capacity might not reduce your scan time. This may be obvious to some readers, but Tenable has had customers add more Nessus scanners as "VMWare" images on top of the same server. This actually slowed down their scanning time. We've also had customers start out scanning with multiple Nessus scanners on high-end Xeon servers and then add 256 Mb laptops running Nessus on Windows. They didn't get much increase either. As a general rule though, if you add more scanners on similar or better hardware then you currently have, then you should see an decrease in your scanning time.

Lastly, at some point, adding more and more Nessus scanners could create a choke point on the network. If your link to the network you are scanning is through a T1 or cable modem, adding more powerful scanners might not speed things up. 

Internal and External Perimeter Scanning

If your organization has policies which require the use of access control devices such as firewalls, web proxies or filtering routers, then performing vulnerability scans is not straightforward.

If your scanners are on the outside of the perimeter, then you may be able to scan at the same levels that an outsider would. Your Nessus scanner would only be able to see the same sort of ports and services that are open to everyone else. This may be by design, but this also can deprive a security audit of useful information that the perimeter is protecting.

Similarly, placing a scanner on the inside of the network can show everything. However, when vulnerabilities are found it is possible to argue that they are protected by a firewall.

Placing a scanner on the inside of the network and the outside may be the answer. Performing two scans can show an external view, as well as an internal view. Both of these scans can be used to measure the relative exposure or risk depending on where they are at.

Security Center organizations can give out the ability to perform scans from specific groups of Nessus scanners called "zones" as a user privilege. When combined with large numbers of scanners, these "inter-zone" scans can be used to not only scan network perimeters and inside the perimeters, but can be used to scan other groups in an effort to look for trust relationships that should not be there.

For example, consider that business Group A and Group B both have a firewall and don't present a lot of services to the outside world. Group B may also "trust" Group A with IP access control "permit" rules or even a dedicated VPN. Performing a vulnerability scan with Nessus scanners in Group A to the Group B network can find this sort of connectivity.

More Accurate Topology Discovery

Using multiple scanners can also help increase the accuracy of your network topology discovery. The basic tool used by Nessus is to perform a traceroute from each scanner to each target. If a certain Nessus scanner traces the route to host A and host B, it will likely get a a list of routers between each scanner and those hosts. However, this may not include a set of routers that host A and host B would use to communicate with each other.

By using multiple Nessus scanners AND telling them to conduct traceroutes to other parts of the network besides their local network, a more accurate list of devices and their connections can be obtained.

With accurate maps, Security Center users can create very interesting 3D visualizations of their networks and asset groups such as shown above.

Less Stress on the Network Infrastructure

Lastly, when considering deploying more than one distributed Nessus scanner users should realize that there is actually less stress placed on the network during scans. Notice that I said "distributed". If you placed many Nessus scanners at one point on your network and started scanning, you could easily choke your local network segment. For truly distributed scanners though, this isn't the case.

This is because each host should only get scanned once. If one were to perform the same scan manually across your target networks or automatically with the Security Center, the same number of packets will be sent to find hosts and probe them for vulnerabilities. Conducting these scans from Nessus scanners placed closer to their targets won't have the port scans and vulnerability probes travel across the infrastructure. This means that backbone devices won't be carrying the extra bandwidth from the scan or have an increased amount of simultaneous network sessions. A fragile device which won't stand up to a regular scan still won't stand up to a distributed scan, but your backbone will be much less exposed to carrying some sort of traffic which is could have an adverse effect.

In particular if your scans are flowing through web proxies, firewalls or VPN devices, they may be limited in what they can find. Each of these devices may have a maximum number of simultaneous connections, drop UDP (and even TCP) packets excessively under load and can generally lower their availability or responsiveness during scans. Keep in mind that since these devices are security devices, they may inherently have design features to specifically prevent vulnerability scanning. 

For More Information

Tenable has a white paper available which discusses this sort of technology in much more depth. The paper is titled "Dedicated and Distributed Vulnerability Management" and can be downloaded here. We wrote this paper in 2002 and have been helping customers deploy large numbers of multiple Nessus scanners for over four years.