With the release of Security Center 3.4.3 as well as Log Correlation Engine 3.0.1, we've updated the main Unified Security Monitoring videos at nessus.org. These videos are free to use and do not require registration. The following new videos are now available:

Unified Security Monitoring

This is a five minute introduction to the concept of performing vulnerability and configuration analysis on the same vendor solution that can perform log correlation and anomaly detection. Unifying this information into one spot allows you to spot security risks and compliance issues early and often.

PCI Enterprise Auditing

This twelve minute video discusses how unifying system and event analysis into one platform can address all 12 requirements of PCI. Demo includes enterprise PCI DSS scanning, auditing anti-virus configurations, scanning for documents which contain credit cards, finding wireless access points, tracking user access to systems with card holder data and much more.

Configuration And Vulnerabiltiy Scanning

This five minute video provides a more in-depth look at how to analyze vulnerabilties and configuration issues that have been obtained from the Nessus vulnerability scanner and Passive Vulnerability Scanner. Many aspects of the Security Center's ability to filter and sort on the security data collected are demonstrated.

Log Normalization And Search

This video shows how syslog, windows events, firewall logs, network session data and much more is aggregated and normalized by the Log Correlation Engine. Multiple examples of event analysis are performed, including searching logs of a firewall for specific patterns.

Correlation And Anomalies

The Log Correlation Engine will perform a variety of event correlation types. This video demonstrates detection of some simple behaviors such as brute force password guessing, continuous scanning detection and statistical changes in network traffic and login events.

Change Detection

Change occurs on your network all the time. With this video, you can see how Nessus, the Security Center, Passive Vulnerability Scanner and the Log Correlation Engine can detect changes from scan to scan, through log analysis and through direct network monitoring. More importantly, this video shows how vulnerability data can be filtered by time so you can easily see when a vulnerability was first discovered. 

Insider Threat

A new feature of version 3.0 of the Log Correlation Engine is to dynamically associate usernames with IP addresses and tag every event with a user name. This makes sorting on firewall logs, netflow and any other type of event by user very easy. This video demonstrates how to use user login events from a popular NAC to then correlate other types of network and system activity.

Nessus has the ability to perform full port scans on UNIX and Windows systems by leveraging credentials. For UNIX systems, the “netstat –an” command is invoked and the results used to mark each reported TCP or UDP port open in the Nessus knowledge base. For Windows systems, WMI is used to identify each open port in a similar manner.

• For enterprise customers using Nessus or the Security Center to perform audits of systems with credentials, this type of audit saves time and improves accuracy over traditional port scanning methods:
• Probing a TCP service with a SYN scan or a full TCP connection takes time. Not only does each packet need to be sent, but it also needs to be tracked in case it was filtered, times out or is rejected.
• Performing UDP scans is very unreliable. By its very nature, a UDP port scan considers a port open if there is no response. Since UDP is unreliable in nature and is often filtered, most UDP port scans return results that are not accurate.
• Placing large numbers of sequential or random port connections to multiple target hosts can impact the performance of firewalls, NAT devices, switches and many other types of network equipment. Network devices which handle packets often keep a table of active connections and a port scan can make your network look very busy, or take a network that is operating at capacity and make it perform very poorly. In some cases, such devices are licensed per concurrent TCP sessions, and such a port scan might even disrupt other legitimate connections.
• The lack of port scanning traffic means that your NBAD, network IDS, firewall logs or SIM does not get hundreds or thousands of alerts that need to be filtered.

These credentialed port scans also have some other compliance and performance advantages:

• Unless someone has placed a rootkit on the OS, this technique will accurately identify all uncommon and high-port listening services. Of course, if an attacker has placed a rootkit, it very likely placed in defenses that make their ports not show up during active scans.
• If you have a PCI requirement to perform a full port scan of a target, this credentialed technique can also be used. PCI requires that assessments of Internet facing servers be performed without any filtering in place and for all 65,535 ports. Performing a credentialed scan is much quicker than doing a full active port scan.
• Since these techniques accurately identify all open ports, it is much more likely that Nessus will perform accurate service identification of these ports and discover vulnerabilities on them. Scans that perform their port scan analysis with active methods may not target all available ports due to time constraints.

Launching these Scans and Understanding them

To make use of these scanners, Nessus and Security Center users should simply enable these port scanners in their scan configurations and also include the required credentials to log into the remote systems. Below is a screen shot of the list of available port scanners in the NessusClient:

Notice that the “Nessus TCP” scanner and the “netstat portscanner (WMI)” were both selected. This would cause a full active TCP port scanner to execute as well as a credentialed WMI scan. There is nothing that prevents a Nessus user from combining these port scans, but there is no additional benefit. A user doing a credentialed audit of a UNIX or Windows system can save a lot of time by only performing the netstat style scans.

Having said that, you should surely consider creating a scan policy that made use of credentiales for Windows and UNIX accounts at the same time. Enabling both the "netstat portscanner (WMI)" and the "Netstat 'scanner'" for UNIX along with the required credentials can rapidly perform full network scans.

Results from these plugins are reported the same way as any other port scanner as shown below:

In this case, we used credentials to perform the WMI netstat scan of a Windows 2003 server. The above ports were identified. Running tcpdump during the scan, we gathered only 784 packets (which explains the title of this blog).

Full port scans place many more packets on the network. Even with a simple SYN scan for TCP and a UDP probe, a scanner would send 65535 * 2 = 131070 packets. Even worse, these packet counts can be much higher. For accuracy, a scanner might send the same packet more than once. When looking at full TCP connections or even a SYN scan, there could be 1000s of “reset” packets sent back from the target. With TCP resets and UDP “ICMP Unreachable” messages, it’s not uncommon for packet counts of full port scans to be more than 250,000.

For More Information

If you are concerned with minimizing network impact during active vulnerability scans, you should read our previous blog posts regarding distributed vulnerability scanning.  You should also review topics such as how to invoke the Nessus “safe checks” option,  UDP service enumeration, detecting “off port” services such as web servers not running on port 80 and generally how Nessus performs operating system fingerprinting.

If you are interested in real-time traffic analysis to identify change, new applications, new vulnerabilities and also discover which systems connect to each other and share data, the Passive Vulnerability Scanner can be used along with the Security Center. It feeds discovered data, including real-time identification of open ports, browsed ports and the applications and clients that make use them into the Security Center which combines this information with data from credentialed and un-credentialed Nessus scans.

Tenable Network Security's research group recently introduced support for credentialed patch auditing of SuSE Enterprise 9 and 10 for both the Server and Desktop editions. Plugins which support patch auditing of these operating systems have been available to Registered Feed, Direct Feed and Security Center users since late 2007. All plugins are published as part of the SuSE Local Security Checks Nessus plugin family.

In addition, patch auditing of AIX 5.x and 6.x is also fully supported through the AIX Local Security Checks plugin family. Customers parsing AIX logs collected with the Log Correlation Engine can now also make use of new updates which analyze login and system activity. These normalized events automatically feed into the automatic statistical event profiling and event correlation of the Log Correlation Engine.

I often get the chance to speak with our Security Center customers who perform active Nessus scans or monitor networks in realtime with the Passive Vulnerabiltiy Scanner (PVS). These customers generally have more than 5 Nessus scanners, 2-3 PVS sensors and need to watch and report on more than 5000 active hosts.

For many of them, deploying Security Center is the first time they've been really able to unify patch/config auditing, active scanning and network monitoring and have this information shared securely across multiple departments.

A common question I get asked is how to make sense of all the data collected. This blog entry considers several different strategies and ideas that use "asset lists" to make sense out of the various technologies, applications and configurations that can occur on an enterprise network.

Dividing the Network into Asset Groups

I've blogged before about how the Security Center can use asset lists to split a network up into "things you know" and "things" that can be discovered independently of any corporate knowledge. Each asset list is simply a list of IP addresses that all have the same sort of property.

For example, if one were to ask an enterprise networking group for a list of all "Cisco router" IP addresses, this list could be loaded into the Security Center and used to report, filter and analyze all vulnerabilities, as well as logs and IDS events if the Log Correlation Engine were in use, just on the "Cisco Routers". At the same time, the Security Center could also use something we call a dynamic asset list that can rely on the operating system fingerprinting (or any other plugin) of Nessus and the PVS to come up with its own list.

What gets interesting is when the "official" list of what constitutes a corporate asset differs from what has been actively or passively derived by the Security Center. These discrepancies usually indicate a failing or lack of a process to disseminate information accurately to security, audit or other types of groups. Many of our customers have also said they've been able to rectify issues or gaps in the accuracy of their corporate asset management systems by comparing their lists to the lists and data within the Security Center.

Standard Dynamic Asset Lists

Dividing your network up into different types of asset classes can map into normal technologies you and your organization are already familiar with. The following is a very easy list of default items and methods to help classify your network:

• DNS and Netbios names can be used to classify hosts. If an organization has a naming convention (my Tenable laptop is named LAP5506 -- guess what the 'LAP' means?) then dynamic asset lists can be used to generate on-the-fly lists based on naming conventions already used in the organization.
• Operating System classification can automatically label various systems in different networks. For example, combining the output of the Nessus OS ID plugin and a domain name filter could result in list of all Windows XP servers in a specific domain.
• If the Passive Vulnerability Scanner is involved, a tremendous amount of client side application and network browsing behaviors can be used to classify hosts. For example, the PVS can list all systems which make outbound connections on port 143. This is a quick way to identify all systems that receive email through IMAP.
• Nessus scanners can differentiate between live hosts and systems running in a VMWare environment. This can allow for a quick and easy way to identify which of your systems are "real" or "virtual".
• Nessus 3 can also make a variety of Windows WMI queries. The data contained on a Windows server available through WMI is richer than what can be queried for in just the registry. These include CPU type, manufacture and hardware type. All of this information is available to help classify your environment. WMI can be used to different not only different types of manufactures such as Dell and Sony, but to also differentiate different types of platforms within a manufacturer.

This list is just a portion of the types of classifications that can be performed with the Security Center and the data obtained about your network with Nessus and the PVS.

Advanced and Innovative Ideas for Classification

Over the past few years I've picked up a few tricks from customers for helping to classify systems and identify devices that have been installed that should cause alarm.

One of the easiest things to do is search for systems that aren't in the DNS system. Nessus plugin #12053 attempts to perform a DNS lookup of each active IP address that is scanned. If you are on a large network, finding systems that are alive, but are not in DNS is a great way to find test networks, non-production systems, networks and hosts that have been "forgotten" and so on.

Another interesting form of classification is to look for systems that don't have a valid OS fingerprint. Nessus uses a wide variety of techniques to accurately identify the operating system of a host. If this process does not result in a guess of the target OS, this could indicate that a host has some sort of firewall or IPS blocking the scan. If this is the case, then this asset might be more important to the organization and should be further analyzed. Some of our customers who also deploy the PVS have taken this concept a step further and have deployed rules to list systems that don't have an active fingerprint, a passive OS fingerprint or are missing both.

Creating assets based on combinations of open ports and browsed ports can also indicate how a system is used. Creating a rule which combines Nessus and PVS plugin '0' (an open port) with PVS's client side port browsing rule can identify a wide variety of systems. For example, if all we know about a host is that it browses on ports 53, 80 and 443 it is likely just performing web browsing. If a system had port 80 open (such as a web server) and also browsed on port 80, this could indicate that a production web server is reaching out to the Internet for update and is not being centrally managed.

Mapping Assets to Corporate Policy

An important item I tell our customers to keep in mind is to map their asset classification efforts into corporate policy. With more than 20,000 active and passive plugins to draw data from for classifying a host, there is ample opportunity to over-classify assets based on today's security headlines or the technical whims of the audit or security staff.

For example, due to PCI, it might be a corporate practice to alert on any system with a vulnerability older than 30 days. With the Security Center, it is fairly trivial to classify and report on any host that has a vulnerabilities older than 30 days. It is much more useful to consider the overall state of a host and how it impacts a standard such as PCI.

For More Information

If this blog entry was useful to you, the following previous entries will also likely be of interest:

• Using Manufacturer Information for Automatic Dynamic Asset List Creation
• Testing The Effectiveness of your Patch Management System
• Knowing When To Patch
• Advanced Dynamic Asset Rules
• Enumerating Corporate Data

To learn more about Tenable's Unified Security Monitoring strategy, please visit us on the web site, contact us or check out one of the online videos of our product offerings.

Tenable has produced a variety of report templates and scanning polices for both the NessusClient 3.0 and the Security Center. This blog entry discusses coverage of the SANS Top 20 2007 Annual Update in Nessus as well as the Passive Vulnerability Scanner and instructs users how to obtain and use these policies.

SANS 2007 Annual Update

As with previous annual updates, the SANS 2007 update classifies vulnerabilities into several categories including "client-side", "server-side" and "zero day attacks". CVE numbers were used in each of the sections to map to the relevant Nessus and PVS plugin IDs.

Several sections did not identify specific CVE entries, but did identify general guidelines for security and auditing your systems. For each session, Tenable suggests the following solutions:

H1 - Excessive User Rights and Unauthorized Devices

With Nessus credentialed checks, a wide variety of configuration auditing polices can be used by Direct Feed and Security Center users to  audit Windows and Unix systems. Many of the policies available have been generated from a variety of "best practices" guidelines including NIST SCAP content and the Center for Internet Security.

