Everything You Ever Wanted to Know about 15,385 Nessus Plugins
Tenable provides a wide variety of information on our vulnerability plugins to the public. This includes RSS feeds, a plugin writer mailing list and an on-line search portal. By visiting the plugins summary page, Tenable publicly displays our latest signature count and how many unique CVE and Bugtraq IDs are currently covered. What I'd like to do in this blog entry is to move beyond the raw "counts" of vulnerability checks and provide some insight into what these numbers mean. The statistics and figures in this blog entry occurred through an analysis of a snapshot of Direct Feed plugins from September 21, 2007.
Multiple Plugins May Test for the Same Vulnerability
I've spoken with several customers who ask "Do you have a check for ...?". My answer is usually one of:
- Yes, but you need credentials
- Yes, but a specific port needs to be open
The easiest type of vulnerability audit to perform is a patch audit. The Nessus scanner simply logs into a target host and performs an operating system specific query to determine if a given patch is installed or not. This works for servers, clients and usually for third party software.
When speaking with a Nessus user that doesn't have access to log into a remote host, having a patch audit doesn't help them very much. If a remote check is possible (this is not always the case, especially if the target application doesn't have any ports open) Tenable's research group will write a plugin to detect this as well.
Since Tenable expects Nessus to be run in many different types of secured and unsecured network environments, we may even develop multiple checks for the same vulnerability, but employing many different techniques. This includes writing checks for the same vulnerability that can occur on different ports.
Identifying Network Services, Applications and Operating Systems
Nessus includes many different types of logic to fingerprint remote network devices and applications. The following list shows how many unique items are checked for.
- Plugins 11153 and 17975 detect more than 210 different types of network services and devices. This is done through port-independent banner analysis as well as specific network probe/response combinations.
- Plugin 25244 (os_fingerprint_ntp.nasl) detects 11 different UNIX operating systems based on the network time protocol.
- Plugin 25250 (os_fingerprint_sinfp.nasl) includes 351 TCP/IP fingerprints for a wide variety of OSes and network devices.
- Plugin 25247 (os_fingerprint_http.nasl) detects 52 different operating system varieties through analysis of web service.
- Plugin 25246 (os_fingerprint_snmp.nasl) detects more than 40 different types of devices and operating systems running an SNMP service.
- The os_fingerprint_smb.nasl or os_fingerprint_msrpc.nasl NASL plugins identify remote Windows versions with accuracy approaching 100%.
Most Plugins Will result in a Single Severity Level
Tenable's research team usually write plugins that perform a single test and then log the results with a specific severity level. On rare occasions, Tenable will produce a plugin that may report multiple severity levels depending on what sort of logic was encountered by the plugin, if credentials were needed to perform the scan and so on. Of the current plugins analyzed for this blog entry, there were 29 different Nessus plugins which can report multiple severity levels for the same scan depending on the results.
Not All Plugins test for Critical Issues, but Most Do
Tenable keeps Nessus up to date with the latest techniques to identify a wide variety of information used to audit your network. Some of the plugins check for very critical items while others simply detect
applications or certain devices.
All Nessus plugins have a severity rating of low, medium or high. Historically, Tenable has scored severity ratings as Informational, Medium or Hole, but for this blog post, we will refer to them as low, medium and high. Tenable uses the CVSSv2 scoring system to score plugins and then use that score to select severity levels. For patch audits, Tenable makes use of severity scores in vendor patch information. If patch severity information is not provided, (such as in the Solaris patch feed) Tenable scores the patch as a High severity.
Of the current 15,385 plugins, here is the following break down of plugins that can score by severity level:
Perhaps more interestingly is to also analyze this breakdown by Nessus plugin family:
Family Low Med. High
AIX Local Security Checks 0 0 116
Backdoors 1 5 65
Brute Force Attacks 0 0 25
CentOS Local Security Checks 0 0 353
CGI Abuses 192 510 784
CGI Abuses: XSS 121 130 22
CISCO 2 14 63
Databases 12 27 44
Debian Local Security Checks 0 0 1363
Default UNIX Accounts 0 0 47
Denial of Service 22 90 189
Fedora Local Security Checks 0 0 829
Finger Abuses 2 5 4
Firewalls 14 10 13
FreeBSD Local Security Checks 1 5 991
FTP 22 27 84
Gain a shell remotely 8 22 109
Gain root remotely 2 17 267
General 67 17 42
Gentoo Local Security Checks 61 576 370
HP-UX Local Security Checks 0 0 1009
MacOS X Local Security Checks 4 14 56
Mandrake Local Security Checks 0 0 1109
Misc. 63 39 83
Netware 0 5 3
NIS 2 0 2
Peer-To-Peer File Sharing 26 6 4
Port scanners 6 0 0
Red Hat Local Security Checks 0 2 863
Remote file Access 4 20 51
RPC 27 4 16
Service Detection 157 3 5
Settings 16 0 0
Slackware Local Security Checks 0 0 235
SMTP Problems 10 3 57
SNMP 2 7 3
Solaris Local Security Checks 0 0 2106
SuSE Local Security Checks 0 99 174
Ubuntu Local Security Checks 0 0 321
Useless Services 13 8 0
Web Servers 33 36 46
Windows 89 84 355
Windows: Microsoft Bulletins 19 76 218
Windows: User Management 16 9 0
This means that the majority of what Nessus looks for is "bad news". Very often, I will hear a customer or a consultant say that the network is not doing well because a system had 1-2 major holes. This is indeed serious, but consider if someone had said that out of 10,000 potential high severity ratings, a system "only" had two.
It's also worth noting that several (most notably the Solaris patches) do not have severity ratings provided by the source vendor. Tenable automatically scores these as "high" severity levels because there is no corresponding CVSS score or severity rating. We are investigating re-using CVSS scores for similar vulnerabilities as referenced by CVE or Bugtraq IDs.
Linking Plugins with Third Party Information Sources
Of the roughly 15,000 Nessus plugins, these comprised checks for 7418 unique CVE entries and 5769 unique Bugtraq IDs. As was discussed earlier, there may be multiple plugins for a single vulnerability, but also a single plugin might also cover multiple CVE entries. The same is true for Bugtraq IDs. For example, Nessus ID 10970 checks for six CVE entries from 2001.
The Nessus plugins also consider cross references with the Open Source Vulnerability Database. In the analyzed data set, there were 1581 entires which had OSVDB links.
All of this can be used to search Nessus plugins under Tenable's plugin search engine.
Also, Tenable automatically synchronizes all CVE and Bugtraq IDs with both the Mitre CVE project as well as the OSVDB database.
Correlating Vulnerabilities with Network IDS Events
Tenable has several relationships with different NIDS vendors. A common practice among SIM vendors is to look for an IDS event which has occurred on a system with a relevant vulnerability. We've blogged about this before and have an online webinar which discusses the topic.
As part of Tenable's update service to our Security Center product, we produce a table of pre-correlated IDS event to vulnerabilities. This allows for realtime VA/IDS correlation.
While I don't want to abuse any of the relationships we have with other companies, I would like to simply list how well various network IDS solutions correlate with Nessus. This following list represents which NIDS correlate "the most" with detected Nessus vulnerabilities.
- Tipping Point
- IBM (ISS)
- Snort (Sourcefire VRT Rules)
- Enterasys (Dragon)
- Snort (Bleeding Threat Rules)
We counted one correlation for every unique IDS event and Nessus plugin combination. Some NIDS rules correlated with multiple Nessus plugins and other NIDS had multiple different IDS rules which all correlated with the same Nessus plugin. When we normalized this set towards "supported" CVE entries, the list did not change much.
For More Information
Many Tenable customers and Nessus users make use of the RSS feed of Nessus plugin updates. This feed includes all available updates for the Direct Feed.
Previously, we've also blogged about Tenable's usage of CVSSv2 NIST scores to rates vulnerabilities.