Securing SCADA: Compensating Controls

Thursday, April 11, 2013 @ 02:04 PM gHale

Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
When it comes to patching in SCADA and industrial control systems, there are pros and cons of using compensating controls as an alternative.

We all understand why rapid and continuous patching just won’t work on the plant floor. Fortunately, there are alternatives – otherwise known as “compensating controls.”

In the telecommunications industry, compensating controls are widely used to safely delay patch deployments so they can be incorporated into regular maintenance schedules. For example, telecommunications equipment vendors often suggest configuration changes that will block exploits of a known vulnerability without requiring a patch. Microsoft also offers this service to customers – included in most Security Bulletins is a section called “Workarounds,” which they define as:

Making Patching Work for SCADA, ICS
Good, Bad and Ugly of SCADA, ICS Patching
SCADA Security: Open Phishing Season
IF-MAP for ICS, SCADA Security

“Workaround refers to a setting or configuration change that does not correct the underlying vulnerability but would help block known attack vectors before you apply the update.”

So far, only a few SCADA/ICS vendors have offered this strategy, but the possibilities are numerous. For example:
• Product Reconfiguration (e.g. Disable the HTTP port)
• Suggested Firewall Rules (e.g. Block all HTTP traffic)
• Suggested IDS Rules/Signatures (e.g. Install signatures for logins using a default password)

Basically, these controls aim to prevent any potentially “dangerous” traffic from getting to the device in the first place. In other words, if you can’t directly fix the flaw, remove the conditions where it could occur.

Advantages of Compensating Controls
The compensating controls strategy offers some clear benefits for vendor and customer.

Compensating controls are safer. Patches that turn out to be flawed usually cannot be removed from a system. However, removing an incorrect compensating control is often trivial.

Compensating controls put the asset owner in control of his/her fate. Patches can affect the entire operating system in a controller or computer. This often results in unintended consequences that are hard to predict. By using a compensating control, such as blocking a vulnerable service, it is easier to understand the impact on the industrial process.

Compensating controls can be released independently of product development and typically require less QA effort. This translates into a faster response to the customer’s security needs.

Compensating controls are independent of the product firmware. This means they often have less impact on product functionality, lowering customer resistance to using them. Finally, this strategy allows support of legacy products that are too old to justify the effort of a full firmware release.

Limitations of Compensating Controls
Of course, there are some limitations to this strategy. For example, vulnerabilities that involve encrypted sessions (such as HTTPS) often cannot be addressed with compensating controls – because it can be difficult to decrypt and inspect the traffic. But for a large number of the PLC and DCS vulnerabilities we have seen, the technique works well.

Requirements for Success
For compensating controls to work on the plant floor, there are a number of key requirements.

First, they must have a low impact on process reliability and safety. Any security “solution” that impacts process reliability or safety will be rejected by the end user.

Second, they must be simple to deploy. In the words of a manager of a chemical company to the ISA99 Committee on Control System Security: “We have to make this [security] something a plant superintendent, engineer, or senior operator can do in their spare time, or it will flop.”

For example, if the compensating control involves hardware, then the field technician should be required to do no more than:
1. Attach the hardware to a DIN rail or panel.
2. Attach instrument power.
3. Plug in network cables.
4. Walk away…

Good examples of this “Zero Configuration Deployment” strategy are the “Fixed Configuration Firewalls” offered by a number of Safety Integrated System (SIS) vendors. These firewalls contain factory configured protocol and signature rule sets designed specifically to match product and vulnerability requirements. They require no configuration by the end user – they just work out of the box.

But that isn’t the only benefit.
• Compensating controls are easy to install.
• Compensating controls can often be installed in a live system without requiring a shutdown.
• Compensating controls are easily upgradeable to address new threats as they appear.

Compensating Controls Strategy Secures Exposed PLCs
An excellent example of how compensating controls can quickly defend against vulnerabilities was demonstrated by Schneider Electric in late 2011. In December of that year, security researcher Ruben Santamarta publicly disclosed details of multiple vulnerabilities in Schneider’s Modicon PLC product line.

At the time of the disclosure, Schneider had produced a fix for two of the reported vulnerabilities, but was still working on patches for the others.

To help customers secure their PLCs while the other patches were being developed and tested, Schneider produced a guide entitled “Mitigation of the PLC Vulnerabilities Using a Tofino SA.” This detailed guide explained how to use an industrial firewall to filter out harmful traffic before it reached the PLC.

Special Rules for Complex Issues
In the Schneider Electric example, some of the mitigations were pretty simple to create. For example, blocking a debug service vulnerability was simple. All the user had to do was install a firewall. As long as they didn’t specifically add rules allowing the debug traffic, the vulnerability was mitigated.

Other mitigations can be more intricate.

For example, the FTP Buffer Overflow vulnerability (ICS-ALERT-12-020-03) could have been addressed by just blocking all FTP traffic. Unfortunately, since FTP traffic was essential for some processes, that approach wasn’t acceptable to Schneider’s customers.

Instead, we worked with Schneider to create “Special Rules.” These rules contained algorithms that looked specifically for the behaviors that suggest the FTP protocol is being exploited. If this behavior is discovered, then FTP messages are immediately blocked by the firewall.

Using Security Profiles with Compensating Controls
All these mitigations were easy to deploy through the use of “Security Profiles.” A security profile is a collection of firewall rules, special rules, and protocol definitions designed to address the vulnerabilities for a specific control product. The profile can also include complex checks that a traditional firewall cannot achieve.

Combining the security profiles with the firewall allowed Schneider to provide a defense for their customers. A defense that was immediately effective – and that did not require any changes to automation equipment or network configurations. Schneider clients could download a single, easy-to-deploy package of tailored rules they could deploy without impacting operations.

Site engineers could confirm the new rules would not harm their operations. As a result, industrial facilities can defend themselves against new threats without having to rely solely on patches for their PLCs, DCS and network hardware.

Strategies for Secure Control Systems
There is no denying SCADA and industrial control systems are difficult and risky to patch rapidly. Patching can work – but only when it is based on proper change control and aligns with maintenance schedules.

Furthermore, a patch strategy depends on the rapid release of well-designed and tested software updates for all control products as vulnerabilities are discovered. In my experience, when looking for a way to secure SCADA and industrial control systems, adopting a compensating controls strategy is a much more flexible and much less risky alternative.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.

Leave a Reply

You must be logged in to post a comment.