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.

The BETA of Nessus 3.2 includes support for a new command line method to invoke quick Nessus scans. This blog entry details some interesting examples for port scanning, operating system identification, testing of a certain bug and testing Windows and UNIX credentials using the nessuscmd tool.

'nessuscmd' Usage

Simply running the command (located in your ~/bin Nessus install directory) will show you the usage. New features and settings may be added before this product is officially out of BETA.

Command line options exist for:

• Port Scan options
• Selecting Vulnerabilities
• Providing UNIX and Windows Credentials
• Scan settings (such as 'max-hosts' or using a remote Nessus daemon)

Port Scans and Operating System Identification

Here is an example port scan with operating system identification invocation:

atragon# ./nessuscmd -sS -v -O -p 1-1024 192.168.20.24
Starting nessuscmd 3.1.4
Scanning '192.168.20.24'...

Host 192.168.20.24 is up
Discovered open port netbios-ssn (139/tcp) on 192.168.20.24
Discovered open port microsoft-ds (445/tcp) on 192.168.20.24
[i] Plugin 11936 reported a result on port general/tcp of 192.168.20.24
+ Results found on 192.168.20.24 :
   - Host information :
     [i] Plugin ID 11936
      | The remote host is running Microsoft Windows XP

   - Port netbios-ssn (139/tcp) is open
   - Port microsoft-ds (445/tcp) is open

Running the nessuscmd utility with a few targeted ports is a great way to quickly obtain very accurate OS ID scans from the command line.

Testing For VNC

Using the Nessus.org plugins search tool, I found 5 plugins that enumerate or identify VNC and test for vulnerabilities associated with it. These were plugins 10342, 10758, 19288, 19289 and 21564. Running the nessuscmd tool can show specific results for these vulnerabilities as shown below: 

atragon# ./nessuscmd  192.168.20.0/24 -i 10342,10758,19288,19289,21564
Starting nessuscmd 3.1.4
Scanning '192.168.20.0/24'...

+ Results found on 192.168.20.9 :
   - Port vnc (5900/tcp)
     [i] Plugin ID 19288
      | The remote VNC server supports those security types:
      | + 2 (VNC authentication)
      |
+ Host 192.168.20.11 is up
+ Results found on 192.168.20.16 :
   - Port vnc (5900/tcp)
     [i] Plugin ID 19288
      | The remote VNC server supports those security types:
      | + 2 (VNC authentication)
      |
+ Host 192.168.20.24 is up
+ Host 192.168.20.28 is up
+ Host 192.168.20.29 is up
+ Host 192.168.20.199 is up
+ Host 192.168.20.201 is up
+ Host 192.168.20.203 is up
+ Host 192.168.20.205 is up

Notice that this scan was performed against the class-C subnet of 192.168.20.0/24. Also notice that the results of these scans were 'informational' as indicated as such by the [i] next to the particular plugin ID output.

Testing for UNIX and Windows Credentials

The nessuscmd tool can also invoke plugins and pass them credentials to log into remote UNIX systems. The --ssh-login and --ssh-password arguments can be used to specify remote access. Here is an example of such a scan which enumerates installed software:

#atragon ./nessuscmd -v 192.168.20.11 -i 22869 --ssh-login root --ssh-password password

(long list of enumerated software deleted)

      | fonts-xorg-100dpi-6.8.1-1|(none)
      | libgnomeprint22-2.8.0-3|(none)
      | eel2-2.8.1-2|(none)
      | linuxwacom-0.6.4-6|0
      | gtk+-1.2.10-33|1
      | imlib-1.9.13-23|1
      | libpng10-1.0.16-1|(none)
      | pyparted-1.6.8-2|(none)
      | gtk-engines-0.12-5|1
      | gnome-kerberos-0.3.3-1|(none)
      | xscreensaver-4.18-5.rhel4.2|1
      | gnome-media-2.8.0-3|(none)
      | gnome-terminal-2.7.3-1|(none)
      | gnopernicus-0.9.12-1|(none)
      | vino-2.8.1-1|(none)
      | eog-2.8.1-2|(none)
      | gnome-volume-manager-1.1.0-5|(none)
      | desktop-printing-0.17-3.EL.1|(none)

