Bandolier

From SCADApedia

Bandolier is a Digital Bond research project that documents best security practice configurations for control system application components, and then program these configurations into audit files that can be used in Nessus and other leading vulnerability scanners. The policy compliance checks allow an asset owner to verify that their system is configured according to best security practice for both operating system and application security settings.

Bandolier audit files are used at initial deployment to verify a secure installation and periodically over time to determine if the security posture has degraded.

Bandolier is funded by the Department of Energy (DOE) and is Objective 1 of a larger effort known as the Cyber Security Audit and Attack Detection Toolkit.

1 Compliance Checks
- 1.1 Compliance Checks vs. Vulnerability Scans
- 1.2 Compliance Check Examples
2 Bandolier Schedule and Deliverables
3 Development Approach
4 See also
5 External links

[edit]

Compliance Checks

Tenable Network Security, along with organizations like NIST and the Center for Internet Security, have developed best practice compliance checks for many operating systems and common IT applications such as databases and web servers. The Bandolier project will use the same concept to develop files specifically for control system applications that reside on a variety of Windows and *nix platforms. The Bandolier audit files can be used with Nessus compliance plugins to compare a deployed control system component to the best practice security settings and identify any variances.

The Nessus compliance plugins are available to Nessus ProfessionalFeed customers. A ProfessionalFeed costs $1200/year and also provides immediate access to new plugins, support, and access to the SCADA plugins that Digital Bond developed for Tenable. With a compliance plugin, the Nessus Vulnerability Scanner can audit a system against a secure configuration as described in the policy compliance file. Bandolier will create the files so the Nessus Vulnerability Scanner can be used to audit the security configuration of the twenty-plus control systems applications that are part of the project.

Nessus is the de-facto standard for vulnerability scanning but there are other tools available that can perform similar functions. To provide maximum benefit and reusability for the community, Digital Bond will also make the compliance checks available in the XCCDF and OVAL formats. This is the format used by NIST's Security Content Automation Protocol (SCAP), and all SCAP validated scanners will be able to use the Bandolier audit files.

[edit]

Compliance Checks vs. Vulnerability Scans

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 scanning tests send packets to the device under scan that have caused many control system applications to crash or operate improperly.

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.

An example of the difference is the method to determine what services are running on a workstation or server. The vulnerability scan would send a packet to each TCP and UDP port and evaluate the response to determine if the port was open. Unfortunately even simple port scanning has caused numerous, poorly written control system applications to fail. The compliance check would connect to the workstation or server as an authenticated administrator, get a list of the services running, and return this information via the administrative connection. An application that would crash on a port scan would not crash when the same information was collected by a compliance check.

[edit]

Compliance Check 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.

[edit]

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>

[edit]

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>

[edit]

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>

[edit]

Bandolier Schedule and Deliverables

A list of all the Bandolier Audit Files is maintained on the SCADApedia. Digital Bond is committed to the following deliverables at a minimum and hopes to accelerate the schedule and increase the deliverables.

The first audit templates will be issued in July 2008.
Ten audit templates will be complete by October 2008.
Twenty audit templates will be complete by September 2009.

All deliverables will be available as Digital Bond Subscriber Content on Digital Bond's website. Each audit template will initially be provided in the Policy Compliance File format for Nessus. At a later time the audit templates will be available in XCCDF / OVAL format that can be imported into other scanners.

In addition to the audit files, documentation pages will be available on the control system application audit tests. Links to the applicable documentation page will be included in the audit results.

[edit]

Development Approach

[edit]

Step 1: Select the control system applications for project participation

There are some factors that make a control system application more applicable for the Bandolier project:

Select a control system application running on a relatively current operating system. For example, do not select a system running Windows 98 or NT.
Select a control system application or component that can be secured. An application that cannot be patched or must be configured in a highly vulnerable manner will be of little use. The audit will only verify it is an insecure state.
Select a control system application that is widely deployed. HMI or operator consoles are ideal candidates because this will allow a quick and consistent audit of many HMI workstations. Similarly, if the same DCS is being used at many power plants the systems than that DCS would be an ideal choice.
Select a critical control system application. This may be contrary to the previous criteria, but a critical control server might be a good candidate for a compliance policy file even if there is only a primary and backup server. The compliance policy file will identify if anyone has made changes to the secure configuration.
Similar control system application components with different configurations can have their own compliancy policy. An HMI might run the exact same software as an engineering workstation, but the permissions on the system could be quite different.

[edit]

Step 2: Develop a secure, hardened configuration for each control system application component

The goal is to create a gold standard configuration for each control system application component, e.g. HMI, Historian, Realtime Server, OPC Server. Deployed control system application components will be measured against the gold standard. This step is extremely important.

Ideally the SCADA or DCS vendor will assist in this step. Digital Bond's research team, the vendor and asset owner users work together to define the gold standard for Bandolier. NIST and CIS guidelines are used as a starting point for operating system and common IT applications, such as web servers and database applications, security configuration settings. They are modified as needed for the control system application to function properly, and then the control system application specific ideal security settings are defined.

It is important to understand that all Bandolier audit templates to not measure the same level of security. HMI A's gold standard may be much more secure than HMI B's gold standard because HMI A's vendor has leveraged operating system security features and build security features into HMI A. Bandolier templates attempt to identify the best possible security setting for each individual control system application component.

[edit]

Step 3: Digital Bond will develop the Compliance Policy Files

Once the secure, hardened configuration is available, Digital Bond will create the Compliance Policy Files. This will require a visit to the asset owner or vendor site to gather information on the secure, hardened system. Each system should take between 4 and 8 hours and will not require the asset owner or vendor to be involved, although they are welcome to be with Digital Bond during every step.

[edit]