To detect unauthorized devices, a variety of methods can be used. The simplest is to scan with Nessus and see what is on your network. In larger enterprise networks, analyzing raw scan results is cumbersome. Continuous network monitoring with the Passive Vulnerability Scanner as well as automatic classification of systems into one or more asset categories by the Security Center is recommended.

H2 - Phishing/Spear Phishing

The Passive Vulnerability Scanner can tell you which hosts on your network connect to the Internet and the Log Correlation Engine can perform a variety of black list analysis to see if your users are connecting to potentially hostile sites.

The intent of this section is to prevent and educate your users from being "socialed" but an interesting feature of the Passive Vulnerability Scanner is its ability to recognize when a web page claiming to be from a bank or credit union appears on your local network.

H3 - Unencrypted Laptops and Removable Devices

Although Nessus does not test for "encryption", it can test for the presence of specific encryption software and to also test if the software is installed and configured correctly. End users would need to develop a Nessus configuration audit policy that identifies if the corporate standard for encryption is installed and configured to policy.

Nessus credential checks can also itemize all USB devices that have been attached to an audited Windows computer. The Security Center can use the output of this audit to classify systems based on the type of detected USB device.

A2 - Peer-to-Peer Programs

The 2007 update did not specify any particular vulnerabilities in any particular P2P applications. I feel this is an oversight, as there have been many severe vulnerabilities in a variety of P2P applications. From a corporate point of view though, the simple presence of a P2P application may have a variety of issues other than security such as the potential sharing or corporate data or the act of obtaining copy written material.

Both Nessus and the Passive Vulnerability Scanner have entire families of plugins dedicated to the detection of P2P applications and identifying any known security issues with them.

Passive Vulnerability Scanner Coverage

The PVS is able to detect relevant SANS 2007 Top 20 vulnerabilities in many of the different sections, especially the client-side vulnerabilities.

Overall, there were more than 60 unique PVS plugins which were directly attributable to the SANS Top 20 2007 audit. There are many more generic plugins (such as simply identifying older browsers or the presence of a certain type of network applications) that also help an organization to removing or mitigating harmful applications.

The relevant plugin IDs for the PVS are enabled in the SANS 2007 report for the Security Center two sections below.

NessusClient 3.0 Scanning Policy

Below are .gz and .zip files which can be used by the NessusClient 3.0.

Download SANS-2007.nessus.gz

Download SANS-2007.zip

The scan policy only enables the relevant Nessus plugins for the SANS 2007 list of identified CVE entries. The policy also includes individual scan policies for each section (such as C1, C2, S3, and so on) such that a quick scan of just that specific section can be performed.

To use this policy, download the .gz or .zip file to your system and uncompress it. Then, after launching the NessusClient, choose 'File', then 'Open' and select the SANS-2007.nessus policy. After loading, your NessusClient should look something like this screen shot below:

The policy does not include the required credentials to perform patch audits. Once you have loaded the SANS 2007 policy, if you wish to perform a patch audit, you should add in the Unix or Windows administrator credentials of the system(s) you wish to audit. If you are auditing multiple sites with different credentials, you should add in your scan targets and save the entire configuration as a new scan policy.

Security Center Reporting Templates and Scanning Polices

The following two downloads enable the Security Center to perform SANS 2007 Top 20 scans as well as generate relevant SANS 2007 Top 20 reports from existing Nessus and PVS scanning data.

Download sans-2007-sc3-scanpolicy.tar.gz

Download sans-2007-sc3-reportpolicy.tar.gz

To install these two files, perform the following steps:

1. Download both files to your Security Center in a temporary location
2. unzip and untar the sans-2007-sc3-reportpolicy.tar.gz file
3. chown each of the .xml files to user 'tns'
4. move all of the .xml files to the /opt/sc3/admin/report_templates directory
5. unzip and untar the sans-2007-sc3-scanpolicy.tar.gz file
6. chown each of the files new files to user 'tns'
7. move these files to /opt/sc3/admin/vpolicy
8. edit the /opt/sc3/admin/vpolicy/vpolicy.txt file and add the value "0033" to the list on the line before the "***END" designator.

Once these files are installed, the are immediately available for use within the Security Center.

If you have existing data from Nessus scans or the Passive Vulnerability Scanner, you can create or schedule a SANS 2007 Top 20 report by choosing one of the new report templates. There are three new templates which summarize vulnerabilities, summarize the effected network and assets and also provide full detail of the vulnerabilities in question.

Also, immediately from within the screens for browsing and analyzing vulnerability and configuration data, if the SANS 2007 policy is chosen, only the vulnerabilities relevant to that policy will be displayed.

To schedule a new scan for just SANS 2007 issues, Security Center users can choose the new policy and launch a scan. As with the NessusClient, if credentials are in question to perform host-based audits, the SANS 2007 scan policy should be cloned and in the new policy, have its credentials specified. If a network asset with known credentials is scanned, the Security Center will automatically use those as well.

For More Information

Nessus is available to end users as a complimentary download. Tenable offers a variety of commercial and no-charge methods to update Nessus to check for recent vulnerabilities. For more information, please visit http://www.nessus.org.

The Security Center, Passive Vulnerability Scanner and the Log Correlation Engine are all commercial products offered by Tenable Network Security. For 500 servers, the Security Center costs less than most commercial vulnerability scanner licenses, yet has the power of and functionality of leading SIM and vulnerability management solutions. For more information on these products, please read about them online or email our sales staff.

Tenable's research group recently added checks to both Nessus and the Passive Vulnerability Scanner to detect HTTP authentication which occurs over plain-text. This blog entry will discuss why this is an issue, and how the detection methods work.

HTTP Plain Text Authentication Security Risks

If you are new to security and you were analyzing how logins to an HTTP server worked, you would not observe your password. Instead, the HTTP protocol will send an encoded string of your password such as this:

Authorization: Basic cGFzc3dvcmQ=

The form of encoding used is not strong encryption, it is just a way to keep the information from being directly recognized by a human. The algorithm used by web servers is known as "Base 64". Encoding and decoding Base 64 passwords is very easy, which makes it very insecure. There are even online forms where you can encode and decode strings. If you copy the above "cGFzc3dvcmQ=" string into a base 64 decoder, you'll see it is the word 'password'.

Security Risks of Plain Text Authentication

Obviously anyone who can sniff a login session to a web application can gain user name and password information. What is more interesting is why these logins occur in the first place. There are several reasons:

First, security is often added later on in the development of web applications. A very stereotypical view of unsecured application development is to imagine someone working on the core functionality of the application and then worry about authentication later.

And secondly, many applications and web management consoles don't care if they are running over HTTPS (a secured web server) or over plain text. When systems are put into production, unsecured access to the plain text web server on port 80 can be forgotten to be disabled or blocked at the firewall. Application and firmware upgrades can sometimes roll back changes and end up re-enabling the unsecured web server.

Detecting Web Servers and Clients Using Plain text Authentication

Nessus plugin #26194 "Web Server Uses Plain Text Authentication Forms" detects remote web servers that have one or more forms which contain a field named 'password'. This script is dependent on the results of the web_mirror.nasl script which performs a wide variety of web site analysis.

PVS plugins #3018 and #4225 detect both web servers and clients which use plain text HTTP authentication. Since the PVS sniffs both sides of any network session, it can see which web servers accept plain text HTTP authentication as well as which clients are also using this.

Both the Nessus and PVS techniques will discover and observe web servers on port 80 and will also recognize web servers running on non-standard ports.

When analyzing the results from both Nessus and the PVS, consider the location and environment where the test is performed. For example, being able to connect to the web management interface of a router from an internal network is not the same as being able to log into a web application interface from the Internet. Both targets might use plain text HTTP authentication, but have different levels of access to potential attackers.

When analyzing large numbers of systems in an enterprise, tools like the Security Center can help make sense of which assets accept plain text HTTP authentication and may be at higher risk.

Over the past few weeks, we've released several new tools, Nessus audit policies, Log Correlation Engine log parsers and Log Correlation Engine TASL scripts. A summary of these releases is provided below.

New Product Releases and Updates

• Nessus 3.0.6.1 for Windows - This release fixes a security hole for users running Internet Explorer 6. All users are strongly encouraged to upgrade. Nessus plugin #25799 checks Windows systems for this vulnerability. Direct Feed customers can download 3.0.6.1 directly from the Tenable Support Portal and it can also be downloaded from http://nessus.org.
• Security Center 3.2.3 - This release improves a wide variety of performance, user management,  reporting and distributed scanning issues. The maximum size of "managed" vulnerability data has been increased from 4GB to 16GB. Also, dynamic asset list computation has been reduced from more than 30 minutes in some cases to less than 1 minute. Builds for RedHat ES3 and ES4, along with a complete list of issues resolved with this release are available for download from the Tenable Support Portal.
• NessusClient 3.0.0 beta 2 - A new release of this Windows and Linux Nessus client is now available for download from http://nessus.org.
• Nessus 3.2 beta 4 - For users testing the Nessus 3.2 beta, a 4th release (Nessus 3.1.4) has been made available for Linux, FreeBSD and Solaris. 

New and Updated Audit Polices

• CIS Certified FreeBSD Audit - Tenable was recently awarded certification to perform Center for Internet Security audits according to the best practice consensus guide of securing FreeBSD systems. This .audit policy is available for download from the Tenable Support Portal by choosing the "Downloads" button and then the "Download CIS Audit and Compliance Files" button.
• PCI Configuration Audit Updates - Version 1.0.2 of the Windows and version 1.0.3 of the Linux Payment Card Industry 1.1 audit polices are now available. This update relaxes some of the more specific checks to accommodate more stringent settings. These .audit policies are available for download from the Tenable Support Portal by choosing the "Downloads" button and then the "Download Configuration Audit Polices" button.

Updated and New Event Correlation TASL Scripts

• blacklist.tasl - Similar to the blacklist_domain.tasl script, which was blogged about here, this IP based blacklist lookup correlation script can now accept two "black lists". The second list is for users who want to maintain their own static list of "bad" IP addresses which is not updated based on content from Arbor, SANS or the Bleeding Threat project.
• long_tcp_sessions.tasl - Previously, Tenable had been maintaining two separate TASL scripts which would monitor the length, bandwidth and ports of each TCP session obtained through NetFlow or direct sniffing. This new TASL script accepts both event types.
• new_user.tasl - Support to automatically recognize new user names from MS SQL Server logins.
  
• successful_login_after_multiple_failures.tasl - Added several new login event IDs and removed account names associated with normal system processes.
• windows_logon_unknown_network.tasl - Added several new login event IDs and removed common account names associated with normal system processes.

Updated and New Log Parsing PRM Files

• nids_snort.prm - More in-depth parsing for Bleeding Threat Snort event names is now supported.
• prm_map.prm - This PRM contains the latest list of all event names and it is parsed by several TASL scripts, such as the Never Before Seen script.
• sql_mssql.prm - Additional log parsing rules for Microsoft SQL Server.
• ssh_dropbear.prm - The Dropbear application is a very small SSH client and server.
• tenable_network_monitor.prm - This PRM is required to parse events from the new long_tcp_sessions.tasl script.
• web_apache.prm - There are several new rules to parse script errors and file handle activity.
• web_w3c_extended_log_format.prm - Bugfixes for Apache '402' Payment Received rules.

Note: To install any of these TASL or PRM files for the Log Correlation Engine, download these files to your /usr/thunder/daemons/plugins directory and then restart the thunderd service.

I've been at several conferences and forums where a panel of CIOs or CSOs gives their guidance about enterprise risk and compliance reporting.  When asked which products are up to the task, as each vendor in the audience is leaning forward on the tip of their chair hoping for a free product placement, the answer most commonly is -- Excel.

One of the very cool features of the Security Center that our customers continually remind me of is the ability for anyone with an account to download anything they are authorized to see as a spreadsheet. This includes vulnerabilities, configuration settings, intrusion events, failed logins and much more. This blog entry focuses on the different kinds of things we've seen our customers do with spread sheet exporting of security, log and compliance data.

Exporting Data via CSV

CSV stands for "Comma Separated Variables". For any type of query performed by the Security Center, the data rendered will also have a corresponding [CSV] link, such as this shown below:

This link also includes the appropriate access control such that someone who is only supposed to have access to the IT systems in Milwaukee only sees vulnerabilities, logs and compliance data from the IT systems in Milwaukee.

The data is also automatically sorted and presented based on the tool the user has invoked. For example, you may have 10,000 unique vulnerabilities you are dealing with, but have chosen to view a "Vulnerability Summary". Your spreadsheet will also be rendered as a summary of vulnerabilities and not list all 10,000 unique entries. This makes working with and manipulating the data very easy.

Obtaining CSV Export by Asset List

A very common request of the Security Center is to find all of the systems with some sort of property, such as an open port, installed software, the existence of given vulnerability or so on. With more than 15,000 active checks and 4000 passive checks, a Security Center that is managing Nessus and Passive Vulnerability Scanners will have a large volume of data to work with and create dynamic asset lists. These asset lists can be used as a filter to create spread sheets just like any others.

Customers have shared with us several different types of useful dynamic asset lists including:

• Highlighting all devices which host some sort of office document through web, FTP or network shares.
• Finding unmanaged devices by looking for certain vulnerabilities that are older than a time period such as 30 days.
• Finding which systems in DMZs and other protected networks connect to the Internet and/or accept connections from the Internet.
  
