The biggest consideration when scanning for vulnerabilities is that your scanner will only report what it can recognize. It compares what it finds to a list of pre-canned, known vulnerabilities. Unlike antivirus or intrusion detection software, your average vulnerability scanner cannot use behavior analysis to identify unknown, zero-day vulnerabilities. For this reason, vulnerability scanning should only be one part of a multi-disciplinary approach to testing your security controls. You should update your scanner regularly, and scan frequently. Consider using multiple tools and cross-correlating results. Some organizations even outsource security scanning to cloud-based services that have databases with tens of thousands of vulnerability signatures.

Another major consideration is to validate vulnerabilities that you do find. Many vulnerability scans produce false positives, or report vulnerabilities that can't actually be exploited. The most common way to validate is to attempt to actually exploit the vulnerabilities and produce evidence of success. Some exploit tools such as Metasploit can directly import the results of a vulnerability scanner and then attempt the exploit.

You should also keep in mind the limits of your scanning tools. Exploit tools such as Metasploit have some built-in vulnerability scanning capabilities. However, this is not Metasploit's primary focus, and its scanning is not comprehensive. This is why you should use an actual scanning tool such as OpenVAS or Nexpose to conduct the scan, and then have Metasploit validate the results. Some tools, such as Nmap NSE scripts, are also out-of-date. Do not rely on any single tool for a comprehensive scan.

Additional Considerations

Some additional things to consider when it comes to vulnerability scanning include:

  • Some vulnerability scans take a great deal of time to run—especially web app scans, which can take days. You may need to configure the scan to run at a more superficial level, or you may need to simply stop scanning after a certain amount of time or until you get a satisfactory amount of results.
  • A scan may use one or more protocols to actually identify, process, analyze, and output vulnerability information. Some protocols are more useful in certain situations than others. For example, application of the Security Content Automation Protocol (SCAP) is mandatory for U.S. government agencies, and is therefore leveraged by several common scanners.
  • The target network's topology can make scanning more or less difficult, as well as impact the results of the scan. For example, in a network that is properly segmented, you may be unable to scan hosts outside of the segment in which you are conducting the scan.
  • Intensive scans can consume a significant amount of bandwidth, especially if several concurrent scans are running against multiple hosts. This can delay the scans or disrupt them entirely. You may need to consider throttling the number of queries launched by the scanner in order to overcome bandwidth limitations.
  • Query throttling can also help you avoid issues with fragile systems and other non-traditional assets that have weaker hardware or are inherently unstable. The less overhead the target needs to deal with, the less likely it is to experience delays, become unresponsive, or crash entirely.