Tenable has released our first batch of audit policies which can test Windows 2000, 2003 and XP Pro systems for compliance with NIST best practice configuration standards.

These ".audit" checks are currently available on Tenable's Support Portal (available to Tenable customers) and can be downloaded to any Nessus 3 Direct Feed scanner or Security Center.

NIST SCAP Program

The US National Institute of Science and Technology has many different groups which keep track of and publish guides for a wide variety of standards, including several for computer security. The NIST Secure Content Automation Program (SCAP), offers content which can be used to automate security testing. The end result of SCAP is to have common configurations and security settings across the federal government. By leveraging more default consistency and security that can be enabled on each operating system, federal agencies will decrease their attack surface and also have infrastructures that is easier to manage. 

The main technology of the SCAP program is a common format to describe system configuration settings known as XCCDF. XCCDF stands for the Extensible Configuration Checklist Description Format. It is an XML file that leverages OVAL descriptions for computer system audits. XCCDF content is available under the SCAP program for a variety of operating systems and applications. Each XCCDF file may include support for different types of reference network functions, as well as different levels of security hardening.

Tenable and XCCDF

Tenable has developed an in-house tool that automatically converts XCCDF polices for Windows to Nessus 3 compatible .audit files. These .audit files are available on Tenable's Support Portal to existing customers. As the SCAP program develops new XCCDF content, Tenable will update these audit policies accordingly. Tenable is also actively developing XCCDF content for Vista, RedHat, and Solaris platforms.

There are 24 new polices. These primarily consist of a combination of Windows XP Pro and Windows 2003 systems which have been deployed in one of the following profiles:

• Enterprise
• Legacy (Support for NT4)
• Stand Alone

In addition, NIST has also published XCCDF templates for several DISA and NSA recommendations to harden Windows XP Pro. Audit files for these policies are also available.

FISMA and OMB

The Office of Management and Budget has recently announced that all federal agencies are required to implement a common configuration standard for their Microsoft operating systems. Throughout the next year, organizations are to implement a plan and then implement procedures to ensure compatibility with existing software and to have consistent configurations across all Microsoft desktop operating systems.

The content available from NIST is ideally suited for choosing a consistent configuration because there are many types of enterprise reference models and the content was developed by NIST and NSA security experts.

Using Tenable's Direct Feed or Security Center to perform these checks is also a good choice because it does not require any agents to be deployed and the specific audit policies can be easily customized.

Using these Audit Files

Any of the .audit files can be loaded into the Security Center for enterprise scanning or leveraged as part of a Nessus 3 Direct Feed scan.

Security Center uses should download the polices they need and place the polices in the /opt/sc3/admin/plugins directory as owner 'tns'. They will then be available as a Compliance Audit policy for any Vulnerability Scan Policy.

Nessus 3 Direct Feed users should download the desired audit policies to their laptop or system where their Nessus client is operating. Nessus 3 clients can reference one or more audit policies for their credentialed scans.

For More Information

Organizations interested in purchasing the Direct Feed ($1200/year per Nessus 3 scanner) or a Security Center ($15,750 to audit 500 servers) can contact Tenable's sales group by emailing sales@tenablesecurity.com. To learn more about Tenable's involvement with NIST and configuration auditing, please consider these previous blog entries:

• NIST CVSS Scores in Nessus Plugins
• Creating "Gold Build" Audit Policies
• Security and IT Controls

Tenable's research group recently released plugin ID #24904 which speaks with the Link Layer Topology Discovery protocol. This is an Ethernet "layer 2" scan, so it is something you need to perform against a server within the collision domain of a Nessus scanner. LLTD allows you to enumerate a wide variety of information about the remote host. The current NASL script supports discovery of:

• host ID
• Physical Medium
• IPv4 and IPv6 addresses
• Link Bandwidth type
• Machine Name

Below is an obscured screen shot of a scan of a test Vista system.

Security Center customers can make use of this data to write dynamic asset lists for automatically classifying their Vista systems based on any of the discovered parameters such as name, IPv6 address, the presence of IPv6 and so on.

A useful "non-security" query would be to use the wireless signal strength to find Vista systems that aren't covered with enough wireless signal.

Also, since you can't send these sorts of queries over IP packets, you need to have your Nessus scanner in the same collision domain. Organizations that have deployed multiple Nessus scanners in each of their VLANs can use this check immediately.