Similarly, Windows systems can also be tested with the --smb-login and --smb-password arguments. We will use plugin #17651 which obtains the password policy.

atragon# ./nessuscmd -v 192.168.20.16 -i 17651 --smb-login Administrator --smb-password password
Starting nessuscmd 3.1.4
Scanning '192.168.20.16'...

Host 192.168.20.16 is up
[i] Plugin 17651 reported a result on port microsoft-ds (445/tcp) of 192.168.20.16
+ Results found on 192.168.20.16 :
   - Port microsoft-ds (445/tcp)
     [i] Plugin ID 17651
      | The following password policy is defined on the remote host:
      |
      |
      | Minimum password len: 0
      | Password history len: 0
      | Maximum password age (d): 42
      | Password must meet complexity requirements: Enabled
      | Minimum password age (d): 0
      | Forced logoff time (s): Not set
      | Locked account time (s): 1800
      | Time between failed logon (s): 1800
      | Number of invalid logon before locked out (s): 0

For More Information

Please send any feedback for the Nessus 3.2 BETA to Tenable's Director of Research, Renaud Deraison. Previously, we've blogged about Nessus 3.2's ability to perform IPv6 scanning as well as make use of pre-compiled NASL libraries, in particular to leverage Nessus's ability to query Windows WMI information.

The Nessus 3.2 BETA is currently available as Nessus 3.1.4 and is available for download at nessus.org under the downloads section.

On Wednesday, August 15th, 2007, Tenable Network Security will begin converting CVSS base scores for Nessus and the Passive Vulnerability Scanner (PVS) plugins from version 1 to version 2. This blog entry discusses how some of the plugin severity and risk ratings will be changing due to our adoption of the new and more accurate CVSS version 2 standard.

CVSSv1 and CVSSv2

Recently, the Forum of Incident Response and Security Teams (FIRST) released new guidelines for scoring vulnerability severity levels. The original standard was CVSS v1 (for version 1) and the new standard is CVSS v2. CVSS version 2 is more accurate than vulnerability severity ratings scored under version 1. It also gives more emphasis to remote, unauthenticated denial of service and compromise vectors.

Tenable Network Security uses the CVSS base score to select Nessus and PVS severity ratings for vulnerability plugins. Values from 1 through 3 receive a Low/Informational rating; 4 through 6 receive a Medium/Warning rating and 7 through 9 receive a High/Hole severity level. CVSS scores of 10 have a severity level of "High/Hole" but also have their Risk factor marked as "Critical".

We will synchronize existing Nessus and PVS plugins with the CVSS v2 base scores in NIST's National Vulnerability Database starting August 15th. Once we implement this change and you update your plugins, you should notice an immediate change in the way scores are displayed in your reports. For example, with v1 you might now see:

  Risk factor :

  Critical / CVSS Base Score : 10.0
  (AV:R/AC:L/Au:NR/C:C/I:C/A:C/B:N)

