Tenable often receives requests for advice and strategies to help very large organizations decrease their scanning time. Readers should keep in mind that from Tenable's point of view, a "large" organization is someone with multiple Class B networks and more than 1 million items reported by Nessus. A basic concept to keep in mind when modifying how scans run is that there is a balance between scanning speed, thoroughness and invasiveness. For example, one may simply be able to decrease scan speed times by decreasing the number of tests performed. The scan happens faster but is not as thorough. This blog entry details some strategies that can help decrease scanning times with Nessus for very large networks. 

Distributed Scanning

Load balancing multiple Nessus 3 scanners can also speed up your scan times. We've blogged about this before, but don't want organizations to forget to take advantage of this. 

Tenable regularly deals with large organizations that deploy 10, 20 or even 30 scanners to scan millions of IP addresses. They manage these scanners with the Security Center.

Don't do Full Port Scans

There is nothing technically wrong with performing a full port scan, except that the laws of physics must be observed. For any network, there will be a maximum number of simultaneous ports and hosts that can be probed. Choke points can come from network devices such as firewalls, low bandwidth links or even the performance of the systems being scanned.

From a "realtive work" perspective, there are 65535 ports that can be targeted whereas there are less than 15,000 Nessus plugins. Most of those plugins don't even run because Nessus efficiently disables plugins that aren't relevant for the system being scanned. This means that for full port scans, it will take much longer to find the open ports than to perform the vulnerability audit.

Also, for enterprise scans, the default port range used by Nessus is typically "good enough" for finding most of your open ports. Tenable's experience with large customers has shown that full port scans do find a few more open ports than the default ports targeted by Nessus, but the amount of extra time involved performing these scans is beyond the point of diminishing returns.

If looking for all open ports is a corporate requirement, consider deploying more Nessus 3 scanners closer to their target networks. Also consider deploying Passive Vulnerability Scanners which find open ports (as well as browsed ports, Internet browsing devices and internal trust relationships) in real-time.

Disable Slower Scan Options

Two parameters for Nessus scans that can dramatically impact  performance are to disable both the "CGI Abuses" and "CGI ABuses : XSS" families and to also disabled "Thorough Tests".

With the 1000s of CGI and XSS (Cross Site Scripting) vulnerabilities disclosed to date, testing for all of them on every discovered web server might not be the most efficient course of action for a large scan. If these families are enabled, for every web server discovered, Nessus will probe for each potential CGI application installed. Since many devices ship with embedded web servers, disabling these families can let you concentrate full scans on just the authorized web servers for your organization. Nessus clients also have a scan policy setting named "Disable CGI scanning" which prevents all things related to CGI probing.

Also, the "Thorough Tests" scanning parameter causes various NASL scripts to "work harder". For example,  when looking through SMB file shares, a NASL might choose to look 3 levels deep instead of 1. This could cause much more network traffic and analysis if the target host has more shares. By default, all Security Center scans have "Thorough Tests" disabled.

Don't scan Dead Space

Another way to scan large amounts of address space is to try and ignore the hosts that are not there. Scanning "dead space" slows down scans because no matter how much CPU or network bandwidth you have access to, Nessus will wait a fixed amount of time to decide that a host isn't there. Of course the caveat is that if you think an IP address isn't occupied, you'll never know it unless you watch for network traffic from it or try to scan it occasionally. Some strategies to only scan an accurate list of active hosts include:

• The Security Center can be used to create a dynamic asset list of all available hosts and then a chained scan can be used to scan just hosts of a certain type, a certain age, a certain OS or many other parameters.
• If one or more Passive Vulnerability Scanners are in place, the information from these hosts can be used to identify active hosts in a dynamic asset list, and then targeted with an active scan.
• If you have access to some sort of asset tracking system, or can query your switching infrastructure for a list of active IP addresses, these can be fed into a Nessus scan or a Security Center static asset list.

If you can place your Nessus 3 scanners closer to the collision domain of a target network, an Ethernet ping will be performed. This is much faster than an ICMP ping and will decrease the amount of time waiting for hosts to reply that are not there.

Look for Choke Points

Another type of analysis that can be performed is to consider the actual network being scanned. There may be choke points that slow down a scan. Here are some ideas to consider and research for your local network:

Are all scans going through the same switch, switching infrastructure, vlan or router? Asking your network engineering folks about network performance during a scan could be enlightening.

Are there security devices or gateways that are operating at capacity during the scan? For example, consider the performance of firewalls, proxy devices, and wireless gateways during the scan.

Consider the "Information about the scan" Plugin

Nessus plugin ID #19506 records the results of the scan, including the amount of time it takes to complete the scan. Below is a screen shot of an example result under the Security Center:

In this case, the host was fully scanned in 10 seconds. However, what if we want to create dynamic asset lists based on the amount of time it takes to complete a scan of a host? This would allow us to use the Security Center's powerful reporting,, sorting, filtering and analysis capabilities to identify which class systems is taking to long.

To do this, we'd need to create some dynamic asset lists and use some regular expressions to identify hosts with "long" scan times. For a quick review of some dynamic asset list creation examples, consider this previous blog entry.

For each of these dynamic asset rules, we will tag it to plugin ID #19506. In each of these examples we will tag the text string "Scan duration : 10 sec" and uses regular expression to look for times other than "10".

Here are some example "text strings" you can drop directly into a Security Center regular expression dynamic asset rule:

• 30 Seconds or more
  19506:Scan duration : ([3-9][0-9])|([0-9]{3}) sec
  This will match scan times larger than 29 seconds.
• 60 Seconds or more
  19506:Scan duration : ([6-9][0-9])|([0-9]{3}) sec
  This will match scan times larger than 59 seconds.
• 100 Seconds or more
  19506:Scan duration : [0-9]{3} sec
  This will match scan times from 100 seconds to 999 seconds.
• 200 Seconds or more
  19506:Scan duration : ([2-9][0-9][0-9]) sec
  This will match scan times from 200 seconds to 999 seconds.
• 300 Seconds or more
  19506:Scan duration : ([3-9][0-9][0-9]) sec
  This will match scan times from 300 second to 999 seconds.

For performance, the 100, 200 and 300 regular expression rules are more efficient than the 30 and 60 second rules.

To add these to your Security Center, add a new Dynamic Asset List. Then add a "pluginid" match filter for 19506. Then add a "plugintext" regex filter for one of the patterns in italics shown above.

In the screen shot below, an asset list named "Long Scan Time" was created with the "30 Seconds or more" example above. We can see that the scan time of this host 37 seconds. On our demo network, this also matched hosts with scan times of 407 seconds, 58 seconds and 39 seconds.

So what sort of analysis can you perform with this type of approach? Consider the following techniques:

• Are these systems all part of the same network or subnet? This could indicate some sort of choke point.
• Do these systems all have something in common that "faster" hosts don't have? Consider things like CPU, memory, and system firewalls. Also consider things like actual applications. It might make sense that the IIS web servers take longer to scan than a Windows 2003 file server.
• Is there a set of vulnerabilities or open ports common to these assets? 

This type of analysis is ideally suited for the Security Center 3D tool. Performing a query for a target network and then a second query for the hosts that have long scan times will allow you to visually compare the open ports and vulnerabilities present such as in this screen shot below:

Summary

Although this blog entry focused on some advanced things to consider for your network scans, don't forget the basics. Make sure your Nessus scanners have enough horsepower (watch their CPU usage during a scan) and enough network bandwidth.

Also, most organizations have upgraded to Nessus 3. If you are still using Nessus 2, consider doing an upgrade as version 3 is much faster than 2. Tenable has produced a comprehensive comparison between Nessus 2 and Nessus 3 scanning speed.

And lastly, Security Center users with multiple Nessus scanners should not run their scanner directly on the Security Center. Generally, you can scan with Nessus from the Security Center, but the performance impact is unacceptable for large scans. If you don't mind the impact to Security Center, your scans will still complete faster by utilizing the CPUs on the Security Center system.

