Previously, I posted a blog which showed how Nessus Direct Feed and Security Center users could audit Windows XP Pro systems against FDCC compliance settings. In this blog entry, we will show how this can also be accomplished for Windows Vista systems. As with the previous blog, we will be performing audits against the reference Virtual PC systems available from NIST.

Configuring Your Vista Target

To enable scanning of a Vista system with Nessus, the following steps can be taken. These steps ensure that the firewall is not blocking connections from the Nessus scanner, that UAC has been modified to enable remote connections and that the remote registry service has been enabled. The last two steps are only required if you are working with a stand-alone Vista system and not one that is participating in a domain.

If you obtained the test image from NIST, you will be greeted with the following start up screen:

The first item to modify is in the firewall settings. The File and Printer sharing exception should be enabled. This will allow Nessus to connect to the Vista system over the network.

The second item is to enable the inbound file and printer exception via the gpedit.msc tool. This tool can be launched from the "Run.." prompt. To navigate to the setting which needs to be changed, follow Local Computer Policy -> Administrative Templates -> Network -> Network Connections - > Windows Firewall -> Standard Profile -> Windows Firewall : Allow inbound file and printer exception.

Third, when you are editing the firewall policy, make sure that the setting to prohibit use of the Internet Connection Firewall on your DNS domain network is also disabled. From within the gpedit.msc tool, you can navigate to this setting  by following Local Computer Policy -> Administrative Templates -> Network -> Network Connections -> Prohibit use of Internet connection firewall on your DNS domain. This setting should either be "Disabled" or "Not Configured".

The next item is to modify Vista's UAC to allow Nessus to perform an audit. There are two choices here. You can simply disable UAC 100%, or you can modify a registry setting to allow Nessus audits.

To turn off UAC completely, open up the Control Panel,  select "User Accounts" and then "Turn User Account Control" to off. 

Alternatively, you can add a  new registry key named "LocalAccountTokenFilterPolicy" and set its value to "1". This key should be created in the registry at the following location:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

For more information on this technique, please consider the following MSDN blog entry:

• http://blogs.msdn.com/vistacompatteam/archive/2006/09/22/766945.aspx

The last step is to enable the Remote Registry service. This service is disabled by default. You can enable it for a one-time audit, or enable it permanently such that it will start if the computer is rebooted.

Performing the Test With Nessus

