Tenable Network Security is pleased to announce the immediate availability of Nessus 3.0.4 which includes changes to the nessusd daemon, specific changes for Nessus 3 running on Windows, specific changes for Nessus 3 running on OS X and changes to the Nessus command line client.

Tenable has also released Nessus 2.2.9 and Nessus Client 1.0.0.

These releases can be obtained by visiting http://www.nessus.org/download/ for downloading.

This new release contains the following enhancements and fixes :

Nessus 3.0.4 daemon

• Processing the plugins after an update is faster
• Better detection and handling of corrupt db files
• It is now possible to use 'default' in a port range just like any other port (ie: '1,default,443,8080')
• Avoid a deadlock in the main process when waiting for a sub process to die
• nessus_tcp_scanner works much better when used over a slow network link
• nessus_tcp_scanner now offers some options accessible thru the GUI
• If 'log_whole_attack' is set to 'no' , do not print messages about shared sockets in the logs
• Fixed the 'on_exit()' nasl function
• Fixed 'nasl -k' which would sometimes not work properly
• Avoid doing some un-necessary system calls, thus resulting in a lower load during a scan (esp. on Mac OS X)
• Fixed a bug in ssh_func.inc which would prevent it from working against HP/UX
• Binaries for Fedora Core 6

Nessus 3.0.4 Command line client

• Logs much faster into a remote nessusd scanner
• Fixed a possible memory corruption issue when creating a list of plugins to launch
• Fixed a corruption of the .nessusrc files when receiving some plugin prefs ending by a space

Nessus 3.0.4 Mac OS X specific changes

• Opening and closing a session window would stop all on-going scans
• Creating a policy and defining it as 'shared' immediately saves the policies on disk

Nessus 3.0.4 Windows specific changes

• Not a beta any more
• Fixed file lock issues

Nessus 2.2.9 Daemon

• Fixed a bug in the PCAP handler which in turn fixes synscan.nes (thanks to Marcel <mkalracuesl (at) gmail.com>)
• Fixed a banner encoding problem in nessus_tcp_scanner and find_service
• Fixed a possible deadlock in synscan.nes
• Avoid a deadlock in the main process when waiting for a sub process to die
• nessus_tcp_scanner works much better when used over a slow network link
• nessus_tcp_scanner now offers some options accessible thru the GUI
• Fixed a bug in ssh_func.inc which would prevent it from working against HP/UX

Nessus 2.2.9 Client

• Fixed a possible memory corruption issue when creating a list of plugins to launch
• Fixed a corruption of the .nessusrc files when receiving some plugin prefs ending by a space

NessusClient 1.0.0 released

• Much faster to load
• Fixed various minor bug fixes
• Binaries for Fedora Core 6

I was on an enterprise vulnerability management panel at the recent Infosecurity show in NY City. On the topic of patch management, a question was asked about using severity ratings for vulnerabilities to select which patches to apply, or the prioritization of which patches to apply first. This blog entry captures my comments from the panel and my general thoughts on the subject.

Don't Let Your Vulnerability Scanner or Penetration Tool dictate your patch policy!

I'm running into more and more people who use Nessus or a penetration testing tool like MetaSploit to discover the "serious" vulnerabilities on their network with the intent to just patch those. This can fail for several reasons.

First, consider three Microsoft Exchange servers, all equally configured except you have credentials for one, the other is behind an IPS and you can only scan the third one. Your vulnerability scanner will likely give you different results for each server, even though they are configured the same.

Second, as far as scanners go, your penetration tool, vulnerability scanner or patch auditing system aren't all built the same way. They may indeed be able to test for vulnerabilities only one way. At Tenable, we often try to make sure we can perform both a remote network check for Nessus, but also try to back it up with a host based check. We extend this even further trying to be able to "sniff" the vulnerability with our PVS. The point is though, that scanner to scanner, you may have different detection algorithms.

And third, even if you have accurate detection, your scanner vendor may set different severity levels for the vulnerability. At Tenable, we include a risk factor, a CVSS score and a severity level for most vulnerabilities detected by Nessus or the PVS. What we score something at may be very accurate or not for your organization. More than 100,000 organizations trust us to write Nessus checks for them, but I would not argue that they should make patching decisions solely based on what Tenable's research group says.