Tenable customers also have access to the support knowledge base which includes other best practices for configuring scans. If you have tips on optimizing your Nessus scan results, please feel free to send them to Tenable or post them to the Nessus mailing list.

If you are not part of the IT group, you may have to ask someone for the right credentials to perform patch and configuration audits with Nessus. This blog entry will offer some advice and strategies to consider when attempting to obtain access to the devices for auditing.

Who Doesn't Have Credentials?

If your organization has mandated security audits, they may have also mandated that credentials be provided to the group performing network scans. If your group is like this, then this blog entry isn't for you. However, you should realize that there are still many organizations where the "audit" group doesn't have full access to the devices they are scanning.

Benefits for IT from Credentialed Scanning

Credentialed audits can show a variety of "good" news about an IT group.

If systems are being patched on a regular basis, then a patch audit won't find many problems. This can show IT management an independent confirmation of how their network is being operated.

When missing patches are found, they are 100% accurate and actionable. This is not to say that a network scan isn't accurate (Tenable shoots for 100% accuracy), but Nessus network scans don't immediately tell you which patch to apply. A vulnerable version of Apache could have any number of potential fixes, but with credentials, the exact missing security patch(es) can be discovered. This is also more efficient to task an IT administrator with. Rather than saying "upgrade Apache" which is ambiguous, someone can say "apply patch #4637".

Credentialed scans can identify and list all of the UNIX and Windows software that has been installed. If you are viewing the data in the Security Center, then the results can be searched or even used to create dynamic asset lists of systems that have certain types of software installed. We've recently blogged about this concept.

And finally, if you are managing your Nessus scanners with the Security Center or subscribed to the Direct Feed, a configuration audit can be performed. If an IT group is managing all of their system configurations centrally, then these audits should independently show consistency and conformity to a global policy. Even if no strict corporate configuration polices are enforced, auditing systems against various government standards for passing and failing settings can also highlight where an IT organization has performed well.

Know What To Ask For

For Windows audits, asking for full domain administrator rights does give Nessus enough credentials to perform its audits, but this sort of request can be unfathomable to an IT group. Instead, Tenable recommends two strategies.

First, consider asking for access to the "backup" account. This account likely has access to read both files and system settings. Second, consider asking for a specific "audit" account be created with similar read-only access. A dedicated "audit" account has the advantage of showing up in the logs and instantly being recognized by everyone in IT as a potentially approved activity.

For UNIX, Nessus supports SSH passwords and public/private keys. For patch auditing, root access is recommended but not mandatory. Be aware the some more secure UNIXes (such as Trusted Solaris) may require root to obtain a package list.

For UNIX configuration auditing, keep in mind that appropriate access is required. For example, a file owned by root might only be "readable" by a root user or someone in the "wheel" group.

Sharing Data With IT

If you do have access to IT and perform scans, sharing the data, or even making sense of it, can be difficult.

Some organizations let IT perform their own scans, and this is great from a "self test" perspective, but self audits are not reliable and should be performed by a 3rd party not involved in the day-to-day operation of the network.

If an audit group performs ad-hoc scans on a set schedule of keys assets and shares the results with asset owners, the right data can be sent to the right people in a timely manner. There is overhead through tracking the need for performing re-scans, tracking which systems should be scanned and even which people in IT have the right to see or review the data.

Tenable offers the Security Center which can be used to centralize scanning, scan results, analyzing the data and tracking which systems need to be re-scanned. Only the specific users of certain IT assets can see the results for those assets. The Security Center can also offer IDS event viewing and log analysis to the same IT users.

If you can't get Credentials

If you are faced with performing network audits without access to system credentials, what are you facing? Several things:

There will be less information on specific client-side (such as Internet Explorer and Mozilla) vulnerabilities. Some clients (such as iTunes) do have network services that Nessus can discover and reliably identify.

The vulnerabilities found will be very accurate, but sometimes very generic. As in the Apache example discussed above, knowing a vulnerability and knowing a patch are two different things. Typically, Nessus network scans can tell you that an upgrade is required, but not the specific patches that are missing. One exception to this rule is while scanning Windows network services. Very often, Nessus will be able to determine the exact patch required, even without credentials.

If things haven't been locked down, don't be surprised if your Nessus scan reports some patch audits. If you have an Admin account on Windows that is not password protected, or similarly with a Guest account, Nessus may be able to use those credentials when performing a scan.

