Tenable recently increased the flexibility of performing configuration assessments of Windows  access control lists (ACLs) with the Nessus compliance checks.

Previously, an ACL policy could only be built with exact understanding if it were "inherited" or "not inherited". For large numbers of checks, it might not make any difference if an ACL were inherited from someplace else or not, just that the actual ACL was correct.

For example, to perform a file ACL test without regard if it is "inherited" or "not inherited", use the phrase "not used" with the "acl_inheritance" keyword. Below is an example .audit file which performs a file ACL test without regard if the policy were inherited or not:

<file_acl: "ASU1">

<user: "Administrators">
  acl_inheritance: "not used"
  acl_apply: "This folder, subfolders and files"
  acl_allow: "Full Control"
</user>
<user: "System">
  acl_inheritance: "not used"
  acl_apply: "This folder, subfolders and files"
  acl_allow: "Full Control"
</user>

<user: "Users">
  acl_inheritance: "not used"
  acl_apply: "this folder only"
  acl_allow: "list folder / read data" | "read attributes" | 
             "read extended attributes" | "create files / write data" |  
             "create folders / append data" | "write attributes" |  
             "write extended attributes" | "read permissions" 
</user>
</acl>

These changes effect the acl_inheritance  keyword for auditing ACLs of files, registry entries and services.   

Obtaining These Checks

Tenable customers who manage their Nessus scanners with a Direct Feed subscription or the Security Center have already received this update. If your organization is not connected to the Internet or performing regular updates, the change was made available on December 29th.

Tenable's research group has recently expanded support for "Black Lists" within the Log Correlation Engine. These new features include enhanced log parsing to identify specific black-list sources as well as leveraging these lists into the "Crowd Surge" detection TASL script.

Why Correlate With Black Lists?

There are many free sources of lists of "bad guys" available.Tenable currently supports the following sources:

• D-Shield's ISC Block list and Top 10 scanning IPs
• Bleedingthreat Botnet, Bot-Block and Spyware (through Blackhole DNS)
• Spamhaus public list of well known spammers

Each of these groups keeps track of abusive activity and publishes lists of IP addresses and networks performing "bad" things. Tenable has written a utility to monitor these lists and feed updated information to the Log Correlation Engine.

The blacklist.tasl script reads in a normalized list of IP addresses and then uses logs from the
Tenable Network Monitor or Tenable Netflow Monitor to look for connections from these sources.

The new lce_tasl.prm library generates unique black-list event names based on the source. Previously, black-list connections were just recorded with the name "Blacklist-Connection". Now, event names are broken apart based on the source list. For example, consider the screen shot below:

In the above image, separate connections were detected from almost all monitored black-list sources. The image was the result of a query to list all black-list connections in the past two hours. There were several thousand connections from IP addresses tracked by the Internet Storm Center (D-Shield), almost 1000 connections from known SPAM sources, a variety of bot net connections and at least 25 attempts by internal systems to reach out to known spyware destinations.

Analyzing Black List Scanning Events

In the above image, several Internet Storm Center "Top 10" connection events are occurring. This means that other organizations have reported being scanned by these sources and now these same sources are scanning your network.

If you monitor security for a network that is "addressable" on the Internet, you will likely get scanned continuously. Knowing how often you are scanned for "popular" exploits or from specific sources could give you an edge on what sort of security issues you need to worry about. For example, if you knew you were being targeted for worms that exploited VNC, specific Windows vulnerabilities or so on, you might be in a better position to recommend priorities for making firewall rule changes or recommending application and OS patches.

When analyzing broad scans, consider the following courses of action:

• Choose the most popular remote scanning IP addresses and then filter the logs at the Log Correlation Engine to see which IDS events or system logs they might be attempting. For example, worms that attempt to brute force SSH accounts or Windows logins aren't normally detected by NIDS.
• Conduct a port summary of connection attempts and then consider information available from the Internet Storm Center (ISC) about the scanned port(s). When listing ports for IDS event and log summaries, the Security Center has an automatic link to the ISC so that port activity can be tracked.
• Also for the targeted ports, use the Security Center to see which vulnerabilities your organization might have open on those ports. If you have a Passive Vulnerability Scanner deployed, it will have already likely picked up on which vulnerabilities or applications the remote scanners have targeted.   

Analyzing Black-list Botnet Events

Black-list connections from known botnets are more serious than a simple scan because they may indicate that you have one or more systems under active control by someone else. If one or more of your systems is connecting to a known botnet network or host, this may indicate that the server or servers have been compromised.

For a potential infected IP address or network, it is very good idea to look at last few days of logs collected. There may have been logs, IDS events and anomalies which could present a clearer picture of how the device got compromised. It may also show changes in behavior or when connections to the botnet started. For example, the image below clearly shows an increase in events during the last few days of a 25 day query.

