Recently the Energy Sector Control Systems Working Group (ESCSWG) published a cyber security procurement guideline. Readers who paid attention to detail may have been left scratching their heads. Here are some items that caught our attention.

Ill advice #1: Use Internet-routable IP address ranges

Contemporary Distributed Control Systems, SCADA products etc. are usually (pre-) configured with IP addresses by an integrator. ESCSWG favors routable address spaces:

“2.7.9. The Supplier shall verify that the procured product allows use of unique routable network address spaces (i.e., address spaces other than 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8 must be supported) that work within the Acquirer’s network. Where this is not available, the Supplier shall offer an alternative approach, with mitigating security measures, that is acceptable to the Acquirer.”

From a cyber security point of view, using Internet-routable IP addresses for DCS servers, HMIs, controllers etc. is a bad idea as such target systems should never be Internet-accessible, and where wide-area networking is used at all, that a solid concept of firewalls and DMZs is in place. The irony here is that a government agency that participated in the procurement guideline (ICS-CERT) just recently felt urged to remind asset owners that control systems should not be facing the Internet.

In the RIPE Plant Planning Guide, there is a strict rule that only non-routable address space is used for industrial control systems.

Ill advice #2: Bless anti-virus as the major means for malware prevention

When it comes to endpoint protection, ESCSWG puts all eggs in the basket of anti-virus. Whitelisting is only mentioned as an optional measure of last resort:

“2.8.2. The Supplier shall implement at least one of the following:

  • Provide a host-based malware detection capability. The Supplier shall quarantine (instead of automatically deleting) suspected infected files. The Supplier shall provide an updating scheme for malware signatures. The Supplier shall test and confirm compatibility of malware detection application patches and upgrades.
  • If the Supplier is not providing the host-based malware detection capability, the Supplier shall suggest malware detection products to be used and provide guidance on malware detection and configuration settings that will work with Supplier products.
  • If the Supplier is not providing a host-based malware detection capability, nor suggesting malware detection products, and if specified by the Acquirer, the Supplier shall provide an application whitelisting solution that is tested, validated, and documented that shall only permit approved applications to run.”

The general problem with malware in control system environments is that anti-virus products will never be able to detect and quarantine sophisticated malicious software. As a case in point that is documented in our Stuxnet analysis, the first version of Stuxnet was rubbed in the face of the global AV industry on VirusTotal but was identified as what it is only five years later, and only because the attackers were lazy or bold enough to leave unneeded code in the payload of a later version that grabbed the attention of virus researchers because of its abundance of zero-day exploits.

As experience has shown, IT-style malware that AV products detect with some reliability and little latency is of remote relevance in production environments. Yes, it may cause several hours of downtime. No, it will most likely never result in a critical or catastrophic plant state. On the other hand, control system environments differ from IT environments in the way that in the former, there is no place for unauthorized software at all, be it a known malicious worm or a non-malicious interactive game, media player, personal diet and workout planner etc. The latter collection will never be caught and prevented by AV as it doesn’t qualify as malware, but still has no place in a control system environment if only for the reason that such software products usually introduce their share of vulnerabilities that would need to be patched.

The bottom line is that whitelisting must be the number one option for control system environments, as only whitelisting catches any kind of unauthorized software. It also introduces the benefit that maintenance personnel becomes aware that updating legitimate software requires a change management process. It can also be demonstrated that the Total Cost of Ownership of whitelisting solutions usually is well below that of AV solutions.

In the RIPE Plant Planning Guideline, whitelisting is the premier method to assure configuration integrity.

Ill advice #3: Minimize the range of your wireless network

This one is pretty bizarre:

“6.1.4. The Supplier shall document the range of the wireless devices and verify that the range of communications is minimized to both meet the needs of the Acquirer’s proposed deployment and reduce the possibility of signal interception from outside the designated security perimeter.”

The idea of this provision seems to be that by limiting the range of wireless transmission to the facility’s fence, the risk of rogue WLAN intrusions can be eliminated. The problem is that WiFi is different from lightsabers in the sense that radio waves don’t have a sharp end point but extend to infinity. It is mostly a matter of antenna technology where a usable signal can still be picked up. Don’t engineers who participated in the procurement guideline know that?

In the RIPE Plant Planning Guideline, WLAN is generally prohibited for process networks. Where WiFi must be used for operational reasons (e.g. moving stations such as forklifts), it is mandated that such wireless networks are strictly segregated from the wire-bound network.

The bottom line

The fact that a particular ICS standard or guideline is issued by a government agency, or a multi-agency workgroup, doesn’t imply that it’s sound or useful.