I was very excited to read Joel Snyder's review of Sourcefire's RNA and our Passive Vulnerability Scanner (PVS). (The article requires registration). He makes a lot of very good points about the accuracy of passive network analysis and does a very good job of contrasting the Sourcefire 3D system for managing IDS events and our Security Center for managing security. There are some points I would like readers to take away from the article though:

• During the evaluation, our PVS mis-identified an anti-spam appliance as having several client-side vulnerabilities. We had an error in the logic of some of our PVS signatures and have fixed it. This single fix would have drastically lowered the number of issues dealing with false positives during the evaluation.
• There are major design differences between RNA and PVS. To quote the article, "If Tenable uses an "innocent until proven guilty" approach to marking vulnerabilities, Sourcefire considers every system "guilty until proven innocent." Basically, as soon as RNA guesses your OS, it attaches any potential vulnerability it knows about it. I think this approach is great for IDS event correlation, but for vulnerability management, it is too broad. At Tenable, the same team that writes the Nessus host based and scanning checks writes the PVS checks. Our Security Center does do IDS/vulnerability correlation with many NIDS including Snort, but since we're more application focused, there are less correlations.
• I wished the article went into more of the benefits of doing continuous and passive analysis as a compliment to active scanning. Joel gives the impression that these tools are only good for large networks. Tenable has many customers putting the PVS in places that A) can't be scanned that often or B) simply can't be scanned. For more information, I highly recommend our papers "Security Event Management" and "Correlating IDS Alerts with Vulnerability Information" available in the White Papers section of our web site.
• Lastly, the article didn't evaluate our Log Correlation Engine product. This would have allowed the evaluators to search all Snort logs for the duration of the evaluation, as well as add in logs from our passive network monitor. The combination of knowing the sort of information that PVS can discover along with having a record of all of your firewall, network sessions, user logs, .etc is very compelling.

If you haven't seen a product like RNA or PVS before, please feel free to take a look at the demonstration video we have here.

As you might expect, I would really like to see more evaluations like this. Tenable has been offering our PVS solution for several years now. We have many different enterprise customers that run our vulnerability detection solutions in credentialed, scanning and passive modes. The more sophisticated customers use different combinations of these technologies across their enterprise as dictated by political and technical network limitations. I think articles like this, although good for Tenable, can also get network users out there to consider other sorts of tools to perform network discovery.

Tenable has made the "3D Tool" for the Security Center available. A web-based video of it can be viewed here. The video shows a three dimensional topology graph of some different networks, as well as port to IP and vulnerability to IP graphs. Videos of all of our products can be view here. This tool is included for Tenable customers who purchased the Security Center.

The Tenable Research Team has made available an pre-compiled NASL script (an .nbin file) which can be used from any Nessus 3 installation to interact with a remote windows host on top of port 139 or 445. This can be used to:

• Navigate thru the remote SMB shares and download files or obtain their version number
• Read/Enumerate the remote SMB registry
• Query/Start/Stop/Pause remote services
• Query information about the remote users / groups
• Obtain an interactive shell (cmd.exe) on the remote host

The .nbin file requires Nessus 3 on UNIX or Windows. For more information and to download the tool, please visit here. The link also includes a quick flash demo and documentation on how to install use this plugin.

If you are not that familiar with .nbin files, Nessus 3 has the ability to use pre-compiled NASL scripts. This allows authors to write their checks for Nessus and not publish their algorithms. For example, if someone had a zero-day exploit they wished to code in NASL, they could do so and give out the .nbin without giving out the source code. There are several .nbin plugins in the Direct and Registered Nessus feeds.

Tenable's Log Correlation Engine (LCE) can accept events from the Reconnex iGuard. If you are not familiar with products like the iGuard, it is a sophisticated network traffic analyzer that can look for social security numbers, credit card numbers, and important corporate data as it flows across instant messaging, email attachments, web surfing and most other forms of network traffic.

