Nessus is a vulnerability scanner that offers many features to help assess the security of control system networks, devices, servers and workstations. Nessus is an active scanner featuring high speed discovery, configuration auditing, asset profiling, sensitive data discovery and vulnerability analysis. Basic vulnerability scanning has crashed many control system devices and applications but new features and techniques make it possible to scan control system networks with minimal impact.
Control System Intelligence
In addition to its low impact vulnerability scanning features, Nessus contains specific control system intelligence in the form of Bandolier security audit files for control system applications and the SCADA Plugins family.
Bandolier is a Digital Bond project funded by the US Department of Energy that creates Nessus security audit files for control system applications. Using the Nessus policy compliance plugins, the audit files report whether the server or workstation is in an optimal security configuration. See additional information in the Policy Compliance Plugins section.
Digital Bond works with Tenable Security to create SCADA plugins for the Nessus scanner. The plugins identify a variety of control system applications and protocols. They also identify known vulnerabilities and default passwords for some control system devices.
Nessus Credentialed Scanning is a safe and effective way to assess the security posture of a servers, workstations, databases, and network devices. As the name implies, credentialed scanning offers a mechanism to authenticate to the remote operating system. Because it makes an authenticated connection, the scans are much faster, more accurate, and have minimal impact.
A simple example exists with port scanning, a basic vulnerability assessment technique. A full port scan of all 65,535 TCP and UDP ports requires a great deal of time and can be taxing for the network and remote machine. This type of scan can be high impact for any system, but is especially dangerous on fragile control system networks and devices. When credentials are provided, the stress is completely removed from the network and remote machine. Nessus can use WMI for Windows or netstat for UNIX to retrieve a list of ports. This happens quickly and with little more impact than an administrator using the same commands at the server console.
Credentialed scanning is often more accurate than unauthenticated network scanning. A simple example of this is evident in UDP port scanning. Because of the way the protocol works, a UDP port scan considers a port open if there is no response. UDP ports can also be filtered. These factors make UDP port scan results unreliable and often inaccurate. Credentialed scanning eliminates the guess work involved with identifying open UDP ports.
Identifying missing security patches is also more accurate and thorough using credentialed scanning. The primary reason for this is that not all vulnerabilities are discoverable from an unauthenticated network scan. Some vulnerabilities are local issues such as privilege escalation while others are problems with client software that may not listen on a network port and are therefore not discoverable from the network. A network scan, for example, would not be able to identify that the browser used on an HMI was vulnerable. An attacker could impersonate a local web-based resource or entice an operator to visit an infected site and compromise the HMI via a browser exploit.
If a machine has already been compromised, rootkit software could provide misinformation. An example of this is if an attacker replaced the netstat executable with one that hides the ports used to control the machine. Credentialed scanning is sometimes questioned because of this possibility. Credentialed scanning should be used as part of an overall security strategy and is not a replacement for full vulnerability assessments or network protective measures that would help identify and prevent a rootkit scenario.
The following sections describe different types of Nessus credentialed scans in more detail.
Policy Compliance Plugins
The Policy Compliance plugins (also referred to as compliance checks or configuration audits) allow a server or workstation to be compared against a policy – be it an established industry standard, local security policy, or custom policies such as those available from Bandolier. The policies are contained in audit files. Nessus compares the values in the audit files to those on the remote machine to determine if it is in the desired configuration.
There is an important difference between compliance checks and traditional vulnerability scanning in Nessus. Each has its own distinct purpose and value. Vulnerability scanning relies on a set of signatures of “known bad things”. The compliance checks, on the other hand, compare a system against the “known good”, hardened configuration. It does this by creating an authenticated administrator connection to the system and inspecting its configuration. Once authenticated, any number of things can be evaluated – user accounts, registry settings, configuration file settings, system settings, permissions, etc. There are also special policy compliance plugins that allow auditing of SQL databases and Cisco IOS devices (routers and switches).
Bandolier provides customized Nessus audit files built specifically for popular control system applications. Digital Bond works with the application vendors to identify the optimal security configurations for their products and capture those in Nessus audit files.
Policy Compliance Examples
Compliance checks are capable of checking many built-in settings at the operating system level. They can also read and evaluate files which makes the number and types of checks available almost limitless. While the examples below do not represent the full array of checks that are available, they highlight the capability of the checks starting with basic service evaluation to very specific application configuration inspection.
Example 1: Service Auditing
The first example shows how the policy for a particular Windows service is audited. In this case we are validating that the SCADA Control Service is set to “Automatic”. In other cases we may want to specify that a service should be “Disabled” or “Manual”.
<custom_item> type: SERVICE_POLICY description: "Verify that the SCADA Control service is set to automatic" value_type: SERVICE_SET value_data: "Automatic" service_name: "SCADAControlService" </item>
This example shows a service audit for a Linux system.
<custom_item> type: CHKCONFIG description: "The crond service is required for proper operation of the SCADA application. This check verifies that it is enabled" service: "crond" levels: "2345" status: ON </custom_item>
Example 2: Password Policy Auditing
Checking the password policy is an important part of any security audit. This example shows a simple check for minimum password length of at least eight characters on a Windows system.
<item> name: "Minimum password length" value: [8..MAX] </item>
The Linux equivalent is very similar.
<item> name: "minimum_password_length" description : "Minimum password length" value : "14..MAX" </item>
Example 3: File Content Auditing
Since the checks can read files and perform regular expression matching, configuration files such as the one below can be evaluated. In this case the audit validates that an Apache server security directive is correctly set.
<custom_item> type: FILE_CONTENT_CHECK description: "Verify that Apache security enhancements have been made as recommended by security best practice and the application vendor." value_type: POLICY_TEXT value_data: "C:\Program Files\Apache Group\Apache2\conf\httpd.conf" regex: "^[^#]*ServerSignature .*" expect: "ServerSignature Off" </custom_item>
In this example, a control system application-level authorization setting is audited.
<custom_item> type: FILE_CONTENT_CHECK description: "Determine if permissions are set correctly for the RealTime Server (bobjAcknowledge)" value_type: POLICY_TEXT value_data: "c:\program files\ControlSystemApp\config\Realtime.cfg" regex: "bobjAcknowledge.*" expect: "bobjAcknowledge, Permission - Control_SCADA" </item>
The screen capture below shows the Policy Compliance plugins in the Nessus scan policy.
Nessus Policy Compliance Plugins
Database Policy Compliance Plugin
With the Database Compliance Plugin, Nessus authenticates to the database over the network and issues SQL commands to audit database security settings or other values stored inside the database. This means that important database security settings can be audited. It also opens up the possibility of auditing application-level settings that are stored in the database. What follows is a simple example of auditing a control system application setting in a database.
For this example, we want to verify that an operator audit trail is enabled for the HMIs. We know there is a setting in the GUI that dictates audit logging and that the value is stored in a database. The setting allows for different levels of audit logging but we want to just verify that is it not disabled.
The first step will be to identify the table and test an SQL query to pull back the information we want to evaluate. We find the value in the t_hmi_cfg table and use this query:
select cfgvalue from T_HMI_CFG where cfgname like ‘audit-trail’;
The query brings back the value ‘1′. Through a series of changing the value in the GUI and running this query, we learn that the value is ‘0′ when audit logging is disabled. We can then write a Nessus database audit check to verify that the value is set to something other than ‘0′. Here is the audit check:
<custom_item> type : SQL_POLICY description : “Verify that the audit trail is enabled for operators.” sql_request : “select cfgvalue from T_HMI_CFG where cfgname like ‘audit-trail’;” sql_types : POLICY_VARCHAR sql_expect : regex: “[^0]” </custom_item>
Cisco IOS Policy Compliance Plugin
A special Policy Compliance Plugin also exists for auditing Cisco router and switch configuration. This plugin authenticates to the Cisco device with SSH, elevates privileges to enable mode with a password you provide in the policy, and then inspects settings based on the audit file you indicated. Tenable provides baseline audit files for IOS industry concensus guidelines, but a user can also create custom audit files.
For this simple example, we want to verify that the substation ACLs are correctly configured. Here is the ACL from the Cisco config:
ip access-list extended smith-substation-acl permit tcp host 10.0.200.1 host 192.168.30.22 eq 20000 permit tcp host 10.0.200.2 host 192.168.30.22 eq 502
Here is the audit check syntax we would use to verify that these rules, one allowing DNP and one allowing Modbus, are configured in the ACL:
<item> type:CONFIG_CHECK description:”Smith Substation ACL Check” context:”ip access-list extended smith-substation-acl” item:”permit tcp host 10.0.200.1 host 192.168.30.22 eq 20000″ item:”permit tcp host 10.0.200.2 host 192.168.30.22 eq 502″ </item>
The Nessus credential checks can also be used to identify missing security patches. The local security plugins check for missing operating system and application patches, including many popular client applications that are often overlooked. Using this Nessus feature can help verify that control system servers and workstations are updated with the current security patches.
Nessus Patch Check Plugins for Windows
Netstat and WMI Port Scanning
Nessus also has the ability to use the authenticated connection to do a “netstat” port scan. This is a safe way to enumerate open ports without a traditional port scan that has been known to crash some control system applications. As the name implies, on Unix systems the command netstat -an is invoked to return the results. For Windows, WMI is used to return the same information.
The authenticated netstat and WMI port scanning offers a safer, faster, and more accurate method than traditional network port scanning. Many fragile control system devices and applications will crash when scanned in the traditional method. Using netstat and WMI, the impact to the machine is no diferent than having an administrator issue those commands on the local console.
One caveat for Netstat and WMI port scanning is that, if the machine has been compromised and has a rootkit present, these utilities are often manipulated to provide false information. Often rootkits will hide the network ports that are being used for remote control. However, a traditional port scan may also miss the remote control channels as it is often not possible to scan all 65,525 TCP and UDP ports. A complete network security program will have other methods is place to help identify malicious traffic.
Nessus Port Scan Options
Using a combination of the Nessus credential scanning features can produce a useful report that often gives more insight into the security posture of the machine than a traditional scan. Combining the Bandolier security audit files, netstat port scanner, and patch auditing yields a report that is also useful for NERC CIP compliance. The amount of information that is returned using the credentialed scanning is thorough and detailed. It is typically more accurate than traditional network scanning which often requires manual follow-up and verification of reported vulnerabilities.
Sample Nessus Report
How it Works
For both Windows and Unix, the Nessus scanner requires only one open port to perform the authenticated scans.
For Windows hosts, Nessus uses Server Message Block (SMB). To do so requires the ability to communicate with the remote host on TCP port 445. The user account defined in the scan policy needs to have administrator privileges. This port is commonly open and is required for normal Windows communication.
For Unix and Linux hosts, the Nessus scanner relies on Secure Shell (SSH), TCP port 22. Root access is ideal—either through the root account or an account capable of using su or sudo.
Nessus Client Showing Credential Input Screen for SSH
Non-credentialed scanning is network vulnerability scanning in the traditional sense. By examining how a computer responds to certain network queries, a the scanner determines if there is a potential vulnerability.
Vulnerability scanning works by comparing the network response of a computer to a list of signatures to determine if there is a vulnerable service, port, application, protocol stack, or operating system kernel. The signatures used by Nessus exist in plugins that are constantly updated. Tenable announced in January 2008 that there are over 20,000 unique plugins. The SCADA plugins are an example of vulnerability scanning customized for control system applications and protocols. Plugins outside the SCADA family will also work in control system environments by assessing for vulnerabilities in underlying applications and operating systems. An example would be a vulnerable web or FTP server — they certainly exist in control systems but are not unique to them.
Web Application Scanning
Beyond the hundreds of web and CGI vulnerabilities that Nessus identifies using signatures, it can also detect new web vulnerabilities using its web application test capabilities.
The web application testing first uses a the Web Mirror (webmirror.nasl) plugin to make a local copy of the website. It makes not of all the scripts in the site for later testing. The Nessus knowledge base becomes populated with all the scripts and forms and then runs through additional plugins in order to identify vulnerabilities.