Mike.Vasquez@cityofmesa.org 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
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