• Finding devices that do not have credentials to log in as an administrator. The Security Center tracks when Nessus can or can't successfully log into a Windows or UNIX host.
• Finding all systems that have certain software installed on them. Customers have used text filtering for the software name, and plugins #22869 and #20811 for UNIX or Windows software enumeration.
• Finding specific non-compliant servers. Customers pick some or all of the available configuration auditing results and then create a dynamic asset list against this list.
• Finding specific types of certain operating systems and network devices. A query for certain types of detected operating system is performed and lists are created for various operating systems.

In each of these cases, a customer performs a query for vulnerability names, system names, networks, IP addresses or open ports and then downloads the spread sheet.

Obtaining Log and System Events for Compliance and Security

For evidence collection, a wide variety of logs and events can also be collected in spread sheet form. Storing certain types of data in a spread sheet is sometimes more efficient than keeping the raw logs. Of course, raw logs should be maintained for legal purposes, but for summaries, investigations and reporting, spread sheets can be extremely useful. 

When managed by the Security Center, the Log Correlation Engine can be used to sort and list many different types of events. Common events which are relevant for compliance and security monitoring include:

• User creation events
• User deletion events
• Access of certain audited objects
• Password changes
• Detecting system and network change events
• Network and login events to show who is accessing key systems
• Times that certain types of activity is occurring
• Statistical deviation events
• Events related to compromise and botnet activity
• Never before seen events

Saving this data as an Excel spreadsheet can make it available to other users in your organization who don't easily read logs or make use of web consoles.

Visualizing Security, Compliance and Event Data

Tenable's 3D Tool makes use of data obtained through the Security Center's CSV exporting functions. An example topology image of a large network is shown below:

A video demonstration of the 3D Tool is available here.

Currently, Tenable's 3D Tool does not support visualization of IDS or Log data. However, several customers have used a variety of commercial and free tools (such as Many Eyes, AfterGlow, Miner3D and Advisor) that work with different types of data.

Typically, a customer will perform some sort of query, such as obtaining a list of all port 22 connections, and then save a raw list of each event as a spread sheet. When feed into a tool such as Miner3D (this was an evaluation copy, but I was really impressed with the flexibility of the tool) you can get very cool visualizations such as shown below:

These images above were obtained from a Log Correlation Engine running at a large university that was running the blacklist.tasl script. The site was scanned by a system tracked by the Dsheild list of known scanners. These images had the X and Y axises mapped to the detected source and destination IP addresses. The Z axis was time. The images show a few hosts making a sweep of the IP space at this location. Also, the target port is indicted in color.

Typically, these tools require an analyst to pick which columns in the spread sheet correspond with which axis of the plot. Source IP might be on one axis, time on another. Color could even be used in some tools to indicate port, protocol or type of event.

For More Information

To learn more about visualization of security data, I recommend visiting the AfterGlow web site  and to also take a look at the Security Visualization web site.

To learn more about what sorts of types of data you can obtain via spread sheet from the Security Center, I suggest requesting a copy of the Real Time Compliance paper. This paper summarizes the specific types of data which should be monitored and reported for as required or recommended by NIST, the PCI standard and many others.

If you are attempting to perform network security monitoring in a large, unmanaged environment that has "poor" security, you are most likely dealing with botnets, phishing attempts, worms and Trojans. Many of these threats install some sort of FTP, SSH or Web server as a backdoor or drop point on a port other than the typical default port. Discovering these on your network may help you find compromised servers, or even administrators who are trying to bypass firewall rules. This blog entry discusses how to find these "off port" services with the Passive Vulnerability Scanner (PVS), Nessus scanner and through log analysis.

Example Passive Detection with the PVS

The Passive Vulnerability Scanner has three built in rules which discover SSH not running on port 22, HTTP not running on port 80 and also FTP servers not running on port 21. The PVS also has many plugins which simply find and report these services regardless of the port that they are on. If a hacker, Trojan or malicious insider has compromised a system on your network and installed a server for their partners to visit and/or transfer files, the PVS will discover this.

To illustrate this concept, below is a screen shot of a port summary for all discovered FTP servers at a small university:

In the image, there are two ports found - 21 and 419. Port 21 is the TCP port assigned for use by the File Transfer Protocol and port 419 is the Ariel service used for printing. Ariel might not be familiar to readers, as it is a printing service which uses the File Transfer Protocol to move print jobs around.

The point of this port summary is that users should expect that their FTP servers normally run on port 21. If an FTP server turns up not on port 21, it should be investigated.

For web servers, the PVS has rules which can find services running on non-standard ports. Below is a screen shot of a port listing of all non-standard web servers found on an operational network:

In this listing, many of the discovered web servers are serving content and also using the HTTP protocol to participate in a variety of P2P networks. Web servers are embedded in many different types of network appliances and often run on ports other than 80. The PVS's largest advantage when looking for these off-port web services is to look for "new" services. In real-time, any of the PVS's vulnerabilities can be sent as an alert, including when a new non-port-80 web server is found.

And for the last example, the following passive discovery of a Secure Shell daemon running on an off-port (in this case port 8080) was discovered at one of Tenable's monitoring sites. Below is a screen shot of a port summary for all SSH vulnerabilities, as well as a banner listing of the SSH daemon on port 8080:

There are a few "port 0" vulnerabilities in the port listing because client-side vulnerabilities are reported with a source port of zero. Also, it is quite likely that port 8080 was chosen by an administrator to look like a commonly used off-port web server. Perhaps port 22 access was being blocked by a firewall, and port 8080 was chosen because it was allowed.

In each of these cases, the PVS also accurately reported on all discovered FTP, HTTP and SSH servers that were running on their correct ports. If there were 100 FTP servers detected and one of them were running on a port such as 2100, the PVS would still report 100 FTP servers and an addition record for the single off-port FTP server.

Scanning with Nessus

Nessus will also readily identify FTP, SSH and HTTP servers not running on their default ports. Unlike the PVS, a detected service event still has the default Nessus IDs. In other words, it will report an SSH server it discovered exactly the same way on port 22 as it will for one discovered on port 5100. With a tool like the Security Center, you can tell it to list all FTP servers and then ignore port 21. The Security Center can also take into account the results from active and passive scanning and automatically create dynamic asset lists with servers that have FTP ports not on port 21.

Below is a screen shot of an FTP server found on port 49152:

In this case, the discovered FTP server was being used to host content, such as movies or music. It was found by sorting on all vulnerabilities discovered from the FTP plugin family, conducting a port summary and then noticing that there were a handful of vulnerabilities on non-port-21 ports.

When performing vulnerability scanning, keep in mind that by default, Nessus doesn't scan all ports.

Analyzing activity with the Log Correlation Engine

If you've found a web server running on a port like 8000 or an FTP server running on 65000, you may be able to analyze the network traffic associated with it. If you have a Log Correlation Engine being fed logs from network monitoring, net-flow or firewalls, they will likely contain access and usage information which can be analyzed.

Simply typing in the IP address of the suspicious server and the port of interest can identify if many or a few remote users are accessing it. If suspicious activity is found, generalizing the search to look for any events may find a sequence of events that indicates a compromise. If the LCE is processing logs from intrusion detection systems, it may also have a record of the actual attack if one was used to compromise the server.

In the previous example with the PVS finding an SSH server on port 8080, we also had a Tenable Log Correlation Engine and a Tenable Network Monitor on that same network. This provides us with a log of every network session. Typing in the IP address of the system with the high port SSH server as well as port 8080 yielded the following information:

There have been several access attempts on port 8080 over the past few weeks. Further queries with the Security Center could yield a list of source IP addresses, determine when the port first went into use and could also determine if remote users achieved access to other system on the network.

For More Information

If this type of network analysis is interesting to the reader, these other Tenable blog entries will also likely be of interest:

• Passive Discovery of User Accounts
• Finding Interactive and Encrypted Network Sessions
• Hunting Symantec Worms
• Using New Port Browsing events to find Worm Outbreaks

This blog entry outlines a wide variety of audits and monitoring techniques that can be used to keep watch over the Secure Shell applications in use on your network. Examples for auditing SSH client and server configurations, vulnerabilities and logs will be discussed using Nessus, the Passive Vulnerability Scanner, the Security Center and the Log Correlation Engine.

This will be a three part blog entry where we will consider discovering the SSH applications, auditing their configurations and then monitoring their logs and network activity. This is part 1 of 3.

Discovering SSH Servers with Nessus Network Scans

Before any type of audit can be accomplished, an accurate inventory of all Secure Shell (SSH) servers should be preformed.

The Nessus vulnerability scanner can find SSH daemons running on many types of operating systems. When it finds an SSH daemon running, it will report several things.

Plugin #10881 "SSH protocol versions supported" will list the specific version of the Secure Shell protocol supported by the daemon with a report similar to the following:

The remote SSH daemon supports the following versions of the
SSH protocol :
. 1.33
. 1.5
. 1.99
. 2.0
SSHv1 host key fingerprint : c2:3f:77:2a:72:10:7d:7d:2a:49:8f:21:a4:d2:20:27
SSHv2 host key fingerprint : 1d:31:f3:6a:5b:c9:86:fa:93:ee:9c:d3:c9:c5:d2:10

This output also includes the SSH host key fingerprints of the daemon being scanned.

Plugin #10267 also identifies the detected SSH daemon and logs the specific SSH banner in use. It also audits which type of authentication methods are available as shown below:

SSH version : SSH-1.99-OpenSSH_3.6.1p2
SSH supported authentication : publickey,password,keyboard-interactive

Nessus will also attempt to enumerate any SSH daemon vulnerabilities that can be discovered through network analysis. There are many vulnerabilities associated with Secure Shell. At the time of writing this blog, searching for Nessus plugins that had the string "SSH" in them returned more than 100 unique plugins.

And lastly, Nessus will attempt to discover SSH servers regardless of which port they are on. Typically, SSH servers listen on port 22, but if a Nessus port scan or services probe is performed against non-standard ports, the SSH daemon will still be discovered. It has become common practice for administrators and/or hackers, to run an SSH daemon on a port other than 22 to "hide". Tenable has also encountered customers who have configured port forwarding firewalls such that connecting to a high port on the outside results in a network connection to port 22 on the inside to a certain server.

Using Credentialed Nessus Scans to Discover SSH Applications

If a credentialed patch audit of a host is also accomplished, Nessus will perform a patch audit of not only the SSH daemons, but any missing patches for SSH clients. There have been many client-side related vulnerabilities in SSH clients.

And lastly, if your credentialed scan occurs on Linux, the "Remote listeners enumeration" check, plugin #25221, will list all open ports and the name of the process which opened the network connection. This is another way to find SSH servers that may have been running on a a port other than 22, or were perhaps blocked by a firewall or ACL rule. 

Passive network monitoring with the PVS

The Passive Vulnerability Scanner can also observer Secure Shell connections. It accurately enumerates all SSH daemons and clients it observes in the network traffic. Here is an example listing of detected SSH applications and security issues from the "SSH (PVS)" plugin family as viewed under the Security Center:

Since the PVS sniffs network traffic it can see all ports. This makes it ideal to find SSH daemons running on ports other than 22. This also makes it ideal to identify security issues with SSH clients. In the above screen shot, there was a detect of a vulnerable "WinSCP" client. This detect was accomplished without any client side credentials of the Windows host running the WinSCP client.

Detecting Change

Once a baseline of known SSH servers and clients has been determined, it must be updated. There are two main ways to accomplish this - repeated Nessus scans and continuous PVS network monitoring.

For repeated Nessus network scans to look for new SSH servers, the Security Center can be used to schedule scans which discover new hosts, discover new SSH servers and also identify new SSH vulnerabilities. The Security Center can be set up to schedule these scans on a needed basis, and email and "new" results to asset system owners.

The PVS can also be used to find new SSH systems. Since the PVS is real-time, it can syslog any new type of SSH issue. The Security Center can be used to alert asset owners when new SSH servers are detected, or if new vulnerabilities have been discovered.

If more generic Nessus scans and PVS monitoring are ongoing, the Security Center can also manually be used to show "what is new". There is a filter in the Cumulative Vulnerability Database view which can specify a discovery filter. This parameter accepts a count of days such that all SSH vulnerabilities or audits discovered in the past 5 days could be displayed and analyzed.

For More Information

Part II of this post will consider auditing the configuration of SSH daemons and clients on UNIX systems. Part III will consider how netflow, firewall logs and other types of traffic can be used to audit SSH usage and abuse such as "leap frog" attacks.

We all receive and are annoyed by the amount of "SPAM" email in our in-box. One way to fight SPAM is to monitor large networks for evidence of compromised hosts that are being used to email out unwanted content. This blog entry shows how passive network analysis and log analysis can be used to look for specific types of events that can indicate SPAM originating from inside your network.

Watch for Changes in the number of Email "Clients"

The Passive Vulnerability Scanner (PVS) detects which hosts connect on port 25 (SMTP) and which hosts have email servers on port 25. Using the Security Center and the PVS, any organization can quickly obtain a list of all systems which connect to port 25 on the Internet and use email clients. By tracking the total number of email clients in use on a network, an organization can observe when there are large changes in this population.

For example, in the screen shot below, we've asked the Security Center to graph the number of unique hosts that communicate on port 25 (SMTP) over the past 90 days.

This graph shows that there have been many more SMTP clients in operation in the last month than has previously been in effect. This could be a zombie botnet making more SMTP connections than before. This could also mean that more users are sending email from more locations. This may also correspond to changes in DHCP lease policies where the same user population is making use of more IP addresses than before. The point is to look for a change, and then perform the investigation to see what has caused it.