Under v2, you will see:

  Risk factor :

  Critical / CVSS Base Score : 10.0
  (CVSS2#AV:N/AC:L/Au:S/C:N/I:N/A:N)

In some cases, though, we are unable to sync scores with the NVD so the switch to CVSSv2 scores for some plugins will not occur immediately. This may happen because a Nessus or PVS plugin checks for a vulnerability for which there is no CVE entry, or because NIST has not scored the entry manually (NIST labels these "approximated" scores). In these cases, Tenable will re-score the plugins using the v2 standard as time permits.

Tenable will also begin to use CVSS v2 scoring on all new plugins starting August 15th, 2007.

For Nessus and the PVS, the new scoring methodology affects the severity ratings for many of the plugins which had been previously scored with the CVSS v1 methodology. There are several severity ratings that will change when the new scoring goes into effect. This means that some systems that have been scanned and did not have "High" or "Hole" vulnerabilities may in fact show vulnerabilities with this severity level if re-scanned. Similarly, some serious vulnerabilities do not have as high of a severity under the new scoring.

Detailed Severity Changes

Changes in the vulnerability scoring of note include:

• The scores for 79 plugins remain the same across v1 and v2. With four exceptions, these are for critical vulnerabilities, with a score of 10.0.
• The risk factor and reporting functions for 293 plugins will have a change.
• The risk factor for 30 plugins will actually go down. In one case, it's because the vulnerability requires adjacent network access rather than just remote access.
• Approximately 133 plugins covering issues that can be exploited by an unauthenticated remote attacker without any access complexity and that have one of C, I, or A scored as "partial" will see their risk factor go from Low (with a v1 score of 2.3) to Medium (v2 score 5.0) due to the increased weighting given the remote access vector in CVSSv2 scoring.
• 14 plugins for vulnerabilities that can be exploited by an unauthenticated remote attacker without any access complexity and with one of C, I, or A scored as "complete" will see their risk factor go from Low (with a v1 score of 3.3) to High (v2 score 7.8), again due to the increased weighting given the remote access vector in CVSSv2 scoring.
• 17 plugins for vulnerabilities that can be exploited by an unauthenticated remote attacker with a medium access complexity and with one of C, I, or A scored as "partial" (eg, XSS flaws) will go from a Low risk factor (with a v1 score of 1.9) to Medium (v2 score 4.3) due to the increased weighting given the remote access vector in CVSSv2 scoring.

Example CVSSv1 and CVSSv2 Scoring

Here is an example comparison of relative scores between CVSSv1 and CVSSv2 for a 'cPanel' path disclosure bug:

v1: 1.9 (AV:R/AC:H/Au:NR/C:P/I:N/A:N/B:N)
v2: 2.6 (AV:N/AC:H/Au:N/C:P/I:N/A:N)

In this example the change in scoring was from 1.9 to 2.6. It is "more" severe than before, but would still be reported as an informational or low vulnerability.

A good example of the another vulnerability jumping a dramatic amount in its severity rating is one that effects the Kaspersky Antivirus solution. Nessus plugin 24758 checks for a CPU DOS. The CVSS v1 and v2 scores are below:

v1: 3.3 (AV:R/AC:L/Au:NR/C:N/I:N/A:C/B:N)
v2: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C)

If the anti-virus solution is running on a mail server, then exploitation could be achieved remotely, without authentication and without any user interaction. CVSSv2 takes these factors into higher consideration when scoring vulnerabilities which results in a "high" score of 7.8.

Learn More About CVSS

For more information about the Common Vulnerability Scoring System, please visit the CVSS Special Interest Group's web site located at http://www.first.org/cvss/.

Tenable's Research group has released a new Log Correlation Engine TASL script which processes web proxy logs and alerts when specific domains are visited. The script is named blacklist_domain.tasl and can be downloaded from here. Tenable has also added several new PRM libraries to support processing logs from web proxies such as Cisco ASA, Blue Coat and Squid. This blog entry discusses how to obtain these PRM files, install the new TASL script and configure it for real time updates.

Security Monitoring with Web Proxies

Looking for internal traffic to suspicious domains can identify a wide variety of potential network abuses including:

• compromised host detection
• visiting known phishing sites
• visiting sites with adult content

An example list of suspicious domains can be obtained from the Bleeding Threat project here. The correlation used in the TASL script makes use of the list of domains tracked by the Bleeding Threats  project and can also be easily extended to include other sources.

When viewing these logs alongside data collected by netflow, sniffed sessions, IDS events, firewall logs and so on, a complete picture of what a host is doing and what sort of activity it is engaged in can be accomplished. Also, organizations that monitor employee activity closely can also attempt to discover when competitor's sites are visited and non-work activity is engaged in.

Installation

To configure this sort of monitoring with the LCE, we need to install the new PRM files, install the TASL script and also install or update the "blacklist" PERL utility which obtains updated lists of threats from SANS, Bleeding Threat and other sites.