This doesn't necessarily mean an infection has occurred, but if multiple systems are connecting to the same destination this may indicate a broader infection.

When analyzing these alerts keep in mind that some mediums, such as IRC, can be shared. A botnet may make use of a very popular IRC server, but this does not mean that everyone else that connects to the same IRC server is also part of the same botnet.

As with other types of analysis, consider the target ports, the frequency of connections, the time of day, .etc If the behavior seems out of sorts, it could be something looking into further.

Analyzing Black List Spam Events

Since there is so much SPAM, you might be asking why to even bother tracking these IP addresses. The short answer is to make sure that the systems the SPAM folks are sending mail to are indeed your mail servers. If they are unauthorized mail servers, mis-configured mail servers (such as those allowing relaying from the Internet) or mail servers from a different organization, matching their traffic against known SPAM lists can give some indication of abuse or potential risk. This technique might also identify your own email servers that are indeed receiving SPAM but do not have their anti-SPAM technology enabled.

Adding this to Crowd Surge detection

The crowd_surge.tasl script was also recently modified to correlate "crowd surge" destinations with the black-list.

For those not familiar with crowd surges, this event occurs when a certain percentage of a given population all visit obscure places at the same time. An example scenario could be when all of your infected Windows systems reach out to an IRC channel at 2:00 AM. The idea is to not alert on the places we all go to (Google, MySpace, CNN, .etc) and to alert when enough of the population starts to go to places such as ddoskiddies.com.

The algorithm in the crowd_surge.tasl script is effective at finding botnets and spyware that use IRC, tor, the web, SSH and proprietary protocols for command and control. More detailed information about "crowd surge" detection can be found in a previous BLOG entry.

By adding the black-list lookup to the crowd_surge.tasl script, more detailed alerts can be generated. If a certain percentage of a given network is reaching out to a known "bad guy", those events will show themselves with a typical "Blacklist" event as we've discussed already. However, if enough hosts visit a known black-list site in a short amount of time, you might be dealing with a real botnet. The crowd_surge.tasl script can alert you to this fact and save you from needing to discover this sort of behavior with manual analysis.

Below is a screen shot of what the events look like for a correlation between a known black-list and a crowd surge:

Installing

Obtaining these files and installing them is very simple:

The blacklist-2.2.tar.gz file can be downloaded from here. It should be installed into the /usr/thunder/daemons/blacklist directory. The file blacklist.cfg should be edited with the IP address of your thunder server (a.k.a. the Log Correlation Engine) as well as how often the web sites with various public black-lists should be polled. If a previous version of this script is running (such as version 2.1), the running program should be killed and the installed directory be completely removed.

The files blacklist.tasl, crowd_surge.tasl and lce_tasl.prm should all be downloaded with the wget tool into the /usr/thunder/daemons/plugins directory. Keep in mind that when wget downloads a file, by default, if a file with the same name exists, it won't be overwritten. Once these files are in place, restart the thunderd process.

A useful event to know about on any network is when something new happens on a given server for the first time. This is a very simple concept and extremely useful.

Regardless if your event logs are from UNIX systems, router access control violations, wireless access DHCP logs, intrusion detection systems or so on, after a certain period of time, the same events tend to repeat themselves. This is because most of our networks run controlled and automated processes.

With this in mind, finding out when something "new" occurs could indicate a security or administration problem.

The nbs.tasl Script

Tenable's research team has written a TASL script which implements this concept for the Log Correlation Engine. The script, nbs.tasl, stands for "never before seen". By default, the script subscribes to all possible event IDs except for network connection events from the Tenable Network Monitor (TNM) and the Tenable Netflow Monitor (TFM).

The script checks to make sure each event has either a source IP or destination IP in the "Customer Ranges.asset" file which the LCE obtains automatically from the Security Center. If an organization had a different asset list they would like watched, one could be substituted easily by modifying the script.

Detecting Intrusions

Tagging "new" events originating on, from or too a specific IP is very useful, especially for intrusion detection events.

For example, the nbs.tasl can differentiate between when a Snort event is generated for the first time from a server as compared to just alert when a system is attacked for the first time.

Consider a network that is being attacked very often. The Log Correlation Engine will likely record normalized IDS events inbound to monitored hosts. Very seldom (if at all) will an IDS event be sent from a target because we hope that our systems aren't attacking anyone. The first time these events occur though, the nbs.tasl script will alert on this "new" type of event.

Example Logs

Below is a screen shot of a set of logs generated by the nbs.tasl script:

Issues and Complimentary Technology

The first time you run the nbs.tasl script, all events will be new. By default, it will wait one day to learn which events are "normal". After that, any event that hasn't  occurred in the past day will be recognized as something "new" for the first time. This will create a spike of events that get generated.