Very often when I speak with Tenable customers about performing IDS or Event analysis, I ask them if they use the Time Distribution tool under the Security Center. This tool is used to identify any combination of low frequency events for any query or time period it works with raw IDS events under the Security Center as well as normalized log or network events under the Log Correlation Engine. Regardless if you are analyzing the last million events which occurred in the last hour, or the entire last 90 days of events, this tool can quickly let you find what is unique and "interesting".

Why Find Low Frequency Events?

Many activities (checking mail, surfing the web, performing backups, .etc) occur at similar times over and over. These result in network and system logs which also occur over and over. Similarly, repetitive activities also generate repetitive false positives in your network IDS.

These events may be very interesting but it is much more likely that they are very boring. Since they occur over and over, an interesting filter would be to remove them and see what is left behind. Another way to look at this is to assume that your network isn't compromised or severely attacked each day. This can be a dangerous assumption in some cases, but as a filter which can be invoked as an analysis tool, can be very effective and useful. 

Basic Algorithm

The Security Center is used to configure any query you want. Maybe you are looking at the default "last 24 hours" view of events. Maybe you want to see all port 21 traffic for the last 5 days or all "User Activity" type events for the last month.

Regardless of your filter, the Time Distribution tool computes the oldest event time and the newest event time and then breaks this time period up into 20 parts. Then, for each unique event or log that has occurred, it counts the total that have occurred in each part. If an event has occurred in at least twelve  of the buckets, it is considered "high frequency" and is suppressed.

Example Output

Below is an image of all logs and events in a 24 hour period involving port 21, 22, 53 and 80.

There are several thousands events each hour in this trace. However, analyzing this data with the Time Distribution tool gives us this view:

In this view, we can see that even though there are thousands of events, the only really "low frequency" or very unique ones occurred at specific times. Clicking on the specific times would allow all events to be analyzed for that specific time period. 

Obtaining This Tool

This feature has been available in the Security Center and Log Correlation Engine for several years and is available while analyzing raw IDS events as well as normalized IDS, netflow, firewall, windows events and other types of logs.

For More Information

For a true low frequency event, Log Correlation Engine customers should consider using the "Never Before Seen" TASL script. This script remembers when a certain type of event first occurs on a host and alerts if a new event (such as an SSH login failure) has occurred for the first time.

Readers interested in learning more about event correlation should consider the existing TASL scripts for the Log Correlation Engine and also consider the "stats" log anomaly engine.

Tenable Network Security also offers several webinars and white papers online:

• Correlating IDS Events with Vulnerabilities (webinar)
• Network and Behavioral Anomaly Detection (webinar)
• Security Event management (white paper)

Quoting directly from Microsoft's web site about Teredo:

"Teredo is an IPv6 transition technology that provides address assignment and host-to-host automatic tunneling for unicast IPv6 traffic when IPv6/IPv4 hosts are located behind one or multiple IPv4 network address translators (NATs)."

Tenable Network Security has had active and passive techniques available to detect Teredo servers in both Nessus and the Passive Vulnerability Scanner for some time. Tenable's techniques for detecting Teredo servers are an excellent example of how a blended approach of active and passive network monitoring can be leveraged for realtime enterprise discovery.

This blog entry describes some of the security ramifications of Teredo as well as operational considerations for running these checks.

Security Issues with Teredo

Teredo enables IPv6 devices on your network to communicate directly with the Internet. This may allow for:

• bypassing outbound/inbound IPv4 network controls such as firewalls and router ACLs.
• avoid monitoring and/or enforcement of your outbound web proxy
• avoid monitoring and/or enforcement of your IDS/IPS
• avoid analysis of your network performance and activity with IPv4 centric solutions

Servers that establish IPv6 connectivity to points outside your local network now also become an attack point. Also, Teredo servers may be targeted directly for attack with yet to be discovered (or published) security vulnerabilities.

Teredo can be limited by blocking UDP traffic at the perimeter of the network.

Teredo Detection with the PVS

Tenable's research group offers two plugins for the Passive Vulnerability Scanner. 

• Plugin #3875 Detection of Teredo IPv6 client
• Plugin #3876 Teredo Server Detection

Analysis of UDP packets is used to identify both Teredo servers and clients that are connecting to it. Since the PVS operate 24x7, it can find all systems that make use of Teredo, even if they are used only occasionally.