Links to the new PRM files and TASL script is available below, and a list of shell commands to install and configure these utilities is included in the next section.

• web_squid.prm
  PRM to process logs from Squid web proxies.
• web_ncsa_common_access_log_format.prm
  PRM to process web proxy logs in the NCSA format
• web_w3c_extended_log_format.prm
  PRM to process web proxy logs saved in the W3C extended format
• prm_map.prm
  Updated list of PRM IDs
• PRM_Mappings.prm
  Updated list of PRM groupings
• lce_tasl.prm
  Updated PRM to process events from the blacklist_domain.tasl script
• blacklist_domain.tasl
  The TASL script which subscribes to web proxy events and performs lookups of suspicious domains.
• blacklist-2.4.1.pl
  PERL script which updates both a list of suspicious DNS domains as well as lists of suspicious IP addresses.

The following list of UNIX commands will allow you to update your LCE to process these new log events as well as install the blacklist_domain.tasl script. The PERL utility blacklist.pl requires a click-through license agreement to be downloaded. This should be placed on your LCE in a directory such as /usr/thunder/daemons.These shell commands below assume that the blacklist-2.4.1.tar.gz file is installed there.

su thunder
cd /usr/thunder/daemons/plugins
rm -f web_squid.prm
wget http://cgi.tenablesecurity.com/tasl/blacklist_domain.tasl
rm -f lce_tasl.prm
wget http://www.tenablesecurity.com/lce_tasl.prm
wget http://www.tenablesecurity.com/web_squid.prm
wget http://www.tenablesecurity.com/web_ncsa_common_access_log_format.prm
wget http://www.tenablesecurity.com/web_w3c_extended_log_format.prm
rm -f prm_map.prm
wget http://www.tenablesecurity.com/prm_map.prm
rm -f PRM_mapping.prm
wget http://www.tenablesecurity.com/PRM_Mappings.prm
exit                                        <-- we need to run this script as root
cd /usr/thunder/daemons
gunzip blacklist-2.4.1.tar.gz
tar xvf blacklist-2.4.1.tar
cd blacklist
./blacklist-2.4.1.pl                  <-- the tool will automatically run in the background

Before restarting the thunder daemon, give the script a chance to reach out and obtain new data. Inside the /usr/thunder/daemons/blacklist directory, the script will update the blacklist.domain file. Once these files have been populated, the thunderd service can be restarted with the following command:

/etc/rc.d/init.d/thunder restart

Managing Static Lists of "Bad" Domains

If you do not want to synchronize your list of potential blacklisted domains automatically, you can also manually edit the file /usr/thunder/daemons/blacklist/blacklist-custom.domain. This file won't exist unless you create it. The format of the contents are the same as those for the blacklist.domain file in that it is a domain suffix, a corresponding web site and a description about the item. For example, if you wanted to alert when web users attempted to receive new information from CNN or FOX, an entry could look like this:

cnn.com,www.cnn.com,CNN
foxnews.com,www.foxnews.com,FOX

If changes to the blacklist-custom.domain file occur, either the thunderd process must be restarted or a SYSLOG message containing the word "Blacklist_File_Update" be received. If the blacklist.pl script is running, it will send such a SYSLOG message to the thunderd process periodically.

For More Information

If this sort of alerting is interesting to your organization, you should also consider running the BlackList IP TASL script. This script uses multiple lists of "bad guy" IP address such as SANS and the Bleeding Threats project to alert when you have network activity to or from these sites. A blog entry detailing how it can be set up and configured is located here.

While reading the 'Declaration of Interdependence' series of articles in the July 1st issue of CIO Magazine (including an additional online article named 'Users Who Know Too Much and the CIOs Who Fear Them'), the term "Shadow IT" was used to describe the aggregate amount of personal, walk-in and employee owned software and hardware that makes its way onto corporate networks and computers.

This blog entry discusses strategies to look for applications that should not be running on your network as well as understanding which "unsanctioned" applications may be the most popular. It also discusses how the Passive Vulnerability Scanner can be used to detect Apple iPhones connected to the local IP network.