Tenable considered placing a longer "learning mode" into the script, but being able to graph how often a "new" event occurs initially, where they come from and how long it takes for these events to "quiet down", can actually generate useful information.

For dealing with intrusions, keep in mind that the nbs.tasl also won't alert on the same event twice, even if it is a very critical alert. This is on purpose. If a server is compromised one day for the first time, and then compromised the second day with the same exact technique, the nbs.tasl will stay silent.

We've also designed the nbs.tasl script to not consider network events from the TNM and TFM. Those logs are verbose and copious and don't add a lot of value. Similar logs for monitoring and detecting network change (as in detecting new hosts, new ports, .etc) are already generated by the Passive Vulnerability Scanner.

And lastly, the LCE's stats daemon is designed to look for changes in the frequency of events and connections. If the data from the nbs.tasl script seems interesting to detect events that have not occurred before, then alerts from the statistics daemon identify changes that also have not occurred in the past.

Setting it UP

Please download all of these files to your /usr/thunder/daemons/plugins directory using wget or some other web client:

• http://cgi.tenablesecurity.com/tasl/nbs.tasl
• http://www.tenablesecurity.com/PRM_Mappings.prm
• http://www.tenablesecurity.com/prm_map.prm
• http://www.tenablesecurity.com/lce_tasl.prm

Keep in ming that if you have an existing file (such as the PRM_Mappings.prm library) wget by default won't overwrite the existing file but will save it with a numerical extension such as PRM_Mappings.prm.1.

By default, the nbs.tasl considers events to or from the Security Center "Customer Ranges" asset group. If a different asset group is available or desirable, it should be entered into the script.

By default, the script also has a variable named LEARNING_PERIOD. This variable is set to the number of seconds in one day. When the script first runs, it will consider all events "new" but won't alert on them until the period of time specified in LEARNING_PERIOD has occurred. If you want to start alerting right away, set this variable to zero.

Once these files are installed, restart your thunderd daemon.

For More Information

If event analysis seems interesting to you, all Tenable TASL scripts are available online. They are easily extended and work with the Log Correlation Engine. Tenable also has two free webinars available and several white papers which consider log analysis and event correlation located here:

• (webinar) Network Based Anomaly Detection
• (webinar) Vulnerability and IDS Event Correlation
• (white papers) Security Event Management

Please contact Tenable's sales or support groups for more information on these scripts.

Dale Peterson is the CEO and founder of Digital Bond, a research and consulting practice which specializes in IT and Control Systems security. Digital Bond recently completed research on behalf of Tenable Network Security which produced the SCADA plugins for the Nessus vulnerability scanner.

I was able to interview Dale and record his thoughts on SCADA security. In the podcast below we discuss what SCADA is, performing security assessments of live SCADA networks, the SCADA plugins for Nessus and passive SCADA network monitoring. 

Download dale-peterson-interview.mp3