Even if you do not have Teredo servers installed, these rules can identify if you have a system scanning for Teredo servers. This could be from a laptop using Teredo in a different environment, or perhaps a worm or malware agent looking for a Teredo server to ex-filtrate data from your IPv6 network.

Teredo Detection with Nessus

Nessus plugin ID #23972 "Teredo Server Detection" sends a router solicitation request on UDP port 3544. If an answer is received, the Teredo router is queried for more information which is displayed in the report.

For More Information

Teredo detection is an excellent example of Tenable's blended form of vulnerability monitoring which combines patch auditing, network scanning and network sniffing. To read more about it this concept, please consider our "Blended Security Assessments" paper available in our Vulnerability Management section of the Tenable Network Security web site.

For specific information about Teredo and IPv6 security, please consider these following links:

• Wikipedia Entry for Teredo
• Using Nessus 3.2 BETA to perform IPv6 scans
• RFC for Teredo
• Microsoft's web site on Teredo technology

Nessus 3.2 will support scanning of IPv6 addresses. The current BETA (released as Nessus 3.1.3) can be used to perform scans of IPv6 addresses. This blog entry shows how to use the current Nessus 3.2 BETA to perform such a scan from the UNIX command line.

Why Scan for IPv6 Addresses?

More and more operating systems are shipping with IPv6 enabled by default. Both Vista and OS X ship with IPv6 stacks. The presence of IPv6  on your network may dramatically alter how computers communicate with each other and connect to the Internet. Communication that occurs over IPv6 may not be blocked by local or network firewalls, observed by network IDS or even correctly logged by your SIM.

For compliance and corporate governance reasons, if you are not detecting IPv6 enabled devices, then you may have unauthorized or mis-configured devices and not know it.

And lastly, one of the more interesting abuses of IPv6 is that in some default situations, an unauthorized or compromised IPv6 host can "declare" itself the router, and then make your entire internal network globally available through the use of a tunnel.

Scanning IPv6 Enabled Systems

If you are used to scanning IPv4 enabled systems, IPv6 can add some new twists. For example, having an active IPv6 address might not allow you to connect to the TCP and UDP services as you can under IPv4. Simply installing an IPv6 address and then scanning the system might not allow connectivity to the various UDP or TCP services.

If you do add an IPv6 address to a host, you may need to restart the application(s) for them to actually "bind" to the IPv6 TCP or UDP 6 sockets. In some cases, depending on the OS and the application, a system reboot may be required or even new application software.

Obtaining Nessus 3.1.3

The current BETA of Nessus 3.2 is available as Nessus 3.1.3 for many different Linux packages and also FreeBSD. If you have an operational Nessus 3.0.x install (such as the currently available 3.0.5 release) you should consider running the 3.2 BETA on a separate host and not upgrade an operational server.

Target Selection

Before running any IPv6 scans, your Linux or FreeBSD scanner needs an IPv6 address on one or more of its interfaces.

IPv6 addresses can be specified directly in the list of targets. In addition, to "ping" the local network for any listening IPv6 addresses the "link6" target can be used.

When specifying a local IPv6 address (starting with fe80::) for Nessus scans, the local network interface of the scanning device must be appended with a "%" sign. For example, the following IPv6 target addresses are correct:

• link6%eth0
• fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0
• fe80::212:17ff:fe57:333b%dc0

If you were scanning a non-local address, the interface name would not be required. Both full and compressed IPv6 notation is supported.

Running a Scan from the Command Line

When running a Nessus scan from the command line, the nessus client tool is used to connect to a remote Nessus scanner with the following format:

nessus -c <policy> <IP> <port> <user> <pass> <target file> <output file>

For scanning IPv6 networks, nothing is really that different from the command line except that the target file contains IPv6 names. During testing for this blog entry, I used two different text files that had content as shown below:

[root@smog bin]# cat ipv6.txt
fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0
[root@smog bin]# cat link.txt
link6%eth0

The file ipv6.txt contained the IPv6 address of an OS X system as shown here:

Running a scan from the command line looked like this (with passwords obscured):

nessus -c policy.txt 127.0.0.1 1241 user password ./ipv6.txt ./output.txt

The policy.txt file is any type of .nessusrc file you would normally use to scan an IPv4 host.

Below is the raw results from scanning two different IPv6 addresses. Notice that one host has nothing reported for it, while the second host was able to connect to the SSH daemon on port 22:

