I was asked this question by a customer of ours at the recent NIST SCAP conference and I'm loosely paraphrasing: 

"We use Nessus and the Security Center to audit 1000s of workstations and laptops for compliance against CIS and eventually NIST SCAP policies. I'd like to be able to have a NAC enforce compliance against CIS policies and the new FDCC policy, but haven't found any to accomplish this yet. Do you know of any?"

Quick Background

If you are not a regular reader of this blog, CIS is the Center for Internet Security. They work with a community of vendors and users to build a consensus of best practices for securing operating systems such as Windows 2003. Vendors who want to audit against CIS best practices can become certified by having their results evaluated through an accreditation process.

Also, SCAP stands for the 'Secure Content Automation Program'. It is a NIST program that produces configuration audit templates in the XCCDF format. XCCDF is a content specification which can be consumed by many different vendors (including Tenable) to perform configuration audits of operating systems such as Windows 2003.

If you visit the CIS or NIST SCAP web sites, you will see a plethora of operating system vendors, patch management vendors, configuration management vendors and auditing companies (like Tenable). However, you will not see typical NAC vendors listed as supporting these standards, or even declaring their intention to support them.

Why is this?

I feel the largest reason NAC vendors have not gone down this road is that consumers have not begun to ask them for these features. Most of the evaluations and reviews of NAC products tend to focus on how easy it is to keep users without passwords or patches off the network.

The technology exists in most NAC products to perform the types of checks required by these audits, but the content has not been produced by the NAC vendors to make this easy for their customers.

A secondary reason is that organizations who have deployed NAC to perform basic authentication and patch auditing and have found it too intrusive won't tolerate a deeper audit of their systems -- especially if it impacts operations.

Why should you care?

NAC solutions that can enforce compliance with corporate configuration standards as well as government and certified best-practice configurations will ultimately reduce variance, reduce the cost of operating the network and keep it secure.

Tenable is not a NAC vendor. However, we do want to see our customers migrate from networks and systems that are un-patched and randomly configured towards systems that are hardened and monitored for anomalies and access control violations. This is the basis of our unified security monitoring strategy.

As standards like XCCDF develop, they create an opportunity for audit vendors, configuration managers and NAC vendors to all enforce the same corporate standards. There is great value and flexibility in being able to access how well a network meets a configuration standard with a solution such as Tenable's, and then at a later date enforce this with a NAC solution.

Next Steps

If you are interested in managing your network towards government or CIS standards, you should start out by assessing any gaps between your current configurations and the standards themselves. You can perform these types of audits with little impact with Nessus and the Direct Feed subscription. Larger organizations who audit against these policies should consider the Security Center.

You should also contact your NAC vendor and tell their sales staff, CTO and marketing people your desires. Nothing speaks louder to a vendor than customers saying they have a need that their solution can meet.

And lastly, if this type of configuration management is new to your organization, IT group or management, you should become as familiar as possible with concepts such as ITIL, Visible Ops and IT Controls. Tenable also offers the "Real Time Compliance Paper" which discusses how configuration auditing, vulnerability management, log analysis and anomaly detection can be jointly used to monitor organizations for PCI, FISMA and many other types of compliance requirements. This paper is available by contacting Tenable.

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
• 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:

Severity          Count
-----------------------
Low                1009
Medium             1875
High              12501

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.

1. Juniper
2. Tipping Point
3. IBM (ISS)
4. Snort (Sourcefire VRT Rules)
5. Enterasys (Dragon)
6. Cisco
7. 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.

Tenable has recently announced FDCC audit policies for Nessus ProfessionalFeed and Security Center users. These policies help government organizations test Windows XP Pro and Vista desktops against OMB's required configuration settings. This blog entry describes how this testing can be performed with Nessus against the reference Windows XP Pro FDCC virtual machine image.

Required Materials or Software

The following resources are required to perform this testing:

