Developing an enterprise scanning program is, by necessity, a highly customized task. You can't simply take a stock plan off the shelf and implement it in your organization. You need to consider the unique technical, regulatory, political and cultural requirements facing your enterprise before launching this inherently intrusive activity. For example, the scanning program used by a research university would necessarily be quite different from that used by an ultra-secret government agency. Both plans would differ significantly from the scanning plan used by an e-commerce retailer. Let's look at a few broad principles that apply in any large enterprise.
- Don't keep scanning secret. Over the course of my career, I've seen many organizations implement vulnerability scanning programs for the first time. With very few exceptions, the security officials responsible for the program decide that the best way to launch this effort is to treat these scans as a tightly-held secret. Invariably, this backfires. The primary reason is political – you don't want system administrators to feel that you're policing their configuration management. On the contrary, the goal of your scanning program should be to increase administrator awareness and assist them in the secure configuration of their systems. A scan that produces very few results is a successful scan!
- Coordinate your scans widely. This advice goes hand-in-hand with the previous tip. In addition to notifying system administrators, make sure that everyone who's even tangentially affected by your scans knows what you're doing. Remember that the scanning process can have unforeseen effects on your infrastructure. You certainly don't want your company to become aware of your new scanning procedures because they brought the network to its knees! Notify system administrators, network engineers, application administrators, management and support personnel of the scans in advance – they will serve as an early-warning system if problems arise. This is especially true the first several times you scan systems.
- Balance the risks and benefits of scanning. Some scans may produce unpredictable results. If you're running scans for vulnerabilities that might produce a denial of service when exploited, the scan itself might induce that denial of service. As a remedy, you may wish to enable the "All but dangerous" option in Nessus for the majority of your routine scans and then perform periodic full scans on a highly coordinated basis. (Don't, however, decide that you'll never run the dangerous scans because you're not the only one with a copy of Nessus – the bad guys also have it!)
- Provide a self-service option. If possible, allow administrators to initiate scans on their own. With Nessus, you can simply create accounts for them using the nessus-adduser command. You can also create rules that limit the systems that individual users may scan. For example, if an administrator is only responsible for the 192.168.53.x subnet and the individual server 192.168.22.13, you might use the following rules to limit the access for that user:
accept 192.168.53.0/24 accept 192.168.22.13 default deny
Nessus 3 uses a directory-based user structure. Rules (such as those in the example above) are placed in a file named rules in the C:\Program Files\Tenable\Nessus\users\username\auth directory.
Allowing users to initiate their own scans lets them go above and beyond your enterprise scanning program. For example, administrators might want to self-initiate scans at various points during the system build process or after making configuration changes on a system.
Hopefully, these tips gave you some good general advice on incorporating Nessus into your enterprise security architecture. In the final installment of this series, we'll take a look at building reports using Nessus output.
Introduction: What is Nessus?
How to install and configure Nessus
How to run a system scan
Using Nessus Attack Scripting Language (NASL)
Vulnerability scanning in the enterprise
How to simplify security scans
How to use Nessus with the SANS Top 20
|Mike Chapple, 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.|
This was first published in June 2008