Nessus Scan Report
------------------

SUMMARY

- Number of hosts which were alive during the test : 2
- Number of security holes found : 1
- Number of security warnings found : 0
- Number of security notes found : 7

TESTED HOSTS

fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0 (Security holes found)
fe80::212:17ff:fe57:333b%eth0 (Security notes found)

DETAILS

+ fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0 :
. List of open ports :
   o general/tcp (Security notes found)
   o ssh (22/tcp) (Security hole found)

. Information found on port general/tcp

    fe80::216:cbff:fe92:88d0 resolves as
     fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0.

. Information found on port general/tcp

    Information about this scan :

    Nessus version : 3.1.3
    Plugin feed version : 200703200708
    Type of plugin feed : Release
    Scanner IP : fe80::20c:29ff:fed1:8965
    Port range : default
    Thorough tests : no
    Experimental tests : no
    Paranoia level : 0
    Report Verbosity : 1
    Safe checks : yes
    Max hosts : 40
    Max checks : 5
    Scan Start Date : 2007/4/15 11:47
    Scan duration : 592 sec

. Vulnerability found on port ssh (22/tcp) :

    The account 'root' has the password 'root'.  An attacker may use it to
    gain further privileges on this system

    Risk factor : High
    Solution : Set a password for this account or disable it
    CVE : CVE-1999-0502

. Information found on port ssh (22/tcp)

    Remote SSH version : SSH-1.99-OpenSSH_4.5

    Remote SSH supported authentication :
     publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive

. Information found on port ssh (22/tcp)

    Synopsis :

    The remote service offers an insecure cryptographic protocol

    Description :

    The remote SSH daemon supports connections made
    using the version 1.33 and/or 1.5 of the SSH protocol.

    These protocols are not completely cryptographically
    safe so they should not be used.

    Solution :

    Disable compatibility with version 1 of the protocol.

    Risk factor :

    Low / CVSS Base Score : 3
    (AV:R/AC:H/Au:NR/C:P/A:N/I:N/B:C)
    CVE : CVE-2001-0361
    BID : 2344
    Other references : OSVDB:2116

. Information found on port ssh (22/tcp)

    The remote SSH daemon supports the following versions of the
    SSH protocol :

      . 1.33
      . 1.5
      . 1.99
      . 2.0

    SSHv1 host key fingerprint : 57:9a:2e:56:72:62:b6:57:8c:7b:0d:32:b1:aa:15:bf

+ fe80::212:17ff:fe57:333b%eth0 :
. List of open ports :
   o general/tcp (Security notes found)

. Information found on port general/tcp

    fe80::212:17ff:fe57:333b resolves as fe80::212:17ff:fe57:333b%eth0.

. Information found on port general/tcp

    Information about this scan :

    Nessus version : 3.1.3
    Plugin feed version : 200703200708
    Type of plugin feed : Release
    Scanner IP : fe80::20c:29ff:fed1:8965
    Port range : default
    Thorough tests : no
    Experimental tests : no
    Paranoia level : 0
    Report Verbosity : 1
    Safe checks : yes
    Max hosts : 40
    Max checks : 5
    Scan Start Date : 2007/4/15 11:47
    Scan duration : 631 sec

------------------------------------------------------
This file was generated by the Nessus Security Scanner

Notice that one host had "nothing" to report, but could be pinged via IPv6. The second host (a new lab Fedora Core 6 server) had IPv6 enabled and also a major vulnerability ("root" password of "root").

Working with Nessus Clients

Any Nessus client that supports scanning of a "hostname" supports a scan of IPv6 addresses. Nessus clients currently do not have any support for scanning IPv6 ranges.

In addition, when scanning an IPv6 host, don't forget to place the trailing network interface (i.e. "%eth0", "%dc0", .etc) of the Nessus scanner to tell it which NIC to use to perform the scan.

Perhaps the most useful type of quick scan is to do one against "link6%eth0" to ping the local subnet for any listening IPv6 systems. Here is an example screen shot from such as scan performed with a pre-BETA copy of the new Nessus 3.2 Windows client:

For More Information

Please send any feedback to Tenable regarding issues found with IPv6 support in the Nessus 3.2 BETA.

We are also interested in learning more about any plans organizations may have for large scale IPv6 technology deployments and how this may effect your network monitoring, logging and auditing requirements.