So unless you are very careful about what you are scanning, using solely the results from your scanner can lead you to inconsistent patch levels on the systems you are trying to secure. This can make applying future patches more difficult since there may be different patch levels or dependencies.

Patching Polices That Scale

If you are part of an organization that is always patching based on the latest threat, you will be expending many cycles always being reactive. Instead, it is much better to align patching process with business processes.

Consider those Exchange servers I was mentioning before. I would consider a mature IT organization to manage those servers exactly the same, with a consistent patching policy. Such a policy would include a timeline to test patches and to install them.

It would also include guidance for what sort of patches to install. This could include the use of 3rd party patches. It could also recognize that a patch for "Google Desktop" is indeed available, but that application isn't authorized to run on that system.

The point is that we shouldn't be surprised by new vulnerabilities and leap into action to test how vulnerable our network is to them. This will only lead us into more and more random configurations of our network. Instead, setting patching policies which make sense for each key asset allows for more scalability and consistency than simply applying patches because they are available.

Working with Network and Patch Management Systems

I've blogged last month on some reasons why patch management can fail. In the context of this blog entry, I'd like folks to walk away with the idea that their vulnerability discovery process should be part of their change control and network management process:

• Systems with vulnerabilities should be evaluated to see if they are being "managed". This means that the system is actively being patched and has a configuration consistent with IT policy.
• All "managed" systems should be evaluated to see if the service level agreements (SLAs) for applying patches are indeed being met. This means that the vulnerabilities you do find should only be "new" ones or ones the organization has chosen to accept the risk for.
• Vulnerability detection (both passive and active) can be used to look for both authorized and un-authorized changes, which may have impact on network management and compliance

Where Tenable Can Help

Nessus and the PVS can obviously be used to discover vulnerabilities, but for independent auditing of the network as a business, the Security Center can be used to help answer many of the questions raised here including:

• detection of vulnerabilities by unique asset type (i.e. a corporate laptop vs. the Exchange server)
• mis-configuration issues for specific asset classes (i.e. all corporate laptops need to have "AutoRun" disabled for CDs and USB drives)
• tracking the life-cycle of vulnerabilities and patches by unique business groups and corporate assets
• communicating clear mitigation tasks with IT about configuration changes, corporate patching policy and their specific vulnerabilities

If you'd like more information about the Security Center, please feel free to contact Tenable's sales team.

Tenable will be hosting a series of interview based webinars over the next few months.

Our first interview will be with noted network security monitoring expert, Richard Bejtlich of Tao Security. Richard has written several books including the "Tao of Network Security Monitoring", "Real Digital Forensics" and "Extrusion Detection".

We're accepting questions from the webinar audience and collecting them during registration. To register for the webinar, please use the following URL:

https://www.gotomeeting.com/register/313888669

Tenable has many new events between now and January 2007. They are all outlined below. More are being added as we speak, including a series of interviews with leading computer and information security experts.

I'd also like to point out the last entry on the schedule - the SCADA Security Scientific Symposium. This is being organized by Digital Bond. I will be presenting at the event about how algorithms can be used to discover a variety of security issues on IP based SCADA networks. Space is limited to 70 attendees, but the talks will also be available to "virtual" symposium attendees who have registered for online viewing.

Webinar - Leveraging Nessus to Address FISMA Regulatory Concerns
October 24, 2006 -- 11:00 AM - 12:00 PM EDT
This presentation reviews FISMA compliance issues and demonstrates how the Security Center can be used to manage multiple Nessus vulnerability scanners. Email sales@tenablesecurity.com to register for this webinar.

Conference - InfoSecurity Event
October 25, 2006, NY, New York
Tenable will have a booth at this show and Tenable's CTO, Ron Gula, will be on a vulnerability management panel with other product vendors.

Conference - Fall 2006 Computer Security Symposium
October 25, 2006, Charlotte NC

Webinar - Network and Behavioral Anomaly Detection
October 27, 2006 -- 10:00 AM - 11:00 AM EsT

Webinar - The Future of Vulnerability Management
November 3, 2006 -- 11:00 AM - 12:00 PM EST

