What has really been learned since Stuxnet about protecting control systems

The control system intelligent control and communication capabilities are moving further down into the “end devices” – process sensors, actuators, and drives. From a cyber security perspective, this is moving the security responsibilities closer to the end user/system integrator. From a cyber security perspective, it is also blurring the lines between a master station (Distributed Control Systems - DCS or SCADA), a data aggregator (asset manager or Remote Terminal Unit - RTU), and field device (smart transmitter or intelligent electronic device- smart relay/breaker). This movement in technology impacts the definitions of Purdue Reference Model Level 0,1 devices. The fundamental question is what is a sensor? A sensor can simply be two pieces of wire – a thermocouple. On the other hand, a sensor can be a smart transmitter that includes the sensor(s) and fully configurable electronics that effectively provides programmable logic controller (PLC) capabilities. Smart transmitters generally have analog inputs that can provide safety input and also have Ethernet ports to go directly to the cloud/Internet – within same device.

I have been analyzing a specific state-of-the-art smart transmitter (hopefully the detailed assessment will become a formal paper). The transmitter is cyber vulnerable because of the design features, similar to the Siemens systems in Stuxnet.  One design feature is the transmitter (not a Siemens device) can utilize a USB to extract configuration files directly from the transmitter. However, there is no capability to lock down the USB port. The implications of this include:

-        Capability-wise, this transmitter is a PLC. However, because the device is considered a transmitter not a PLC, the Stuxnet “fixes” of monitoring firmware changes, precluding configuration/logic changes, USB control, etc. have not been included.

-        Capability-wise, the transmitter can directly communicate with the cloud, Internet, etc. yet there is no DMZ because it is a transmitter not a server.

-        There is a move toward embedding web servers directly into the field devices. This has already started many years ago with some distribution transformers because that would provide the transformer temperature to whomever needed it (specious reasoning).  After all of the discussions about keeping control systems, especially those devices with no security off the Internet, why do this?

I have provided numerous examples where the “good guys” have demonstrated a lack of imagination as to cyber threats. Here is another example to add to the list. These examples also beg the question – shouldn’t there be a safety assessment before new capabilities/features are added to control systems, particularly those with no cyber security capabilities?

Joe Weiss


Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • Current thought at the FieldComm Group/Fieldbus Foundation and in the Open Process Automation Forum (OPAF) calls for moving function blocks to field instruments, and providing Internet connectivity to those field instruments/actuators. At least in OPAF, we plan to base all connectivity on OPC UA that has Transport Layer Security (TLS) for all devices, certificate-based authentication, and AES encryption for all transmissions. We appreciate your caution on lock-down or elimination of USB ports, but since we use Ethernet for network communications, my input to the OPAF effort is that routine diagnostics include at least a checksum to prevent unauthorized code changes. We must provide for patching/updates through the network, but even this must be done securely.


RSS feed for comments on this page | RSS feed for all comments