To perform an audit of the required Vista FDCC settings, Tenable Direct Feed or Security Center customers can download the "FDCC Windows Vista Desktop" audit policy from the Tenable Support Portal. A scanning policy that enabled the Windows Compliance Check plugin (ID #21156 in the Policy Compliance family), included credentials for the Windows Vista system(s) being scanned and also included the FDCC_Vista_v2.audit policy file should be created in either the Security Center or Nessus Client. Screen shots of this sort of configuration for the Nessus Client are shown below:

Below are two separate HTML based Nessus Client 3.0 reports generated from scans made with this policy against an FDCC compliant and non-compliant target Vista system:

• Download FDCC_Vista_Compliant.html
• Download FDCC_Vista_Non_Compliant.html

Nessus, SCAP and FDCC Certification

If you have been tracking the NIST SCAP and FDCC programs, you will know that only a few vendors have been certified at this time to perform FDCC audits. Tenable is about to undergo FDCC certification for the Security Center product.

In the mean time though, Tenable has released audit content for Nessus based on FDCC and other types of NIST SCAP checks. Tenable currently has several large federal customers using this content to audit more than 25k desktops and servers in a single distributed Nessus scan being managed by the Security Center.

One of the requirements of FDCC certification is to be able to parse the XCCDF content. Below is a screen shot of a new tool that will shortly be available to Security Center customers which can read the XCCDF content.

With this tool, a Security Center user will be able to work directly with the OVAL content distributed by NIST and produce a compliant Nessus audit file. Also, customers will be able to optionally include reference content (such as FISMA, DISA, ISO and other indexes) into the actual Nessus audit file. This data will automatically be parsed and available to Security Center users after these scans are performed.

For More Information

The following links below reference previous blog entries about the FDCC and NIST SCAP program.

• Using Nessus Configuration Audits to test FDCC Compliance (of Windows XP Pro systems)
• Federally Mandated Configuration Settings for XP and Vista
• NIST FDCC Implementor's Workshop Notes
• NIST Audit Policies for Nessus 3

Another ShmooCon has come and gone. Tenable had the opportunity to run our products on the ShmooCon network. We deployed two blades which ran Nessus, the Passive Vulnerability Scanner, the Security Center, the Log Correlation Engine and a few agents for monitoring network traffic. We also placed Snort on one of the blades and ran a set of Sourcefire VRT and Bleeding Threats rules. This blog entry discusses how each component worked and what types of activity was observed.

Deployment

The network was well organized and had well defined VLANs and IP address segmenting for attendee secure and unsecured wireless access, speaker podiums, registration, the hacker arcade, servers providing DNS, DHCP, a 'pf' firewall and so on.

This made it very easy to configure the Security Center with a set of assets that matched the ShmooCon network. Below is a screen shot of an asset summary of all detected vulnerabilities:

At the time we had taken this screen shot, we had not performed any active scans with Nessus, but were monitoring all traffic with the Passive Vulnerabiltiy Scanner. The same blade was also running Snort and the Tenable Network Monitor which logged the start and stop of every network session.

Log and Network Monitoring

This network data was sent to the Log Correlation Engine, along with logs from the DNS server, DHCP servers, the 'pf' firewall and a few others. This allowed us to show normalized and logs correlated logs over any time range such as the following screen shot:

In this screen shot, we're looking at a time graph of all normalized event types for the past 24 hours from approximately 1:00 PM on Friday to 1:00 PM on Saturday of the conference. You can see a few things in this screen shot:

• The "detected-change" events were mostly logs from the Passive Vulnerabiltiy Scanner detecting new hosts, new open ports and so on.
• The surge in "error" events were from a switch that had a few flapping ports.
• There was a spike in "firewall" logs and then nothing. A firewall rule change stopped outbound syslog messages at one point.
• P2P activity was detected by some of the Snort rules and this activity occurred throughout the conference.
• The first real large scan of the network was done by Qualys and you can see a spike occurring in multiple other event streams just after the spike in "scanning" activity.

Something that we monitored closely was what type of correlated events occurred below:

In these screen shots, we're looking for evidence of compromised hosts, such as a host that was attacked and then was used to attack another host. On a normal network, your servers don't normally start attacking each other. However, at ShmooCon, this activity may have been occurring often.

One of the more simpler correlation rules in the Log Correlation Engine is the brute force password guessing script. This rule is simply looking for a number of login failures in a certain period of time. It does differentiate between a single host failing a login across multiple targets as well as one host failing multiple logins against one host.  In the above screen shot on the right, the Qualys scan I mentioned above had attempted several login attempts to a Cisco device.

Active Scanning, Passive Scanning and Found Vulnerabilities

The typical ShmooCon attendee uses Windows and does not patch their version of Firefox. We were able to determine this using the Passive Vulnerabiltiy Scanner. Below is an example screen shot of the detected critical vulnerabilities around 2:00 PM on Saturday:

There are many client side issues found by the Passive Vulnerability Scanner. Not only were there several issues with web and chat clients, you can see that many users run older versions of 'curl', 'ssh' and 'wget'. Security issues in these types of clients are often forgotten to be audited by system administrators.

Another interesting, and non-surprising item, was the detection of people running certain types of scanners and security testing tools:

In a future blog post, we'll investigate the network logs from these hosts and analyze if multiple were using these servers, and what other types of activity was detected.

During the set-up of the network, having the passive scanner online was very valuable. Active scanning was initially prohibited because all traffic was going through a very underpowered firewall. At one point, even the basic network profiling of the Qualys scanner was overloading the firewall and had to be halted.

When we did start active scanning though, as expected, scanning many laptops with firewalls not offering any type of responses proved to be a difficult target. You can configure Nessus scans many different ways to try various techniques to determine if a host is indeed there.

However, with the Security Center and the Passive Vulnerability Scanner, we simply created an asset list of known live wireless devices and had Nessus focus on those. This made our scans, much more effective than trying to scan a full class B for any hosts that might be alive.

Future Posts

There was a lot of very interesting data gathered which we will be using as a topic of future blog posts here to show different types of network and log events. I would also like to thank the ShmooCon staff for letting us participate in the monitoring of their network.

Tenable Network Security was recently awarded certification by the Center For Internet Security to perform audits of the following best-practices benchmarks:

• Windows Server 2003 Legacy Benchmark for Domain Controllers v2.0
• Windows Server 2003 Enterprise Benchmark for Domain Controllers v2.0
• Windows Server 2003 Specialized Security Benchmark for Domain Controllers v2.0
• Windows Server 2003 Legacy Benchmark for Member Servers v2.0
• Windows Server 2003 Enterprise Benchmark for Member Servers v2.0
• Windows Server 2003 Specialized Security Benchmark for Member Servers v2.0
• Windows 2000 Server Level 2 Benchmark v2.2.1
• Windows 2000 Level 1 Benchmark v1.2.2

Previously, Tenable products had been certified to perform audits of Windows 2003 servers against version 1.2 of their benchmark. Version 2.0 of this benchmark was recently released, our content was updated and then re-submitted for certification by CIS.

Additionally, Tenable has selected SAIC to test the Security Center against the requirements of the Security Content Automation Protocol (SCAP) Validation Program. Specifically, we are seeking approval to be an authorized Federal Desktop Core Configuration (FDCC) scanner.

Myself and several Tenable Network Security employees will be attending Shmoocon later this week.  As a conference sponsor, we'll be giving away cool items at our table such as iTunes gift cards and chocolate covered espresso beans. We'll also be working in the labs and will be running all of our products to perform logging, network monitoring and scanning.

If you've never seen Nessus scan a network, or would like to learn how to aggregate passive network data, logs, configuration information and vulnerabilities for enterprise networks, please stop by and chat with us in the lab or at our table.

If you are attending Shmoocon and are interested in learning about oppurtunities to work at Tenable, please seek me out at the conference. We're looking for a variety of research, development and customer support engineers.

When you perform vulnerability discovery via network scanning, passive network monitoring or patch auditing, the discovered vulnerabilities can each be classified if they were newly discovered, or if they were previously known about. If you have historical vulnerability data, such as with the Security Center, you can also classify vulnerabilities that have been previously known about, but were somehow mitigated or are no longer present. In this blog entry, I will discuss a variety of ways to analyze new vulnerabilties, and to also analyze how vulnerabilities are being mitigated.

Many IT security managers I speak with want to produce some sort of graph or statistical data that records the amount of security incidents occurring on the network. This data is used to not only inform management of business risk, but to also justify budget for ongoing security and compliance activities. In this blog, we will consider several high-level sources of "incident data" and discuss their relevance for tracking in the enterprise.

I get this question from Nessus users and Tenable customers very often. They want to know if they are scanning too often, not often enough and they also want to know what other organizations are doing as well. In this blog entry, we will discuss the many different reasons why people perform scans and what factors can contribute to their scanning schedule.