If the audit group does have access to part of the domain with (such as a regular user's username and password), this type of account may be enough to audit other Windows systems on the domain. It all depends on how locked down the network it.

Lastly, if credentials are not available, consider deploying the Passive Vulnerability Scanner alongside your Nessus scanners. This sniffer can find many client and server side vulnerabilities without any scanning at all. It also integrates seamlessly with the Security Center for centralizing active, passive and credentialed vulnerability and configuration data into one spot. If data obtained passively is contrary to what IT is claiming (i.e., they may claim that all web browsers are patched, but sniffing clearly shows older versions of Mozilla) this may also be enough evidence to convince management to allow auditing with full credentials.

For More Information

If performing credentialed audits with Nessus is a new concept for you, a good place to start is the  Nessus Credentialed Checks for UNIX and Windows paper.  To help understand the advantages and limitations of active scanning, credentialed scanning and passive network monitoring, please read the Blended Security Assessments paper.

If you are performing network monitoring on a large network that is infected with any number of worms or botnets, there are many different techniques you can use with Tenable products to identify infected hosts. This blog entry considers a variety of worms/botnets that attack Symantec anti-virus agents. Many of the techniques identified here can be used to look for other worms that attack other applications and are active on different ports. For this post though, we will focus on port 2967 activity, which has recently dramatically increased, as reported by the SANS Internet Storm Center.

Signature Content Analysis

If you run an NIDS, there are typically rules which identify "known" botnet/worm/virus exploits. Here is a screen shot of Snort IDS events running the Bleeding Threat signature database:

We've highlighted the event by darkening it and also obscured the real IP addresses in questions. The event shows a remote host (69.16.196.189) sending traffic to port 2967 on host X.X.21.147 which matches a signature for an exploit against Symantec anti-virus agents. The other various "TNM" events show sessions starting and stopping on port 2967. These events are being viewed under the Security Center and have been collected and normalized by the Log Correlation Engine (LCE).

If this were a network you were defending, you should be asking yourself what else can be learned about this threat and if there are any other ways to detect compromised hosts. One of the things that would be concerning in the above image is that out target host X.X.21.147 is not only being scanned, it is also actively reaching out to other hosts on port 2967.

Combining Open and Browsed Ports

If you have the Security Center and the Passive Vulnerability Scanner (PVS) monitoring a network, you can query your cumulative vulnerability database for hosts that are listening on port 2967 and also browsing on port 2967. The  PVS records open ports as vulnerability ID #0 and browsed ports as vulnerability ID #2.  Within the Security Center, a query for a list of IP addresses that both browse and serve on port 2967 looks like this:

The IP addresses have been obscured. In the "port" filter, the value 2967 has been entered and in the plugin ID area, both IDs #0 (for open ports) and #2 (for browsed ports) have been entered.  In the chart on the right of the image, the IPs with the most vulnerabilities have been listed. Any of the IPs with two vulnerabilities have both a port open on 2967 and also browse on port 2967. The other IPs with only one vulnerability have either port 2967 open or they browse on it, but not both.

These hosts may not be compromised. Perhaps that do have port 2967 open for the Symantec anti-virus engine and also browse on port 2967 for some P2P, VoIP or other application. On the other hand, the chance of this occurring may be low on your network and hosts which both browse and serve on port 2967 may indeed be infected.

SANS has also recorded an increase in port 2968 traffic. Port 2968 is also associated with the Symantec anti-virus application. Similar queries for these ports can be accomplished with the Security Center.

Using Dynamic Asset Lists to Track Behavior

The Security Center can be used to create an automatic list of IP addresses based on the vulnerabilities and information discovered by Nessus and the PVS. We've blogged about this sort of capability in the past here. In the above example, since we only have three IP address of interest, perhaps a static asset list could be more quickly entered, but if new hosts became infected the list would not be automatically updated.

To create such a list, add a rule to match on port 2967 being opened, and a second rule to perform a regular expression search for vulnerability ID #2 ending in the content " 2967" (the space is on purpose). Examples of a similar dynamic asset rule are covered here. If you wanted to look for a host that browsed on either port 2967 or 2968, you could use a regex rule such as this:

2: 296[78]$

Such a rule searches for PVS vulnerability ID #2 records that end in a space followed by either "2967" or "2968".

On one of Tenable's large test networks which has been having issues with various Symantec worms, we created a Dynamic Asset List that considered systems that browsed and served on port 2967. This list was named "Symantec Worms". We then compared the trends of events and logs on port 2967 with just the events for the "Symantec Worms" systems and got the following results:

"Symantec Worm" hosts	All Port 2967 traffic

In the above graphs, there was a clear spike in traffic from our hosts which is easy to see. However, by just trending for port 2967 traffic, there is so much background noise, these particular hosts didn't register with any sort of spike or anomaly. (In this case, it was because these compromised hosts were performing large port scans on ports other than 2967).

For more analysis of the pure "port 2967" traffic, different queries could have been performed with the Security Center to compare "inbound" vs. "outbound" events.  Also, doing a "top talker" or "top destination" query of IP addresses for port 2967 could identify some problem hosts. And lastly, any "Crowd Surge" events on port 2967 would surely be indicative of many hosts scanning at the same time for this port.

Looking for Backdoors on Potentially Compromised Hosts

Once you have identified a list of hosts which may be part of a worm or botnet, it could be interesting to look for potential backdoors. One of the things both Nessus and the PVS do really well is identify applications, regardless of the port they are on. Consider the following list of vulnerabilities found on our "Symantec Worms" asset list where we are specifically excluding detected port 21 issues:

In the above image, we've highlighted PVS vulnerability ID #3222 which detects FTP servers on any port. This one happens to be on port 50126. Sniffing traffic to the system yields a hit such as this:

Clearly, this is an FTP server set up by someone who exploited the server, perhaps using an exploit for the Symantec anti-virus agent, perhaps with a different exploit. Regardless, we were able to use a combination of information to lead us to this host.

A different analyst may have chosen to look for all "non-port 21" systems running FTP servers on a daily basis an use the LCE or PVS to alert when a new system was added to the list.

Summary and More Information

These examples can be applied to many different types of worms and general log and event analysis. Knowing which vulnerabilities and network browsing activity occurs on your hosts can be used to help focus on specific events and systems. If this blog was of interest to you, the following entires will also likely be interesting:

• The Security Center can be used to push Bleeding Threat signature rules to your Snort sensors, as well as just enable the specific signatures that match existing vulnerabilities and applications on your network.
• The Log Correlation Engine can be used to match all of your network connections against "blacklists" published by SANS and Bleeding Threat . This includes matching traffic to or from known botnets.
• If you are using credentialed scans, the Nessus vulnerability scanner can find compromised Windows hosts that have had their ability to reach out to various anti-virus disabled.
• When the PVS finds a new port being browsed, the alerts can be sent to the Log Correlation Engine and used to find worm outbreaks.

Version 1.2 of the 3D Tool is now available. This version is much faster then the previous version. It makes use of Security Center 3.2's ability to obtain data as a .csv spreadsheet. Those types of queries are much faster against Security Center 3.2 than the previous method with Security Center 3.0. A list of new features includes:

• A legend has been added for color-coded datasets.
• Pre-defined queries, setting a default query, and the ability to save query filters has been added.
• Enhanced visual effects that include mirroring and camera animation for the 3D topology view.

To upgrade to version 1.2, the prior version 1.0, should be completely removed. Original data left over from 1.0 will not be available for version 1.2, as there have been some changes in the underlying data-store to increase stability and performance. Tenable customers should contact support to obtain download instructions for the 3D Tool.

Below are screen shots of the new "mirror effect" in the topology view and the latest vulnerabilities vs. IP address graphs:

This point release provides fixes for multiple minor issues with Nessus 3.0.4. The fixes include:

• Faster startup time, especially on laptops
• Improved the performance of the SYN port scanner
• Fixed a memory leak in the Mac OS X client
• Vista compatibility improved
• Various minor bugs fixed in the NASL engine
• Better chasing of zombie processes

Platform specific changes include:

• Windows : Improved Vista compatibility
• Mac OS X : fixed a memory leak in the client
• Mac OS X : fixed the way plugin preferences are processed (some prefs would not be displayed)
• Red Hat/Fedora : The priority of the nessusd startup script is now at 98 instead of 90, so that it starts later in the boot process
• On Debian, the dependencies of the Nessus package have been fixed to reflect the need of libssl0.9.7

Other changes of interest :

• nessusd.conf now accepts the option "listen_address" which can be used to bind the nessusd daemon to a specific port (just like 'nessusd -a' does). Adding 'listen_address 127.0.0.1" in nessusd.conf will force nessusd to only listen on the loopback interface (thanks to Martin Mačok for suggesting this)
• If you write your own plugins you'll notice that the changes you make are not reflected in the scan itself until the next plugin update. To speed up the startup time of nessusd, we now compare the timestamp of the plugins db with the time of the last update. This avoids inspecting thousands of files at startup. To force nessusd to inspect the timestamp of every plugin at startup, simply start it with the '-t' switch (as in 'nessusd -t -D').

Other minor fixes :

• nessus-update-plugins now displays a proper error message when plugins.nessus.org is unreachable
• 'nessus -i report.nbe -o report.html' would sometime crash when converting a malformed .nbe file to another format
• In NASL, shared_socket_acquire() now returns 0 on error, not -1

Nessus users should upgrade to Nessus 3.0.5 and obtain it directly from http://www.nessus.org. Tenable recommends that all Nessus 3 users perform the upgrade.

There are many ways to visualize raw data in graphical form. This blog entry will consider network topology visualization, trust relationship graphing and security event analysis. We will use a combination of Tenable products to procure the event and vulnerability data, the Tenable 3D Tool and AfterGlow.

Network Topology

For viewing how network components are connected, Tenable's 3D Tool can use the traceroute data collected by one or more Nessus scanners. The 3D Tool connects to the Security Center where all topology data is stored.

For large enterprise networks, attempting to place all of the nodes on a single 2D graph can be very complicated. By representing the same data in 3D, analysis of how networks are connected can be more easily understood. Below is a screen shot of such a topology as viewed in the 3D Tool.

All nodes are connected to a router, and all routers are placed on a helix. This type of view lets users see which routers have more hosts on them. It also lets users see how the routers are connected to each other.

Previously, Tenable's Lightning Console used a 2D display to show the topology as shown below:

This "hub and spoke" view is still useful, but had limitations in the number of nodes that can be displayed at one time. Viewing this data in 3D is more efficient than working with a 2D model.

Afterglow - Trust Relationships with Passive Vulnerability Scanner

The Passive Vulnerability Scanner (PVS) can detect when a certain host connects to another host at least once. For example, consider this report from a PVS:

192.168.20.199|unknown (22/tcp)|3|Security Note|192.168.20.199 -> 192.168.20.200:22
192.168.20.199|unknown (37/tcp)|3|Security Note|192.168.20.199 -> 0.0.0.0:37

The first line says that host 192.168.20.199 connects to 192.168.20.200 on port 22. The second line says that the same host connects to 0.0.0.0 on port 37 (time). The IP 0.0.0.0 represents a destination "outside" of the PVS's immediate network, i.e., someplace on the Internet.

These logs are "permanent" in that if the PVS sees a connection, it adds this to the database.  For  a realtime understanding of what the PVS can generate, read this blog entry which details the type of alerts that can be generated on the fly.

Using the the Security Center's ability to save queries as a .csv spread sheet file,  it is possible to create an AfterGlow image of these trust relationships. Below is a screen shot of small number of hosts which "connect" to each other:

The nodes that have more "destinations" (such as 10.10.131.37 in the lower right) are used by many remote clients. For this rendering, the center location is a "null" node that connects disparate nodes to a central place. If a more complete PVS data set were uses, the 0.0.0.0 node would have been a common destination for everyone, as this represents an Internet destination.

Knowing where your clients go on the internal network can help identify critical internal systems and systems that have sensitive data.

AfterGlow - ICMP Flood

Sometimes 2D visualization doesn't shed light or offer insight to what is going on. Consider this example. An ICMP flood is observed on a large enterprise network with the Log Correlation Engine (LCE):

Using the Security Center to extract a very large sample of records in the "spike" of ICMP traffic, AfterGlow generates the following type of display:

There are so many nodes on the graph that it is virtually unreadable. This is not any fault of AfterGlow or the underlying Graphviz rendering engine. It's just that attempting to display more than 10,000 unique IP addresses on a bitmap becomes very crowded. If you look closely, you can see IP addresses in there. The black IPs are the "internet" and the yellow IPs was our network. Basically, there are a lot of IP addresses sending ICMP traffic to a lot of our network.

Also, in this case, we used the wrong tool to try and understand what is going on. Consider a simple list of "Top IP Addresses" for the same ICMP flood data (with our network IP addresses obscured):

Most of the ICMP traffic came from one host. What we ended up graphing out in AfterGlow was all of the background ICMP traffic along with the actual ICMP flood. The point of this example is to always keep in mind what you are graphing.

AfterGlow - Port Scan Example

For the last example, we'd like to see if we can correlated pairs of "sources" and "destinations" for port scans. The PVS can detect when an internal system begins port scanning. We could have used Snort, Tipping Point, or any other sort of log data. With the Log Correlation Engine, five days of port scan events graph out this way on a large demo network:

It would be interesting to use the Security Center and ask it to summarize the top IP addresses involved in this traffic. However, this would not show the real distribution of a host that may have scanned 50 unique targets once as compared to a host scanning a single host 50 times. Visualizing this data with AfterGlow generates the following image:

The external "Yellow" hosts are actually from our test network. All of the nodes in the center are target nodes for the port scans. What this graph shows is hosts that have a large number of unique targets. In the lower left of this display, several nodes have scanned several dozen unique targets whereas, there are many other port scan sources that only targeted one host.

Working With AfterGlow

To create the above displays, data was downloaded from the Security Center as comma separated variables. It was then sanitized (i.e. replacing certain live IP addresses with something else). Lastly, the data was modified from the .csv format to something that AfterGlow can consume. The following PERL script can be used to convert a .csv file from the Security Center that listed IDS or Log events:

#!/usr/bin/perl
open(FH,"source.csv");
open(WH,">afterglow.csv");
$line = <FH>;
while (<FH>)
        {
        $line = $_;
        #$line =~ s/xxx/yyy/g;
        $line =~ s/\"//g;
        @stuff = split(",",$line);
        print WH ("$stuff[2],$stuff[3]\n");
        }
close(FH); close(WH);

It takes a file named source.csv and creates afterglow.csv. The new file will simply have the source IP and the destination IP on the same line separated by a comma. On the commented out line, the 'xxx' and 'yyy' could be replaced with various octets to obscure your IP network ranges. For example, if you wanted to replace all IP addresses that started with 10.10 to be  20.20, you would use a statement like:

$line =~ s/^10\.10\./20.20/g;

Please refer to the AfterGlow web site for more information on how to create these sorts of graphs.

For more info

The Tenable 3D Tool is available for the Security Center and can visualization topologies, IP vs. Port relationships and IP vs. Vulnerability ID relationships. A video of how the tool is used is available here. The video includes a display of a network with more than 400 routers and 10,000 nodes.

The SecViz web site also has very good discussions and example images of security data visualization.

Version 3.0 of the Passive Vulnerability Scanner (PVS) dynamical alerts when it finds "new" pieces of information about the network. Potential information includes open ports, browsed ports, OS fingerprints, client applications and network services. This blog entry discusses how the occurrence of "new browsed port" events can be used to look for various types of malicious behavior.

Browsed vs. Open Ports

Obviously, both Nessus and the PVS can tell you which systems have ports that are open for services such as http, smtp, ftp and so on. What is unique about the PVS though, is that it can tell you which systems on your network have been known to browse on a certain port at least once. It uses ID #00002 and is labeled "Client Side Port Usage" by the Security Center. Consider this screen shot for a single IP address of 192.168.20.16:

This server has only browsed on ports 5900 (vnc), 80 (http) and 443 (ssl). It may have used the VNC client one time, 50 times or more. From this report, we don't know how many time this host was active on a certain port, but could if we had configured a Log Correlation Engine (LCE) to grab netflow or network sessions.

Consider this host which performs "heavy" network browsing, P2P file downloads and uses the Skype chat tool:

This host has reached out to 32 unique ports at least once while the Passive Vulnerability Scanner was monitoring it.

Real-time Notification of New Port Browsing

The PVS has the ability to alert when something "new" has been added to it's model of the network. This includes alerting when a host begins browsing on a certain network port. Under the Log Correlation Engine, these events look like this:

For this particular demo network, the PVS has generated 42 "PVS-New_Port_Browsing" events in the last 24 hours. These events are used by many LCE TASL scripts to look for network change, and even look for events from various NIDS which may be followed by a host performing "new" types of network activity.

Looking for Worms and Trojans in "Live Data"

When systems are compromised by some sort of rootkit, botnet agent, maleware or some other type of malicious software, they tend to use their own network channels to communicate for command and control. Obviously, some bots are more stealthy than others, but the large bulk of them open up network connections to someplace else to report home and receive commands. If these connections are on ports not normally visited  by a system, they "stick out" in the traffic.

Consider the following list of "new browsed ports" for all systems on a large network being monitored by the Passive Vulnerability Scanner for the past 5 days:

Many of the ports involved (7000, 7777, 22, 6667, 8008, .etc) are very common server ports to host maleware and control botnets with. This information needs to be analyzed. Just because a server connects to port 6667 (irc) for the first time, doesn't mean it is not used for IRC chatting and is a bot.

Someone who wished to analyze this data further could use the Security Center and simply query for the number of "browsed ports" that the PVS has detected for a specific network. Such a query could look like this:

These are all of the ports that the network has reached out on at least once. Port 80 is web traffic and many of the other ports are chat or P2P specific.

Those listed ports in the above image are just the top ports. If we wanted to get a listing of all systems that had browsed on port 7000 or some other port, we'd just select plugin ID #00002 and the port or ports of interest, and then perform a "Summary by IP" or "Summary by Class C" report. This is also an excellent way to figure out if your outbound firewall or proxy configurations are being effective.

For worm and trojan analysis, it can be more interesting to track the "new" port events in the Log Correlation Engine. For example, considering port 7000 "new port browsing" events over the past 25 days produces a graph like this:

These spikes indicate that large numbers of hosts all began browsing the network at the same time on port 7000. This can correspond to worm outbreaks, use of P2P and chat applications and also initial botnet infections.

It's important to understand that there are legitimate reasons for spikes in everyday network activity and to consider other environmental factors. For example, consider your DHCP lease times. If you have a large user population that gets brand-new IP addresses every few days, then their normal traffic will show up as a spike of new port browsing events.

For More Information

Tenable has posted several items in this blog which discuss virus and worm analysis with Nessus scanning and passive network monitoring. They are listed below:

• Detecting Compromised Windows Hosts
• Finding Patched/Infected MS06-04 Systems
• Detecting Zombie/Botnet Crowd Surges
  
• Blacklist Event Correlation
  

Tenable's research group released a Log Correlation Engine (LCE) log parser library for events generated by the Port Scan Anomaly Detector (PSAD) tool. The LCE PRM library is available here for download. PSAD considers logs from the Netfilter firewall and alerts when port scans occur. It also has the ability to react to the scan by adding "block" rules to the firewall.

Adding the PRM to the Log Correlation Engine

Using wget, download the PSAD PRM library, as well as the latest copy of the prm_map.prm file. This is a list of all PRM event IDs and is required by TASL scripts such as the Never Before Seen script. If users have also deployed the portscan_spike.tasl script, it has been updated to accept port scan detects from PSAD.

Firewall Monitoring and Cipherdyne

Michael Rash runs the Cipherdyne web site which hosts his blog and several useful tools relating to iptables. He also has an upcoming book titled "Linux Firewalls: Attack Detection and Response". I've had the chance to review an early copy and think it will be very useful for organizations that run Linux firewalls.

A general theme in Michael's work is that firewall log data should be considered for security monitoring and incident response. Too often, I encounter organizations that consider a firewall as purely an access control enforcement device and not something that can produce rich logs.

The firewall PRMs written for the Log Correlation Engine not only process accept and deny events, but also proprietary events such as port scan detection, spoofing events, attacks on the firewall and perhaps the most import type of log, firewall configuration changes.

In the absence of netflow or direct network sniffing, a firewall's "accept" logs could be the only evidence of a network connection. Many of the TASL scripts written for the LCE will process firewall logs just as readily as a netflow or sniffed session.

Many organizations have IT configuration polices that require CDs and USB drives to be disabled. This blog entry discusses a simple way to use a Nessus 3 .audit file to test a Windows 2003 server for the correct registry settings that disable "AutoRun" of programs on CDs as well as disables USB drives.

Windows 2003 Registry Settings

On Windows 2003 servers, the following registry setting controls "AutoRun" for CD drives:

HKLM\SYSTEM\CurrentControlSet\Services\Cdrom

If the item "AutoRun" is set to zero, then the system won't run CDs when they are inserted into the server. Below is a screen shot, with the "AutoRun" item circled, of a Windows 2003 server's registry settings using the regedit.exe tool:

To disable USB drives, the following registry setting should be set to a value of "4":

HKLM\SYSTEM\CurrentControlSet\Services\UsbStor\start=4

According to Microsoft Knowledge Base #823732, systems that have this setting in place will have their USB drives completely disabled. Please note that this registry setting only applies to USB storage devices that are being installed and have no effect on devices already attached to a server.

Example .audit File

The following is a self-contained .audit file which tests the registry settings to have CD-ROM "AutoRun" and USB drives disabled:

<check_type: "Windows">
<group_policy: "Audits Windows 2003 Systems for AutoRun and USB storage devices being disabled">

<custom_item>
        type: REGISTRY_SETTING
        description: "CD AutoRun Disabled"
        value_type: POLICY_DWORD
        value_data: 0
        reg_key: "HKLM\SYSTEM\CurrentControlSet\Services\Cdrom"
        reg_item: "AutoRun"
        reg_type: REG_DWORD
</item>

<custom_item>
       type: REGISTRY_SETTING
       description: "USB Storage Devices Are disabled"
       value_type: POLICY_DWORD 
       value_data: 4
       reg_key: "HKLM\SYSTEM\CurrentControlSet\Services\UsbStor"
       reg_item: "start"
       reg_type: REG_DWORD
</item>

</group_policy>
</check_type>

Click below to download the example .audit file:

Download autorun-disabled.audit

Using this .audit file with Nessus 3 For Windows

Nessus 3 Direct Feed subscribers can save the above .audit file to their local computer. They should then create a scan policy which makes use of this .audit file and has the appropriate credentials to read the registry of the audited systems.

If an existing scan policy with the right credentials is available, consider adding this .audit file as a second or third policy. Each scan policy can have up to 5 separate UNIX and Windows .audit files.

Below is a screen shot of an example report generated by the above .audit file from a test Windows 2003 server.

Vulnerability ID #21157 is the value assigned to all Windows compliance audit results. In the results, it can be seen that CD-ROM "AutoRun" has indeed been disabled, but USB storage devices are enabled with a value of "3".

Using this .audit file with the Security Center

Security Center users should have their administrator save the .audit file to the /opt/sc3/admin/nasl directory, and then restart the Security Center to ensure it gets pushed out to all of the managed Nessus scanners.

To make use of the new .audit file, either a new scanning policy should be created with the proper Windows credentials that makes use of the new .audit file, or this new .audit file should be added to an existing scanning policy. Like Nessus 3, scanning policies in the Security Center can also use multiple .audit files.

Below is a screen shot of the results of a scan against the same Windows 2003 server we tested above with Nessus 3.

Since these compliance results have been imported into the Security Center, they have been given unique IDs of #60186 and #60187. The Security Center interprets Nessus plugin IDs #21156 (UNIX) and #21157 (Windows)  as "compliance" IDs and re-maps these to IDs greater than 65000. This allows for unique reporting, ticketing, dynamic asset list creation and tracking for unique compliance issues. 

For More Information

Tenable has placed several dozen .audit files online which can perform comprehensive audits of UNIX and Windows systems. These polices are derived from the United States CERT, NIST and NSA organization's guides for locking down UNIX and Windows servers. Documentation and tools are also located at that site which can be used to create your own policies. Compliance audits with Nessus 3 are available to all Direct Feed subscribers and Security Center users.

There have been several security bloggers "tagging" each other this new year and recently I got tagged. Normally, I try to keep this blog fairly technical and product centric. Since I don't have a personal blog and I don't want to be rude, I'm posting "5 things about Ron Gula" most folks may or may not know here and tagging 5 other folks who have not been tagged yet. We'll follow this post up with a technical one right away.

Five facts on Ron Gula you might not know

1. I originally went into the Air Force to be a pilot, but didn't do that well in flight school, had issues with G forces and eventually went back purely into computers. The experience really helped me focus much later on how important it is to know your audience and give them the right data at the right time. Experiences describing information security issues to the "war fighter" helped me prepare for building security products which were relevant to small and large enterprise customers.

2. I work with my wife, Cyndi Gula, voluntarily. A lot of folks who find this out seem to be quite surprised by this fact. This is the second company we've worked on together, the first being Network Security Wizards which did the Dragon IDS. Cyndi runs the internal operations for Tenable.

3. I'm also the CEO for Tenable Network Security. Most of the time, I use the CTO title, which tends to get more attention and less requirements for wearing a suit or a tie.

4. I like to run almost as much as I enjoy a good cigar. Fortunately for my lungs, I tend to run more than lite up a Macanudo.

5. I still feel very positive about my experience at Enterasys with Dragon. There were many people that benefited (and still do) from working with Dragon. This included a lot of technical, marketing and sales folks who went on to form new companies and new careers in the security space. This also includes a lot of customers who are still running Dragon today. I recently had the chance to do some incident response for a customer who had deployed Tenable products all over the world. In their SOC was also Dragon.

Five blog pings for people I respect

• Robert David Graham
• Michael Rash
• Dale Petersen, CEO Digital Bond
• Ariel Silverstone
• Timothy 'TK' Keanini., CTO nCircle

On January 3rd, 2007, Tenable's research group released a NASL script (plugin #23971, currently available to Direct Feed and Security Center customers) to test if a scanned host is on a different logical network, but also on the same physical network. If this is the case, your network may have a potential security issue, as IP based access control filtering may not be effective. This blog entry discusses what the plugin does, why this is important and comments on general firewall and access control auditing with Tenable solutions. 

What the Script Does

The NASL script attempts a layer two "ping" of target IP addresses that are not part of the local IP network (i.e., outside of the local netmask). If a response is received, then both devices share the same switching fabric and the potential security issue is reported as an informational vulnerability.

Why this is Important

If you are using some sort of routing, firewalling or proxy filtering to segment IP based networks, then an attacker may be able to create a virtual network interface and then connect directly to the target network.

For example, perhaps your organization has a DMZ with some "important" servers in them such as mail, web, .etc. and you also have a public network. There may be IP access control rules separating  the two networks. If these devices connect to a common switch though, a user in the public network may be able to configure a virtual interface with an IP address inside of the DMZ and directly access those servers. This could bypass security completely.

Consider a simpler example such as a web application that has a simple "IP based" form of access control, and requires remote users to originate from the 192.168.20.0/24 subnet. If there was one large collision domain and a remote host could perform an Ethernet "ping" of this application, they may also be able to create a virtual  interface with an IP such as 192.168.20.3 and connect to the application.

The solution is to use separate VLANs to segment layer 2 (Ethernet) traffic, or even multiple physical switches separated by routers or firewalls.

Analyzing the Results of the Plugin

Keep in mind several things when analyzing these results:

• The test is occurring from the Nessus scanner. If you've provisioned your scanner with multiple interfaces and/or on multiple VLANs, then there might not be such an issue. However, if you've put the Nessus scanner in the HR network, and it can ARP ping hosts in the DMZ, you likely have a layer 2 security issue.
• If you have MAC filtering in place on your switches, this is better than no filtering at all, but a user may be able to create a virtual interface with a MAC address that is either valid or not explicitly filtered.
• Even if you have a firewall or some sort of IP filtering in place, if packets can be sent at layer two, you may be able to completely bypass the firewall.
• The script basically says, the target is on a different IP network than I am, but I can also do an Ethernet ping to him. Keep in mind that some types of firewalls, proxies, NAC devices, security routers/switches and even honeypots may "respond" on behalf of their target.

Auditing Firewalls and ACL Polices In General

Tenable recommends a few different strategies for monitoring the security of IP based access control schemes.

• Use distributed Nessus scanners that both scan "from the outside" as well as between political groups and organizations. If you conduct this sort of monitoring routinely, you can find changes in firewall policies when new ports become open, and you can also identify trust relationships between organizations within your network.
• Continuous passive network monitoring, such as with the Passive Vulnerability Scanner, can identify all active hosts, hosts with open ports, hosts browsing on the Internet and internal trust relationships. By analyzing this data, a good understanding of the "real" set of access control policies can be determined.
• Conducting log analysis of the actual firewall logs can be used to look for changes in the actual firewall configurations and lack of logs for expected and authorized traffic. Tenable's Log Correlation Engine supports this sort of analysis.      

Obtaining This Plugin

This plugin will be available to Registered Feed users January 10. It is currently available to Direct Feed and Security Center users.

Many Tenable customers and Nessus users have asked us for recommended strategies to discover where sensitive information is placed on the network. Often, organizations have segregated networks to separate sensitive data and want to verify compliance with the corporate policy. This is particularly important for organizations subject to legislation such as Sarbannes-Oxley or HIPAA. This blog entry describes some scenarios and strategies for finding sensitive data using Nessus, the Passive Vulnerability Scanner and the Security Center.

Searching for "Office" Documents on Web Servers

Plugin #11419 will search web servers for any documents with the following extensions:

.doc .wri .xls .ppt .csv .rtf .pdf

as well as less common:

.dif (another spreadsheet extension)
.sxw (Open Office Writer)
.sxi (Open Office Presentation)
.sxc (Open Office Spreadsheet)
.sdw (StarWriter)
.sdd (StarImpress)
.sdc (StarCalc)

This plugin is dependent upon the Web Mirror plugin (#10662). This NASL creates a mirror of all files on the remote server. Plugin #11419 then searches the Nessus knowledge base for files which have the above extensions. Mirroring a web server could take longer than your average scan due to bandwidth, size of the web server or even the performance of the web server.

Also, the Web Mirror plugin will follow links on default web pages and try to enumerate common web directories, but it won't find a specific file just being served on a web server. It needs to see a link to the file. For this demo, I placed an example.ppt file in the root directory of an Apache web server. The scans didn't find it until I either turned on directory indexing, or created an index.html file which references the example.ppt file.

Here is an example record of plugin #11419 as viewed under the Security Center:

The presence of one of these files by itself doesn't necessarily mean that your internal records are exposed to the Internet. All this means is that you have found a web server which is hosting a file with an extension that may indicate an "office" document that isn't protected by a password. Tenable has many customers which publish "official but unsensitive" documents as spreadsheets, Word documents or event Adobe PDFs.

Searching for "Office" Documents in Network Shares

Nessus plugin #23974 scans systems for SMB shares which contain the following list of "office" related files:

.doc .wri .xls .ppt .csv .rtf .pdf

as well as less common:

.dif (another spreadsheet extension)
.sxw (Open Office Writer)
.sxi (Open Office Presentation)
.sxc (Open Office Spreadsheet)
.sdw (StarWriter)
.sdd (StarImpress)
.sdc (StarCalc)

Access to the shares is based on the credentials of the scan. Documents identified with this plugin may or may not contain sensitive information. The purpose of the plugin is to simply try to find all of the systems (laptops, servers, SANs, portable NAS devices, .etc) which have files that might need to be secured.

Using Security Center Dynamic Asset lists

The Security Center can be used to create a dynamic asset list of all hosts that have certain types of documents being shared on the web. Actually, the Security Center can create asset lists on almost any sort of data detected by Nessus or the PVS. Below is a screen shot of a dynamic asset rule that would create a list of all systems that had Nessus vulnerability #11419 active:

Plugin #11419 looks for many different types of files (.doc, .pdf, .ppt, .etc), but there may be occasions when we want to look for content that is just for a specific file type. If we know what sort of file extensions we want to find, we can add some text search to our dynamic asset rule to match just what we want. In this case, if we wanted to look for just "Power Point" files, we could add a "Contains the Pattern" clause for the word "PowerPoint" as shown below:

If the pattern was more complex, we could have used a regular expression instead of a simple pattern match.

What can we do with these Asset Lists of hosts that contain sensitive data?

Once we have an asset list of all hosts that contain potentially sensitive data, there are several actions we can take:

All of the vulnerabilities for these servers can be independently considered. For example, all of these servers have specific web or SSH issues that should be addressed.

Instead of looking for the "top" vulnerabilities on these assets, searching them for systems or servers which were not under management could prevent future disclosure issues. If a system is holding sensitive data and it is not under management, common sense dictates this to be a problem.
If a system is holding sensitive data AND it is browsing the network, this could potentially also be suspicious. Typically, servers browse the network only for updates, backups and database queries. If a system holding sensitive data is heavily browsing the Internet, it could potentially be a target for malware, or perhaps the user doesn't know that they are also hosting a server.

If IDS events are being sent to the Security Center, or logs and network traffic are being sent to the Log Correlation Engine (LCE), they can be considered in context of the targets with sensitive data. Dynamic asset lists created by the Security Center are available for immediate use with  queries to the LCE. Login failures, buffer overflows, network anomalies, and even authorized access attempts can all be logged. This can help identify access control violations. For example, if a connection from a certain business group or even the Internet were seen connecting to a server with sensitive data on it, this could constitute a policy violation.

Advanced Dynamic Asset List Usage

Let's say we have many servers, all with some sort of interesting data on them and we also have the PVS recording which ports the systems it is monitoring get "browsed".  We'd like to create a dynamic asset list that identifies all systems with  both Nessus plugin ID #11419 and PVS plugin ID #2 destined for port 80. To do this, create a rule that looks like this:

The first rule clause is probably not familiar to readers. This is an extended regular expression, also associated with a plugin ID. For performance reasons, most rules are evaluated as an "OR" sequence. This makes it easy to find a certain combination of plugin IDs and ports. This rule clause matches if a server has plugin #2 present on it, and the data for that vulnerability ends with " 80". The ":" is used to separate the plugin ID from the regular expression. Regular expressions can use anchors such as "^" to indicate the start of a line and "$" to indicate the end of the line.

The second rule clause is a simple plugin match for Nessus ID #11419.

Both of these rules together will create a dynamic asset list of any host that has sensitive data that has also browsed the web on port 80. Since servers likely use the web queries to obtain updates, the reader should consider using a port such as 110 for POP or 143 for IMAP  or even 22 for SSH. These ports aren't used as often as port 80 though.  Another idea would be to look for PVS plugin IDs that identify the web browser in use as Mozilla.

For More Information

Tenable has other methods to search for sensitive data in motion. Several plugin libraries exist for the Passive Vulnerability Scanner which allow it to monitor plain-text traffic for credit cards, social security numbers and other types of sensitive data. Tenable has blogged about the PVS libraries and how to install them here. In addition, Tenable has partnered with content monitoring vendors such as Reconnex and has written several TASL scripts for the Log Correlation Engine engine.

This entry concerns more information and analysis of output from the "Never Before Seen" TASL script for the Log Correlation Engine (LCE). We've had the script running at several customer locations and have had interesting data to discuss which helps show the script's usefulness. This blog entry discusses analyzing the results from IntruShield IPS events as well as overall "never before seen" event trending.

Reviewof the "Never Before Seen" Concept

As we've previously blogged, the nbs.tasl script alerts when any event type from any source occurs for the first time towards or away from a given "local" IP address. This can be a IDS event, firewall deny log, Active Directory login failure -- it doesn't matter. The basic principal is that stuff that happens all the time doesn't get alerted on and only new stuff does.

Event with this sort of filtering, on real "large" or "busy" enterprise networks, there can still be a large number of "never before seen" events. Analyzing them can lead you to a rich set of unique event data that may normally get overlooked.

IntruShield IPS Event Analysis

In the screen shot below, a large network being monitored by the IntruShield IPS, a PVS and the Log Correlation Enginer's Network Monitor has all of their events normalized:

There were 2062 unique events we've not seen before. Conducting a sort for top IP addresses yields this view (with our IP addresses concealed):

The IP at 204.16.209.59 was out top source of "new events" that haven't been seen before. Keep in mind, the same IP could have also been doing many evil things that have been seen before, but those events would have been buried in all of the other normalized events.

Looking at the actual SYSLOG messages for this these events reveals that the source IP has been detected by the IntruShield IPS for violating some sort of protocol:

Looking at the logs, it can be seen that the remote IP address is trying several IP addresses in a row in the same local subnets.

Knowing that we might have a "bad guy" IP address on our hands, doing a quick summary of all events for 204.16.209.59 yields the following results:

So not only have there been a good deal of protocol violation events logged by the IntruShield IPS, this IP address was tagged by the SANS Internet Storm Center and matched with the blacklist.tasl script. The algorithm of highlighting "never before seen" events helped point us in the right direction for an attacker scanning our network.

Large Scale Trending

Here is a graph of "never before seen" events occurring at a large network:

The amount of "never before seen" events may appear random, but (from left to right) it is steadily decreasing over time. As the nbs.tasl script learns more and more about what happens on which hosts, as new events occur, they can be easily highlighted. These new event types might identify compromised systems, new types of scans, configuration changes and so on.

Tenable has seen similar patterns of decay for the nbs.tasl script alerts on lab networks, home networks and multiple large networks. As time goes on, the alerts become more and more unique and this becomes very valuable to understand what has changed on a given network.

For More Information

The previous blog entry on "never before seen" events is located here. Tenable also has a webinar on network based anomaly detection located here.

One of the new features of Security Center 3.2 is the availability of many report templates. These allow any Security Center user to quickly create a report for one or more of their asset groups.

Some templates are very simple (such as all of the vulnerabilities from a specific Nessus plugin family) and included for convenience. Other templates take advantage of some unique features in Security Center 3.2 and our other products such as the Log Correlation Engine (LCE) and the Passive Vulnerability Scanner (PVS).

To select the verbosity level of a report, most templates include three options being "Summary and Trend", "System Details" and "Vulnerability Details". The trend report presents a list of matching vulnerabilities, vulnerability count by asset group and other high level information. The "System Details" options adds in lists of specific networks (summary by Class C network address) and lists of IP addresses. And lastly, the "Vulnerability Details" template includes all data known about the
vulnerabilities, including the unique responses from the systems reported on.

Below is a screen shot of where Security Center 3.2 users can select the report templates:

This template interface is available after a user chooses a report title and filter.

Below is an alphabetical list of each report type and what it does. For each chapter template, the source of data (Nessus, PVS, LCE or IDS data) is noted. In addition, if there are any special prerequisites (such as having a specifically named Asset Group) they are indicated as well.

NOTE: The "Vulnerability Details" report is extremely verbose. Even for a list of 100 computers, it can produce reports hundreds of pages in length.

AIX Patch Audit (Nessus credentialed patch audits) These templates include a list of all missing AIX patches.

Apache Web Servers (All Vulnerability Sources) For asset groups named "Apache 2_2 Web Server", "Apache 2_0 Web Server" and "Apache 1_3 Web Server", any available vulnerability data is reported on. Dynamic asset templates to automatically classify systems within these assets lists are available in the Security Center.

Asset Vulnerability Summary (All Vulnerability Sources) This template creates chapters unique to the actual assets assigned to the individual creating the report. These "by asset" chapters include generic vulnerability summaries, Database issues, Compliance issues, new issues discovered in the last 30 days, open ports, browsed ports, Internet browsing devices and patches.

Browsed Ports (Passive Vulnerability Scanner) Reports separately the TCP and UDP ports that are being "browsed". A third chapter includes a list of Class C networks which browse the Internet.

Cisco Patch Audit (Nessus credentialed checks) Lists all missing IOS security patches.

Common Open Ports (Nessus and Passive Vulnerability Scanner) Lists all open TCP and UDP ports, as well as unique Class C networks with open UDP and TCP ports.

Compliance (Nessus credentialed compliance audits) Reports on all compliance configuration issues.

Database (All Vulnerability Sources) Lists all vulnerability issues actively and passively discovered.

Discovery Report (All Vulnerability Sources) This template highlights very useful information about the discovered devices on the network. Chapters include passively discovered operating system types, trends of "pingable" hosts, trend of Internet browsing hosts and lists of detected services.

Email Server and Client Issues (All Vulnerability Sources) This report highlights all things related to email delivery, client usage and server security issues. Chapters include all vulnerabilities discover on common email ports, patches missing for Outlook and Exchange, lists of hosts and network which send or receive email, and unique chapters for Nessus and PVS families related to email.

Exchange Servers (All Vulnerability Sources) For asset groups named "Exchange - W2003", "Exchange - W2K", "Exchange - W2K-SP3" and "Exchange - WinXP", any available vulnerability data is reported on. Dynamic asset templates to automatically classify systems within these assets lists
are available in the Security Center.

Hosts With Discovered Vulnerabilities in Last 'N' Days (All Vulnerability Sources) This chapter finds all vulnerabilities discovered in the last 5, 15 or 30 days and lists them out, their ports, the networks and the assets effected by them. If the PVS is in use, or daily active scans are occurring, these reports can show the most recent vulnerabilities.

HP-UX Patch Audit (Nessus credentialed checks) Lists all missing HP-UX security patches.

IDS Targeted Events (IDS Events) Summarizes yesterday's IDS activity with separate chapters for inbound, outbound and internal events, as well as separate summaries for TCP and UDP events.

IDS Targeted Ports (IDS Events) Summarizes yesterday's IDS activity with separate chapters for inbound, outbound and internal ports corresponding to IDS events, as well as separate summaries for all TCP and UDP ports with IDS event activity.

IIS Web Servers (All Vulnerability Sources) Summarizes all vulnerability data for assets pertaining to specific IIS web server type. The asset names are "IIS 6_0 Web Server", "IIS 5_1 Web Server" and "IIS 5_0 Web Server". Templates for dynamic asset rules for these asset types ship with the Security Center and make use of both active and passive discovery.

Incorrect Credentials (Nessus credentialed checks) This template summarizes output from Nessus ID #21745 which reports on issues related to incorrect SSH and Domain credentials. Separate chapter summaries are provided for unique Class C networks and hosts.

LCE Event Summary - Last 'N' Days (Log Correlation Events) This template summarizes all events recorded by the Log Correlation Engine for the past day, two days, five days and 25 days. It lists all events and has separate chapters for inbound, outbound and internal logs.

LCE Port Summary - Last 'N' Days (Log Correlation Events) This template summarizes all ports effected by events recorded by the Log Correlation Engine for the past day, two days, five days and 25 days. It lists all ports and has separate chapters for inbound, outbound and internal logs.

Linux Patch Audits (Nessus credentialed checks) This template lists all known missing security patches for Linux operating systems supported by Nessus. This includes RedHat, CentOS, and several others. Separate chapters for each OS are included.

MacOS X Patch Audit (Nessus credentialed checks) Lists all missing MacOS X security patches.

Nessus Scan Summary (Nessus scan and credentialed checks) This chapter summarizes all vulnerability data. The "Vulnerability Details" version of this template should only be used on small numbers of hosts.

Open Ports Summary (All Vulnerability Sources) This template lists all open TCP and UDP ports, as well as lists of all assets which have open ports. A last chapter includes a list of vulnerabilities which have "high" severity levels.

Outbound Internet Connections (Passive Vulnerability Scanner) This template makes extensive use of PVS ID #3 (the show connections plugin) and any targets of 0.0.0.0. The template summarizes all hosts, outbound ports, internal browsing networks and browsing hosts per day.

Passively Discovered Clients (Passive Vulnerability Scanner) The PVS identifies many different types of information about monitored networks. This template includes chapters for passively discovered operating systems, passively discovered email client types and passively discovered web client types.

PCI Level 4 and 5 Asset Summary (All Vulnerability Sources) This template lists all assets which have vulnerabilities scored as a PCI level 4 or 5 severity.

PCI Level 4 and 5 Nessus Scan Summary (Nessus scan and credentialed checks) This template lists all vulnerabilities which have scored as a PCI level 4 or 5 severity.

PCI Nessus Scan Summary (Nessus scan and credentialed checks) The PCI standard assigns vulnerability severity levels between 1 and 5 with 5 being the most severe. This template produces a report which maps all Nessus vulnerabilities into each of these severity levels.

PVS (Passive Vulnerability Scanner) The vulnerabilities and information about the systems and networks monitored by the PVS is captured in this report template. Separate chapters for browsed ports, discovered vulnerabilities, open ports and Internet browsing devices are included.

SANS Top 20 (All Vulnerability Sources) Tenable includes report templates for the vulnerabilities and recommendations published by the organization. The report template produces chapters which correspond to the topics (such as the "W2 Windows Libraries" in the SANS Top 20 2006 Q4 update) in the corresponding SANS lists.

Solaris Patch Audit (Nessus credentialed checks) Lists all missing Solaris security patches.

Vulnerability Report (All Vulnerability Sources) This template includes various chapters about discovered vulnerabilities.

Web Server and Client Issues (All Vulnerability Sources) This chapter considers all vulnerability data and network information pertaining to web security. Separate chapters are included for Nessus and PVS plugin families related to web servers and clients, vulnerabilities on port 80 and 443, and lists of systems and networks which browse the Internet on port 80 and 443.

Windows OS (All Vulnerability Sources) This template lists vulnerabilities by asset groups which have been defined by the Windows operating system type. Several dynamic asset lists are included to build asset lists named "Windows 2000", "Windows 2003" and "Windows XP". This template summarizes vulnerability data for each of these assets in separate chapters.

Windows Patch Audit (Nessus active and credentialed scan data) This template summarizes vulnerability data from the "Windows : Microsoft Bulletins", "Windows : User management" and "Windows" Nessus groups.

Windows OS and Application Audit (All Vulnerability Sources) This template summarizes all vulnerabilities by asset type for the Windows operating sytems and applications. Chapters for the "Windows 2000", "Windows 2003", "Windows XP", "IIS 6_0 Web Server", "IIS 5_1 Web Server", "IIS 5_0 Web Server", "Exchange - W2003", "Exchange - W2K", "Exchange - W2K-SP3" and "Exchange - WinXP" are included.

Tenable Network Security has released version 3.0 of the Passive Vulnerability Scanner (PVS). This version supports realtime vulnerability alerting, enables monitoring of corporate networks for data leakage and completes the re-branding from "NeVO".

A major new feature of the PVS is the ability to stream new vulnerability information in realtime to the Security Center and to the Log Correlation Engine. As the PVS finds new data about the network, it is sent in realtime in logs such as this:

Apr 20 19:58:21 pvs: 192.168.20.22:0|0.0.0.0:0|17|13|new-host-alert|00:11:95:89:d4:8a
Dec 21 10:56:04 pvs: 162.21.99.99:53|192.164.141.12:36788|17|1016|DNS server detection|||INFO
Dec 21 10:56:04 pvs: 169.31.24.219:80|0.0.0.0:0|6|0|new-open-port|INFO

The PVS realtime alerts include:

• new vulnerability and network data with low, medium and high severity levels
• new hosts, new open ports, new "browsed" ports, new systems that perform
  Internet browsing and new trust relationships between internal devices
• evidence of compromised systems and serious attacks, such as against SCADA devices
• detection of internal hosts performing port scans
• support for detecting a variety of sensitive data in motion and at rest

Example Screen Shots

Below is a screen shot of PVS events on a large enterprise network under the Security Center:

Each of the "events" listed above occurred when the PVS encountered new vulnerability data that it wasn't previously aware of. The LCE normalizes the 1000s of potential PVS vulnerabilities based on their severity levels. In the above screen shot, 26 new vulnerabilities with "HIGH" severity levels have been discovered.

Although not a network IDS, the PVS does discover very useful events which can be fed into the Security Center, the Log Correlation Engine or most SIM products. Below is a screen shot of several PVS events intermixed with IDS events from an Intrusheild IPS. There are several different port scan events as well as two Windows error event detections.

Log Correlation Engine Support

With this release, a separate Log Correlation Engine library for PVS events has been produced, and several of the existing correlation scripts have been updated to take advantage of the new events. These include:

• tenable_pvs.prm log normalization library for PVS events
• botnet_with_scan.tasl correlates detected IDS Botnet events with the same host performing a port scan
• detect_change.tasl now also processes new host and new open port events from the PVS (Note: this script can be extended to alert on new trust relationships, new Internet browsing and new client side port browsing if desired.)
• ids_event_followed_by_change.tasl considers changes in host configurations or behavior after being attacked. Now supports detected attack events from the PVS.
• new_host_portscanning.tasl uses PVS events which identify new hosts and port scan events to discover when a new device immediately begins port scanning.
• portscan_spike.tasl now uses port scan and host scan logs from the PVS, along with any portscan log from supported IDS and firewall devices to look for short term spikes in scanning activity.
• windows_crashes_and_restarts.tasl now makes use of PVS ID #4722 which sniffs Windows error messages being sent back to Microsoft. The script considers this event along with Windows OS events such as crashing applications and system restarts to look for failed worm attacks and even failed compromise attempts.
• lce_tasl.prm is the LCE PRM library which normalizes events from the TASL scrips. This file should be updated on your LCE if any of these modified TASL scripts are implemented.

Obtaining PVS 3.0

Versions for UNIX and Windows are both currently available. Tenable recommends that both products are recommended to be managed with the Security Center. Existing NeVO 2.2 customers can upgrade to PVS 3.0 as long as their maintenance is up to date. New customers should contact Tenable's sales staff.

Tenable has released version 3.2 of the Security Center. This new version includes several major new features:

• templated reporting with many new pre-configured reports
• data export via spreadsheet for any interactive query
• per user Active Directory authentication

The Security Center is available for Red Hat ES3 and ES4. Existing Tenable Security Center customers can upgrade to version 3.2 if their maintenance is up to date. New customers should contact the Tenable sales group for pricing.

Templated Reporting

This release enhances the reporting options available to all users. When creating a report, users can make use of the existing 3.0 report wizard or select from a list of pre-configured reports. Report templates exist for many basic reports, such as all missing Microsoft Patches, and also advanced reports such as SANS Top 20 and PCI.

Data Export via Spreadsheets

Any user of the Security Center can export their vulnerability, compliance, IDS event or log data to a .csv spreadsheet file. Any tool which summarizes ports, lists vulnerabilities, lists logs, and so on, can have the output saved into a spreadsheet. This data can be saved at any point a user is navigating through the Security Center's GUI.

LDAP Authentication

Security Center 3.2 can be configured to authenticate to any LDAP server, such as a Microsoft Active Directory server. Once this is enabled, any existing user (or new user) can be set to authenticate via LDAP. When adding a new user, the Security Center will also pre-populate the user's data such as full name, phone number and organization.