Conference - 33rd Annual CSI
November 6-8, 2006, Orlando Florida
Tenable's CTO, Ron Gula, will be speaking on the current and future trends in vulnerability detection, security management and compliance.

Conference - University of Florida IT Security Awareness Day
November 8, 2006, Gainesville FL

Forum - Midwest Information Security Forum
November 7-8, Chicago IL
Tenable is also offering the 1-day Nessus certification training class in conjunction with this event. The class is taught by Tenable's CSO, Marcus Ranum.

Webinar - Nessus Compliance Checks
November 10, 2006 -- 11:00 AM - 12:00 PM EST

Forum - SCADA Security Scientific Symposium
January 25 -25, Miami Beach, Florida
Tenable's CTO, Ron Gula, will discuss algorithmic approaches to discovering anomalies on IP networks running SCADA applications.

Digital Bond has placed screen shots of the SCADA checks for Nessus under development in their blog. Below is a screen shot of some of the plugins being developed for the new "SCADA" family.

The research for the SCADA plugins has yielded four types of SCADA plugins:

• device specific checks for Modicon PLCs
• application specific checks for Windows OS based SCADA components (through Windows RPC calls)
• protocol specific checks to find COTP and Modbus
• checks for known SCADA vulnerabilities

These checks will be available to Nessus Direct Feed subscribers and Security Center users.

Tenable has already implemented many SCADA protocol decodes in the Passive Vulnerability Scanner. The PVS can be placed inside or on the perimeter of a network running SCADA protocols and passively determine both SCADA specific applications and generic vulnerabilities. Tenable has a webinar about this subject this Friday at 3:00 PM EST. Tenable has also produced a white paper on protecting and monitoring SCADA networks with both active and passive vulnerability auditing.

I've been collecting comments made to me by various Nessus users and Tenable customers about what it means to be compliant. This is by no means scientific, but I only put stuff on this list that I've heard more than once.

PCI requires full scans of all 65,000 Ports

There are several issues with this statement. First of all, there are actually 65535 potential port values and 131070 if you count both UDP and TCP protocols. Second, and more importantly, PCI doesn't say this anywhere. There are several places in the PCI standard that recommend scanning of both  port 80 and 443, but it doesn't say anywhere to do a full port scan.

Technically, performing a full scan of this nature is easy for one or two systems, but can be difficult for a larger enterprise network. If this is something you are interested in performing on a wide scale, I highly recommend considering distributed Nessus scanners or performing passive network monitoring.

I can't use Nessus for PCI/SDP audits

This is very misleading! Many managed security providers use this argument, even though their technology is based on Nessus. Mastercard's wording is also misleading since they refer to service providers as "vendors".

In actuality, for the more in-depth PCI/SDP audits, you can't "self audit" and need to use an outside service provider to do this. Mastercard keeps a list here.

So even though, you can't "self audit" yourself, if you want to be proactive, you can use the same technology the vendors are using. Many of these vendors purchase the Direct Feed for their Nessus scanners or use the Security Center for scheduling, reporting and configuration of compliance audits.

You can't be compliant and have Nessus detect "Holes"

The only compliance regulation I am aware of that specifically outlines which vulnerabilities are unacceptable is PCI. It defines levels 5 through 1 with levels 5 and 4 consisting of things like detected malware, trojans and backdoors.

If you read through what it means to run a network according to COBIT, ITIL, or NIST standards, none of them say you can't have vulnerabilities. They actually not only expect you to have vulnerabilities, but also expect you to manage them.

So if an auditor is saying that you have a serious vulnerability so you can't pass your audit, she might be really saying that it is your process for managing or detecting the vulnerability that is the issue,not the vulnerability itself.

I need to have a firewall and an IDS/IPS to be compliant

Some compliance regulations do indeed say that organizations are required to perform access control and to perform monitoring. Some do indeed say that "perimeter" control devices like a VPN or a firewall are required. Some do indeed say the word "intrusion detection". However, this doesn't necessarily mean to go and deploy NIDS or a firewall everywhere.

Access control and monitoring can be performed with many other technologies. There is nothing wrong in using a firewall or NIDS solutions to meet any compliance requirements, but what about centralized authentication, network access control (NAC), network anomaly detection, log analysis, using ACLs on perimeter routers and so on? 