1. To perform this test, you need a virtual machine player such as VMware or Virtual PC. This will be used to run the virtual disk images of Windows XP Pro.
2. The actual Windows XP Pro images can be obtained from NIST's web site. These are "evaluation" copies of Windows XP, XP Pro and Vista. Make sure your organization is aware of these OS images as unlicensed copies used for testing.
3. Nessus 3 or later with a ProfessionalFeed subscription or actively managed by a Security Center is required.
4. The FDCC Desktops v90 audit policy is available from the Tenable Support Portal under the "Downloads" button and then under the "Compliance and Audit Files " you will find a link for the "Nessus NIST and FDCC Compliance Audit Policies".

Preparing the FDCC Reference Image

When the system is booted up, you will see the following desktop and end user license agreements:

VM Desktop	EULA

The default image is very secured in that the firewall is blocking all ports and remote access has been disabled. To enable access and auditing by Nessus, the following steps must be performed:

Choose the Start button, select "Run" and then enter "gpedit.msc". From this new GUI, choose "Computer Configuration", then  "Administrative Templates", then  "Network", then "Network Connections", then  "Windows Firewall" and then finally "Domain Profile/Standard Profile".

Modify the following sections accordingly:

• Enable "Windows Firewall: Allow File and Printer Sharing exception"
• Enable "Windows Firewall: Allow Remote administration exception"
• Disable "Windows Firewall: Do not allow exceptions"

Screen shots of these steps are shown below:

Print/File Sharing	Enable Remote Admin	No Exceptions

Also keep in mind that the last check of "Domain Profile" or "Standard profile" depends on whether the system is part of a domain or just a standalone machine. By default, the NIST FDCC reference virtual machine is a standalone machine. However, most government agencies make their Windows desktops part of a domain, so if you've configured this VM to be part of a domain, keep in mind there are separate settings for that profile.

After modifying group policy, the following Local Security Policy setting must be changed for non-domain Windows XP desktops: "Network access: Sharing and security model for local accounts". It is located in "Local Security Settings" under: "Local Policies" => "Security Options". According to Microsoft, "This security setting determines how network logons using local accounts are authenticated". See screenshot below:

By default, this option is set to: "Guest only: local users authenticate as guest". Since remote network users are assigned "Guest" access, they do not have the required privileges to perform a credentialed Nessus scan. Switch this setting to "Classic: local users authenticate as themselves" to give remote Nessus credentialed scans the privilege they need.

Customers are also encouraged to run firewalls on their desktops. However, if they are auditing the Windows XP desktop with Nessus, ports 445 and 139 should be left open, or the IP address from the authorized auditing node running Nessus should be trusted.

Configuring Your Nessus Scanner

We will use NessusClient to perform this scan. To perform such an audit, create a scan policy with the credentials of the target server, then select the "Windows Compliance Checks" plugin, make sure that "Enable Plugin Dependencies" is enabled, and then select the FDCC Desktops v90 audit file is selected. Screen shots of this process are shown below:

Credentials	Windows Compliance Plugin	FDCC Audit Policy

Although we are focusing on an FDCC configuration audit, the scan could have just as easily implemented tests for other configurations, performed a full patch audit, or launched vulnerability checks.

If you were performing this test with a different Nessus client, or with the Security Center, the same data would need to be completed in your scan policies.

Analyzing the Results

When scanning the FDCC Reference system, testing should show 100% compliance with all required OMB settings. Below are two reports of a scanned Windows XP Pro FDCC reference system.

The first report shows 100% compliance with all settings.

The second report shows several issues which reflect non-compliant configurations For the second test we changed several settings to something less than required by the FDCC and performed a new scan.

Both reports are HTML compliant and can be viewed with web browsers.

Download FDCC_WinXP_Compliance_Report.html

Download FDCC_WinXP_Non-Compliance_Report.html

If these scans were performed with the Security Center, the scans themselves could be scheduled with the proper credentials, and specific non-compliant settings be reported across thousands of desktops for analysis and action by auditors and asset owners. 