Having the LCE be able to parse logs from the iGuard allows users of the Security Center to analyze traffic on their separate network segments. This means Joe from accounting can see the iGuard events for his network and Sue from HR can get alerted for their events. Tenable has also written some advanced TASL correlation rules that look for systems being attacked and then having their sensitive data transferred by the attacker. Using intrusion detection logs and iGuard logs, the LCE can recognize when a system has been under attack and then sensitive data has been obtained from the target.

I was at a Security Center customer this past Friday and they had asked how they could report on just certain computers that had certain applications on them. One of the things the Security Center can do is "mine" the results of the existing and future Nessus and Passive Vulnerability Scanner results to come up with dynamic lists of IP addresses with matching criteria. For example, consider this screen shot:

In the above image, the Security Center has been configured to dynamically create lists of various IIS, Sendmail, Apache and other types of applications. These rules are wizard driven and look like this:

That "2004" plugin ID probably isn't recognized by Nessus users because IDs 1 through 10,000 are reserved for results from Tenable's Passive Vulnerability Scanner. This rule says for each known IP address, if there has been a discovery of ID 2004 or 10263 (plugins which discover SMTP servers regardless if they are on port 25 or not) look at the content and if we see "Sendmail" and "8.13" put it on the list of "Sendmail 8.13" servers.

The Security Center allows for dynamic lists to be created like this with active or passive content based and also some interpreted content including:

• DNS name
• NetBIOS/Workgroup name
• MAC Address
• IP/Network address
• open TCP port
• open UDP ports
• existence of particular vulnerability IDs
• regular expression content search

Very sophisticated dynamic rules can be created. For example, all OSes actively fingerprinted as "Linux", in the 10.10.20.0/24 network with port 22 open could be placed on a list. 

If an organization knows about their devices or networks, they can simply upload these lists of IP addresses and CIDR blocks to the Security Center. We call these static asset lists as compared to the dynamic asset lists generated based on the vulnerability content. All asset lists can be used for reporting, filtering and asset control as shown in this image below:

Recently, Michael Arnone from Federal Computer Week wrote an article about various open source projects going closed source. The article mentioned Nessus, OpenBSD and Mozilla and had several quotes from industry experts. We felt some of the comments about Tenable and Nessus were taken out of context and I would like to add some commentary to them:

• Nick Selby, a senior analyst for 451 Group, mentioned that "Nessus was probably the first major open-source IT security tool to become proprietary". We feel that both the Tripwire integrity checking tool and Gauntlet firewall projects had gone from open source to closed-source projects long before Tenable even existed.
• The article gives the impression that the licensing change was big news. I agree it made some headlines, but we've added far more users to the Nessus community. Most of these users are on the Windows platform and are not driven by the need to use an open source product. I think the real story is that most folks can get a product with a license and support model that is in line with their corporate guidelines.
• The article also implied that people were required to change their scanners. We have many users still running Nessus 2 and Tenable is still maintaining it, free of charge. For organizations who want to use that platform, we are not preventing them at all. Users who want more performance and support do have the option to upgrade to Nessus 3.

Tenable has been working on a 3D Visualization tool that works with the Security Center. We're almost out of BETA testing with it and the screen shots are something pretty neat to look at.

The tool allows anyone with an account on their organization's Security Center to present vulnerability and compliance data in a comparative manner. For example, one could display on a network topology where all the unpatched Windows IIS servers for two different political organizations were. This can make some stunning executive presentation moments.

In the above examples, we're showing network topology for two different very large (more than 10,000 node) networks. All routers are placed on the helical spiral, and all known hosts are linked off of their nearest router. The third image shows a comparative plot of IP addresses and open ports.

When I say comparative, this means that a user can do multiple queries to the Security Center for data and then visualize each set with the 3D Tool. For example, one could query for all vulnerability data about the "West Coast Data Center" email servers as well as data for the "East Coast Data Center" email servers. Both of these data sets can be analyzed at the same time to determine visually differences in topology, port/IP relationships and vulnerability/IP relationships. Because the query is being powered by the Security Center, the same query could be performed using any filter available including Nessus vulnerability families, specific port rages, discovery dates and much more.