Can we get a list of Nessus checks to test for compliance?

Tenable often gets questions like this from both new and long-time Nessus users. The reality is that compliance standards audit your IT processes, not your vulnerabilities. As such, you will likely find the Nessus 3 "compliance checks" found in the Direct Feed of much more use to you in your audits than any of the latest vulnerability checks. Specific vulnerability checks are ideal for testing against the SANS Top 20 list of common vulnerabilities or even some aspects of the PCI standard. However, to prove to an auditor that your IT controls and procedures are working, Nessus can be used to audit the configuration of specific hosts and assets.

I can't perform these audit's myself

Depending on the type of audit, this may be true. However, I usually hear this sort of comment as an "excuse" not to perform some sort of ongoing compliance, security or vulnerability monitoring.

For example, the NERC regulations require a vulnerability scan of all critical cyber assets once per year. If this is all you are doing, then your once-a-year scan may find many unexpected surprises. If you were doing more proactive scanning, or even continuous passive monitoring, you can detect compliance issues earlier when they may be easier (and less costly) to mitigate.

Many auditors will use Nessus as their vulnerability scanner, or a similar type of tool. Being able to run these sorts of scans before the auditors do may also give you an advantage or head start and avoid a repeat audit.

Realtime Compliance Paper and Webinars

If this sort of summary was useful, you might be interested in how Tenable's full product line relates towards PCI, SOX, FISMA, NERC and many other types of compliance audits. We've prepared an 80 page paper which "summarizes" each of these standards and shows how our vulnerability, configuration, log analysis and passive network monitoring technologies can be leveraged for "realtime" compliance monitoring. Please email us at sales@tenablesecurity.com to request a copy of this paper.

Tenable also offers public webinars on these topics. The next few webinars cover vulnerability management, performing configuration audits with Nessus 3, SCADA network monitoring and network anomaly detection.

I'd like to point all Nessus users and Tenable customers towards a new guide from The Institute of Internal Auditors. The guide helps internal auditors ask the right questions of the IT security staff. It also helps an auditor recognize when an organization is using best practices when managing vulnerabilities and when they are not. If you are not involved in performing audits, but are the one being audited, this guide can help you prepare for the tough (or easy) questions which may be asked of you. 

The IIA has published many guides for auditing internal controls, mitigating risk and auditing technology. The technology audit guides are called "GTAGs" which stands for Global Technology Audit Guides. This latest is the sixth in a series. Previous GTAGs covered topics such as patch management, auditing IT controls,  and managing privacy risk. The IIA has created a reference powerpoint presentation here which summarizes all GTAGs.

Readers of this new guide on auditing IT vulnerabilities should expect to understand:

• how to differentiate between high and low performing vulnerability management organizations
• how organizations progress their vulnerability management techniques from a technology based approached, to a risk-based approach and ultimately to a process based approach
• how to articulate recommendations for vulnerability management to chief executives

Regardless of your technical prowess or your political position in your organization, there should be something in this for anyone involved with IT security audits. My personal favorite is the section on the "Top 10 Questions" you should ask about vulnerability management. The questions are:

1. What percent of total systems are monitored or scanned?
2. How many unique vulnerabilities exist in your enterprise?
3. What percentage of systems are managed?
4. What percent of vulnerabilities have you validated?
5. What is the mean time to remediate a vulnerability?
6. What percentage of actionable vulnerabilities was remediated in the past quarter?
7. What percent of your operation level agreements are met?
8. What percent of IT Security work is unplanned?
9. How many security incidents have you experienced during the past quarter?
10. What was the average cost of your last five security incidents?

The reason I like this section is that for each of these questions, the guide provides you example answers from a "low performer", "high performer" and a "manager in denial". Sharp auditors who follow the GTAG will be looking for responses along these lines, so I highly recommend folks be familiar with these sections and have their answers with data to back them up ready.

I also like these questions because I know that organizations who use Nessus, the Security Center and the Passive Vulnerability Scanner have an easier time answering these questions. I regularly speak with customer who "confirm" network based vulnerabilities discovered with Nessus or the PVS with an agent-less patch audit also performed by Nessus. I also know that many of the reporting features we've put into the Security Center came as requests directly from customers who had to produce reports and data similar to what the GTAG is asking.

