Leland Teschler, Executive Editor
[email protected]
On Twitter @DW_LeeTeschler
An article in Wired Magazine raised eyebrows awhile back when it explained a way hackers could destroy motors powered by variable-speed drives. It described work by a researcher at IT security firm Digital Bond Labs who pointed out that several VSDs have no way of authenticating commands sent to them over the network to which they are attached. Those commands can include setting motor speed. Worse, someone with nefarious intent could query the VSDs about the highest safe operating speed of connected motors. It was then possible, the researcher pointed out, to reset the maximum-speed setting over the network and tell the VSD to exceed it.
The tone of the Wired article was such that readers could come away with the impression of VSD makers as a bunch of bumblers who were clueless about hacking. But those knowledgeable in industrial controls probably realized the article fingered the wrong culprit. The real problem is the industrial network to which VSDs and other industrial devices connect. Many of these networks use a Modbus serial protocol originally developed in 1979 for programmable logic controllers.
Back then, of course, nobody worried about hacks. So in the interest of speedy network communications, Modbus includes no security measures; devices on the network just assume commands on the bus are valid and originate from something that is supposed to be there. That assumption applies for any device on a Modbus, not just VSDs.
Nor is Modbus the sole network with this vulnerability. In terms of security, all common industrial networks are similarly configured. This makes all industrial networks prime targets for determined mischief makers.
The ramifications of poor industrial-network security got highlighted in an episode of the TV series Mr. Robot in which hackers penetrated a misconfigured HVAC network. Like Modbus, widely used HVAC network protocols lack security. In the show, administrators had put the HVAC server on a network connected to the internet, which left it visible to anyone trying to break in.
Industrial device makers are well aware of such problems, despite what the Wired article may have implied. Security measures have begun to emerge. One widely used way of fortifying open protocol networks such as Modbus is at the gateways connecting them to other networks. Many gateway devices for Modbus now include firewalls and other features to thwart malicious applications and defuse them before they ever get access to Modbus connections.
But those sorts of security measures don’t help if an attacker has physical access to the Modbus network. Most worrisome is a Trojan Horse-style approach in which miscreants add villainous software to legitimate Modbus devices. With that scenario in mind, vendors have begun fielding security techniques that let IT personnel use software to inspect individual Modbus packets for trouble.
Unfortunately, none of these countermeasures are foolproof. So industrial networks hacks are likely to be a thorn in our sides for a long time to come.
Filed Under: Commentary • expert insight, Factory automation, Electronics • electrical
I don’t see a distinction between the ICS protocol and the device manufacturer. Often the device manufacturer is the source of the protocol, eg Modicon (now Schneider Electric) and Modbus or GE and Ethenet/IP CIP. Yes the protocols are insecure by design. There is often an administrative interface that is also insecure by design, plus backdoors and much more. Readers interested can look at Project Basecamp as a survey of the issues with PLC’s, RTU’s and other devices.
It has taken way too long to address this, but thankfully it is happening now. There is a Secure Modbus underway that wraps the protocol in TLS. Same with a secure version of EtherNet/IP. And we are finally seeing the manufacturers sign their firmware. So lots of progress. We actually had to turn away some great secure protocol / secure PLC talks for S4x18 this January because of the quantity received.
The question now is how long before these secure options become the rule rather than the exception in new deployments, and does this accelerate upgrades or refreshes in deployed systems.