If you are interested in testing more aspects of the Nessus 3.2 BETA, we've previously blogged about new features in it at these links:

• Nessus 3.2 BETA -- Example WMI Library Usage
• Nessus 3.2 BETA Available for testing

Today, Tenable's research group released a remote Nessus plugin check (ID #25035) for a new vulnerability in Microsoft DNS servers. Microsoft has released a security advisory with details of the vulnerability and Tenable has confirmed the issue with an exploit in our lab.

To exploit this flaw, an attacker needs to connect to the DNS server RPC interface and send a malformed RPC query. Until a patch is available, all Microsoft RPC queries to effected DNS servers should be prevented from potential attackers.

This plugin is currently available to Nessus Direct Feed subscribers. Direct Feed subscriptions include access to the latest vulnerability checks, the ability to have Nessus perform agent-less configuration and content audits and technical support.

Security researchers interested in this type of Windows RPC security vulnerability should also find Tenable's mIDA plugin for IDA Pro also useful.

Tenable Log Correlation Engine customers who have Stonegate firewalls within their environment can now make use of a new normalization library. The new PRM parses logs obtained from the Stonesoft product. The new PRM is available here.

If you have Stonegate firewalls within your network, download this new library and place it in the /usr/thunder/daemons/plugins directory and then restart the thunderd process. Also, if you are using the Never Before Seen TASL script, you should also update your PRM_mappings.prm file, which contains the event IDs for the new Stonegate logs. 

The current list of supported network and host based firewall logs includes:

• Checkpoint
• Cisco ASA
• Cisco PIX
• CyberGuard (Secure Computing)
• Gauntlet
• Juniper
• Astaro
• Arkoon
• Fortinet
• ipchains
• Iptables
• Ipfilter
• Kerio
• NetGear
• OpenBSD's pf
• SideWinder (Secure Computing)
• SonicWall
• Stonegate
• PortSentry
• Sygate
• Symantec
• Windows XP
• ZoneAlarm

Tenable has added two new plugin families for the Passive Vulnerability Scanner. Previously, all of the Corporate Policy plugins belonged to the plugin family of "Policy". However, with plugin updates occurring today, they will now be in one of the following families:

• Abuse - Detection of pornographic activity being downloaded or served on a host.
• Data Leakage - Detection of Credit Cards, SSNs, wire transfers, HIPAA content and other types of sensitive data.
• Policy - Use of services such as YouTube, FaceBook, Gmail and so on.

In addition the following PVS plugins are also now included in the Data Leakage family:

• 3822 Office files .xls detection
• 3823 Office files .doc detection
• 3824 Office files .ppt detection
• 3825 Office files .csv detection
• 3826 Office files .rtf detection
• 3870 Detection of .xls file attachment in an email
• 3871 Detection of .zip file attachment
• 3940 Detection of .pst file attachment in an email
• 3941 Office files .pst detection
• 3943 Detection of .ost file attachment in an email
• 3944 Office files .ost detection
• 3946 Office files .uni detection
• 3963 Office files .pdf detection

Below is an example screen shot of PVS Data Leakage plugin detection as viewed under the Security Center:

For More Information

All PVS plugin families and descriptions are available in the following PDF document which is updated daily. In addition, new PVS plugin information is available in this RSS feed.

Tenable has also previously blogged about using the PVS to detect sensitive data leakage and corporate network abuse. 

Modern business attempt to put in place "Non Disclosure Agreements" with each other. These agreements dictate the rules for use for knowledge gained through interaction with each other.

Tenable's research group recently added a .audit content policy file to search for NDAs in Adobe and Word documents. The expected location for an NDA would be in your legal department. However, discovering NDAs on public web servers, on public network folders or on mobile sales laptops may indicate that unauthorized people have access. 

The .audit file performs some keyword searches. This could also be extended with specific names of competitors or business partners to be more exact in what is discovered. Below is a screen shot of a "hit" on a file which is a Tenable Network Security NDA:

The ability to audit content on remote systems with Nessus is available to Security Center users and Direct Feed subscribers.

Tenable will be participating in the following events in the next few months. I will be involved with all of these events, and many Tenable folks will also be there too.

CanSec West 2007
April 18-20, 2007 in Vancouver, Canada
Ron Gula will be presenting about using vulnerability data for event correlation.