All Log Correlation Engine licenses include the stats daemon. This daemon reads any log source, including netflow or sniffed TCP sessions, builds a baseline of normal activity and then creates alerts when there is activity which is statistically significant. This blog entry will explain in greater detail how the stats daemon accomplishes this, and discusses several example "anomaly" detections.

Tenable's Correlation Model in General

The stats engine for log and event analysis is part of our overall strategy for detecting significant events on your network. The correlation technology includes:

• Real time vulnerability to intrusion events with most leading NIDS solutions
• More than 50 TASL scripts for sophisticated real time discovery of worms, specific types of anomalies, compliance issues and compromises
• The stats engine to find statistically significant events on your network

Each of these events is viewed under the Security Center. This means any event can be viewed for specific asset groups by asset owners as a means of filtering and reporting.

The Statistical Model

The stats daemon keeps track of the following statistics for each IP address on your network:

• number of client and server connections
• number of internal, external and inbound connections
• number of unique events or normalized logs which occur

These statistics are maintained for each hour of each day. The statistics consider both the rolling averages of any particular occurrence, as well as the grouping of the values which build the rolling averages. For more information on how the mathematics works, please read the "Statistics Daemon Guide".

Each of the items tracked by the stats daemon are not "critical" in nature. For example, a Windows IIS server may normally have "server" connections and not act like a client. It may do outbound connections for logging, to obtain patch updates and perhaps synchronize with other servers.

In the classic example of "NBAD", if the machine were compromised and used for a botnet it may begin to connect to IRC or some other form of proprietary command and control. It may even start to scan other devices. In those cases, perhaps the client/server statistics as well as the balance of internal/external and inbound connection rates would generate an alert.

We'll consider a few examples of statistical events with screen shots from live networks. These screen shots came from live systems, and have had their IP addresses obscured.

First Example Analysis - Spike of Web traffic on an email server

Below is a summary of all stats anomalies for the last 24 hours at a major university. There are a lot because the stats daemon is very sensitive to small types of change. These particular events have been selected for systems which accept SMTP traffic. There are a variety of events, including changes in connections and a single "Large_Anomaly" event. Since mail operates 24x7, detecting slight changes in the balance of email coming in from the outside world as compared to being delivered internally isn't that interesting. However, the Statistics-Large_Anomaly event is certainly worth investigating.

Below is the SYSLOG content for the Statistics-Large_Anomaly event. It tells us a few things. First it is a "network spike" event. The TNM-TCP_Session_Completed event is generated by the Tenable Network Monitor which creates logs for when specific TCP sessions start and stop. Normally for this IP address between 4:00 AM and 5:00 AM, we get 207 hits of this event with a standard deviation of 403 hits. However, today we got 45178 hits.

Investigating further, using the IP address in question, for the last 24 hours, we can look at a summary of all events as well as a time-based summary. Although interesting, the specific events (specifically the Snort events) are fairly normal for this host. If they weren't we'd get statistical events for the new events as well. The time based summary is more interesting. Clearly between 4:00 AM and 5:00 AM there was a spike.

Investigating even further, we consider two more queries involving both a port summary and a list of involved IP addresses. The conclusion is that a majority of the traffic occurred on port 80 and to a single IP address. The second IP address (the one ending with .129.242) carried the bulk of the events.

So what was this? This turned out to be a proxy device which incorrectly went out to the Internet to keep an updated cache of a certain web site. The proxy was accidently placed on the list of SMTP servers because it acted like an SMTP when being scanned. We've actually been able to detect these sorts of things with the Passive Vulnerability Scanner, but in this case, only active scanning was used to identity SMTP devices.

You may be reading this entry and ask yourself, why lead off with a "false positive" for an example? The reason is that Tenable feels that statistically profiling a network's behaviors is very enlightening, but when an anomaly occurs it is not necessarily an evil hacker. More likely it is a change in a server or an issue with assumptions made before monitoring started. Let's look at a second example.

Second Example Analysis - Firewall Traffic Spikes

