your letters | Readers Respond

InTech, Aug 2007 by Bowen, David J, Byres, Eric

PLCs, protocols, and flaws, oh my

I1 and my colleagues, was very interested in the article "The Line" in the March InTech. In that article Eric Byres mentioned CERN had tested "25 industrial control devices (mostly PLCs)." I was wondering if you were able to provide me with information that showed which PLC's were tested, what network type and protocol was used (Ethernet/Profibus, etc - I presume Ethernet TCP/IP), and what flaws were found.

I may be naive, but access to the PLC requires very specific information regarding the protocol and machine code within the PLC, even we (as control systems engineers/programmers) do not work at this level, except with the specialty tools. As far as I know, there are no virus/worms that target PLC's and no AV software to combat them. Even if someone gains access to the PLC, what can they do? PLC code should be robust enough to detect equipment failures and take appropriate action. The only way this could be upset would be code modification (requiring the Vendors programming software). Surreptitious code modification, I am sure, would generate memory checksum failures, shutting down the controlled system.

As for a nuclear power plant having a safety display, well a display by implication is not a safety device; it is merely a window into the safety control system. Even if the display (and I presume here a HMI/SCADA device) was locked, the design of the plant safety/control system should not have been compromised; if it was, it did not meet the required SIL rating.

As far as use of multiple firewalls and patch management, I can understand this, but one needs to weigh the risks at the end of the day. Are we not starting to over complicate things when we need a WSUS server in a control environment? After all, most of these networks are managed by the plant maintenance or external controls specialists. One should not allow a corporate IT dept. to issue Windows patch updates to a "live" control system attached to its network. This would almost certainly lead to SCADA failures (probably through increased security patching). The deployment of AV software is OK, and virus image updates should be OK, but AV software patch updates may cause issues too and need to be managed not automatically applied (and not by the IT dept).

Segregation, in my view, is always best, but in today's world of MES and VPN/ RAS/WiFi connectivity, this will always be impossible to achieve without a router and firewall. The question would be who manages this firewall: control specialist or the Corporate IT (MIS) department? Maybe two firewalls would be the correct solution here - one managed by the MIS, the other the Control specialist.

Don't get me wrong, security is required, but how far should one go? Let's not get too paranoid. The first line of defense is sound engineering practices for the IT, control, and safety systems.

It would be appreciated if you could provide any additional information relating to this topic. I and the company I work for, Controlsoft Pty Ltd, are committed to providing safe, sound and reliable controls systems, but with an easy to implement and manage/maintain philosophy. I am sure any information you can provide will only serve to enhance this.

David J. Bowen, senior project engineer

Response:

Thanks for the e-mail regarding my article "The Line." You bring up a number of interesting points, which I will cover below.

First, regarding the CERN testing, my information comes from several papers CERN has published in the past few years and my personal work with them. The most accessible paper can be downloaded at http://ethernet.industrialnetworking.com /articles/articledisplay.asp?id=1490. For specific details on what PLC's were tested, what network type and protocol were used, and what flaws were found, you will have to ask CERN as it is their data, as I am not authorized to release it.

My own testing while at BCIT and the work of others has shown PLCs and RTUs are not difficult to attack. These devices use standard operating systems such as VXworx that are very well known in the hacking community. As for virus/worms that target PLC's, there have been several researchers (including some of my former staff at the BCIT Labs) who have demonstrated these are simple to write. No responsible researcher releases these example SCADAworms into the "wild," so they remain safely in research labs, but it is only a matter of time before someone malicious writes one (if they haven't already). In fact, detailed presentations on how to exploit SCADA vulnerabilities have been given at public conferences such as BRUM2600, ToorCon 2005, and Blackhat Federal, to name a few. (These three hacker presentations are on the web, and if you want to download them the URLs for them can be found at http://www.byressecurity.com/.)

I agree one should not allow a corporate IT dept to issue Windows patch updates to a "live" control system with out very specific safe guards. That said, many major companies have successfully sent up patch management systems that are specific for process control and have publicly shared why and how they do it. For example, at ISA EXPO 2006, Dow, Procter and Gamble, and Astra Zenica gave talks on their use of patch management in control system. These companies clearly did weigh the risks and decided that patching could be done safely AND was far better than no patching at all. Based on my research, I completely agree with them - I am aware of at least 60 incidents where viruses or worms impacted control systems in the last five years and in one case the losses exceeded $14 million.