For More Information

This test did not consider the FDCC desktop firewall audit requirements. Tenable has produced a policy for FDCC desktop firewalls directly based on the NIST SCAP recommended configuration guidelines. However, in order to work with domains, patch management systems and other Microsoft centric solutions, most organizations will need to make exceptions to this policy. Organizations who do make exceptions should modify the Nessus audit policy to reflect their desired firewall settings.

If you are using Nessus to audit a control system network, Digital Bond has recently released a set of guidelines (part 1, 2 and 3) for securing OPC servers. These guidelines include three Nessus configuration audit policies (for use with Direct Feed subscriptions) to test OPC servers running under Windows XP Pro, Windows 2000 and Windows 2003. The guidelines and audit files are available to Digital Bond content subscribers.

OPC stands for "Object-linking and embedding for Process Control". This is a set of Microsoft technologies which leverages OLE, DCOM and COM for use in automation and controls. The need for OPC arose because each time a new control system was introduced it likely had a proprietary method to interact with it. Having a common communication standard within OPC simplifies control system design. This makes it easier to write management and monitoring applications which are independent of the actual hardware deployed at the dam, on the pump, on the oven, at the generator and so on.

However, securing these technologies is not a simple process. Doing things such as adding firewall rules or attempting to have services or processes not run with administrator credentials can easily break "out of the box" OPC deployments. The content produced by Digital Bond can help any organization that wishes to harden their Windows control systems by letting them understand how OPC works and where it can be hardened.

To use these OPC policies, you should not only be subscribed to the Digital Bond content, but also be either a Nessus Direct Feed or Security Center customer.

Previously, Digital Bond and Tenable have collaborated to produce SCADA vulnerability checks for Nessus Direct Feed and Security Center users. I also had the chance to interview Digital Bond's CEO, Dale Petersen, in a podcast. Tenable also offers a 30 minute webinar on SCADA network monitoring with Tenable solutions.
 

Tenable's research group has recently released several updated plugins for both the Nessus scanner and Passive Vulnerability Scanner to detect Tor in operation and waiting for connections.

Tor is a self organizing peer-to-peer network application. It encrypts network communications and also randomly spreads it across other Tor nodes to prevent traffic analysis.

Tor can be used for anonymous network browsing. It has recently been reported as being used by the Storm worm to connect to other potential victims as well as obtain command and control instructions.

Hostile "Tor users" have been running a Tor network "end node" in order to monitor and sniff unencrypted exit traffic for sensitive information.

Detecting Tor

Nessus plugin #26026 (currently available to Direct Feed customers) can be used to scan a network for systems configured as a Tor server.

For the Passive Vulnerability Scanner, several plugins exist

• 2542 - Tor Tunnel Detection (detects on start of Tor communication)
• 2543 - Tor Tunnel Detection (detect ongoing Tor communication)
• 4212 - Tor Tunnel 'End Point' Server Detection

When analyzing a network that contains Tor applications, you should ask yourself the following questions:

• Does carrying this anonymous traffic expose my network to risk?
• Does the presence of Tor indicate that the network has been compromised?
• Has there been an increase in the amount of virus, IDS or other types of alerts from the systems running the Tor software?
• Does the host running Tor consume noticeable network bandwidth?
  
• Does Tor open up any unauthorized or un-auditable connections into our network?

Below is a screen shot of a node discovered to be running Tor as viewed under the Security Center. This particular host also has a version of Firefox which is fairly outdated.

This site also was running the Log Correlation Engine with a Tenable Network Monitor. When viewing the last 25 days of network connections from this node, several were made to ports in the 9000-9100 range which is common for Tor communication. Below is a bar chart port summary of all TCP and UDP network connections.

This discovered Tor node was a client. If it were a Tor end server, the Log Correlation Engine and Tenable Network Monitor agent could have been used to analyze all "outbound" network connections.

For More Information

Nessus active network scans do not discover clients with installed Tor software. Tor clients don't have open ports which can be identified with traditional network connection requests and fingerprints.