Below is a screen shot of raw NetScreen firewall logs event spikes and TNM activity of UDP and ICMP traffic. They have all occurred between 11:00 PM and midnight (23:00 for us ex-military types). These particular firewall events are all "accept" events, which means the firewall has passed this traffic.

In the case of the network which was being monitored here, the TNM agent was sniffing "inside" the firewall, so we were getting "double" hits. The purpose of this example is to show that NBAD shouldn't necessarily apply to netflow or direct network monitoring. Many types of anomalies can be discovered with logs from firewalls, proxies and even applications.

In the particular example shown, during the time period, event rates of around 10 were the norm, but in some cases, more than 20,000 had occurred during that time period.

Third Example Analysis - Multiple Hours of Misbehaving and Follow-on Activity after IDS events

The last example combines the LCE's TASL time-based correlation with events from the stats daemon. The events generated by the stats daemon also follow a "bell curve" of results. If you refer to the very first image of this blog, you can see that besides the one Statistics-Large_Anomaly event, there were several dozen events of lesser statistical significance.

Given that the stats daemon keeps a separate "model' of normalcy for each host and for each hour of the day, the LCE's TASL scripting can be used to see if a host is behaving oddly for more than one hour at a time. The standard_deviation_long_term.tasl script looks for stats events occurring more than two hours in a row.

Similarly, the ids_event_followed_by_change.tasl script looks for critical IDS events inbound to your network followed by some sort of statistical activity. The idea is to correlate an attack detected by a NIDS with a "behavior" change.

For more information

Tenable has several white papers on correlation that are free for download in our Security Event Management section. These papers are:

• "Security Event Management" - summarizes Tenable correlation technology, as well as log storage and acting on the events.
• "Correlating IDS Alerts with Vulnerability Information" - shows how NIDS alerts can be correlated with vulnerabilities found though scanning, passive analysis and host analysis
• "Advanced Event Correlation Scripting" - several case studies of TASL scripts

Tenable also has a video of the Log Correlation Engine's log analysis and correlation functions being viewed through the Security Center.

The Log Correlation Engine can be used to track DHCP leases and Active Directory authentication logs to automatically learn each user's Ethernet address and then alert when this relationship changes. Tenable has released a TASL script named user_to_mac.tasl which can perform this function with a variety of DHCP sources and Active Directory "successful login" events. This script is useful for several reasons:

• It continuously updates a text file named user_mac.txt with a list of all users, their last IP address and their MAC address.
• If a user account logs in from a different laptop, an alert will be logged.
• New user to MAC address detection events are also detected by the detect_change.tasl script.

Below are some screen shots of what these alerts look like under the Security Center.

Summary of Events	Raw Syslog Capture

To make use of this new script, download it to your plugins directory and also update your lce_tasl.prm file to parse the new event names.

During the past year, the Passive Vulnerability Scanner's rules were modified to detect network proxies and firewalls. This process also involved the reduction of reporting multiple browser types for different hosts running behind a NAT device or proxy.

As an example, what happens if PVS (or any sniffer, IDS, etc.) see's the following string in a packet leaving the network?

GET/StageOne/msnmsgr_exe/6_2_0_137/hungapp/0_0_0_0/00000000.htm?OS=5.1.2600.2.00010300.1.0&...
User-Agent: MSDW
Host: watson.microsoft.com

Well, most folks would think that:

1. The source IP is running MS Windows version 5.1.2600.2.etc and,
2. An error just occurred in MSN Messenger version 6.20.0.137 and,
3. The client is now sending an error message to Microsoft

And, a year ago, the PVS would have flagged the machine for the items denoted above.  However, within the last six months, Tenable has been undergoing a process of detecting where and why false positives are occurring within PVS.  One of the problem areas was that PVS was flagging firewalls and proxies as the actual client.  Mind you, I'm not talking about known NAT devices, as you can always turn off alerts going to/from those devices via the configuration file. 

We decided to find a generic way of detecting proxies and firewalls on the network.  The primary goal of this was to weed out false positives.  A tangential benefit has been that companies can now detect firewalls and proxies that are deep within their corporate network. 

Why does finding these NAT or proxy devices matter for a larger enterprise network? Consider the following issues:

