The researchers are a bit detached from reality.
The researchers are basing their assumptions on the premise that PLCs are used in the same way that commercial PC software is developed. They aren't in most cases, and the researchers' whole plan falls down on that fact alone.
Ladder logic is meant to look like wiring up relays in order to be familiar to people who aren't professional programmers. It lets the regular maintenance crews repair and improve equipment controls at all hours of the day or night. Most PLC programming is done by electricians or similar skilled trades, especially after installation. Input blown on the third I/O module and you don't have a compatible spare module? No problem, find an unused input point, switch the sensors wiring to that, and change the program. You're off and running again in 15 minutes. Something has changed in the parts from your supplier and the fix is to change a delay timer? No problem, that's a quick program fix. The original program has bugs which don't show up until the right conditions occur, and then they trigger all the time? Debug and fix on the spot. Etc. That's why factories use PLCs instead of writing their software in C on an embedded computer.
El Reg: "They note it's very easy to conceal commands that will go as far as bricking the PLC, using legitimate instructions to fool around with arrays"
That happens with ordinary bugs. I've dealt with this sort of problem, although the PLCs didn't get "bricked", just the program corrupted. Some brands (e.g. Siemens) are more prone to this than others because they allow programming methods more akin to a restricted form of assembly language than ladder logic. Ladder logic itself is pretty much bomb proof unless there are firmware bugs.
El Reg: "or create stack overflows (the latter is pure simplicity: create a recursive subroutine that calls itself)."
Any PLC that I've worked with has a hard coded subroutine call depth limit to prevent that, usually a pretty low number. That's why it isn't practical to use recursive algorithms on a PLC. A more plausible method is to create an infinite loop in in PLC that allows in-scan looping (many do not). However, PLCs have a watchdog timer to prevent that. If the scan times out, the watch dog trips and faults the PLC. This is PLC programming 101 level stuff. These researchers are not coming up with anything new.
El Reg: "First, companies should centralise their PLC software storage into a single location,"
Any competently run factory already does that. You need that so you can replace the PLC CPU when it craps out. It's routine repair and maintenance.
El Reg: "with all engineers submitting what they call “golden samples”
Most PLC programming is not done by "engineers" much like most business spreadsheets are not created by "engineers". This is why the PLC programming languages created by academics have a minuscule market share compared to ladder logic outside of a few niches.
El Reg: "Second, operators should (preferably automatically) run periodic checks that validate the software on PLCs with the central logic store. ”
The software to do this with the major PLC brands has been off the shelf for several decades at least. It's nothing new. Most factories don't do it because they don't have the centralised industrial networking infrastructure to make it feasible. Instead they rely on manual procedures to send program update files back to whatever network disk share they are stored on. Of course though if you do centrally network the PLC CPUs in order to do this automatically, you've now created a new security risk that didn't exist before because now this potential malware has a path to all the PLCs via the IT network.
El Reg: "and PLCs only take updates from those samples”
This will do nothing to alleviate a Stuxnet-like problem. Stuxnet worked by infecting the PCs used for PLC programming and used the software to download changes to the PLCs. The virus thus operated with the same credentials as an authorised person. Stuxnet was simply a normal Windows virus which was used for an unusual purpose. Network air gaps were bypassed by simply infecting the appropriate PCs. To solve this problem, you need to solve the Windows virus problem. Good luck with that one. Most of the major PLC brands have had username/password features for decades to limit who can change programs, but hardly anyone uses them because it doesn't solve any realistic problems for them.
Overall, there's nothing really new in the story. The recommendations to have "known good" backups of PLC programs is good practice from normal problems associated with hardware failures. I can think of a number of occasions where a production line was shut down because the factory didn't have a working backup of a PLC program when the machine puked its program and a new program had to be cobbled up at short notice by working long hours. The main threat here though isn't hackers, it's project managers who get given a CD with the PLC program (and all the drawings) by the machine builder and who proceed to chuck it in the back of a drawer and forget about it instead of seeing that proper backups are made.
Biting the hand that feeds IT