Lone Star Information Security Forum
May 1-2, 2007 in Dallas Texas
Tenable's Sales team and Ron Gula will be participating.

World Summit on Intrusion Detection
May 8-9, 2007 in Baltimore Maryland
Ron Gula and Marcus Ranum will both be speaking.

2007 Techno Security Conference
June 4-6, 2007 in Myrtle Beach, South Carolina
Ron Gula will be presenting about using vulnerability data for event correlation.

New York Metro Information Security Forum
June 20-21 in New York City
Tenable's Sales team and Ron Gula will be participating. Also from Tenable, Carol Fennelly will present on developing a site security policy  and security strategy.

On March 21st, Tenable announced that our products were officially under NIAP Common Criteria evaluation.  Tenable is scheduled to complete the certification this year. This was good news to our United States DOD customers, but we also received a wide variety of feedback and comments which is the focus of this blog.

Common Criteria in the DOD

If you are not familiar with the concept of NIAP, the DOD can only officially acquire products that have gone through this sort of evaluation. In reality, organizations can get a waiver if they want to purchase something that has not been certified. Most organizations also wait until a product is officially "in evaluation" with NIAP before they attempt to acquire it.

The National Information Assurance Project (NIAP) is a U.S. Government initiative between the National Institute of Standards and Technology (NIST) and the National Security Agency.  NIAP sponsors a variety of projects and activities, including the Common Criteria Evaluation and Validation Scheme (CCEVS).  The Common Criteria is a standard for evaluation of security measures in a given product.  Many government agencies require that products they deploy have been evaluated under the Common Criteria process.

Tenable has contracted SAIC to perform a Common Criteria (CC) Evaluation at Evaluation Assurance Level Two Augmented with Flaw Remediation (EAL2+) of the Tenable Security Center 3.2 product.  The Target Of Evaluation (TOE) includes all the elements that comprise a full deployment of the Security Center suite: Nessus Vulnerability Scanner (Nessus), Log Correlation Engine (LCE) and the LCE Clients, Passive Vulnerability Scanner (PVS), and the 3D Tool (3DT).

We're not finished with NIAP by any means, but to get into evaluation means that our product architecture, documentation and even our internal processes at Tenable has been considered. In some cases, we had to add certain features into Security Center 3.2 or enhance our documentation specifically because of a NIAP requirement.

United States Based Sources for Plugin Downloads

We've participated in a few trade shows since our announcement and one type of feedback we consistently got from DOD attendees was:

It's great that your products are in certification, but I can't use Nessus because the downloads come from France.

This really surprised us, because there are a great number of ".mil" accounts used to register for Nessus. Although we don't publish Nessus download statistics, we never felt that the ".mil" community was under-represented. As it turns out, certain portions of the DOD block all access to international sites. In this case, plugins.nessus.org is hosted by an ISP based in France. This is the site that the "free" users of Nessus obtain their registered plugins from.

Our co-founder and Nessus author Renaud Deraison is from France. Because of this, you should expect that Tenable has been able to have great relationships with new customers and business partners there. In this case, we have site that supports all worldwide Nessus user plugin downloads.

Tenable has several places we conduct our hosting, mail delivery and product distribution. The main page that plugins are distributed to Direct Feed and Security Center customers is from our offices in Columbia, Maryland. If you need to obtain plugins directly from a United States sources, you can do this with a purchase of the Direct Feed or operate the Security Center.

For More Information

If you are interested in Tenable products, please feel free to contact us or visit our products pages. To review our evaluation status with NIAP, please visit: http://www.niap-ccevs.org/cc-scheme/in_evaluation.cfm

I was speaking with an attendee at the Mid Atlantic IANS Forum, and they had an issue tracking new virtual servers that were "popping up" all over their enterprise. They had a secondary problem in that many of these new OSes weren't properly licensed as they were all installed off of the same ISO. This blog entry discusses discovery of VMware systems with active and passive methods.

Nessus 3 Detection

Nessus 3 can help very much with this issue. Consider these two plugins:

• #20094 VMWare Host
• #24273 Remote Copy of Windows Not Activated

The first plugin primarily detects Windows systems that are running on VMware. This is accomplished through the MAC address which can be obtained without credentials simply by asking the Windows server. If UNIX credentials are used on the host, the MAC address is also saved. And lastly, for either UNIX or Windows hosts, if Nessus and the target host are in the same collision domain, the MAC address will also be obtained. Once the MAC address is obtained, it is compared to a list of known VMware addresses.