Review of Active and Passive Software and Device Enumeration

In a previous blog entry we've discussed how Nessus can use credentials to find UNIX and Windows installed software. Without credentials, Nessus can also scan for a variety of "client side" software that has open ports such as iTunes. It also finds a wide variety of operating systems, applications and network devices.

And lastly, the Passive Vulnerability Scanner (PVS) watches network traffic 24x7 and can identify client applications, servers, operating systems and network devices. The PVS is a bit more stealthy than Nessus in that it might be able to fingerprint that a host is running Ubuntu Linux, simply by watching how it makes queries for software updates.

When Nessus's advanced active scanning and credentialed methods to determine operating systems is combined with the PVS's 24x7 monitoring, a very accurate form of blended discovery can occur.

Each of these technologies can be used to look for authorized technology, as well as looking for those comprising your "Shadow IT" organization.

Supporting Un-supported Technology

Also in the CIO Magazine series of articles, there was a pie chart presented under a title named, 'If You Can't Win, Don't Fight'. The data reflected how surveyed IT departments dealt with unsupported technology.

• 42% said they'd monitor the activity for risk.
• 30% said they'd study the business case for mainstreaming the technology.
• 28% said they'd shut it down as soon as it was detected.

Reading this sort of data tells me that 70% (42% + 28%) of those surveyed need to monitor their networks for something they perceive as "bad" software. And for the remaining 30% that are interested in mainstreaming the technology, there still needs to be some sort of montioring solution to detect when certain technology becomes popular enough to mainstream.

We'll see in the next few sections that deciding what is indeed "bad" or even "not good" isn't as easy as we'd like it to be.