• What happens if a remote business unit (connected to your internal network) is dual-homed to another network? 
• What happens if a user decides to set up an access point within your corporate network? 
• What happens if a user sets up a 3G connection to their corporate laptop, enables routing, goes home, and then uses the laptop as a remote router when they want to connect to corporate resources?

Finding firewalls and proxies within large, complex networks can be a daunting task. The good news is that these firewalls and proxies all leave their fingerprint as they pass NATed traffic around the network - and the PVS can detect these.

So, how do we detect firewalls and proxies? We modified the PVS rules to look for anomalies within the client-side applications and OS behaviors that only occur if multiple hosts are behind a NAT device or proxy. Here are a few examples currently implemented in the PVS signatures:

• The PVS looks for applications which are specific to an operating system.  PVS then finds mismatches.  Example: A host running the Firefox browser on the Microsoft platform AND a Safari browser on MAC OX X coming from the same IP.
• PVS looks for anomalous operating system updates. Most OSes and many applications have automated software for figuring out when an update is available.  The PVS looks for mismatches on the same IP.   
• Multiple versions of the same application. This is very straightforward. It's "odd" to see three versions of Firefox coming from the same IP.  This is also accomplished with MSN Messenger, AIM, Zonealarm, etc. etc.

By searching for the applications of multiple individual hosts occurring on "one" public IP address, the PVS can identify where NAT devices and proxies are located with a high degree of accuracy.

If passive network monitoring to find vulnerabilities is a new concept to you, please feel free to download the "Blended Security Assessments" whitepaper. This shows how both active and passive vulnerability analysis provides much deeper coverage and monitoring of your network than either technology by itself. There is also a video demonstration of PVS data being managed by a Security Center.

We've gotten requests for more webinars on a variety of topics. Below is the current schedule of webinars presented by Tenable in the month of October. These include an additional "Future of Vulnerability Management" talk, as well as sessions on the Nessus 3 compliance audit capabilities, network behavioral anomaly detection and passive SCADA network monitoring. Each session requires registration and completion of a short survey.

The Future of Vulnerability Management
October 10, 11:00 AM EST
https://www.gotomeeting.com/register/800578374

The Future of Vulnerability Management
October 12, 9:00 AM EST
https://www.gotomeeting.com/register/987349111

Nessus Compliance Checks
October 12, 2:00 PM EST
https://www.gotomeeting.com/register/917710907

Network and Behavioral Anomaly Detection
October 13, 10:00 AM EST
https://www.gotomeeting.com/register/167372290

The Future of Vulnerability Management
October 17, 11:00 AM EST
https://www.gotomeeting.com/register/981647110

Nessus Compliance Checks
October 19, 9:00 AM EST
https://www.gotomeeting.com/register/191464433

Passive SCADA Network Monitoring
October 20, 3:00 PM EST
https://www.gotomeeting.com/register/627584779

Organizations with large networks can enhance their vulnerability scanning efforts by deploying multiple Nessus vulnerability scanners. This blog entry discusses the advantages of using multiple scanners for both Nessus users and Security Center operators.

Scanning Very Large Networks

Tenable customers use distributed scanning to scan networks that were either once out of reach due to size or to really minimize their scan time. A typical large enterprise customer may have 6-10 Nessus scanners targeting more than live 50,000 hosts across multiple Class B addresses spaces. Some of our customers who deploy one scanner per "customer" (like an MSP), or one scanner per state or business unit can have 25 or more scanners.

Our customers who perform scanning with the Security Center get a "hosts scanned per minute" value for each vulnerability scan completed. We don't publish raw numbers because there are dramatic differences between performing different types of scans such as a ping vs. a full port scan, host enumeration time-outs, the amount of "live" hosts on a given network and so on. Having said that, we have some customers who scan more than 5000 IP addresses in a minute as part of scanning many times more than that.

Having this baseline for scan performance can really help detect scan time changes when more Nessus scanners are added, when scan policies (such as different maximum hosts and maximum checks per scan) change or when new hardware is used for the scanners.   

Decreased Scan Time

Using more than one scanner can be much faster than a single scanner. There are a few concepts to consider though.

For manual scanning of large networks, it is much more efficient to break the target lists up into smaller scan jobs. This way you won't have a Nessus scanner sit idle if it finishes its task early. If your Security Center is managing the scan jobs, then it does this automatically for you. 