The second plugin is purely for Windows. It requires credentials and WMI access. It performs a check to see if the running copy of Windows has been activated or not. If your organization is running unauthorized or unlicensed copies of various Windows operating systems, this plugin will determine it. It may also indicate that a system has been installed but not fully configured.

Passive Detection

This process can also be complimented with continuous monitoring from the Passive Vulnerability Scanner. The PVS can detect when various VMware systems reach out to detect if new versions are available. This process is detected by the PVS and can be used to identify real hosts that operate one or more virtual servers. It can also identify systems which run VMware, but run their hosts isolated or perhaps NATed.

Enterprise Considerations

Security Center users could place all of their detected VMware systems into one dynamic asset list. This would allow them to see if their configurations are correct, if they have been deployed in the correct locations and even if the right type of software has been installed.

Dynamic lists should be built with combinations of Nessus plugin ID #20094 or PVS plugin #3396. Below is a screen shot of a PVS detect as viewed under the Security Center:

For More Information

Readers who found this blog entry useful will also be interested in these blog entries:

• Enterprise Software Discovery with Nessus
• Detecting Change -- Part II
• Detecting Network Change

Note: This blog entry was originally posted in April, 2007 and was updated on May 28, 2009

The Security Center can be used to manage multiple Nessus scanners and Passive Vulnerability Scanners for continuous monitoring of sensitive data at rest and data in motion. This blog entry discusses various deployment scenarios that can be used to effectively perform data leakage detection.

Active and Passive Detection Methods

In March, 2007, Tenable released the ability for Nessus ProfessionalFeed and Security Center users to scan Windows hosts for sensitive data such as credit cards, employee information and even things like source code. This technology works as part of the regular vulnerability or configuration auditing scans.

Previously, Tenable also released policy libraries for the Passive Vulnerability Scanner (PVS) to identify servers and users transmitting sensitive data in motion. The PVS can not only identify hosted Adobe, PowerPoint, Word and Excel files as Nessus can, it can look into the traffic in email, chat and web browsing to look for specific types of data such as social security numbers and credit cards.

When managed by the Security Center, the combination of active and passive data leakage monitoring is an effective method to discover where sensitive data is and when it leaves the networks. Below is a screen shot of an America Express credit card number being hosted on a web server:

Why Find Sensitive Data?

When sensitive data is identified through the Security Center, several courses of action can be taken:

• A list of all systems with sensitive data can be obtained by IP address, MAC address, DNS name or Windows name. This list is available as a spreadsheet or can be created as a PDF report.
• A list of all corporate assets with sensitive data can similarly be created, allowing users to see if any systems unauthorized to hold data actually have any.
• The Security Center's ability to combine qualities of vulnerability detection with asset identification also allows it to find hosts with sensitive data that are unmanaged or have vulnerabilities.
• If necessary, different types of sensitive data records can be classified into different asset groups. For example, all systems holding credit card data could be placed into a PCI asset list while all records holding patient health data could be placed into a HIPAA list.
• If the Security Center is able to detect a system compromise, the incident response process can immediately take into account if this was or was not a server or system with sensitive data.

All of these capabilities allow an organization to combine information about system vulnerabilities, system configurations and systems holding sensitive data to identify and manage potential compliance, security and data leakage issues.

Creating Dynamic Asset Lists based on Sensitive Content

Information about sensitive data found by Nessus or the PVS can be used to create a Security Center dynamic asset list. This data can be combined with other attributes such as IP address, system usage, open ports, domain name, system asset information and so on to create unique asset lists.

For example, in the screen shot below, we've scanned the network for documents containing the word "Tenable" in them.

If we wanted to write a dynamic asset rule for all systems that had this data on it, we'd target ID #60186 and also had the content of "[FAILED]". This second step is required because if a systems did not have any .doc files that had the word "Tenable" in it, it would also have an active ID #60186 but would have the content "[PASSED] in it.

For More Information

Information on purchasing the Security Center ($15,750 for 500 servers), Passive Vulnerability Scanner ($9995 for any network) or the ProfessionalFeed ($1200/year per Nessus scanner for end users) is available here.

Readers who are interested in compliance can request a copy of Tenable's "Real Time Compliance Monitoring" paper, as well as any of our application notes on PCI, or HIPAA compliance monitoring.