September 2011
By: Bill Lydon
His background is an important qualifier that lets you know what I already know - Eric Byres is a knowledgeable professional committed to the cause of industrial automation and SCADA cyber security. This is serious business.
Eric’s Comments: The “defense-in-depth” concept is to manage risk with diverse defensive strategies. It doesn’t just apply to cyber security – for example, banks employ defense-in-depth security measures to maximize their safety and security. Just to name a few defenses, a typical bank has steel doors, bulletproof windows, security guards, security box keys, safes and security-trained tellers.
Now layering defenses gives several benefits. The most obvious is that if one layer of defense is compromised, another defense, using a different security method, presents an additional obstacle which can inhibit further penetration. A more subtle, but equally powerful benefit is that attacks come in different flavors and each defensive layer can be optimized to deal with a specific range of threats. For example, defending against a standard computer worm needs different techniques compared to defending against a disgruntled employee.
Eric’s Comments: Every control system should use defense-in-depth architectures. Very critical safety systems just need more layers.
Consider the office environment. In addition to the corporate firewall, even the most unimportant office PCs will have personal firewalls, automatic patch systems and anti-virus software installed. This is a defense-in-depth strategy for office equipment. Now isn’t the PLC, DCS or the HMI more critical to the success and safety of the company, compared to say an intern’s desktop? Yet in most companies the PLC or DCS will be completely undefended, while the intern’s desktop gets hundreds of dollars (if not thousands) of security software and security resources thrown at it. We have our priorities all mixed up.
Eric’s Comments: They should be asking that the vendors equipment is ISASecure certified. Obtaining the ISASecure Level I certification is significantly more difficult than passing a Communications Robustness Test (CRT) like Achilles Level I (or II or III). It starts with a CRT assessment phase similar to Achilles Level I (it actually uses the Achilles tool), but then it adds two more assessment phases:
- Functional Security Assessment (FSA)
- Software Development Security Assessment (SDSA)
Eric’s Comments: NO – Computers with two network cards are known as “Dual-homed” and are widely seen as easy targets by the hacking community. For example, the following discussion can be found on the web by searching for the phrase “Dual-Homed Computers”:
Dual-home machines were also a significant factor with Stuxnet. I strongly recommend against the use of Dual-homed computers as a security mechanism in any control system.
Eric’s Comments: Malicious traffic can travel over a serial network just as easily as an Ethernet-based network. For example, the Slammer worm was able to infect a paper machine HMI via a dialup modem. Researchers have also shown how deliberately malformed MODBUS packets over serial can be used to crash PLCs.
Eric’s Comments: No – I can show you how to intercept most PLC passwords in under a minute. Dillon Beresford did the same with Siemens PLCs at the recent Black Hat 2011 conference. Most PLC passwords are just a dangerous placebo.
Eric’s Comments: Virtualization really doesn’t increase or decrease security risks. It can save you money for hardware, management and energy consumption, but for security it is pretty much even. After all, the hackers’ goal is typically to compromise an application on a server. He or she does not care what physical or virtual platform it is running on.
Eric’s Comments: Frankly it is still early days for IPv6 in the corporate network. Many major manufacturing companies I have talked to still have no plans to deploy it internally. Even fewer have plans to push it to the plant floor. So this is very new ground and “best practices” are really limited.
What I can say is as you noted, there is little chance that any manufacturing or process operation can do a wholesale IPv4 to IPv6 conversion. There are just too many legacy control products that will be stuck at IPv4 for decades. So this means any solution must be a coexistence solution and there are three approaches for this:
1.Dual-Stack
2.Translation
3.Tunneling
Translation in particular can have its issues (just like NAT in IPv4), especially with protocols like FTP or OPC were addresses get embedded in the message. So most of the applications I have seen in the ICS space involve the latter, namely tunneling IPv4 from an ICS network over an IPv6 corporate network. Standards like Host Identity Protocol (HIP) can be useful for sorting out this.
Bottom line is there is an interesting toolbox of IPv6 transition methods, but each is suited to certain scenarios. There is no single ‘best’ solution at this point.
Eric’s Comments: Not many dangers, but unless you are completely IPv6, there is little benefit. Right now, few vendors really support IPv6 on SCADA and control system equipment.
Eric’s Comments: Perhaps a little, but remember that Stuxnet made extensive use of Profibus to both coordinate attacks between infected PLCs and to eventually reprogram the drive controllers to damage the centrifuges. Basically, the improved security benefits are marginal.
Eric’s Comments: According to the ISA99.02.01 and IEC62443 standards, the first should be a Security Risk Assessment, a belief I share wholeheartedly. Unless you know the risks you are trying to mitigate, you are just throwing your money away.
Next, Vulnerability Analysis and High Level Security Requirements Analysis are needed. In other words, now that I understand the risks, what are my vulnerabilities and what must I do to address them at high level. Again, while some companies have the internal skills to do this, most need the help of a specialist team like exida.
Then we can start getting into the details and technologies. The first step is to design a security architecture/mitigation strategy and select specific security technologies to achieve their security goals. For example, these technologies might include:
- firewalls for SCADA/ICS traffic management (e.g.
- VPN technologies to secure traffic over networks like the Internet (e.g.
- access control technologies (e.g.
- anti-virus products
- patch management products
- security incident event monitoring (SIEM) tools
http://www.tofinosecurity.com/products/Tofino-Firewall-LSM)
http://www.tofinosecurity.com/products/Tofino-VPN-Server-and-Client-LSMs)
http://www.matrikonopc.com/products/opc-security/index.aspx )
This list can get long, but the above covers the main technologies currently used in modern SCADA and ICS systems.
It seems logical that cyber security risks for automation systems are growing with the incorporation of mainstream technologies by automation protocols including Modbus TCP, EtherNet/IP, PROFINET, WirelessHART, ISA 100, WIA-PA, and BACnet. A major enabler for hackers are the IT standards leveraged by these protocols including TCP/IP Ethernet, wireless Ethernet (802.11), Wireless Mesh (802.15.4), and 6LoWPAN.
The wider use of these standards outside of automation makes them targets for hackers.
IPv6 doesn’t seem to be a factor at this point that will affect automation networking. In fact none of automation network standards are IPv6 ready and in most cases it will require major structural changes in the protocols creating incompatibilities between the IPv4 and IPv6 versions. I still feel that this will become an issue at some point in the future.
It is clear that automation groups should have plans to protect systems from cyber threats and Eric Byres recommendations are a good starting point.
By Steven J. Vaughan-Nichols, October 14, 2010
Deploy CGN to Retain IPv4 Addressing While Transitioning to IPv6 (PDF - 490 KB)
