Reader Comment – More on PLC’s

An interesting comment was posted on yesterday’s blog about ICS misconceptions. It seems that I missed one of the underlying points about another way to go about securing control systems at their points of action; the PLC. The Anonymous readers suggest that instead of allowing for reprogramming of PLC’s via the hard wired connection (which is a potential source of attack through the networked control computer) that the reprograming could be done by physically changing the memory card for the PLC like one does with the memory card on a digital camera.

While this novel suggestion would certainly avoid the in situ reprograming of the PLC that was seen in the Stuxnet attack (for instance) it has some limitations on its applicability in large scale control systems like those found in chemical plants. It also ignores the fact that the programing of the PLC memory chip still takes place using the same workstation that would allow the Stuxnet type attack in the first place.

Large Number of PLCs

A large scale chemical manufacturing facility can have thousands of PLC’s in operation. The relatively small specialty chemical manufacturer that I last worked at had one reaction vessel (the one I spent the most of my time working with) with over 100 controllers on it alone. While most of these operated valves (a fairly simple operation) a great deal of time was spent over the years on tweaking the specific interlock rules and valve operation timing (including how fast the valve opened and closed) instructions. And that was with processes that were still largely operator controlled. As we moved to increased process automation the programing got even more complicated and time consuming.

For the vast majority of PLC’s in use in a modern manufacturing facility I don’t think that the physical changing of program memory cards is practical. While the act of switching a memory card is fairly simple when one looks at the number of PLC’s involved in a fairly simple process adjustment the number of card changes involved almost ensures that a wrong card will be put in an inappropriate slot.

Physical Security Issues

There is also a physical security issue that must be addressed, a fact frequently overlooked in discussions of cyber security. If programing changes are now going to be physically implemented at the PLC we now have to provide protections that will prohibit the unauthorized change of cards as a means of cyber-attack. The current centralized programming operation only requires physical security measures for the control computer and its associated hardware. And physical security measures are frequently more expensive than cyber-security measures.

Programming Vulnerability Remains

Finally, the programming still has to be done at the facility level, even if that means hiring an outside consultant to handle that job. This leaves the programing control workstation as the point of attack on the PLC’s. It would avoid the problems associated with the wireless network capabilities that vendors are adding to their PLC’s (and are apparently being sucked up by system owners), but the computer that allowed the networked attack on the PLC in the Stuxnet attack is still the point of vulnerability.

Safety Systems

Having noted all of these shortcomings in this proposed solution, there is certainly one area where a control system owner might want to consider this methodology; safety control systems. These stand-alone systems are tweaked infrequently at worst and are relatively simple systems. Their strong points are reliability and inaccessibility. It would seem that only allowing programing changes via firmware substitution would be ideally suited to these types of systems.

Since these systems backstop security systems by not allowing for catastrophic failure of the process, separating them from the potential for a Stuxnet type attack would seem to be a smart idea. Their limited use and infrequent need for updates would also seem to be ideally suited for the design of a single use programing work station that would only be able to program these devices and have no ability to connect to the internet or corporate networks. Device signing could be used to ensure that only trusted drives and memory cards could be used on the system.

Safety system designers may well want to consider this methodology to increase the reliability and security of those systems.