Asset Based Behavior Analysis

Another method to search for internal SPAM sources is to look for systems sending email that shouldn't be sending email. For example, your web server most likely isn't your email system and it probably doesn't even have an email client installed on it.

Combining the Security Center's ability to classify network nodes into one or more "asset" groups and the PVS's ability to report which hosts have email clients on them can provide a list of which assets have email clients. Consider this example chart produced by the Security Center below:

In this list, it is understandable that there are no email clients on the "DNS Servers" or that there is one email client in the "POP Servers" list of assets. However, many of the other asset groups such as "FTP Servers", "SSH Servers" and "HTTP Servers" have multiple detected email clients.  Being able to drill into these asset lists and see which specific hosts are sending email can identify if a server has been compromised and is part of a botnet. It can also be used to see if a "server" resource is being used as a desktop system which may also violate corporate policy.

Log Correlation Engine Analysis

If the Log Correlation Engine is in use and receiving netflow, network sessions or firewall logs, performing some analysis on port 25 traffic can also be very enlightening. For example, in a corporate environment where all outbound email is authenticated and goes through a well known email server, listing outbound "Firewall Deny" events for port 25 can identify host trying to connect directly to the Internet. These may just be normal users trying to send mail to a non-corporate mail account, but this can also be an indicator of SPAM.

Below is an example screen shot of all port 25 traffic over the past 7 days at a large enterprise network:

Notice the dramatic increase in email connections observed towards the right side of the graph.

The LCE also has the ability to use Black Lists of IP addresses that are well known SPAM providers. The current blacklist.tasl script uses a publicly available list of well known SPAMing sites for correlated activity.

Detecting "The Bat!"

The PVS also has rules to detect the specific email clients in use by each end node. It performs this analysis to discover if there are any vulnerabilities associated with the email client in use. One of the email clients we look for is a client known as "The Bat!" which can be used for mass mailing.

Below is a screen shot of a listing of all client side email vulnerabilities discovered on a medium sized network, including two detects of "The Bat!" email client:

To analyze this further, choosing this vulnerability and then performing an asset summary could tell us which organizations or resources (such as one of our HTTP servers as compared to an office laptop) were using this potentially unwanted email client.

SOCKS4 and SOCKS5 Proxies

There have been several cases of malware which seeks out local SOCKS4 or SOCKS5 proxies in order to connect to the network. Both Nessus and the Passive Vulnerability Scanner can be used to detect these types of proxies. The PVS passively identifies SOCKS4 and SOCKS5 proxies and can look inside these protocols to see if there are any botnet command and control messages being passed.

For More Information

If you would like to learn more about the capabilities of the Passive Vulnerability Scanner, Log Correlation Engine and Security Center, consider watching one of the many demonstration videos available at the Tenable Network Security web site.

Over the past few years, there have been several vulnerabilities disclosed about the Snort network intrusion detection sensor. I recently had a Tenable customer inquire for a strategy of "scanning" to find these Snort systems. This blog discusses some basic and more advanced ideas and issues on how to approach this with Nessus and the Passive Vulnerability Scanner.

Network Scanning of Passive Listening Devices

Solutions like Snort sniff packets on a network interface for evidence of network abuse and log this data to SYSLOG, a local file or some sort of log agent.

Typically, there are no daemons or open ports that can be probed or fingerprinted which indicate that Snort is indeed installed. In many cases, best practice for running a network IDS also recommends that the monitoring interface not even have an IP address.

There have been tools and research in the past used to identify devices that are sniffing, but these don't specifically identify Snort. A good example of this is the AntiSniff tool written and released by the L0pht.

Using Credentials to Find Managed Snort Packages

If Snort is included or supported with your OS distribution, Nessus may likely have some client side checks to look for these security issues. At nessus.org, using the plugin search interface, there were eight different UNIX patch audits concerning Snort as shown below:

There are a few issues with looking for Snort this way though:

• Many Snort users obtain distributions directly from snort.org and not the operating system provider
• Some Snort users hand compile their distributions
• Relying on the patch from an operating system vendor might take longer than getting it directly from Snort.org.

Scanning for Snort Files

Nessus Direct Feed customers can look for evidence of Snort installations on UNIX systems with the following .audit file:

<check_type: "Unix">
<custom_item>
type: PROCESS_CHECK
  description: "Check snort process status" 
  name: "snort"
  status: OFF
</custom_item>
</check_type>

This audit simply checks if the 'snort' process is running and reports a failure if it is detected. This scan requires SSH credentials to perform the audit.

Passive Network Monitoring

The Passive Vulnerability Scanner can detect systems that send SYSLOG messages which contain "snort" logs. If your organization uses SYSLOG to send logs from your Snort sensors to a central location, PVS rule #3986 will identify those systems. The rule will also match a secondary log server which is forwarding log which contain Snort events as well.

In order to see these logs, the PVS would need to observe the SYSLOG traffic. If your PVS was on the perimeter of your network and your Snort sensors were further inside and logging to an internal host, it would not be able to observe the traffic.

For More Information

If running Snort alongside Tenable products is interesting to you, please consider these other blog entries:

• Vulnerability Based Snort IDS Management - Use the vulnerabilities found by Nessus and the PVS to manage the active rules on your Snort sensors.
• Automated audit policy creation for UNIX Nessus compliance checks - Discusses how to use the current settings in your configuration files to build a baseline template. Uses the snort.conf file as an example.
• Good and Bad Uses of Vulnerability Data for IDS Correlation - Discusses some of the nuances of correlating IDS events with vulnerabilities.

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

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

Most readers should be familiar with the concept of "Microsoft Tuesday" as the day when Microsoft, and many other OS vendors, release security patch information. These releases occur on a regular basis. Because of this, we've had many Tenable customers configure their Security Center to automatically update Nessus and Passive Vulnerability Scanner plugins, perform a scan and then email a report on the following Wednesday. This blog post discusses how this is accomplished.

Research of Vulnerabilities

Tenable's research team publishes all new plugins to this RSS feed. This information is publicly available to anyone. Anytime we release a remote check or patch audit, it shows up there. Patch audits are usually the first (and easiest) plugins to produce, and then more complex remote "service" audits come next. Checks that can be accomplished purely through sniffing are also produced for the Passive Vulnerability Scanner (PVS) which also has it's own RSS feed of new plugins as well. Typically, within the first 12 hours of major bug releases, the checks will be available for Nessus Direct Feed subscribers, and Security Center and PVS users.

Automatic Monitoring with the Security Center

If your Security Center is updating the Nessus and PVS plugins on a nightly basis, than scheduling a scan for early "Wednesday Morning" can give you very good insight as to how open your network is to the immediate vulnerabilities. If the PVS is also deploiyed on the network, then it will also alert to new vulnerabilities without the need for a scan.

Scans can automatically be scheduled to perform patch audits of certain types of network assets such as all of the domain controllers, all of the mail servers, all of the server farm and so on. The Security Center manages the updating of each Nessus scanner as well as the credentials required for a full audit of each asset. Security Center users accomplish this with a "vulnerability policy" and a "scan policy".

The vulnerability policy specifies what you want to scan for. This includes scan configuration settings, such as credentials and target ports, as well as which Nessus plugins (by family or individual plugins). Since the Security Center uses the Nessus Direct Feed for its source of plugins, you can also create a vulnerability policy that makes use of the most recent plugins in each family. For example, you could create a policy to scan for just "Windows Patches" and only those, including the latest patch audits, would be executed.

Scanning polices can be very simple or quite sophisticated. For example, a scanning policy could launch a credentialed scan against the "Windows Servers" everyday at 5:00 AM. Scans can also occur at specific days of the week, weekends, certain days of the month and so on. Scans can also be chained together such that the results of the first scan can be used to update a dynamic asset list which is scanned by the second scan. Scan policies can also select which Nessus scanners (or groups of scanners we call "zones") perform the audit.

If the PVS is deployed on the network, the Security Center will update those sensor with the latest vulnerability plugins. No policies, scan schedules or credentials are required to configure the PVS. It just montiors the network and accurately reports client and server side vulnerabilities to the Security Center.

Automatic Reporting

For active Nessus scans, each scan policy also has the option to generate an email of any vulnerabilities found, or just "new" pieces of information. When these scans occur immediately after a "Microsoft Tuesday", they will identify all of the systems which have the "brand new" missing security patches.

The Security Center can also automatically create a scheduled PDF report of vulnerabilities which can be emailed to you. This report is generated from the Security Center's "cumulative" vulnerability database. This database includes any passively discovered vulnerabilities from the PVS. 

A very useful part of the cumulative database is the filtering of vulnerabilities based on when they were "first seen". A "Tenable Wednesday" report could easily be limited to all vulnerabilities that have been discovered within the past day. This is a very convenient way to automatically report on all "new vulnerabilities" identified by multiple Nessus scans and PVS monitoring.

For some customers who do not scan that often, but use the PVS, the passively discovered vulnerabilities are their first indication that there may be new security issues. 

Conclusion

Reporting on the most recent vulnerability information available is a method of finding out the "bad news" as quickly as possible. This is a completely different process than our previous blog post, which suggested reporting about vulnerabilities based on classes of systems that were managed or un-managed.  The intent of scanning for the latest and greatest vulnerabilities should be to discover any critical security issues that will impact your business in the short term.

We've blogged in the past about how the Security Center can use any data obtained by Nessus or the Passive Vulnerability Scanner to automatically classify a host into one or more political or technical asset lists. Information gathered by the 13,000+ Nessus scanning, patch auditing and compliance checks and the 3000+ Passive Vulnerability Scanner plugins can be used to automatically find and categorize your networks and systems by Windows domain, installed software, location on the network and so on.

