[EMAIL PROTECTED] wrote: > I'd be interested in hearing from anyone who has enterprise level > deployments of Nessus, and how you handle a few items, for those that are > able to share:
I would like to share some of our customer experiences that capture larger Nessus deployment as well as Security Center users in the enterprise. > 1) With regulations such as PCI requiring production network scanning -- > when do you scan? Downtimes? Daytime, etc? Across the customers we deal with, there is a wide variety of scan frequency times as well as combinations of big scans and little scans. The more "managed" an asset is (such as production systems) the more often they are scanned. I think it is very common to scan production servers once a week or more often. Many of our PCI customers that use the configuration audits perform these scans on a daily basis. These would be credentialed patch audits and configuration audits. > 2) What has your experience been with outages, overload, etc based on the > above? How have you mitigated the risk of overloading network devices > with sessions, device failure, etc? Anything that goes wrong during a scan will get the scanner blamed. We've actually replaced some of our competitor's products at various organizations because Nessus had less impact. Anyone who is concerned about impact should also look at the Passive Vulnerability Scanner. Our customers who have this product scan less often with their Nessus scanners. Having said that, we haven't seen a firewall outage or modern server outage in a while. We have had people scan the IPs of older unpatched switches and flip a switch, however scanning through the switch has no effect. Very rarely do we have people complain about new plugins or fingerprints having impact on existing systems. Issues only arise when people scan something new for the very first time, or something drastically changes in the network such as a roll back of firmware in a network device. One other thing that is occurring more and more are IPS devices which respond with live IPs or fake services. If these devices are configured to offer fake results, Nessus finds them just as well but scans do take longer because there is more to scan. > 3) What settings as far as throttling/sessions/# hosts, have you found to > be most efficient (and over what sort of network, fast ethernet\gb, etc) This really depends on the target network, the power of your Nessus scanner and the type of scan you are trying to accomplish. It also depends on if you want your scans to complete as fast as possible or have as little effect on the network as possible. For fast as possible, I suggest watching the CPU of your Nessus scanner and slowly increase the number systems to scan at the same time. > 4) What settings for safe checks, port range, paranoia, thorough -- have > been most effective as a balance between accuracy / false positives / > speed? At the enterprise level, it is really a decision between scanning with credentials and scanning without them. Some organizations have implemented the Passive Vulnerability Scanner as an alternative to getting credentials for their Nessus scanners. > 5) Have you implemented workstation scanning? Do you scan all? A pool? > Rotate quarterly? Almost all of our federal customers scan the desktops with credentials. Things like the new FDCC standards require this sort of reporting. In commercial and academic organizations, credentials are usually used to audit the servers, not the end nodes. We have more and more customers that use the Passive Vulnerability Scanner for the realtime "big picture" of the vulns on their network than scanning with full credentials on user desktops. > 6) For those using a distributed scanner architecture -- what's been > effective? what did you "do wrong"? What do you wish you'd done? > Tips/thoughts? Our largest customers scan IP ranges in the 300k active IP range with a single Security Center and 30+ Nessus scanners. These organizations have bandwidth, stable servers to run Nessus and SC3 on and have also deployed their scanners redundantly in case one goes down due to power failures, hardware, network connectivity, .etc. Having said that, we also have customers who don't have reliable networks and they will litterally lose connection to their remote Nessus scanners because the Security Center can't connect to it for a signification amount of time. Often there is a VPN, firewall or otherwise unreliable link between the Nessus scanner and the Security Center. I'm not saying that you shouldn't deploy a scanner on the other side of these sorts of technologies, I am saying that you should consider the uptime and availability of those devices as it will effect the availabiltiy of your Nessus scanner. > 7) Thoughts on Security Center as a management tool for distributed > scanning? Of course I am biased, but from a pure Nessus point of view: - It updates each Nessus scanner with the Direct Feed and latest plugins. - It intelligently combines all of your scan results into one "cumulative view" such that the latest vulnerability data per port, per host is always up to date. - It also combines the realtime results of the Passive Vulnerability Scanner so you can see what has been recently added, changed or discovered. - It intelligently distributes a scan across your Nessus scanners or allows you to say that the scan should just be performed from one set of scans. This is cool for seeing what vulnerabilities are visible from across different organizations. There are plenty of demos and webinars online here: http://www.nessus.org/demos/index.php?view=demo_videos Ron Gula, CTO Tenable Network Security _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