Tenable recently added a credentialed Windows check (Nessus ID #23910) to find systems that have been infected by certain viruses. The check considers the contents of the file:

SYSTEM32\Drivers\etc\HOSTS

and sees if it has been manipulated to prevent virus updates. A common virus technique (such as in MyDoom, Bagel and their variants) is to disable a computer's ability to update its anti-virus signatures once it has been compromised. Typical anti-virus software performs a DNS lookup to find the update server where new signatures are available.

By adding alternate IP addresses (usually 0.0.0.0) for common update sources such as Symantec, Sophos, Microsoft, Kaspersky and so on, a virus can prevent anti-virus software from updating itself. Tenable has also seen viruses place destinations for anti-spyware solutions as well.

If Anti-Virus Software is there in the first place, why does it fail?

The answer is pretty simple: zero-day (or recent vulnerability announcements) exploits and the desire to maintain control over a compromised system. Worm writers who use a new exploit can compromise many systems before the anti-virus vendors develop signatures for the files in motion or network attack vectors.

A savvy worm writer will "know" that if their Trojan or worm is popular or successful enough, it will get the attention of the anti-virus community and signatures will be developed and deployed to target it. With this in mind, a worm writer who disables or neuters an anti-virus solution can keep control of the infected host well after the anti-virus rules have been updated.

Other Nessus Anti-Virus Checks

There are several other anti-virus and Trojan/backdoor detection plugins available for Nessus. Here is a quick overview:

• For most commercial anti-virus solutions, a Nessus local check can be used to determine if the system is running with the latest available updates, or if the solution is installed but disabled or not running.
• For popular viruses, Tenable maintains a set of "quick check" local tests in plugin #11329. This is not a comprehensive list of the 1000s of various virus and Trojan variants, but does check for several dozen very popular viruses.
• For many popular worms that have well known network backdoors, Tenable does write plugins to scan for and discover these. For example, the Sasser Virus Detection plugin (Nessus ID #12219) connects to various ports to look for an FTP service.

Being Proactive and Vigilant

Tenable offers a variety of solutions to extend a typical Nessus deployment to monitor enterprise networks for worms, virus outbreaks and  even network anomalies:

Besides discovering most of your server and client vulnerabilities simply by watching network traffic, Tenable's Passive Vulnerability Scanner discovers when new ports become open, can identify the presence (or lack thereof) of several anti-virus solutions and can also alert when an internal host begins port scanning.

When fed netflow logs, firewall logs or using the Tenable "TNM" agent for direct network traffic analysis, the Log Correlation Engine can identify hosts infected with spyware, malware, botnets and trojans. This is done primarily through cross referencing several popular black lists, as well as considering anomalies such as "Crowd Surges" of samples of the network population to suspicious locations.

Tenable's Nessus 3 scanner can also perform agent-less host-based configuration audits. These tests can consider the configuration a specific asset class (server, desktop, web server, .etc) should have and look for discrepancies. For example, Nessus can test that the content of the "HOSTS" file contains a "corporate" standard, that certain base configurations are met and that specific processes are indeed running.

Obtaining These Checks and Thanks

Tenable would like to thank both the folks at Sensepost as well as Michel Arboi for suggesting this sort of check. The check is currently available in the Direct Feed. All Security Center and Direct Feed users have access to this plugin at this time.

The Passive Vulnerability Scanner (PVS) can be used to discover web servers hosting files which may be copyrighted or as potential sources of data leakage events. Such material may contain sensitive intellectual property that is not intended for public release. By passively sniffing traffic to and from web servers, the PVS can discover hosted content that may be in violation of corporate policies.

Finding Potential Copyright Violations

Several plugins are available to discover movies and music files being hosted on a web server. These files may be subject to inquiries from the RIAA or the MPAA.

Typically, if a user on your network is sharing copyrighted content, they are either physically bringing it into your network, or they are using your bandwidth to download content via P2P file sharing. A user that attempts to share their movies or music using a web server could be a liability for your organization.

The following PVS plugins are available to discover hosted entertainment content:

• 3827 Web Server hosting .mp3 file(s)
• 3828 Web Server hosting .wav file(s)
• 3839 Web Server hosting .ogg file(s)
• 3840 Web Server hosting .wma file(s)
• 3847 Web Server hosting .avi file(s)
• 3848 Web Server hosting .mpg file(s)

Tenable considers these plugins very complementary to the Nessus plugins which perform scans for similar content. Tenable has blogged about using active scanning with Nessus to discover potential copyrighted content on web servers, SMB shares and FTP servers.

Finding Potential Data Leakage Files

Many enterprise organizations have experienced inadvertent or malicious disclosure of sensitive corporate data and sensitive customer data. Many of these cases resulted from having sensitive data "too available" to employees who didn't really need access to it.

One way to help combat this is to simply take an inventory of which web servers are hosting typical corporate documents. The PVS has the following rules available to detect web hosted files:

• 3822 Web Server hosting .xls file(s)
• 3823 Web Server hosting .doc file(s)
• 3824 Web Server hosting .ppt file(s)
• 3825 Web Server hosting .csv file(s)
• 3826 Web Server hosting .rtf file(s)

The intent of finding these files isn't to find data leakage incidents, it is designed for organizations to discover if they have any web servers hosting this sort of content. Since the PVS watches 24x7, it can also act as an alerting mechanism when new servers or new content are available.

Tenable has recently made rules available for the PVS which can look for patterns of credit card and social security numbers in network traffic. We've also blogged about how the PVS can be extended to look for proprietary tags of sensitive data.

Comparing with Nessus Active Scanning

Since the PVS is 24x7, it does have an advantage of seeing data in motion. The PVS is also monitoring all unencrypted web servers, regardless of port. It will also see unencrypted web servers hosting this content that are protected by a password. Obviously, Nessus scans can be configured with credentials to perform a scan, but an IT auditor might not have the right password for a rouge web server containing movies or music files.

For active scans, Nessus may be able to find files that are available, but have yet to be downloaded. Nessus can also "log on" to SSL encrypted web servers (providing there is no password) and discover files.

Working With the Security Center

Since the output of these PVS plugins can be used by the Security Center's dynamic rules engine, there are many possibilities for reporting, analysis and alerting. The Security Center can be used to create an asset list of each web server that is hosting potentially sensitive content. Once this occurs, the following activities can take place:

• All systems which have been passively discovered could be automatically (or manually) scheduled for an in-depth active Nessus scan.
• The vulnerabilities of all web servers hosting sensitive content can be analyzed, trended and reported on. This may be a quick way of simply discovering where all the main "servers" with corporate data are located.
• If the Log Correlation Engine is in use, an analysis of who has accessed this data and from where can occur. This can be accomplished using netflow, firewall or sniffed network sessions.
• If intrusion detection logs are available, a separate report or analysis of all attacks against these servers can occur.
• If these assets hosting sensitive data are being managed, the Log Correlation Engine can be used to track changes to the local system, users and supporting network devices.
• If the RIAA or MPAA makes an inquiry to your organization, the PVS can help provide data for the investigation. The Security Center can keep this data on record for "historical" evidence as well.
• The Security Center can be used to find servers that are hosting movies AND music or perhaps PowerPoint AND Spread Sheet files. These correlations can help find a more likely source of interesting files for analysis.

I recently encountered logs from a Buffalo Wireless Access Point. DHCP leases and MAC address associations generate logs like this:

AP00160114430C : WIRELESS: wl0: 11g : Associated User - 00:04:23:76:34:20
AP00160114430C udhcpd: sending ACK to 192.168.11.2

The log identifying the remote MAC address is in one line and the log identifying the remote IP address is in a second line. Most of the TASL correlation scripts for the Log Correlation Engine expect to derive MAC/IP pairs from single logs lines like those of the DHCP daemon shown below:

Mar 24 11:07:46 util04 dhcpd: DHCPREQUEST for 10.9.102.183 from 00:c0:4f:0c:27:14 via eth0

Scripts like the user_to_mac.tasl expect to parse DHCP logs that contain both the MAC address and the IP address on the same line. So how can we take the logs from the Buffalo WAP and generate something that looks like a log from a typical DHCP daemon?

The buffalo_dhcp_one_line.tasl script is a very simple TASL that subscribes to events from the accesspoint_buffalo.prm library. It "keeps state" on the last MAC address in the "Associated User" logs encountered. Those are normalized to event ID 400. When an ACK (event ID 402) or OFFER DHCP (event ID 403) log is encountered, a new log is generated that looks like this:

DHCPREQUEST for 192.168.11.2 from 00:04:23:76:34:20 via buffalo_one_line.tasl script

The MAC address is added from the MAC address seen in the last "Associated user" event. The format of this log is very similar to that of the logs generated by the regular DHCP daemon. This is readily processed by the dhcp.prm plugin library.

Below is a Security Center screen shot of the events from Buffalo WAP being processed by the accesspoint_buffalo.prm library and the buffalo_dhcp_one_line.tasl script.

The two DHCP-Request events were generated by the TASL script while processing the BuffaloWAP-Associated_MAC and BuffaloWAP-DHCP_Address_ACK events.

Tenable has released 32 plugins for Nessus 3 which specifically test SCADA devices. These plugins were the result of a four month research contract between Tenable Network Security and Digital Bond. This blog entry details how to obtain the plugins, strategies for using them with Nessus and strategies for using them in concert with Tenable products such as the Security Center and Passive Vulnerability Scanner.

Availability and Compatibility

All Direct Feed and Security Center users will receive these plugins through a plugin update. The SCADA plugins are only available to Tenable Direct Feed or Security Center customers. Other compatibility notes to consider:

• The plugins are designed to work only with Nessus 3
• Some of the plugins require local checks, but many are network probes
• Nessus 3 Windows users will see the new "SCADA" family after they update their plugins.
• If you use the Nessus 3 OS X client, the UNIX GTK client or NessusWX, you will see the SCADA plugins and family after you connect to a Nessus 3 scanner subscribed to the Direct Feed or being managed by the Security Center.

Tenable customers should contact our support group at Tenable if they require assistance obtaining these plugins. Below are screen shots of how the plugins look under the Nessus 3 for Windows GUI, the Nessus 3 OS X GUI and NessusWX:

SCADA Plugin Functionality

The plugins reside in their own family named "SCADA". Each plugin is listed below with a short description:

• Areva/Alstom Energy Management System - Identifies if the remote host is running an Areva/Alstom EMS Server.
• DNP3 Binary Inputs Access - Read binary inputs using DNP3 from RTU/IED.
• DNP3 Link Layer Addressing - Determines link layer address of DNP3 station by iterating through likely values.
• DNP3 Unsolicited Messaging - Determines whether the DNP3 outstation supports unsolicited responses.
• ICCP/COTP Protocol - COTP (ISO 7073) is running on the host and may be part of an ICCP server, MMS application, or substation automation device that uses IEC61850/UCA.
• ICCP/COTP TSAP Addressing - Determines a Connection Oriented Transport Protocol (COTP) Transport Service Access Points (TSAP) value on an ICCP server by trying possible values.
• LiveData ICCP Server - Identifies hosts running a LiveData ICCP server.
• Matrikon OPC Explorer - Identifies hosts running Matrikon's OPC Explorer tool. These hosts may also have additional diagnostic tools and trust relationships.
• Matrikon OPC Server for ControlLogix - Identifies hosts running a Matrikon OPC Server for Allen-Bradley ControlLogix PLC.
• Matrikon OPC Server for Modbus - Identifies hosts running a Matrikon OPC Server for Modbus devices and used to access data from PLCs, RTUs, and IEDs. OPC servers are commonly used in SCADA and DCS systems to exchange data between different vendor systems and disparate applications.
• Modbus/TCP Coil Access - Modbus uses a function code of 1 to read "coils " in a Modbus slave. Coils represent binary output settings and are typically mapped to actuators. The ability to read coils may help an attacker profile a system and identify ranges of registers to alter via a "write coil" message.
• Modbus/TCP Discrete Input Access - The Modbus protocol function code of 2 reads discrete inputs from Modbus slaves. The ability to read discrete inputs may help an attacker profile a system.
• Modicon Modbus/TCP Programming Function Code Access - Finds hosts with the proprietary Modbus/TCP function code 126 active. An attacker that is able to gain network access to devices like this may be able to reprogram PLC logic or otherwise impact the integrity of physical processes.
• Modicon PLC CPU Type - Uses an SNMP Get Request to obtain the Model Information of a Modicon PLC.
• Modicon PLC Default FTP Password - Checks for the default FTP username and passwords on a Modicon PLC.
• Modicon PLC Embedded HTTP Server - Finds Modicon PLCs running an embedded HTTP server used for configuration or monitoring.
• Modicon PLC HTTP Server Default Username/Password - Tests HTTP servers on Modicon PLCs for the default user name and password.
• Modicon PLC IO Scan Status - Uses an SNMP Get Request to obtain the scan status of a Modicon PLC.
• Modicon PLC Modbus Slave Mode - Uses an SNMP Get Request to obtain the Modbus mode. The Modbus mode is either direct, gateway, unit or some combination of these three types. The Modbus mode could help an attacker determine the type of attack necessary against the PLC.
• Modicon PLC Telnet Server - Tests Modicon PLC Telnet servers for the default user name and password.
• Modicon PLC Web Password Status - Uses an SNMP Get Request to obtain the Web Password Status of a Modicon PLC.
• National Instruments Lookout - Identifies hosts running the National Instruments Lookout Application.
• OPC DA Server - Identifies hosts running the OPC Data Access Server.
• OPC Detection - Finds hosts with OPC application components installed.
• OPC HDA Server - Identifies hosts running an OPC Historical Data Access Server.
• Siemens S7-SCL - Identifies hosts that contain Siemens S7-SCL Development Tool(s).
• Siemens SIMATIC PDM - Identifies hosts running the Siemens SIMATIC PCS 7 PDM Application.
• Siemens-Telegyr ICCP Gateway - Identifies hosts running a Siemens Telegyr ICCP Gateway server.
• Sisco OSI/ICCP Stack - Identifies hosts running a Sisco OSI/ICCP stack, and most likely acting as an ICCP server.
• Sisco OSI Stack Malformed Packet Vulnerability - Identifies hosts running a version of the Sisco OSI stack that can be crashed by a malformed packet.
• Tamarack IEC 61850 Server - Identifies hosts that may be running an IEC 61850 server developed by Tamarack Consulting, Inc.
• Telvent OASyS System - Identifies hosts running a Telvent OASyS Server.

Complementary to the current Passive Vulnerability Scanner SCADA plugins

Tenable customers who have also implemented the Passive Vulnerability Scanner (PVS) can now perform both active and passive SCADA network monitoring. Similar SCADA plugins for the PVS have been available since mid-2006. These offer no impact to the monitored network and effectively identify all devices which speak Modbus, ICCP and DNP3.

Organizations can tailor their vulnerability monitoring programs by using a combination of active SCADA scanning with these new Nessus plugins and passive monitoring with the PVS. Many organizations are required to perform annual vulnerability scans, which must be scheduled to avoid
impacting the production network. Using the PVS throughout the year meets the requirement for scanning, without impacting the network.

SCADA Device Active Scanning Strategies

As with all vulnerability scanning of devices which control physical equipment, consider the following strategies:

• If you have a SCADA test lab, start scanning those devices to identify any potential impact.
• When scanning operational SCADA devices, ensure that a second device is available for "fail over" and also ensure that the device operators are informed of the scheduled scanning.
• If you have access to data from a Passive Vulnerability Scanner, consider tailoring your scan to more robust device such as operating systems which were produced in the last five years.
• For configuring Nessus scans to be "safe", make sure scan polices have "safe checks" enabled and "thorough tests" disabled. Tenable has previously blogged about "safe checks" usage for Nessus.
  

For more strategies to consider for scanning SCADA networks with Nessus and these new SCADA plugins, Tenable recommends reading a white paper from Digital Bond entitled "Scanning Control Systems".

Working with the Security Center

Tenable customers who use the Security Center to manage one or more Nessus scanners in a SCADA environment should consider the following strategies:

• The new SCADA plugins will readily produce data that can be leveraged into dynamic asset lists. This can help create various lists of devices by active protocol (ICCP, DNP3, .etc) as well as function or even "Area of Responsibility".
• For each asset list, a separate vulnerability analysis can be conducted. Separate asset types will likely have different "top 10" vulnerabilities or configuration issues.
• Once separate asset lists are created, the components for each group can be displayed in three dimensions with the Tenable 3D Tool (demo video).
• Perhaps one of the most interesting types of analysis on "older" networks is to discover SCADA devices that are no longer needed, were failed to be decommissioned or deployed in locations that are not protected. 
• For NERC compliance, this process can help make sure the list of "Critical Cyber-Security Assets" is accurate and does not include too many hosts or ignores others.
• If intrusion detection events or the Log Correlation Engine is also in use, an event analysis for security, compliance and even network management issues can be conducted.

For More Information

Tenable recommends the following resources for learning more about SCADA security monitoring:

• Digital Bond blog
• Tenable White Paper: Protecting Critical Infrastructure (free download)
• Tenable White Paper: Real-Time Compliance Monitoring (covers NERC regulations. Contact sales to request a copy)

I'd also like to recommend the S4 conference (PDF brochure) coming up in January of 2007 in Miami. This is a technical conference and covers a wide variety of SCADA security topics.

Tenable's CSO, Marcus Ranum, discusses many of the trends, assumptions and misconceptions about computer security facing us today. Mr. Ranum discusses why security mechanisms fail and why it is such a hard state to be "secure". Slides and audio are available below:

Tenable has made an RSS feed of vulnerability plugin updates available for the Passive Vulnerability Scanner. The feed is located at:

http://www.tenablesecurity.com/pvs.xml

Tenable customers who manage their PVSs with the Security Center automatically synchronize with the latest checks daily. However, if a new vulnerability check is available that is of interest, you can force an update under the "Force Nessus Plugin Update" link under the "Policies" tab.

Tenable also offers a feed for Nessus plugins located at:

http://www.nessus.org/rss-plugins.xml

This includes information about plugins from both the direct and registered feeds.

If you are performing credentialed patch audits with Nessus, you can also create an inventory of installed software on each of your UNIX and Windows hosts. This blog post will review how Nessus can perform these tasks and what you can do with the results.

Finding Software on UNIX and Windows Systems

For Windows servers, Nessus plugin #20811 will enumerate all of the installed software by considering the "Uninstall" values set in the registry. This technique won't detect a simple executable present on a system, but it will find just about any piece of software that uses an installer. This particular check uses registry calls because it is intended to be generic. Other checks that Nessus performs to look for a variety of patch audits, questionable applications or specific versions of software consider both registry settings and analysis of local files such as DLLs. 

For auditing UNIX software, the default "command line" technique to enumerate managed applications is considered. Nessus plugin #22869 performs this task. For example, on Red Hat based systems, a list of RPMs is obtained through the use of the rpm command. This technique is quite fast and is intended to report just the applications that the OS is tracking. It won't enumerate software that was placed just as a binary or which was compiled natively on the system. Also, unlike Windows software enumeration many "applications" which were installed with the base OS will also be enumerated, creating very verbose lists of software.

Configuring a Nessus scan

Nessus scans should be configured for remote credentials for the target UNIX or Windows machines. For UNIX, this means an SSH account which can run commands such as "rpm". On Windows, this means an account that has access to the registry (although for full and reliable patch audits, Tenable recommends a domain account which can read files).

On Windows, plugin #20811 can be selected individually, or by enabling the entire "Windows" Nessus plugin group. For UNIX, plugin #22869 can also be run individually, but if you want to complement an existing patch audit, this plugin is part of the "Generic" plugin family.

Dynamic Asset Lists and Ad hoc Searches

If you are using the Security Center to manage multiple Nessus scanners or for sharing the scan results with different auditors and departments securely, the list of installed software can be very useful.

Below is a screen shot of a list of installed applications on a fairly bare Windows 2003 server:

A quick analysis of this will see that VNC 4.1.1 is installed and that it is the free version. Data like this can be very useful for a variety of tasks such as:

• verifying compliance with software licenses
• verifying compliance with corporate policy
• identifying potential vulnerable applications which aren't running
• identifying lack of required software

The Security Center can be used to quickly display or report all hosts that have certain types of software installed on them. If the software is Windows, type plugin ID #20811 into the plugin ID field of the Cumulative Database or Scan Results filter, and then in the "Search Vuln Text" field type a string which represents the software you are looking for. You might not know the exact string to search for unless you see it in a listing from a scan.

The Security Center can also be used to take this content and create a dynamic asset list of all systems that have (or don't have) specific installed software. In the image below is an example rule which combines plugin ID #20811 and a simple pattern search for "VNC Free Version 4.1.1".

This rule gets applied each time a scan is accomplished and creates a dynamic list based on the results. This means that every IP address that matched this criteria would be added to the list as shown below:

This is a list of vulnerability severities by asset group and the second to last group is our system with VNC 4.1.1 installed.

It might be more interesting to find servers that didn't have this installed. Since we have a regular expression engine available for pattern matching, a dynamic asset rule could be created with the following string:

20811:(?s)^((?!VNC Free Edition 4.1.1).)*$

In the Security Center dynamic asset rules interface, this would be entered as a "regex" type of match. This code matches strings which don't have the string "VNC Free Edition 4.1.1" in them. Under the Security Center's dynamic asset rules engine, we couple this with the specific Nessus ID of #20811. Writing the pattern with a preceding "20811:" string tells the engine to only apply the match to vulnerability data a host may have for just that particular ID. Also adding a generic match for plugin ID #20811 is an easy way of only listing Windows hosts for which we have software enumeration data. Otherwise, we'd have many matches for our Cisco routers, Linux servers and so on which didn't have this code in plugin #20811.

Conclusion

These software enumeration plugins can provide a great deal of information which is extremely useful for auditing remote hosts. Audits can help find illegal software, misconfigured hosts and can help identify classes of servers by technology or function.

Tenable has released several new PRM libraries and TASL scripts. This blog entry details the changes and how Tenable customers can obtain them.

PRM Updates

dns_bind.prm

New rules to parse zone transfer updates.

Added rule for generic "IP deny" events.

firewall_cisco_pix.prm

Added rule for generic "IP deny" events.

firewall_netscreen.prm

Added rules to detect authorized SNMP polling and running policy configuration changes.

mail_postfix.prm

Added rule to process rejected logs due to Spamhaus filtering.

nbad_arbor.prm

This new library has rules to parse events from the Arbor network behavioral anomaly detection products. Incidentally, the nids_stealthwatch.prm was renamed to nbad_stealthwatch.prm.

os_win2k_sys.prm

New rules were added to identify unexpected Windows service crashes, as well as application faults due to failed memory write attempts. These may be generated by failed buffer overflow or worm attacks. These events are also consumed by the new windows_crashes_and_restarts.tasl script that looks for these events occurring across multiple hosts.

PRM_mappings.prm

This PRM library does not contain any rules, but does include a list of all PRM IDs used by all libraries. This is useful to have for TASL writers and for choosing new IDs for new PRM rules.

router_cisco.prm

New rules for "RSH" connection attempts as well as link "up" and "down" messages.

ssh_openssh.prm

New rule added for processing of user login attempts which don't have executable shells.

virus_clamav.prm

A new PRM library to analyze logs generated by the Clam Anti Virus application. Multiple PRM rules are used to normalize detected viruses as Trojans, Worms, Phishing attempts and so on.

vpn_cisco_concentrator.prm

The regular expressions were modified to handle logs from systems specified by an IP address or a DNS name. Also, administrator login success events and failures now generate specific events.

TASL Updates

detect_change.tasl

Now processes change detection events for NetScreen firewalls.

ids_event_followed_by_change.tasl

This TASL has been updated to include alerts from Arbor devices. In addition, it now also considers normalized Snort IDS events for detected executable code in motion.

standard_deviation_long_term.tasl

This TASL has also been updated to include alerts from Arbor devices.

windows_crashes_and_restarts.tasl

This TASL looks for many different types of Windows events, including new events added to the os_win2k_sys.prm library. These rules identify unexpected Windows service crashes, Windows restarts due to crashes as well as application faults due to failed memory write attempts. These may be generated by failed buffer overflow or worm attacks. The script looks for these events occurring across multiple hosts.

Obtaining These Rules

To obtain a particular PRM library, a user can use the UNIX wget program to load the file directly from the www.tenablesecurity.com web site. below is an example of a user obtaining the os_linux.prm file:

wget http://www.tenablesecurity.com/os_linux.prm .

The period is needed and means to place the file in the local directory. If this command were executed from the /usr/thunder/daemons/plugins directory, a user would just need to make sure the file is owned by user 'thunder' and then restart the thunderd service. To restart the Log Correlation Engine, please run:

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

The TASL scripts are available for web download from:

http://cgi.tenablesecurity.com/tasl.html

Individual scripts can also be obtained with the wget tool in a similar manner. Here is an example download of the Windows Event Correlator script:

wget http://www.tenablesecurity.com/os_linux.prm . http://cgi.tenablesecurity.com/tasl/windows_event_correlator.tasl

As with PRM libraries, if this command were executed from the /usr/thunder/daemons/plugins directory, a user would just need to make sure the file is owned by user 'thunder' and then restart the thunderd service.