With the recent introduction of the "Computer Manufacturer Information" Nessus check (plugin ID #24270), it is now possible to use this information to classify your Windows assets based on hardware manufacturer information. This blog entry shows what sort of data can be obtained by this plugin and how it can be used to create lists of existing Dells, HPs and ThinkPads, as well as existing portable, tower, rack mount and other types of systems.

Computer Manufacturer Information Example

Plugin #24270 can query the remote Windows device and ask it which manufacturer made it, the model of the unit and what sort of type it is. Let's look at two examples:

Computer Manufacturer : Dell Inc.
Computer Model : Latitude D820
Computer Type : Portable

Computer Manufacturer : Dell Computer Corporation
Computer Model : Dimension 8200
Computer Type : Mini Tower

This text comes from two scans against a laptop and an older tower. The plugin provides information on the manufacturer and the specific vendor computer model. Both of these values are controlled by the manufacturer.

The type indicates the physical form factor of the device and can have the following values:

• All in One
• Bus Expansion Chassis
• Desktop
• Docking Station
• Expansion Chassis
• Hand Held
• Laptop
• Low Profile Desktop
• Lunch Box
• Main System Chassis
• Mini Tower
• Notebook
• Other
• Peripheral Chassis
• Pizza Box
• Portable
• Rack Mount Chassis
• Sealed-Case PC
• Space-Saving
• Storage Chassis
• SubChassis
• Sub Notebook
• Tower
• Unknown

Asset Classification

The Security Center can make use of the output from this plugin and automatically create dynamic asset lists based on the manufacturer or type. Below is a screen shot of a basic rule that matches the word "Dell" as a manufacturer:

Each time Nessus performs a scan of this plugin, with the above dynamic asset rule, the Security Center will automatically create a list of all "Dell" computers.

Any of the information in this plugin can be used to create a dynamic asset list.  With this plugin and Security Center,  it is very trivial to scan a network with credentials and create lists for many different items such as unique manufacturers, unique device types and specific deployed models .

Security, Compliance and IT Management Implications

Being able to categorize assets based on manufacturer, model and type can have a variety of implications for IT monitoring. These include:

• Discovering manufacturers which have been purchased against corporate acquisition policies. For example, you might be an "HP" shop. If so, why are there a few "Dell" laptops in the network?
• Remotely identifying if a device is a mobile device or not. Laptops, hand-helds and even mini-towers can be easily moved. Being able to determine what a device actually is without physically touching it is very valuable.
• Having the ability to identify just the models from a specific IT purchase or from a recent merger/acquisition is also extremely useful. Occasionally, a computer vendor will ship computer units with different default Windows settings, different BIOS settings, hardware that requires replacing and so on.
• Rapid counting of assets. Being able to scan with Security Center or Nessus and then quickly report on the number of unique manufacturers, number of laptops, specific model counts is very valuable to IT.

For More Information

Tenable has released this plugin under the Nessus Registered Feed. It is released for Nessus 3 as a .nbin file and makes use of Tenable's implementation of agentless WMI technology. Users who wish to write their own WMI queries for Nessus should consider the current Nessus 3.2 BETA which supports a library for rapid development and testing.

With the advent of the current Solaris Telnet Worm, Tenable has had many requests and comments about not only finding the specific associated vulnerability, but how to monitor Telnet in general. This blog entry discusses the worm, how to scan for the Solaris 10 in.telnetd vulnerability and how to monitor your network for Telnet activity.

Scanning for the Solaris in.telnetd Vulnerability

Tenable has released three checks to discover this vulnerability on Solaris systems:

• Plugin #24323 Solaris 10 Telnet Authentication Bypass
• Plugin #24343 Solaris 10 (sparc) : 120068-02
• Plugin #24342 Solaris 10 (i386) : 120069-02

Like most of Nessus's active scans, plugin #24323 confirms the presence of the vulnerability by actually attempting to interact with it. In this case, the NASL script tries to obtain the /etc/passwd file. Plugins #23434 and #24342 are both patch audits which require SSH credentials to audit the presence of the related missing patch to secure in.telnetd.

Looking for Telnet Worm Compromised Hosts

There are several techniques available to look for any evidence of Solaris systems on your network that have been compromised by this worm.

A simple way would be to use a Nessus scan and the "Trojan horses" plugin (Nessus ID #11157). This plugin was recently updated with a common back door port associated with the Telnet worm. To effectively use this, make sure you either perform a full port scan or at least target TCP port 32982.

Using the Security Center, a dynamic asset list can be created of all Solaris devices based on either a TCP/IP OS fingerprint with Nessus, passive TCP/IP fingerprint with the Passive Vulnerability Scanner (PVS) or even based on known SSH keys. Once the list of "all Solaris" servers is known, several things can be accomplished:

• If a PVS is configured to detect outbound port scans or a source of networks IDS events is available, any Solaris assets performing port scans could be infected with the worm.
• If any of the Log Correlation Engine's NBAD TASL scripts are enabled, such as the Shell Proxy or Suspicious Shell Proxy scripts, these will fire when there is an inbound connection quickly followed by an outbound connection. Considering these events for just your "Solaris" assets is also a useful filter. Like many worms, this Telnet worm makes many connections.
  
• The Security Center can correlate attacks from many different network IDS devices with the vulnerabilities scanned for by Nessus. This includes the Solaris 10 Telnet vulnerability. Security Center customers had automatic coverage for this correlation with Snort VRT, Bleeding Snort, Tipping Point and many other NIDS.
• If an attack has compromised a Solaris device they will undoubtedly create new logs. The LCE has a TASL script named "Never Before Seen" which highlights new log events that haven't occurred before. It is very likely that an attacker will generate firewall logs, host logs or event IDS logs that have not been seen yet. Filtering these alerts for just the Solaris assets also can give a sense of how much is really "new" in the system logs.
• CERT advisory TA07-059A mentions several files and directories that are commonly created by users and worms that compromise Solaris systems. Nessus scanners subscribed to the Direct Feed or managed by the Security Center can perform an audit of the Solaris hosts to see if these files exist with permissions indicative of a hacker or worm.

One last example is a combination of the PVS's ability to generate alerts when it sees new activity, specifically a system that begins to browse on a new port for the first time. These events can be sent to the LCE and trended. Here is an image of new port browsing events for port 23 at a small university:

Each of these events indicates a single host that has never been previously observed to send any network traffic on port 23. This activity started a few weeks ago and is indicative of a worm. The graph clearly shows that hosts that have never ever browsed on port 23 started to about a week ago. We've previously blogged about using this technique to find evidence of Symantec worms.

Auditing Telnet Use In General

There are many techniques an enterprise can use to audit protocol or application usage. For Telnet, Tenable offers many different ways to perform one time audits or continuous monitoring.

• Nessus Scanning Simply scanning a local network and finding all of the Telnet daemons that are open can highlight where these hosts are at.
• Distributed Scanning If multiple Nessus scanners are being managed by the Security Center, a scanner on the "outside" of a network can be tasked to scan for open Telnet servers. By scanning from the outside on a regular basis, the entire security posture of firewalls, screening routers and the systems potentially running Telnet can be routinely monitored.
• Passive Scanning If a PVS is in use, then it will automatically log not only which servers are running Telnet servers, but which ones use Telnet clients to reach other servers. If the PVS is deployed at a network boundary, then this can also indicate Telnet activity in and outside of your network.
• Host Configuration Assessment If the Security Center or a Nessus Direct Feed is in use, UNIX configuration files and running processes can be checked. This can ensure that TCP Wrappers is/isn't installed and that the Telnet service is/isn't running.

Conclusion

Telnet on Solaris 10 is the current worm of interest, but many of the concepts discussed here can be applied for day-to-day monitoring of your network. Tenable products are very useful for looking for the needle in the haystack when you know what to look for, but they also can shed a lot of light on network activity before they become public knowledge.

The User Datagram Protocol (UDP) transfers data much differently than the Transmission Control Protocol (TCP). Services that run on UDP can make use of the client and server model that TCP uses, but it can also transfer data without an established connection and send data to multiple computers with a single packet. This blog entry discusses UDP port scanning, active services enumeration and passive network monitoring to identify UDP services and vulnerabilities.

Probing for "open" UDP Ports

A very common question that Nessus users ask of Tenable is why there isn't a UDP port scanner option for Nessus. The short answer is that Nessus performs UDP service enumeration for 1000s of different applications but doesn't perform generic UDP port scans.

There is nothing technically wrong with performing a UDP scan, but on most networks, there is a very good opportunity to report open UDP ports incorrectly.

Probing for UDP ports consists of sending a UDP packet to each port and then either waiting for no response, potentially a UDP packet response or an ICMP (Internet Control Message Protocol) "port closed" message. If no response is received the scanner can conclude that the port is open. If an ICMP "port unreachable" message is received, the scanner can conclude the port is closed.

There are several potential false positives and false negatives that can occur here:

For many networks, when performing scans of many ports on many systems at the same time, the actual probing packet might not make it to the target host due to network congestion. Since no response is received, the scanner might conclude the port is open. If no response is received, it might consider trying again, but this could also cause more packets to be used in the probe and cause a different probe packet to not reach it's target. A slang term for the "U" in "UDP" is unreliable.  Any router or switch along the way can drop the packet if it gets too busy.

Also compounding the issue, firewall rules between the scanner and the target might explicitly deny outbound ICMP messages. For UDP packets that make their way to a closed port and have the system respond with an ICMP port unreachable message, this packet might be dropped at the egress firewall or router. Since this ICMP message isn't received, the scanner may incorrectly assume that all is good and the UDP port is indeed open.

ICMP packets may also not be sent from a host because modern TCP/IP stacks have implemented rate limiting. Although responding to a UDP probe with an ICMP port unreachable packet may be the "right thing to do", if the number of ICMP packets being sent exceeds a rate limit, they won't be sent at all. This will cause the scanner to think the UDP port is indeed open.

UDP Application Enumeration with Nessus

Nessus discovers open UDP ports by simultaneously identifying the actual application using the port. It performs this by sending specific application probes for UDP protocols (such as SNMP or DNS) and then waiting for the correct application response. This is very accurate and leaves little ambiguity if a particular UDP application is reachable or not.

Nessus does not do service fingerprinting on UDP protocols.  In other words, when probing UDP port 53, we don't send in a SQL query, DNS query and then SNMP and wait for a response.  The majority of UDP services only reply to a well written query .

For UNIX systems being scanned by Nessus with credentials, the "netstat -an" command can be used to enumerate all open ports, including UDP ports.

Nessus also learns about UDP services through queries to the SunRPC and MSRPC portmappers. Each of these protocols provides very accurate listings of both UDP and TCP services and the processes that are listening on their ports.

UDP Service Enumeration with the Passive Vulnerability Scanner

Another interesting way of identifying UDP client and server applicants in use is to simply sniff the network traffic. Tenable's Passive Vulnerability Scanner identifies a wide variety of UDP based protocols and associated vulnerabilities in both the clients and servers. This has no impact on the network and is extremely accurate.

Tenable often receives requests for advice and strategies to help very large organizations decrease their scanning time. Readers should keep in mind that from Tenable's point of view, a "large" organization is someone with multiple Class B networks and more than 1 million items reported by Nessus. A basic concept to keep in mind when modifying how scans run is that there is a balance between scanning speed, thoroughness and invasiveness. For example, one may simply be able to decrease scan speed times by decreasing the number of tests performed. The scan happens faster but is not as thorough. This blog entry details some strategies that can help decrease scanning times with Nessus for very large networks. 

Distributed Scanning

Load balancing multiple Nessus 3 scanners can also speed up your scan times. We've blogged about this before, but don't want organizations to forget to take advantage of this. 

Tenable regularly deals with large organizations that deploy 10, 20 or even 30 scanners to scan millions of IP addresses. They manage these scanners with the Security Center.

Don't do Full Port Scans

There is nothing technically wrong with performing a full port scan, except that the laws of physics must be observed. For any network, there will be a maximum number of simultaneous ports and hosts that can be probed. Choke points can come from network devices such as firewalls, low bandwidth links or even the performance of the systems being scanned.

From a "realtive work" perspective, there are 65535 ports that can be targeted whereas there are less than 15,000 Nessus plugins. Most of those plugins don't even run because Nessus efficiently disables plugins that aren't relevant for the system being scanned. This means that for full port scans, it will take much longer to find the open ports than to perform the vulnerability audit.

Also, for enterprise scans, the default port range used by Nessus is typically "good enough" for finding most of your open ports. Tenable's experience with large customers has shown that full port scans do find a few more open ports than the default ports targeted by Nessus, but the amount of extra time involved performing these scans is beyond the point of diminishing returns.

If looking for all open ports is a corporate requirement, consider deploying more Nessus 3 scanners closer to their target networks. Also consider deploying Passive Vulnerability Scanners which find open ports (as well as browsed ports, Internet browsing devices and internal trust relationships) in real-time.

Disable Slower Scan Options

Two parameters for Nessus scans that can dramatically impact  performance are to disable both the "CGI Abuses" and "CGI ABuses : XSS" families and to also disabled "Thorough Tests".

With the 1000s of CGI and XSS (Cross Site Scripting) vulnerabilities disclosed to date, testing for all of them on every discovered web server might not be the most efficient course of action for a large scan. If these families are enabled, for every web server discovered, Nessus will probe for each potential CGI application installed. Since many devices ship with embedded web servers, disabling these families can let you concentrate full scans on just the authorized web servers for your organization. Nessus clients also have a scan policy setting named "Disable CGI scanning" which prevents all things related to CGI probing.

Also, the "Thorough Tests" scanning parameter causes various NASL scripts to "work harder". For example,  when looking through SMB file shares, a NASL might choose to look 3 levels deep instead of 1. This could cause much more network traffic and analysis if the target host has more shares. By default, all Security Center scans have "Thorough Tests" disabled.

Don't scan Dead Space

Another way to scan large amounts of address space is to try and ignore the hosts that are not there. Scanning "dead space" slows down scans because no matter how much CPU or network bandwidth you have access to, Nessus will wait a fixed amount of time to decide that a host isn't there. Of course the caveat is that if you think an IP address isn't occupied, you'll never know it unless you watch for network traffic from it or try to scan it occasionally. Some strategies to only scan an accurate list of active hosts include:

• The Security Center can be used to create a dynamic asset list of all available hosts and then a chained scan can be used to scan just hosts of a certain type, a certain age, a certain OS or many other parameters.
• If one or more Passive Vulnerability Scanners are in place, the information from these hosts can be used to identify active hosts in a dynamic asset list, and then targeted with an active scan.
• If you have access to some sort of asset tracking system, or can query your switching infrastructure for a list of active IP addresses, these can be fed into a Nessus scan or a Security Center static asset list.

If you can place your Nessus 3 scanners closer to the collision domain of a target network, an Ethernet ping will be performed. This is much faster than an ICMP ping and will decrease the amount of time waiting for hosts to reply that are not there.

Look for Choke Points

Another type of analysis that can be performed is to consider the actual network being scanned. There may be choke points that slow down a scan. Here are some ideas to consider and research for your local network:

Are all scans going through the same switch, switching infrastructure, vlan or router? Asking your network engineering folks about network performance during a scan could be enlightening.

Are there security devices or gateways that are operating at capacity during the scan? For example, consider the performance of firewalls, proxy devices, and wireless gateways during the scan.

Consider the "Information about the scan" Plugin

Nessus plugin ID #19506 records the results of the scan, including the amount of time it takes to complete the scan. Below is a screen shot of an example result under the Security Center:

In this case, the host was fully scanned in 10 seconds. However, what if we want to create dynamic asset lists based on the amount of time it takes to complete a scan of a host? This would allow us to use the Security Center's powerful reporting,, sorting, filtering and analysis capabilities to identify which class systems is taking to long.

To do this, we'd need to create some dynamic asset lists and use some regular expressions to identify hosts with "long" scan times. For a quick review of some dynamic asset list creation examples, consider this previous blog entry.

For each of these dynamic asset rules, we will tag it to plugin ID #19506. In each of these examples we will tag the text string "Scan duration : 10 sec" and uses regular expression to look for times other than "10".

Here are some example "text strings" you can drop directly into a Security Center regular expression dynamic asset rule:

• 30 Seconds or more
  19506:Scan duration : ([3-9][0-9])|([0-9]{3}) sec
  This will match scan times larger than 29 seconds.
• 60 Seconds or more
  19506:Scan duration : ([6-9][0-9])|([0-9]{3}) sec
  This will match scan times larger than 59 seconds.
• 100 Seconds or more
  19506:Scan duration : [0-9]{3} sec
  This will match scan times from 100 seconds to 999 seconds.
• 200 Seconds or more
  19506:Scan duration : ([2-9][0-9][0-9]) sec
  This will match scan times from 200 seconds to 999 seconds.
• 300 Seconds or more
  19506:Scan duration : ([3-9][0-9][0-9]) sec
  This will match scan times from 300 second to 999 seconds.

For performance, the 100, 200 and 300 regular expression rules are more efficient than the 30 and 60 second rules.

To add these to your Security Center, add a new Dynamic Asset List. Then add a "pluginid" match filter for 19506. Then add a "plugintext" regex filter for one of the patterns in italics shown above.

In the screen shot below, an asset list named "Long Scan Time" was created with the "30 Seconds or more" example above. We can see that the scan time of this host 37 seconds. On our demo network, this also matched hosts with scan times of 407 seconds, 58 seconds and 39 seconds.

So what sort of analysis can you perform with this type of approach? Consider the following techniques:

• Are these systems all part of the same network or subnet? This could indicate some sort of choke point.
• Do these systems all have something in common that "faster" hosts don't have? Consider things like CPU, memory, and system firewalls. Also consider things like actual applications. It might make sense that the IIS web servers take longer to scan than a Windows 2003 file server.
• Is there a set of vulnerabilities or open ports common to these assets? 

This type of analysis is ideally suited for the Security Center 3D tool. Performing a query for a target network and then a second query for the hosts that have long scan times will allow you to visually compare the open ports and vulnerabilities present such as in this screen shot below:

Summary

Although this blog entry focused on some advanced things to consider for your network scans, don't forget the basics. Make sure your Nessus scanners have enough horsepower (watch their CPU usage during a scan) and enough network bandwidth.

Also, most organizations have upgraded to Nessus 3. If you are still using Nessus 2, consider doing an upgrade as version 3 is much faster than 2. Tenable has produced a comprehensive comparison between Nessus 2 and Nessus 3 scanning speed.

And lastly, Security Center users with multiple Nessus scanners should not run their scanner directly on the Security Center. Generally, you can scan with Nessus from the Security Center, but the performance impact is unacceptable for large scans. If you don't mind the impact to Security Center, your scans will still complete faster by utilizing the CPUs on the Security Center system.

Tenable customers also have access to the support knowledge base which includes other best practices for configuring scans. If you have tips on optimizing your Nessus scan results, please feel free to send them to Tenable or post them to the Nessus mailing list.

If you are not part of the IT group, you may have to ask someone for the right credentials to perform patch and configuration audits with Nessus. This blog entry will offer some advice and strategies to consider when attempting to obtain access to the devices for auditing.

Who Doesn't Have Credentials?

If your organization has mandated security audits, they may have also mandated that credentials be provided to the group performing network scans. If your group is like this, then this blog entry isn't for you. However, you should realize that there are still many organizations where the "audit" group doesn't have full access to the devices they are scanning.

Benefits for IT from Credentialed Scanning

Credentialed audits can show a variety of "good" news about an IT group.

If systems are being patched on a regular basis, then a patch audit won't find many problems. This can show IT management an independent confirmation of how their network is being operated.

When missing patches are found, they are 100% accurate and actionable. This is not to say that a network scan isn't accurate (Tenable shoots for 100% accuracy), but Nessus network scans don't immediately tell you which patch to apply. A vulnerable version of Apache could have any number of potential fixes, but with credentials, the exact missing security patch(es) can be discovered. This is also more efficient to task an IT administrator with. Rather than saying "upgrade Apache" which is ambiguous, someone can say "apply patch #4637".

Credentialed scans can identify and list all of the UNIX and Windows software that has been installed. If you are viewing the data in the Security Center, then the results can be searched or even used to create dynamic asset lists of systems that have certain types of software installed. We've recently blogged about this concept.

And finally, if you are managing your Nessus scanners with the Security Center or subscribed to the Direct Feed, a configuration audit can be performed. If an IT group is managing all of their system configurations centrally, then these audits should independently show consistency and conformity to a global policy. Even if no strict corporate configuration polices are enforced, auditing systems against various government standards for passing and failing settings can also highlight where an IT organization has performed well.

Know What To Ask For

For Windows audits, asking for full domain administrator rights does give Nessus enough credentials to perform its audits, but this sort of request can be unfathomable to an IT group. Instead, Tenable recommends two strategies.

First, consider asking for access to the "backup" account. This account likely has access to read both files and system settings. Second, consider asking for a specific "audit" account be created with similar read-only access. A dedicated "audit" account has the advantage of showing up in the logs and instantly being recognized by everyone in IT as a potentially approved activity.

For UNIX, Nessus supports SSH passwords and public/private keys. For patch auditing, root access is recommended but not mandatory. Be aware the some more secure UNIXes (such as Trusted Solaris) may require root to obtain a package list.

For UNIX configuration auditing, keep in mind that appropriate access is required. For example, a file owned by root might only be "readable" by a root user or someone in the "wheel" group.

Sharing Data With IT

If you do have access to IT and perform scans, sharing the data, or even making sense of it, can be difficult.

Some organizations let IT perform their own scans, and this is great from a "self test" perspective, but self audits are not reliable and should be performed by a 3rd party not involved in the day-to-day operation of the network.

If an audit group performs ad-hoc scans on a set schedule of keys assets and shares the results with asset owners, the right data can be sent to the right people in a timely manner. There is overhead through tracking the need for performing re-scans, tracking which systems should be scanned and even which people in IT have the right to see or review the data.

Tenable offers the Security Center which can be used to centralize scanning, scan results, analyzing the data and tracking which systems need to be re-scanned. Only the specific users of certain IT assets can see the results for those assets. The Security Center can also offer IDS event viewing and log analysis to the same IT users.

If you can't get Credentials

If you are faced with performing network audits without access to system credentials, what are you facing? Several things:

There will be less information on specific client-side (such as Internet Explorer and Mozilla) vulnerabilities. Some clients (such as iTunes) do have network services that Nessus can discover and reliably identify.

The vulnerabilities found will be very accurate, but sometimes very generic. As in the Apache example discussed above, knowing a vulnerability and knowing a patch are two different things. Typically, Nessus network scans can tell you that an upgrade is required, but not the specific patches that are missing. One exception to this rule is while scanning Windows network services. Very often, Nessus will be able to determine the exact patch required, even without credentials.

If things haven't been locked down, don't be surprised if your Nessus scan reports some patch audits. If you have an Admin account on Windows that is not password protected, or similarly with a Guest account, Nessus may be able to use those credentials when performing a scan.

If the audit group does have access to part of the domain with (such as a regular user's username and password), this type of account may be enough to audit other Windows systems on the domain. It all depends on how locked down the network it.

Lastly, if credentials are not available, consider deploying the Passive Vulnerability Scanner alongside your Nessus scanners. This sniffer can find many client and server side vulnerabilities without any scanning at all. It also integrates seamlessly with the Security Center for centralizing active, passive and credentialed vulnerability and configuration data into one spot. If data obtained passively is contrary to what IT is claiming (i.e., they may claim that all web browsers are patched, but sniffing clearly shows older versions of Mozilla) this may also be enough evidence to convince management to allow auditing with full credentials.

For More Information

If performing credentialed audits with Nessus is a new concept for you, a good place to start is the  Nessus Credentialed Checks for UNIX and Windows paper.  To help understand the advantages and limitations of active scanning, credentialed scanning and passive network monitoring, please read the Blended Security Assessments paper.

Many Tenable customers and Nessus users have asked us for recommended strategies to discover where sensitive information is placed on the network. Often, organizations have segregated networks to separate sensitive data and want to verify compliance with the corporate policy. This is particularly important for organizations subject to legislation such as Sarbannes-Oxley or HIPAA. This blog entry describes some scenarios and strategies for finding sensitive data using Nessus, the Passive Vulnerability Scanner and the Security Center.

Searching for "Office" Documents on Web Servers

Plugin #11419 will search web servers for any documents with the following extensions:

.doc .wri .xls .ppt .csv .rtf .pdf

as well as less common:

.dif (another spreadsheet extension)
.sxw (Open Office Writer)
.sxi (Open Office Presentation)
.sxc (Open Office Spreadsheet)
.sdw (StarWriter)
.sdd (StarImpress)
.sdc (StarCalc)

This plugin is dependent upon the Web Mirror plugin (#10662). This NASL creates a mirror of all files on the remote server. Plugin #11419 then searches the Nessus knowledge base for files which have the above extensions. Mirroring a web server could take longer than your average scan due to bandwidth, size of the web server or even the performance of the web server.

Also, the Web Mirror plugin will follow links on default web pages and try to enumerate common web directories, but it won't find a specific file just being served on a web server. It needs to see a link to the file. For this demo, I placed an example.ppt file in the root directory of an Apache web server. The scans didn't find it until I either turned on directory indexing, or created an index.html file which references the example.ppt file.

Here is an example record of plugin #11419 as viewed under the Security Center:

The presence of one of these files by itself doesn't necessarily mean that your internal records are exposed to the Internet. All this means is that you have found a web server which is hosting a file with an extension that may indicate an "office" document that isn't protected by a password. Tenable has many customers which publish "official but unsensitive" documents as spreadsheets, Word documents or event Adobe PDFs.

Searching for "Office" Documents in Network Shares

Nessus plugin #23974 scans systems for SMB shares which contain the following list of "office" related files:

.doc .wri .xls .ppt .csv .rtf .pdf

as well as less common:

.dif (another spreadsheet extension)
.sxw (Open Office Writer)
.sxi (Open Office Presentation)
.sxc (Open Office Spreadsheet)
.sdw (StarWriter)
.sdd (StarImpress)
.sdc (StarCalc)

Access to the shares is based on the credentials of the scan. Documents identified with this plugin may or may not contain sensitive information. The purpose of the plugin is to simply try to find all of the systems (laptops, servers, SANs, portable NAS devices, .etc) which have files that might need to be secured.

Using Security Center Dynamic Asset lists

The Security Center can be used to create a dynamic asset list of all hosts that have certain types of documents being shared on the web. Actually, the Security Center can create asset lists on almost any sort of data detected by Nessus or the PVS. Below is a screen shot of a dynamic asset rule that would create a list of all systems that had Nessus vulnerability #11419 active:

Plugin #11419 looks for many different types of files (.doc, .pdf, .ppt, .etc), but there may be occasions when we want to look for content that is just for a specific file type. If we know what sort of file extensions we want to find, we can add some text search to our dynamic asset rule to match just what we want. In this case, if we wanted to look for just "Power Point" files, we could add a "Contains the Pattern" clause for the word "PowerPoint" as shown below:

If the pattern was more complex, we could have used a regular expression instead of a simple pattern match.

What can we do with these Asset Lists of hosts that contain sensitive data?

Once we have an asset list of all hosts that contain potentially sensitive data, there are several actions we can take:

All of the vulnerabilities for these servers can be independently considered. For example, all of these servers have specific web or SSH issues that should be addressed.

Instead of looking for the "top" vulnerabilities on these assets, searching them for systems or servers which were not under management could prevent future disclosure issues. If a system is holding sensitive data and it is not under management, common sense dictates this to be a problem.
If a system is holding sensitive data AND it is browsing the network, this could potentially also be suspicious. Typically, servers browse the network only for updates, backups and database queries. If a system holding sensitive data is heavily browsing the Internet, it could potentially be a target for malware, or perhaps the user doesn't know that they are also hosting a server.

If IDS events are being sent to the Security Center, or logs and network traffic are being sent to the Log Correlation Engine (LCE), they can be considered in context of the targets with sensitive data. Dynamic asset lists created by the Security Center are available for immediate use with  queries to the LCE. Login failures, buffer overflows, network anomalies, and even authorized access attempts can all be logged. This can help identify access control violations. For example, if a connection from a certain business group or even the Internet were seen connecting to a server with sensitive data on it, this could constitute a policy violation.

Advanced Dynamic Asset List Usage

Let's say we have many servers, all with some sort of interesting data on them and we also have the PVS recording which ports the systems it is monitoring get "browsed".  We'd like to create a dynamic asset list that identifies all systems with  both Nessus plugin ID #11419 and PVS plugin ID #2 destined for port 80. To do this, create a rule that looks like this:

The first rule clause is probably not familiar to readers. This is an extended regular expression, also associated with a plugin ID. For performance reasons, most rules are evaluated as an "OR" sequence. This makes it easy to find a certain combination of plugin IDs and ports. This rule clause matches if a server has plugin #2 present on it, and the data for that vulnerability ends with " 80". The ":" is used to separate the plugin ID from the regular expression. Regular expressions can use anchors such as "^" to indicate the start of a line and "$" to indicate the end of the line.

The second rule clause is a simple plugin match for Nessus ID #11419.

Both of these rules together will create a dynamic asset list of any host that has sensitive data that has also browsed the web on port 80. Since servers likely use the web queries to obtain updates, the reader should consider using a port such as 110 for POP or 143 for IMAP  or even 22 for SSH. These ports aren't used as often as port 80 though.  Another idea would be to look for PVS plugin IDs that identify the web browser in use as Mozilla.

For More Information

Tenable has other methods to search for sensitive data in motion. Several plugin libraries exist for the Passive Vulnerability Scanner which allow it to monitor plain-text traffic for credit cards, social security numbers and other types of sensitive data. Tenable has blogged about the PVS libraries and how to install them here. In addition, Tenable has partnered with content monitoring vendors such as Reconnex and has written several TASL scripts for the Log Correlation Engine engine.

The SANS organization released an update of the "Top 20" list of security issues organizations should be concerned about. The updated list includes many specific vulnerabilities, as well as generic guidelines. This blog entry shows how Nessus, the Passive Vulnerability Scanner, the Security Center and the Log Correlation Engine can be used to monitor for SANS Top 20 issues. Active vulnerability scanning policies for both Nessus 3 and the Security Center are also included here.

Specific Recommendations

The Top 20 guide is divided into different sections such as "W1 Internet Explorer" and "C5 Media Players". Some sections specify very specific vulnerabilities by CVE entry. In those cases, we've made sure to highlight the specific Nessus and Passive Vulnerability Scanner (PVS) plugins which can perform tests related to these issues. The specific active Nessus checks for the referenced CVE entries are included in the scanning policies below. Other sections are more generic and require interpretation by each organization. This blog entry also identifies strategies that can be used to generically monitor a network for these issues.

Patch Auditing with Nessus

Throughout this blog entry, we will make reference to specific Nessus checks to perform an audit. A majority of these audits (especially the client side tests) are accomplished with patch audits. If you are not familiar with using credentials to audit UNIX or Windows hosts to perform a patch audit, you should read the "Nessus Credentials Checks for UNIX and Windows" paper.

W1 - Internet Explorer

Microsoft has released many patches for IE. Performing a credentialed patch audit with Nessus will test for all security patches, including those for IE. Having said that, the "Top 20" policy specifies specific CVE entries and those have been used to map specific Nessus checks for testing IE in the scanning policies below.

There are no "remote" ways to identify IE issues without credentials with Nessus 3. Some of the issues identified in by the "Top 20" list can be monitored for passively with the PVS, but not all of them.

W2 - Windows Libraries

As with Internet Explorer, performing a credentialed patch audit with Nessus covers all of the security issues relating to Windows patch audits. Very few of the checks can be performed with network scans or passive monitoring. The specific Nessus checks related to the CVEs listed in this section are included in the scanning policies below.

W3 - Microsoft Office

Similar to the previous sections, the bulk of these checks is performed with patch audits. Some of these can be monitored for with the PVS, such as ID #3365.

W4 - Windows Services

Unlike previous entires, many of these checks can be performed with network scans that don't require credentials. In most cases though, Tenable provides both a network check as well as a patch audit for the Windows Services vulnerabilities identified here.

One vulnerability in particular was MS06-040. Tenable has previously blogged about how this particular security issue can be discovered with passive scanning, active scanning and patch auditing.

Nessus plugins indicated by the CVE entries in this section for both active scanning and patch auditing are included in the scanning policies below.

W5 - Windows Configuration Weaknesses

This section discussed password strength polices, default passwords as well as specific issues related to "NULL" passwords and Windows domains.  There were no specific vulnerabilities mentioned, just configuration issues. As such, there were no specific Nessus checks added to the scanning policies below.

Having said that, the entire Nessus "Windows: User management" plugin family as well as the generic "Windows" plugin family have checks which are very relevant to this section of the "Top 20" report.

For Security Center or Direct Feed subscribers, Nessus 3 can be used to audit the password policy for specific Windows servers. Tenable has blogged about this sort of testing in the past.

M1 - Mac OS X

The "Top 20" report identified a variety of client and server side issues specifically for Apple's OS X operating systems. All of these issues can be tested for with a credentialed patch audit of OS X. Tenable has previously blogged about how to accomplish this here.

All of the CVE issues identified with this section are covered with active Nessus checks, Nessus patch audits and PVS rules. All related Nessus active scans and patch audits are included in the vulnerability polices below.

U1 - Unix Configuration Weaknesses

This section combines several concepts for hardening and locking down UNIX systems, as well as tips for monitoring them once they are installed. Since no specific vulnerabilities were mentioned, there aren't any specific Nessus checks added to the scanning policies below.

This section specified many strategies and recommendations for locking down and monitoring UNIX servers. Tenable customers should keep in mind:

• The Log Correlation Engine (LCE) can be used to monitor UNIX logs as well as network activity to discover SSH, Telnet and FTP brute force attacks.
• Security Center and Direct Feed customers can perform configuration audits of UNIX servers to see if they have been hardened to CIS standards, as well as NIST and NSA recommended configurations. This includes password strength policies.
• In addition to network vulnerability scans, Nessus can perform full patch audits of most major UNIX OSes.
• For monitoring all network ports in real time (in lieu of performing a full port scan) consider using the PVS.

C1 - Web Applications

This section detailed issues with Cross Site Scripting, SQL Injection and many other issues relating to web applications. There are 1000s (if not more) of specific web application vulnerabilities that have been publicly disclosed. A Nessus active scan can find most of these, however, to find all issues with your specific applications, SANS recommends a source code review. Having said that, keep the following in mind:

• Nessus has a specific plugin family for Web Server vulnerabilities.
• Nessus also has specific plugin families for both CGI abuses, as well as abuses due to Cross Site Scripting.
• Tenable writes network checks for Nessus, as well as for the PVS, for most publicly disclosed web application issues.
• The PVS includes plugin families for Web Servers as well as CGI issues.

C2 - Database Software

SANS identified major vulnerabilities in most available Database solutions. These have all been cross linked with Nessus plugins and have been included in the scanning policies below. Most of these checks do not require credentials, but some Microsoft SQL checks do require credentials.

C3 - P2P File Sharing Applications

The "Top 20" list also identifies ways to enumerate and monitor P2P software in use on your network. They did not specify specific vulnerabilities to scan for, however, Tenable customers can accomplish the following actions:

• The PVS has an extensive library to identify P2P applications as well as their vulnerabilities, regardless if there are any local firewalls in use.
• Nessus has an entire family dedicated to P2P application and vulnerability discovery.

C4 - Instant Messaging

As with P2P, the "Top 20" list also identifies security issues with instant messaging applications like Trillian and AIM. Tenable customers can approach monitoring IM applications very similar to what has been recommended for P2P apps.

C5 - Media Players

The "Top 20" list also includes a wide variety of issues with media players. During 2006, many viruses and malware was able to propagate by exploiting vulnerabilities with various media players. SANS specifically sites several dozen CVE entries which relate to these issues. Nessus can perform checks for all of these, but often requires credentials to perform a host audit. The PVS can also be used to monitor for many of these issues.

C6 - DNS Servers

SANS does not specify specific vulnerabilities related to DNS servers. However, they do address DNS recursion. Tenable has previously blogged about how both the PVS and Nessus can be used to identify mis-configured DNS servers here.

C7 - Backup Software

During 2006, many vulnerabilities were identified in enterprise backup solutions, some of these were also discovered by Tenable. SANS identified several CVE entries, most of which can be tested for with Nessus. These checks are included in the scanning policies below.

C8 - Security, Enterprise, and Directory Management Servers

As with backup software, SANS has also identified many issues surrounding enterprise software. This includes corporate anti-virus software, authentication software and even patch management systems. The Nessus checks which perform these audits are included in the scanning policies below.

N1 - VoIP Servers and Phones

A new category into the SANS "Top 20" list covers vulnerabilities associated with Voice Over IP technologies. Tenable researches vulnerabilities in these applications and has Nessus checks for the items identified by SANS. Many of these checks are also available for the PVS.

N2 - Network and Other Devices Common Configuration Weaknesses

Both Nessus and the PVS can be used to monitor network devices for vulnerabilities. SANS specifies example vulnerabilities in printers, routers, firewalls and many other devices. However, the database of equivalent checks available for Nessus and the PVS is much larger. When auditing a network device, consider the following:

• Nessus has two entire families Cisco and SNMP, which focus on network security issues.
• The PVS also has a family dedicated 100% to SNMP monitoring.
• Active and passive OS fingerprinting includes network device discovery.
• Nessus includes a wide variety of checks for network printers.

H1 - Excessive User Rights and Unauthorized Devices

SANS stresses that organizations should strive to remove unneeded devices and unneeded user privileges. This will be a very subjective process for each organization. Active scanning, credentialed scanning, passive network analysis and log analysis can be used to build a monitoring solution for almost any situation.

Tenable has blogged about this related subject several times. Perhaps, the most relevant blog entry would be about how all Tenable products can be used to monitor generic IT controls.

H2 - Users (Phishing/Spear Phishing)

Tenable does not specifically perform research or checks to look for users who have been victimized by a phishing attempt. Having said that, Tenable does help in many areas:

• The PVS can be used to monitor network activity in realtime for potential "abuses" of the network. This includes systems (that have likely been compromised)  which send bulk emails with "The Bat!" software.
  
• Both Nessus and PVS can be used to monitor the susceptibility of the network's email and web clients to client side attacks.
• The LCE can be used to analyze web proxy logs and network traffic logs to analyze phishing instances if and when they occur. 

Z1 - Special Section: Zero Day Attacks and Prevention Strategies

SANS also identified several CVE entries which were used as "Zero Day" exploits throughout the year. The Nessus checks related to these vulnerabilities are included with the scan policies below. When monitoring for "Zero Day" vulnerabilities, Tenable customers should keep the following in mind:

• Direct Feed customers (and Security Center users) have immediate access to the latest vulnerability checks.
• PVS users also have access to the latest checks. Since PVS monitors 24x7, Tenable customers often have "early warning" of new vulnerabilities from the PVS.
• Both the PVS and the LCE can be used to look for changes in network behavior. For example, one the the LCE's correlation scripts, the windows_crashes_and_restarts TASL, can alert when there has been a large number of "failed", "crashed" or "restarted" programs.

Nessus 3 Scanning Policy

Below is a text file that is a Nessus 3 scanning policy. The Nessus plugins enabled in this policy were derived from the SANS references to specific CVEs.

Download SANS-2006-Q4.conf

On UNIX, this policy can be invoked from the command line with the "-c" option to specify a Nessus "rc" file. Windows Nessus 3 users can save this file in their Nessus configuration directory which will have a path as follows: Documents and Settings / {User Name} / Tenable /  Nessus / Config

The "{User Name}" is the account name of the person using Nessus under Windows. Restarting the Nessus 3 Windows scanner will allow the user to see (and edit if desired) this policy under the "Manage Policies" link. This file is named SANS-2006-Q4.conf and will show up as a policy named "SANS-2006-Q4".

Security Center Scanning Policy

Tenable has also produce a vulnerability policy which reflects the Nessus checks outlined by the SANS Q4 2006 "Top 20" list. The files below should be downloaded to your /opt/sc3/admin/vpolicy directory.

Download 0024.ep

Download 0024.info

Download 0024.prefs

The polices are indicated as "0024". If you already have a policy using number 24, you should download these to a different directory, and rename then to something else, such as "0025". Once these files are in place, make sure they are owned and readable by user "tns" and the value "0024" is added to the vpolicy.txt file. The Security Center can make use of this file immediately and does not need to be restarted.

Using These Scans

Nessus and Security Center users should perform these scans using credentials. A majority of the Nessus plugins specified in these policies are patch audits or require host-based access to analyze local files and registry settings.

Note: This blog was first posted on November 27, 2006. Since then, plugin ID #11777, which enumerates files that potentially represent copyright violations, has been rewritten.  It is now dependent on plugin ID #23973 which enumerates files hosted on SMB shares and checks for a much broader range of file extensions. 

Nessus includes three plugins to look for systems containing movies and music files being served through web servers, ftp servers and SMB shares. This blog entry will discuss why this is something you might want to look for, how these plugins work and how you can use the Security Center to analyze these results.

Background

Plugins #11777, #11778 and #11779 look for files with the following extensions:

.mp3
.mpg
.mpeg
.ogg
.avi
.wma
.vob

These files are normally associated with movies, music and DVDs that have been obtained from the Internet through P2P file sharing such as Bittorrent, BearShare, eMule, Kazaa and WinMX. 

Having a movie or music file on a computer is not a crime, however, having data that is copyrighted can be a crime. If users on your network are sharing this sort of data illegally, they may be exposing your organization to potential investigations from the Recording Industry Association of America (RIAA) or the Motion Picture Association of America (MPAA).

Tenable's university customers (and even our corporate customers) regularly tell us that if a user starts to blatantly use the network for sharing files with music or movie content, that they can expect to get a letter from the RIAA or MPAA. This can take time for the IT staff to respond to.

Internally, any organization that hosts a file server containing copyrighted material may be open to lawsuits or even embarrassment if news of this leaves the organization.

There are also a great deal of security threats from shared illegal content such as this. The SANS Q4 Top 20 list identifies both media players (C5) and P2P applications (C3) as being targeted by malicious users. An attacker who wishes to compromise a large number of systems could create a music or movie file with very appealing content, such as a popular song or movie, and also include an exploit which attacks iTunes, Media Player or Quicktime.

The NASL Scripts

Tenable has produced three different plugins to search for files with these extensions in SMB shares, on FTP servers and on Web servers.

#11777  SMB share hosting copyrighted material

This plugin uses the current scan credentials to find file archives of movies and music on SMB shares. For performance reasons, the script only looks for three levels of recursion deep.

#11778 Web Server hosting copyrighted material

This plugin is dependent on the webmirror.nasl script. The webmirror.nasl script creates a virtual archive of all content on the scanned web server. Plugin #11778 then searches this archive in the Nessus knowledge base for any file extensions which match those of movies and music.

Typically, users will find web archives on port 80 servers, but if a user is more savvy, they may try to hide their web server on a high port. If Nessus is performing a full port scan, it will find this port, identify it as a web server and log in. If performing a full port scan is not an option for all systems, using the Passive Vulnerability Scanner (PVS) to monitor network traffic to find web servers on non-standard ports is suggested.

#11779 FTP server hosting copyrighted material

This plugin logs into detected FTP servers and traverses the directories of hosted files for archives of movies and music. For performance reasons, the script only looks for three levels of recursion deep.

As with off-port web servers, if Nessus finds an FTP server not running on port 21, it will still attempt to perform this analysis. The PVS will also find off-port FTP servers.

Interpreting The Results

Finding a movie or a music file does not imply that the host is indeed violating someone else's copyrighted material. Many of the following situations occur on modern enterprise networks:

• legally obtained content is being shared unintentionally
• content intended for downloads (such as podcasts, movie trailers, .etc) is found
• content included with applications and operating systems is found

When analyzing systems with this data on them, consider the following concepts:

• Is this data something required for normal usage?
• Is this data consuming network bandwidth or storage?
• Does this data contain offensive material or subjects?

Analyzing Results with the Security Center

Below is an image of a server at 192.168.20.23 that was hosting copyrighted material over an SMB share:

This system had a few movies (Cars and Monster House) as well as some MP3s. If we had many hundreds (or even thousands) of servers with this condition, how could we use the Security Center to narrow these down into different groups? There are several things we could do:

• The Security Center has a "Search Vuln Text" field. If we wanted to find just movies, just music, .etc we could refine our search there. For example, we could type "cars.avi" and we'd find just systems that had that movie.
• We could extend this concept to look for "dirty" words which were associated with pornographic material. This would find systems potentially hosting adult entertainment content.
• We could also extend this concept to look for music of popular bands and title such as "ColdPlay", "U2" and "Madonna". 
• These filters could also be used to create a Security Center dynamic asset list. These rules could either simply match plugins #11777, #11778 and #11779 or have a more refined algorithm by also performing a text search to look for specific content. 
• Lastly, once these dynamic asset rules were in place, the Log Correlation Engine could be used to analyze network traffic (via direct sniffing or netflow) going to and from these devices to look for who has been accessing this data and how long they've been accessing it. 

For more Information

If this type of monitoring is interesting, Tenable customers should request a copy of our "Realtime Compliance Monitoring" paper. It has a section for strategies on dealing with RIAA and MPAA inquiries. All request for the paper should be sent to sales@tenablesecurity.com.

Also, both the PVS and Nessus have extensive families for detecting P2P applications in use. The Nessus plugin family for identifying P2P apps is available for analysis online. The PVS is a commercial product. If there is interest in that, please contact sales@tenablesecurity.com.

Lastly, we've previously blogged about using the PVS for corporate monitoring. 

About once a month, Tenable gets a call from an MSP, IDS vendor or SIM vendor that wants to take the output of a Nessus scan and do "correlation". The concept is to do something more intelligent with the IDS events with the knowledge of what is actually on your network.

Tenable has several products in this space and has also written several white papers on this topic. Over the past few years, we've also seen several approaches in SIMs and IDS/IPS solutions that have used techniques which can very misleading. This blog entry discusses some of the issues we've seen and how we've overcome them in Tenable solutions.

Correlating based on the Target OS

One of the easiest concepts to understand is to use the idea of the detected operating system of a target to "throw away" or "decrease the severity" of IDS events which won't have any effect. For example, if you have a "UNIX" attack heading to a "Windows" server, the attack is less likely to succeed.

Although, easy to understand, this can be very misleading. Consider the following implementation details:

• How accurate is the OS detection? We don't want to mis-classify IDS events because our Solaris server was misclassified as a Linux server. This occurs more often than people realize because there aren't enough ports open to identify an OS or there are true "proxies" in place.
• What do you do with cross-platform applications such as Apache, MySQL or even iTunes?
• If I am running a 100% UNIX network, or 100% Windows, .etc, this technique may help throw away some IDS events, but, a good NIDS administrator would have disabled the attack rules for the OSes not running on their network.

Perhaps the most misleading implementation of OS detection is to derive the vulnerabilities associated with the OS purely based on its signature. For example, one could actively or passively fingerprint an OS X server and then associate all vulnerabilities ever released for that OS as being "live". If someone patches these vulnerabilities, the OS fingerprint never changes and IDS events could be incorrectly elevated or de-emphasized.

Correlating based on the Application version and/or known Service

I feel very comfortable with solutions that accurately measure the presence of specific applications and then associate their known vulnerabilities. The key here is how accurate these applications can be determined. Consider the following technical implementation issues:

• How often is the system being assessed for the presence of an application? Using an out of date list can incorrectly effect the severity of a correlated IDS event.
• If the solution is scanning based, how does it handle applications from vendors such as Red Hat which provide patches to services without revising the revision level?
• Also if the solution is scanning based, does it find off-port services such as SSH running on port 2200 or web servers running on port 8000?

This last issue is very important. We've seen some correlation systems that even throw all IDS events to these ports because they were not in the scanner results. If your correlation system believes that what your vulnerability scanner gives to it is an accurate representation of the network, you should make sure to scan all ports, scan often, and to make sure you are using the latest vulnerability checks.

If you are using Nessus, this means that users should update their Nessus plugins very often and consider using the Direct Feed. If you are using a product other than Nessus, don't assume it is self-updating. make sure you perform an update of the vulnerability checks before performing and inputing a scan into your IDS or SIM solution.

De-emphasizing critical events with old vulnerability data

One theme we've seen in the past two examples is the de-emphasis of IDS events in an incorrect manner. What we would hope for is to correlate accurate vulnerability information with accurate IDS event data.

Consider a typical NIDS solution. It gets updated almost daily with new signatures based on the latest public vulnerability information. If it detects an attack that involves a vulnerability disclosed in the last few days, this could be quite serious. But what happens if the correlation system doesn't have evidence of the corresponding "serious" vulnerability from a network scanner?

A well made correlation system should leave the IDS event as-is since it doesn't have any information to raise or lower its severity level. A correlation system which removed the IDS completely could have very misleading results.

Not using Patch audit data

Something that surprises us at Tenable is the lack of interest in third parties to correlate patch audit data with IDS events. Patch audit data gives some unique types of vulnerability data as compared with a traditional scan. This includes:

• Extremely accurate vulnerability information, sometimes much more accurate than can be determined with a remote network scan.
• Client side vulnerabilities, such as security issues with Outlook, Mozilla and Eudora.

More and more IDS/IPS solutions are performing network monitoring for client-side exploits. Using a correlation system which doesn't accept or consider client-side vulnerabilities won't be able to help mitigate "false positives" IDS events or correctly identify serious compromise events.

Not using "Passive" Vulnerability Data

The last technique that many IDS/VA correlation implementations are missing is to make use of passively obtained vulnerability data. By "passive" we mean the process of monitoring the network traffic to accurately conclude vulnerability data. Passive monitoring has several advantages over network scanning and credentialed auditing when it comes to VA/IDS correlations.

Passive scanning is "always on" and sees all network traffic. Often a passive monitor will be exposed to the same traffic an IDS/IPS sees. This means at worse, a passive solution sees vulnerability information as soon as it is discovered by a remote hacker. If this data is fed into a correlation system, then the vulnerability data will always be current.

Passive scanning will see all traffic, including activity on ports not normally scanned for. If a server runs a web administration interface on a high port, a passive scanner will learn about this and report on it over time.

Lastly, passive scanning will also see client information which is in use on the network. When network users surf the web, check email or even use P2P software, all of this activity can be identified, usually down to the specific applications and their associated vulnerabilities being used.

IDS/IPS and SIM solutions which overlook the rich data obtained by passive network monitoring miss out on using valuable data for more accurate IDS event correlation.

VA/IDS Correlation with Tenable Solutions

Tenable's Security Center can accept vulnerability data from:

• scheduled Nessus network scans
• scheduled Nessus credentialed scans for patch auditing
• realtime vulnerability data from the Passive Vulnerability Scanner

This allows many forms of vulnerability detection to be used for accurate detection of all network vulnerabilities. It can also accept realtime IDS events from Snort, Tipping Point, Dragon, the Cisco IDS/IPS, NFR's Sentevist and IntruSheild. When these events are received, they are correlated in realtime with any relevant vulnerability on the target port or client of the attacked system.  A video demo of this process can be seen here.

If your organization is running Snort IDS sensors, the Security Center can also be used to push signatures from the Sourcefire VRT signature set and/or the Bleeding Snort signature set. The Security Center can push either the latest available signatures, or only push the Snort rules for which you network has vulnerabilities. This allows your Snort sensors to run with less rules.

If this was useful to you ....

Tenable has several white papers and available webinars on this topic.

• White Paper - Correlating IDS Alerts with Vulnerability Information
• White Paper - Security Event Management
• Recorded Webinar - Network and Behavioral Anomaly Detection (recording available)
• Live Webinar - Interview with Richard Bejtlich, Founder of Tao Security (Nov 17, 2006)
  Mr. Bejtlich is a noted author on network security monitoring.
• Live Webinar - Interview with Thomas Ptacek, Founder of Matasano Security (Nov 28, 2006)
  Mr. Ptacek was a pioneer in NIDS evasion research.
• Live Webinar - Correlating IDS events with Vulnerabilities (Dec 1, 2006)

As always, if there is interest in learning more about Tenable product offerings, please contact us at sales@tenablesecurity.com. Besides VA/IDS correlation in the Security Center, Tenable also offers a variety of correlation solutions for many log and network sources in the Log Correlation Engine.
 

I've been collecting comments made to me by various Nessus users and Tenable customers about what it means to be compliant. This is by no means scientific, but I only put stuff on this list that I've heard more than once.

PCI requires full scans of all 65,000 Ports

There are several issues with this statement. First of all, there are actually 65535 potential port values and 131070 if you count both UDP and TCP protocols. Second, and more importantly, PCI doesn't say this anywhere. There are several places in the PCI standard that recommend scanning of both  port 80 and 443, but it doesn't say anywhere to do a full port scan.

Technically, performing a full scan of this nature is easy for one or two systems, but can be difficult for a larger enterprise network. If this is something you are interested in performing on a wide scale, I highly recommend considering distributed Nessus scanners or performing passive network monitoring.

I can't use Nessus for PCI/SDP audits

This is very misleading! Many managed security providers use this argument, even though their technology is based on Nessus. Mastercard's wording is also misleading since they refer to service providers as "vendors".

In actuality, for the more in-depth PCI/SDP audits, you can't "self audit" and need to use an outside service provider to do this. Mastercard keeps a list here.

So even though, you can't "self audit" yourself, if you want to be proactive, you can use the same technology the vendors are using. Many of these vendors purchase the Direct Feed for their Nessus scanners or use the Security Center for scheduling, reporting and configuration of compliance audits.

You can't be compliant and have Nessus detect "Holes"

The only compliance regulation I am aware of that specifically outlines which vulnerabilities are unacceptable is PCI. It defines levels 5 through 1 with levels 5 and 4 consisting of things like detected malware, trojans and backdoors.

If you read through what it means to run a network according to COBIT, ITIL, or NIST standards, none of them say you can't have vulnerabilities. They actually not only expect you to have vulnerabilities, but also expect you to manage them.

So if an auditor is saying that you have a serious vulnerability so you can't pass your audit, she might be really saying that it is your process for managing or detecting the vulnerability that is the issue,not the vulnerability itself.

I need to have a firewall and an IDS/IPS to be compliant

Some compliance regulations do indeed say that organizations are required to perform access control and to perform monitoring. Some do indeed say that "perimeter" control devices like a VPN or a firewall are required. Some do indeed say the word "intrusion detection". However, this doesn't necessarily mean to go and deploy NIDS or a firewall everywhere.

Access control and monitoring can be performed with many other technologies. There is nothing wrong in using a firewall or NIDS solutions to meet any compliance requirements, but what about centralized authentication, network access control (NAC), network anomaly detection, log analysis, using ACLs on perimeter routers and so on? 

Can we get a list of Nessus checks to test for compliance?

Tenable often gets questions like this from both new and long-time Nessus users. The reality is that compliance standards audit your IT processes, not your vulnerabilities. As such, you will likely find the Nessus 3 "compliance checks" found in the Direct Feed of much more use to you in your audits than any of the latest vulnerability checks. Specific vulnerability checks are ideal for testing against the SANS Top 20 list of common vulnerabilities or even some aspects of the PCI standard. However, to prove to an auditor that your IT controls and procedures are working, Nessus can be used to audit the configuration of specific hosts and assets.

I can't perform these audit's myself

Depending on the type of audit, this may be true. However, I usually hear this sort of comment as an "excuse" not to perform some sort of ongoing compliance, security or vulnerability monitoring.

For example, the NERC regulations require a vulnerability scan of all critical cyber assets once per year. If this is all you are doing, then your once-a-year scan may find many unexpected surprises. If you were doing more proactive scanning, or even continuous passive monitoring, you can detect compliance issues earlier when they may be easier (and less costly) to mitigate.

Many auditors will use Nessus as their vulnerability scanner, or a similar type of tool. Being able to run these sorts of scans before the auditors do may also give you an advantage or head start and avoid a repeat audit.

Realtime Compliance Paper and Webinars

If this sort of summary was useful, you might be interested in how Tenable's full product line relates towards PCI, SOX, FISMA, NERC and many other types of compliance audits. We've prepared an 80 page paper which "summarizes" each of these standards and shows how our vulnerability, configuration, log analysis and passive network monitoring technologies can be leveraged for "realtime" compliance monitoring. Please email us at sales@tenablesecurity.com to request a copy of this paper.

Tenable also offers public webinars on these topics. The next few webinars cover vulnerability management, performing configuration audits with Nessus 3, SCADA network monitoring and network anomaly detection.