What is your policy? (What isn't on your White List?)

Unless your organization has a policy of what sort of software and devices have been authorized for use, the process of trying to detect "illegal" things can be very difficult. This is because there are millions of software titles and network devices available. It is much easier to enumerate what is allowed. Anything not on the list, by definition, isn't allowed and worth tracking.

There is no "Shadow IT" help desk that you can go to or open a trouble ticket with to see what has been deployed "outside" of normal channels. Instead, one needs to collect information many different ways to discover what has been deployed on their network.

Regardless of your technical or political environment, I recommend going "up the stack" when reporting things that are odd or unauthorized as outlined below.

• Networks and Devices. Audit any networks, devices or infrastructure that isn't documented or authorized. Your organization should be able to control which devices such as firewalls, wireless access points, SANs or routers are in place and even which IP addresses are in use. Sniffing with the PVS may be the easiest way to find which IP addresses are in use. Scanning with Nessus is also an option, but you will need to decide how deep of a scan you wish to perform.
• Operating Systems. Audit all discovered operating systems to ensure that authorized ones are deployed into the correct locations. Perhaps you have an AIX data center, but there should not be any AIX servers within the payroll IT closet or for the "development" lab. Consider the results of the audit by asset group (i.e., what are the OSes deployed in the DMZ?) as compared to trying to consider everything deployed across your organization.
• Server Applications. When auditing network services such as Web, Email, file sharing and so on, keep in mind that many products will OEM commercial solutions and also make use of open source projects. Don't be surprised if your new router is using a web server for the management interface which isn't on your list of approved servers.
• Client Applications. More an more client applications have a server component. P2P, chat tools, video conferencing tools and others open up a port to enable certain types of communication. These are discovered by Nessus network scans as well as by the PVS when these ports are used for communication. Traditional "client only" applications like web browsers, RSS readers, SSH clients and mail clients are identified by Nessus through the use of credentialed scanning, and by the PVS by observing network traffic and performing protocol analysis.
• Non-Internet-Connected Software. For software that does not connect to the Internet, it can still be identified by a credentialed Nessus scan. Plugin #20811 performs an audit of all Windows software and plugin #22869 audits all installed UNIX software.

Separating the "discovered" applications into these five groups can help simplify communication with senior management. There may also be some correlation between these groups such as detecting the presence of both Linux distributions, Apache web servers and Mozilla web clients in a supposedly 100% Microsoft environment.

If you are managing this active and passive security data with the Security Center, then using the dynamic asset filtering can help ensure that you are looking for the right software on the right asset. For example, if you have a "Data Center" asset group, then performing a list of operating systems within that asset can be accomplished with a few clicks of the Security Center interface.

Enumerating "Bad" Software, Devices and Operating Systems

I've run into several organizations that need to keep certain types of software or devices off of their network. They need a way to find it on existing computers, alert when it is in use and report that computers are "clean". Also, some organizations have active programs to keep certain OSes and network devices out of their networks too. Perhaps they've not paid maintenance on a previous network-wide license, perhaps there is a licensing issue with the vendor, perhaps the CIO is just anti-Microsoft, anti-IBM, anti-RedHat or so on.

With Nessus and the PVS there are really three strategies that you can use to look for things that are "bad".

• Monitor network traffic with the PVS to find evidence of a client or server protocol.
• Scan networks with Nessus to look for fingerprints of the particular software, operating system or network device.
• Log into the various OSes or network devices with a credentialed Nessus scan and look for the 'bad' software.

Starting from scratch, if you wanted to find out if Nessus could find a certain type of device, a good place to start is the Nessus plugin search tool located here:

http://www.nessus.org/plugins/index.php?view=search

If a plugin does exist, you should read the available description to see if this is a network check or if credentials are required. If you wanted to perform testing with the script by itself, you should considering using the 'nasl' command line tool. Also, the new Nessus 3 Client BETA makes it very easy for Windows, OS X or Linux users to select just the plugin in question and run it against multiple targets.

Also for Nessus, there are three plugins (find_services.nes, find_services1.nasl and find_services2.nasl) which will identify a wide variety of devices and services. If you have access to your "illegal" software, OS or device, scanning it with Nessus may likely produce a result that identifies it.

If you wanted to see if there are rules for the Passive Vulnerability Scanner to find your "Shadow IT" technology, you can check the list of published plugins located here:

http://www.tenablesecurity.com/tenable_plugins.pdf

This PDF file is updated daily and contains a list of all plugins available. Using the search tools available in most PDF readers, you can see if there exist rules for software products you are interested in.

Detecting the Apple iPhone

So what does all this have to do with detecting the brand new Apple iPhone? The iPhone is a classic example of a technology that can walk into any organization in any employee's laptop case or shirt pocket. It may or may not be sanctioned for use, can save data, connect to the local network and so on. It is on many people's "must have" lists and starting to show up on many organization's "must not have" lists.

When the iPhone is used to connect to a local IP network via wireless 802.11, it gets a real IP address and the email and web clients are easily fingerprinted. PVS rules #04134 and #04135 identify IP addresses that are likely iPhone by performing protocol analysis on port 25 and port 80 network traffic. Below is a screen shot of such a detection in the Windows PVS user interface:

At Tenable's demo sites, we've been seeing more and more iPhones used to connect to the local wireless networks and surf the Internet and send email.

Conclusion

The iPhone is just the latest type of technology to come to the forefront of many organization's "must/must-not have" lists. If we had written this blog post at various points during the past few years, we may have used the Google Toolbar or Skype as examples.

Regardless if your organization needs to monitor technology to see if it is being adopted by your users, or to see if it should be blocked, using a combination of active, passive and credentialed auditing can help identify what is in use and what has been widely adopted.

Detecting a "Shadow IT" organization within your organization is doable if you know where to look and have some sort of monitoring program in place.

Normally, we focus on the technical usage of the products at Tenable, but we have a number of open positions I'd like to make people aware of. If you are a regular BLOG reader, you might enjoy working on some of the projects we have ongoing as well as working with our customers and Nessus community. We have the following positions open:

Nessus Support Engineer
Qualified candidates should be familiar with Nessus and have a good understanding of UNIX and Windows system administration and underlying technology. Tenable customers tend to scan very large networks, scan with credentials and perform configuration audits. No two networks are alike and our support staff is exposed to many different combinations of technology and audit requirements.

Nessus Compliance Trainer
Nessus 3 Direct Feed and Security Center customers can make use of Tenable's library of audit templates to perform NIST, CIS, PCI and many other types of configuration audits. We are looking for the right individual to help deliver a training class focused on Windows and UNIX configuration auditing.

UNIX and Windows C Programmers
Tenable offers a wide variety of network monitoring, log watching, visualization and scanning tools which run on both Windows and UNIX operating systems. We are looking for several new C developers who have experience in Linux and/or Windows programing. 

Web Application Developers
Tenable is seeking web developers who have experience developing Linux/Apache based web interfaces written in PHP and AJAX. Web developers will work directly on the award winning Security Center product.

Pre-Sales Engineering
Tenable is seeking a qualified pre-sales engineer to assist our customers in the New York, Philadelphia and Boston metropolitan locations. Qualified engineers should have solid experience with vulnerability auditing, configuration auditing, log analysis or network behavioral analysis. Limited travel within the region is expected, as well as performing webinars and attending security conferences.

Interested candidates should send a resume to jobs@tenablesecurity.com. All development, training and support jobs are located at Tenable's headquarters in Columbia, Maryland.

Tenable is entering our 5th year of business and a large part of our success has been the great people at Tenable I've been lucky enough to work with. I'm very much looking forward to meeting readers who are interested in joining our team and taking on new challenges.

Tenable's sales and support groups continue to get the following type of question:

"I'm considering purchasing a scanning service from vendor XYZ and they claim to use Nessus. Are they certified by Tenable to perform PCI scanning audits?"

There are several points to consider when such a question is posed and this blog entry will attempt to discuss many of the nuances involved with this issue.

Products are not Certified for PCI Audits

There is no product solution available on the market today that can be purchased and used to perform accredited PCI vulnerability audits. There are services which can be procured to perform vulnerability audits and some of the technology these services use is available in the form of a product.

For an organization attempting to navigate the requirements of PCI, the differences between buying a service and the product based on that service may not seem great. For example, many scanning services include an appliance which is deployed on a customer's network which gives the feeling of a product.

If an organization governed by the PCI regulation does buy a product solution to perform PCI scanning, that organization will still be required to procure a 3rd party service to perform certified PCI vulnerability scanning. These services must be acquired from an Approved Scanning Vendor.

The benefit of buying a product that can perform realistic PCI audits is that when your official quarterly PCI scan is performed, you won't be surprised and you will have had a chance to fix issues before your audit occurs. Also, if your scanning service makes an error or has inaccurate results, being able to compare their results with your own can help expedite any incorrectly reported issues.

90% of the Certified PCI Services use Nessus

The PCI organization does list more than 130 service providers that are authorized to perform PCI scans. Of those on the list, almost 90% (the actual percentage was 87%) actively use the Tenable Security Center, Nessus Direct Feed or Nessus Registered Feed. We performed this analysis by cross-referencing the published list of PCI scanning vendors with Tenable's list of customers and registered Nessus users that update their vulnerability checks at least weekly.

Does this mean that if you use Nessus to scan for vulnerabilities, you are on the path to PCI compliance? The short answer is yes, but you still need to get a 3rd party to officially audit you.

Does this mean that any service who bases their vulnerability scans off of Nessus is qualified for PCI audits? Absolutely not. To be certified for PCI scanning, the organization must submit to a rigorous process which analyzes how scans are administered and performed and most importantly, presented to the customer.

Through our Direct Feed support for Nessus and product support for MSPs that use our Security Center to perform scan scheduling and reporting, Tenable is in a unique position to work with a wide variety of solution providers which are certified to perform PCI audits. No two solution providers have the same exact solution. Many of them have different procedures and policies for performing scans and communicating with their customers. For example, some prefer to accomplish discovery with multiple tools, including direct customer input, and then perform vulnerability scanning with Nessus while others perform their audits entirely with Nessus.

Although many organizations do use Nessus to perform PCI scanning, the regulation is not tool specific and is focused on the actual vulnerabilities, policies and procedures of the organization being audited.

Differences between in-house and Remote Scanning

There are also some very stark differences between remote PCI vulnerability assessments and what can be done with an in-house tool.

For example, section 8.5.9 of the PCI Audit Procedures document specifies that user passwords should be changed every 90 days. This sort of setting is something that can be audited with the Nessus Direct Feed and Tenable has even written specific PCI audit polices to look for this setting on UNIX and Windows operating systems. However, section 8.5.9 also gives MSPs some latitude in performing these audits and there are allowances for manual review of polices.

There are many more examples of this sort of discrepancy. Searching for the term "For Service Providers Only" in the audit guidelines will show many examples where a full internal PCI audit can be replaced with manual procedural reviews.

If such a review only occurs manually and quarterly, then when violations are found, fixing them implies not only changing the settings on various servers, but also changing the procedures and policies which allowed these lapses to occur in the first place. Performing in-house automated checks allows for early detection of compliance violations.

Another advantage of in-house scanning is that you may chose to perform a credentialed patch audit with Nessus. Patch audits  are very accurate and work for Windows and UNIX operating systems. If your MSP or ASV is not using credentials to audit your systems, it is possible that their scans may be less accurate than ones with credentials. If this is the case, performing these scans in-house with credentials can help expedite any issues reported by your ASV that are not accurate.

Monitoring PCI Compliance with Nessus

No discussion of PCI Compliance issues is complete without considering the full ramifications of the regulation. Complying with the PCI is much more than keeping your many e-commerce systems free of critical vulnerabilities. It includes firewall reviews, searching for insecure wireless access points, hardening of your servers with strong auditing and account security, log analysis, patch auditing and much more.

Tenable offers the 'Real Time Compliance' paper which shows how Nessus, and other Tenable log analysis and network monitoring products, can be used to audit and monitor e-commerce systems for PCI compliance and violations. The paper also discusses other regulations and IT management procedures such as COBIT and ITIL. If you are interested in reading the comprehensive paper, please email us at sales@tenablesecurity.com.

Tenable also offers a 30 minute webinar which focuses on compliance monitoring. The webinar is free but requires registration and is available to watch on-demand here.

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

Tenable's Research group has produced two Nessus PCI configuration .audit files for both the Windows and Linux operating systems. These configuration checks are derived from specific recommendations and audit requirements based on the PCI 1.1 standard.

These checks go above and beyond the PCI requirements of performing vulnerability and patch auditing and makes it very easy to audit and analyze system configurations against specific PCI items. These new audits also makes it easy to perform a single scan of one or more PCI hosts and accomplish a vulnerability, patch and configuration audit.

For the Windows PCI policy, configuration audits are available to ensure that a host firewall is enabled, that unnecessary services are disabled, that the system is secured to prevent or log abuse and that user account security is sufficient. For the Linux PCI policy, similar audits are performed to limit abuse, to audit new accounts and to ensure that logging is enabled. Each audit file includes the ID of the corresponding PCI DSS Security Audit Procedures document.

Compared to the certified Center for Internet Security .audit policies for Windows and Red Hat available, these .audit files are not as in-depth or comprehensive. However, if you are a PCI auditor or want to see how your systems would do before an official audit, these checks can produce content required to show compliance with a wide variety of sections of the PCI 1.1 standard.

To obtain these .audit files, Direct Feed or Security Center users should log onto the Tenable Support Portal, click on the 'Download' button and then the 'Download Configuration Audit Policies' button. Both polices are available for download under the 'PCI' section.

To install these on the Security Center, copy them to the /opt/sc3/admin/nasl directory. They will then be available as a .audit policy that can be included within a Security Center vulnerability scan policy. A demonstration video of using the Security Center to audit a Windows 2003 server is available here.

Nessus 3 Direct Feed users should save these .audit files to their laptop or server which runs their Nessus client and then create a scan policy which includes the desired .audit file as a configuration audit. A demonstration video of performing a configuration audit of a Windows 2003 server is available here.