If this is a requirement, consider performing a credentialed network scan and enumerate the installed software. Keep in mind that if you want to find out this sort of information in real time, you should use a network IDS or monitor the network with the Passive Vulnerability Scanner.

For other thoughts on passive network monitoring, we've blogged before about several different methods such as watching for new ports being browsed on, detecting network proxies and monitoring traffic for known and unknown encryption.

Nessus 3 UNIX scanners have the ability to save all of their generated packets as a convenient libpcap compatible file. This means you can save your scans and view them under applications such as TCPDUMP or Wireshark. Please note that this feature is not available on Nessus 4.

Why is this Useful?

There are many reasons to do this.

Having a network trace can greatly assist in diagnosing your environment as well what Nessus is attempting. Tenable's support group often encounters customers who are scanning hosts that are firewalled or are being screened with an intrusion prevention system which is spoofing responses. Having exact packet logs of what is occurring can help diagnose the results.

When new devices are encountered, having a packet dump of what has occurred is very useful for sending information to Tenable's research group. This helps our team write better plugins with the exact bytes and responses being seen in the wild.

Saving a packet dump is also a good way to "prove" that a system was scanned. Text reports can easily be manipulated. Manipulating the 1000s of network connections, three way handshakes and specific protocols can be faked but requires much more effort.

If you have a product like the Passive Vulnerability Scanner which can accept libpcap network traces, these packet traces can be replayed at a later date. If your PVS is updated with newer rules than when the scan occurred, you may be able to conclude new information about vulnerabilities on a network scanned some time ago.

And lastly, having a pure network log of a full vulnerability scan can be very useful for stress testing your network intrusion detection or prevention system. Replaying network scans at a high rate of speed can test how well your network monitoring systems are working.

How is this accomplished?

Within your scan policy settings, there is a setting named 'Save a packet capture of the scan'. In the Nessus 3 client beta, this option is found under the 'Options' tab as shown below:

When a scan is completed, the results will be found in the 'tmp' directory. On RedHat systems, this is /opt/nessus/var/nessus/tmp. Files will be named for the target system IP addresses as well as the process ID of the nessusd instance which performed the scan. Below is a screen shot which shows some example traces:

The trace files can be readily read by TCPDUMP and Wireshark. To view this data under TCPDUMP, use the -r option to specify the source trace file as shown below:

A screen shot of a Nessus scan as viewed under Wireshark is shown below:

Keep your Traces as Secure as your Scan Results

If you do record network traces of your scan results, please treat them as sensitive information. These traces may contain passwords, vulnerabilities and sensitive data that should not be given to unauthorized people.

Tenable has launched our Unified Security Monitoring (USM) concept. There is a new white paper available which details how event monitoring, vulnerability analysis and configuration auditing can all be leveraged in one process.

I realize this is a pretty advanced concept for some organizations, especially those that are large enough that their audit, incident response and patch management groups don't regularly communicate with one and other. Having said that, Tenable has many financial, government and academic customers where log analysis, configuration auditing, vulnerability monitoring and passive network monitoring are all performed by the same team. Accomplishing these tasks with not only the the same product suite, but also with the same core team has many political, efficiency and financial advantages.

I am also very excited to announce the launch of the merged Tenable and Nessus web sites. If you have not seen the new "unified" site yet, you'll notice the new Tenable company logo, and the new website design.

Tenable Network Security has received certification from the Center for Internet Security to perform configuration audits of the Solaris 9 and SuSE Linux 9 operating systems. Audits can be performed with Nessus 3 scanners subscribed to the Direct Feed as well as by enterprise networks with the Security Center.

To obtain these audit polices, please log into your Tenable Support Portal account and download them from the 'Download CIS Compliance and Audit Files' section.

To review all of Tenable's certified CIS audit polices, please view this CIS web link. All CIS certified audit polices are available to Tenable customers at the Tenable Support Portal.