Bandolier User Guide for Nessus
From SCADApedia
Bandolier helps asset owners and vendors identify and audit optimal security configuration for control system servers and workstations. In this Department of Energy funded project, Digital Bond partners with leading control system application vendors to establish practical security configuration guidance for SCADA, DCS, and other industrial control system components. Digital Bond then creates and distributes specialized security audit files that can be used with the Nessus vulnerability scanner. Bandolier, in conjunction with Nessus, is the most widely used security tool in industrial control systems.
This guide shows how to use Bandolier with Nessus.
Contents |
Nessus Compliance Checks
This guide provides enough information for an engineer or IT administrator to use the Bandolier security audit files with Nessus, but there is a great deal more information on installing and configuring the Nessus scanner available from Tenable Network Security.
The compliance checks are a subset of the Nessus credential checks. As such, much of the supporting documentation for configuring the Nessus scanner for Bandolier will be found in the document titled Nessus Credential Checks for UNIX and Windows.
The compliance checks test for compliance against a pre-defined policy. The policy is defined by the audit file that is selected in the Nessus client. Tenable provides many audit files for a variety of standards, operating systems, and applications. The Bandolier audit files make use of these and other industry consensus baseline security settings, but they add control system application checks and customize the baseline security settings as necessary for the control system device or application to work properly.
Prerequisites
The following subscription services are necessary to use the Bandolier audit files:
- Digital Bond Site Subscription
- Nessus Professional Feed Subscription
Many control system application also offer the Bandolier security audit files for their products directly. In this case, a Digital Bond site subscription may not be required.
Operational Requirements
- For UNIX hosts, an SSH server must be running and SSH communication (TCP port 22) must be allowed in the network path from the Nessus scanner to the target host
- For Windows hosts, SMB over IP (TCP port 445) must be allowed from the Nessus scanner to the target host
- Credentials for a user with Administrator privileges must available for use in the Nessus scanner
- Information regarding additional configuration requirements and user privileges can be found in the Tenable document Nessus Credential Checks for UNIX and Windows
Step-by-step Instructions
- Verify that you have access to the Bandolier audit files and a Nessus ProfessionalFeed subscription.
- Download the Bandolier audit files for your control system application from the Digital Bond website or from your vendor.
- If you haven't already, download and install Nessus according to the Nessus installation guide for the current version. The compliance checks work with the UNIX\Linux, Windows, and Mac OS X versions of the scanner.
- Verify that the appropriate network communication is allowed between the scanner and the target(s). (For UNIX, this will be TCP port 22, SSH. For Windows, it is TCP port 445, SMB over IP.)
- Verify that you have the appropriate user account information for accessing the target server or workstation. The authentication options are described in detail in the Nessus Credential Checks for UNIX and Windows document available on the Tenable website.
- Configure a scan policy in the Nessus client according to the directions in the "Example NessusClient Usage" section of the document Nessus Compliance Checks: Auditing UNIX and Windows Device Configurations available from the Tenable Support Portal.
- For Windows scan policies, enable the Remote Registry settings as follows:
- Under the Plugin Selection tab, expand Settings
- Select the four SMB Registry plugins
- Under the advanced tab, select the drop-down option for SMB Registry: Start the Registry Service during the scan
- Check the box next to: Start the Registry Service during the scan
- Execute the scan policy against the target host. (It is advisable to test the scan on a development, backup, or secondary server or workstation if available.)
Audit File Structure
The Bandolier audit checks for each application component are split between two files. One file contains checks that are more application specific while the other contains general operating system security checks. They are designated with the label App and OS, respectively. The example below shows how the audit files are divided for components of the Telvent OASyS DNA application:
OASyS DNA 7.5-Engineering Station-Windows Server 2003-App Checks.audit OASyS DNA 7.5-Engineering Station-Windows Server 2003-OS Checks.audit OASyS DNA 7.5-Historical Server-Windows Server 2003-App Checks.audit OASyS DNA 7.5-Historical Server-Windows Server 2003-OS Checks.audit OASyS DNA 7.5-RealTime Server-Windows Server 2003-App Checks.audit OASyS DNA 7.5-RealTime Server-Windows Server 2003-OS Checks.audit OASyS DNA 7.5-XOS Workstation-Windows XP-App Checks.audit OASyS DNA 7.5-XOS Workstation-Windows XP-OS Checks.audit
The App file reaches into the application level and inspect settings but also includes security guidance spelled out by the vendor or checks for supporting application such as web servers. Digital Bond developed all of the application level audit checks.
The OS file is a modified version of a .audit file originally written and maintained by Tenable Network Security, www.tenablesecurity.com . The original .audit file is copyright Tenable Network Security. Tenable has granted Digital Bond permission to make modifications to the original .audit file, to produce an updated .audit file, and to distribute this updated .audit file to its customers and partners. Tenable and Digital Bond maintain a collective ownership of this updated .audit file, called a Bandolier Security Audit File for OS checks. They are also easily modified for site-specific security policy or requirements.
Nessus can use one or both of the applicable audit files in one audit session. In fact, Nessus can run up to five audit files simultaneously and the results will display in a single report. The image below shows multiple audit files selected during a scan:
Check Documentation
For each check in an application audit file, there is a corresponding documentation page. Links to these pages will show up in the Nessus report that result from a Bandolier audit. The documentation pages, which are available only to Digital Bond site subscribers, include additional information beyond what displays in the report. This includes general background data, guidance on how to validate if a check has failed, and suggestions for remediation. A sample documentation page is available on the Digital Bond site.
In the Bandolier alpha release, only select pages will have the documentation pages and links in the Nessus report. The audit files and Digital Bond site will be updated over time to include the additional documentation for application level checks.
Report Analysis
It is unlikely that any deployed server or workstation will be 100% compliant at the first audit. Configuration change decisions should be evaluated against local security policy and business requirements. The host can then be re-evaluated for compliance.
There are several characteristics of each check that can help when evaluating what action to take based on an audit report. First, Nessus rates the check as high, medium, and low. Unlike traditional Nessus scans, however, these ranking are mapped as follows for the compliance checks:
- High = Non-compliant
- Medium = Inconclusive
- Low = Compliant
A non-compliant result indicates that the value or range of values defined in the audit file do not match the value or range of values at the target host. This generally means that the host is not configured according to the defined best practice. In certain cases, the setting may actually be more secure but just happens to not match the value. In other cases, it does indeed mean that there is a a configuration weakness that should be further examined.
An inconclusive result indicates that the particular check has failed. This can happen in a variety of scenarios. The most common cause is that the object, usually a file or Windows registry setting, could not be found. It could be that your application was installed at a different location and that some checks should be customized in your audit file.
A compliant result indicates that the value or range of values defined in the audit file match the value or range of values at the target host.
Each result color coded for easier reading on the report.
- Red = High (Non-compliant)
- Yellow = Medium (Inconclusive)
- Blue = Low (Compliant)
The image below shows a snippet of a Nessus report with a result of each type:
Each check includes the header that reads "Windows Compliance Checks" or "Unix Compliance Checks". This is the name of the Nessus plugin used to execute the audit files. Below that is the check number, a short description, and a link to additional documentation.
In addition to the Nessus classification, Digital Bond has developed a set of three Bandolier Severity Ratings: Severe, Moderate and Informational. In their final versions, each audit check will include this rating in the text that is part of the result.
Customizing the Audit Files
The Bandolier audit files are text files that can be edited or amended to match your security policy or business requirement. The simple example below shows how the values for password length and age are defined for a Windows system.
<item> name: "Minimum password length" value: 8 </item>
<item> name: "Maximum password age" value: 90 </item>
If a site-specific security policy specifies a minimum password length of 12 and a maximum password age of 30 days, those values can simply be edited in the Bandolier audit file.
For a slightly more complex application-specific example, consider this case where a configuration file is evaluated to determine if the bobjAcknowledge privilege is assigned only to the Permission - Control_SCADA group:
<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>
If the user group Permission - Emergency_Ops should also have the privilege, the check is modified to look like this:
<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, Permission - Emergency_Ops" </item>
To better understand how to modify and write your own checks, please see the document Nessus Compliance Checks Auditing UNIX and Windows Device Configurations. It can be downloaded from the Tenable support portal which is available to ProfessionalFeed subscribers.
See also
Cyber Security Audit and Attack Detection Toolkit
External links
Bandolier Sample Documentation Page
Digital Bond Site Subscription Information
