How do you handle vulnerability scanning on your enterprise network? If you're like many of your peers, you've...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
either invested in an expensive enterprise-wide commercial vulnerability scanner, or you've jury-rigged an open source product to keep within a shoestring budget. For most organizations, neither one of those approaches is entirely satisfactory: the former involves a potentially excessive commitment of financial resources, while the latter sacrifices security and manageability in the interest of saving a buck (or a hundred thousand of them!).
Enterprise-class vulnerability scanning systems, such as Qualys Inc.'s QualysGuard and Tenable Network Security's Security Center, offer many advantages over freely available security tools. They often combine database-driven, trend-tracking capabilities with reporting facilities designed to meet the demands of both technical professionals and executive management. However, the products often come with a hefty price tag based upon the number of IP addresses covered by their licenses. In larger installations, the cost of implementing such a system may quickly rise into the low six figures.
For the vast majority of networks, widespread deployment of an expensive scanning product is overkill; security dollars are better spent elsewhere. These systems provide value, but I instead advocate a hybrid model: use an expensive tool where it delivers the most value, and deploy an open-source one for the vast majority of the network. I've seen several organizations successfully implement a combined approach to optimize use of security resources.
Why do multiple vulnerability scanners work?
On most networks, productivity workstations comprise the bulk of network-connected computers. In many organizations, security configuration standards limit the network exposure of those systems to a very small set of ports -- if any at all! If you run a network vulnerability scan against a system configured in this manner, it's merely confirming that the firewall is functioning properly. This verification is valuable, but there's a cheaper way to accomplish the same objective: use the time-tested tool that holds a place of honor in every security practitioner's toolkit: Nmap.
The hybrid approach to vulnerability scanning requires the prioritization of assets into two groups: servers and workstations. (Alternatively, you could divide them into categories based upon other value-ranking criteria: strength of data assets, importance of operating system, or anything that makes sense in your business environment.) Use a commercial scanning tool to keep tabs on your high-value server assets. They're a more likely source of potential exposures, as they're intended to offer services to other systems.
Meanwhile, use Nmap to handle the remaining workstations and lower-value assets. Write a simple script that periodically runs Nmap scans against your network, finds open ports, and stores the results in a database. You can use the language of your choice, but I prefer to use Perl and the free Nmap::Scanner library. Here's the pseudocode to scan a network:
- Start an Nmap scan of the system, using parameters tuned for your environment.
- Remove any ports from the results that are part of your standard workstation build, such as remote administration ports.
- Retrieve prior scan results from the database and remove any ports from the results that were previously reported.
- If any ports remain in the results, report them to the administrator to either accept or investigate.
- Move on to the next system.
Once you've done this a couple of times, you should have a pretty stable baseline. There should be only occasional reports, most likely the result of a system exposing a new service that differs from the baseline build. When this occurs, examine the system and determine which of three cases applies:
- The system is actually a server and should be added to the enterprise scanner.
- The system is a workstation that is not authorized to offer the service and should be remediated.
- The system is a workstation that is authorized to offer the service, and this should be noted in the database to prevent future false positive reports.
With this approach, it Is possible to miss a vulnerability on a workstation. Nmap doesn't perform vulnerability assessment; it's only a port scanner. If something more sophisticated is needed to spot flaws, consider using an automated Nessus-based approach instead. However, this open-source and commercial product combination will surely satisfy the Pareto principle, allowing you to achieve many of the enterprise scanning system benefits for a fraction of the cost.
About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.
Michael Cobb examines how a solid application vulnerability scanner can be a valuable part of an enterprise's development strategy.
Need more help with Nmap? Learn how to scan ports and services.
Find out the top five freeware tools that can spot your network vulnerabilities.