Adding more scanners with much less CPU or memory capacity might not reduce your scan time. This may be obvious to some readers, but Tenable has had customers add more Nessus scanners as "VMWare" images on top of the same server. This actually slowed down their scanning time. We've also had customers start out scanning with multiple Nessus scanners on high-end Xeon servers and then add 256 Mb laptops running Nessus on Windows. They didn't get much increase either. As a general rule though, if you add more scanners on similar or better hardware then you currently have, then you should see an decrease in your scanning time.

Lastly, at some point, adding more and more Nessus scanners could create a choke point on the network. If your link to the network you are scanning is through a T1 or cable modem, adding more powerful scanners might not speed things up. 

Internal and External Perimeter Scanning

If your organization has policies which require the use of access control devices such as firewalls, web proxies or filtering routers, then performing vulnerability scans is not straightforward.

If your scanners are on the outside of the perimeter, then you may be able to scan at the same levels that an outsider would. Your Nessus scanner would only be able to see the same sort of ports and services that are open to everyone else. This may be by design, but this also can deprive a security audit of useful information that the perimeter is protecting.

Similarly, placing a scanner on the inside of the network can show everything. However, when vulnerabilities are found it is possible to argue that they are protected by a firewall.

Placing a scanner on the inside of the network and the outside may be the answer. Performing two scans can show an external view, as well as an internal view. Both of these scans can be used to measure the relative exposure or risk depending on where they are at.

Security Center organizations can give out the ability to perform scans from specific groups of Nessus scanners called "zones" as a user privilege. When combined with large numbers of scanners, these "inter-zone" scans can be used to not only scan network perimeters and inside the perimeters, but can be used to scan other groups in an effort to look for trust relationships that should not be there.

For example, consider that business Group A and Group B both have a firewall and don't present a lot of services to the outside world. Group B may also "trust" Group A with IP access control "permit" rules or even a dedicated VPN. Performing a vulnerability scan with Nessus scanners in Group A to the Group B network can find this sort of connectivity.

More Accurate Topology Discovery

Using multiple scanners can also help increase the accuracy of your network topology discovery. The basic tool used by Nessus is to perform a traceroute from each scanner to each target. If a certain Nessus scanner traces the route to host A and host B, it will likely get a a list of routers between each scanner and those hosts. However, this may not include a set of routers that host A and host B would use to communicate with each other.

By using multiple Nessus scanners AND telling them to conduct traceroutes to other parts of the network besides their local network, a more accurate list of devices and their connections can be obtained.

With accurate maps, Security Center users can create very interesting 3D visualizations of their networks and asset groups such as shown above.

Less Stress on the Network Infrastructure

Lastly, when considering deploying more than one distributed Nessus scanner users should realize that there is actually less stress placed on the network during scans. Notice that I said "distributed". If you placed many Nessus scanners at one point on your network and started scanning, you could easily choke your local network segment. For truly distributed scanners though, this isn't the case.

This is because each host should only get scanned once. If one were to perform the same scan manually across your target networks or automatically with the Security Center, the same number of packets will be sent to find hosts and probe them for vulnerabilities. Conducting these scans from Nessus scanners placed closer to their targets won't have the port scans and vulnerability probes travel across the infrastructure. This means that backbone devices won't be carrying the extra bandwidth from the scan or have an increased amount of simultaneous network sessions. A fragile device which won't stand up to a regular scan still won't stand up to a distributed scan, but your backbone will be much less exposed to carrying some sort of traffic which is could have an adverse effect.

In particular if your scans are flowing through web proxies, firewalls or VPN devices, they may be limited in what they can find. Each of these devices may have a maximum number of simultaneous connections, drop UDP (and even TCP) packets excessively under load and can generally lower their availability or responsiveness during scans. Keep in mind that since these devices are security devices, they may inherently have design features to specifically prevent vulnerability scanning. 

For More Information

Tenable has a white paper available which discusses this sort of technology in much more depth. The paper is titled "Dedicated and Distributed Vulnerability Management" and can be downloaded here. We wrote this paper in 2002 and have been helping customers deploy large numbers of multiple Nessus scanners for over four years.