In New York City? Tenable Network Security is sponsoring a free networking event hosted by (ISC)2 and The Institute for Applied Network Security. The event is July 19th at the Crowne Plaza Times Square (4:30 to 6:30 PM, including cocktails and food). This reception, is being held in conjunction with attendees from The Institute for Applied Network Security and their 6th Annual New York Metro Information Security Forum. I will be attending the event along with some of Tenable's staff and customers.

I'm always really glad to see Tenable products independently reviewed and accurately reported on. Information Security magazine recently reviewed the Security Center and gave it really good marks in the July issue of the magazine. They did a very good job in a small amount of words describing how we do vuln scanning, correlation and compliance monitoring.

To read the original article, you need to grab a copy of the magazine, register at the Information Security web site, or can read the content here.
 

Plugin #20094 attempts to guess if the target host is indeed a system run under VMWare. It does this by looking at the Ethernet address and checking to see if it is one allocated to VMWare "hardware". To do this, the plugin looks in the knowledge base of the scan to obtain the Ethernet address.

Originally, the MAC address was either obtained by a local ping (plugin #10180) or from scanning a Windows host. Tenable recently added a change to the SSH login process such that the local MAC addresses are also populated into the knowledge base. This means that a non-Windows VMWare hosts not on the local network will now be detected as a VMware host. 

Tenable has produced a set of plugins for our Passive Vulnerability Scanner (PVS) based on the publicly available SCADA IDS signatures from Digital Bond. This allows the PVS to discover which devices speak SCADA protocols in addition to more than 3000 other server and client vulnerabilities. This monitoring is done in real time and without any network impact. Along with Tenable's Security Center, Nessus scanner and Log Correlation Engine, this can become a very powerful tool for security monitoring of SCADA networks.

The Department of Energy recommends 21 separate activities for monitoring and securing SCADA networks. All of Tenable's products can be used together for a comprehensive analysis of SCADA network devices, protocols and traffic. Tenable also has published a paper (free for download) about how each of the DOE's 21 recommendations can be accomplished with Tenable active, passive and log analysis solutions.

Security Enhanced Linux (commonly known as SE Linux) offers several methods to secure what the kernel and the applications can and can't do. This can help prevent successful buffer overflow attacks from both local and remote sources. When exceptions occur, the operating system will generate logs that are processed by Tenable's Log Correlation Engine. Currently, the logs are processed and can be manually analyzed by users. Shortly though, Tenable will release a TASL script that correlates attacks detected by intrusion detection systems with system events from SE Linux servers. This will allow Tenable customers to detect more serious Linux network attack attempts. 

Tenable has recently added several TASL correlation rules which detect a variety of network changes. These rules automatically detect:

• Changes to servers such as new software and added patches
• Changes to users such as adding/removing a user, changing their passwords and disabling their accounts
• Changes to network devices such as saving new configs of a router or switch
• Changes to the network such as new hosts being added

Here is a screen shot of what these look like under the Security Center:

These new TASLs also compliment the existing scripts which detect user account to host relationships and alerting when new Ethernet addresses are discovered in DHCP logs and logs from Tenable's Passive Vulnerability Scanner.

Tenable is now tracking patch updates to the CentOS Linux operating system. The Nessus Direct and Registered feeds are now updated with host-based patch audits for CentOS. There are more than 200 audits currently available at the time of this post writing. 

If you are using Nessus to perform credentialed audits of UNIX or Windows systems, analyzing the results to determine if you had the correct passwords and SSH keys can be difficult. Nessus users can now easily detect if their credentials are not working. Tenable has added Nessus plugin #21745. This plugin detects if either SSH or Windows credentials didn't allow the scan to log into the remote host.

Tenable would like to thank everyone who came to see us at the User's Conference. In particular we'd like to thank our guest speakers including Johny Long, Richard Bejtlich from Tao Security, Russ Rogers from Security Horizon and Brian Kee and Brent Deterding from Lurhq. Each session was well attended and we had great participation from the audience. We hope to see you next year!

Welcome to the official Tenable Network Security blog. We will be using this to communicate a variety of information including network security best practices, Nessus updates, vulnerability scanning techniques, log correlation best practices, compliance monitoring, Tenable product news and Tenable events.