[Editors note: On Aug. 10, Editor in Chief Walt Boyes wrote a SoundOff! blog post called, Security and Safety with Blood and Guts. In it, he recommends the monograph, Weapons of Mass Casualties and Terrorism Response Handbook by Charles Stewart, M.D., FACEP. The monograph, says Walt, is an absolutely terrifying look at what might happen if a terrorist attack on the control systems of critical infrastructure industries, or, God forbid, more than one attack, might succeed. The post generated quite a dialog. Were reproducing some of the best here.]
Francis L: When you say things like blow up a refinery, it suggests some software fault (caused by some hacker) might be able to do it. But, as you know, the ultimate protection (and a great deal of effort goes into it) is at the lowest physical level possiblerelief valves, for example, and hardwired logic, high-integrity safety systems, etc. I had this argument over Y2K many years ago. Dont you think you may be feeding the trolls?
Walt: No, Im not feeding trolls. Francis, I saw a live demonstration of a hack against a SIS system last week. It took 26 seconds to cause the valves to fail open. The danger is, in fact, real.
Francis: More details please, Walt. My mind boggles that anyone could engineer an SIS to permit such a hack, and how such an SIS could be called a safety system. Doesnt this situation imply a failure in the SIS (hacked or not) could open the valves? So how can it be called an SIS?
Walt: Your guess is as good as mine. Fact remains, this product is being sold as a SIS. I dont know the vendor. Anytime a SIS is connected to the plant network, it becomes open to an attack. Nearly all PLCs, including safety PLCs are vulnerable to DoS attacks unless properly firewalled.
Francis: Walt, Id like to briefly explain what Id expect to find in an SIS, and indeed what I thought they did. They used to have: 1) A physical switch, in fact, a key switch. Only when the key is inserted and turned to the Allow Program Change setting should it be possible to change the software that can open valves, etc. 2) The control logic must run independent of the network its connected to. Yes, the controller should expose the values of its variables and I/O to the network, but read-only mostly. The network should only write to the SIS values that cant override the safety. I really thought this sort of protection, and much more, were defined as paramount aspects of SIS design. Its impractical for PCs, but nobody would use a PC for an SIS, would they? As I said earlier, I worked on Y2K. I found that the people selling the disaster scenario had no idea what a process controller is.
Comment by ab3a: Francis, I was there too. The demonstration PLC was in a black box because the security firm was working with the vendor to correct these problems. This wasnt some esoteric or fancy programming hack. In fact, it was so simple that most of us who understood what it was were shaking our heads in amazement. You need to understand that SIS doesnt deal with security. Its focused almost entirely on reliability. This is one reason why my skin crawls every time I see someone marketing an SIS controller that sits on a network.
For more of this thread, go to Security and Safety with blood and guts. Then scroll to August 10 entry.
