Reader feedback: Cybersecurity of field devices

July 31, 2020
William (Bill) l. Mostia, Jr. responds to Ian Verhappen's recent column about maintaining cybersecurity of field devices

I read Ian Verhappen’s article (June ’20, p 18) on this subject with interest. I agree with a lot of what he said, but have some differences of opinion that I'd like to clear up.

As far as I know, all modern digital field devices—even decades-old ones—have a physical jumper that prevents anyone from changing its configuration, locally or remotely. In order to change the configuration of a field device this jumper must be in the correct position.

Given this, it seems to me that external cybersecurity of field devices boils down to properly controlling the jumpers: making all changes locally, and ensuring that the communicators used by techs are cybersecurity-controlled to minimize the potential for cybersecurity threats entering through the communicators.

Now, if you allow an engineering station access (via the jumper), you introduce the potential for a DCS or asset management system that's been cyber-compromised to initiate changes to field devices.

Again, access control is the key. With respect to internal cyberthreats, you can't prevent someone who has access to the communicator and knows how to change the jumper from tampering with a device. This essentially leaves only disgruntled instrument techs as likely perpetrators. I have not heard of this occurring in practice. Mistakes happen, but these are not cyberthreats.

I've also seen some claimed cyberattacks on field devices, involving repeated starts of a motor until the device was destroyed, which would have been prevented if the circuit had been designed properly. Proper design of an instrumented system (in addition to the common zones and conduit and computer approaches) can prevent some types of cyberattacks on control or safety systems—including field devices—which I find is not commonly discussed.

I can't see how any verification or authentication scheme can improve cybersecurity, unless you allow open access (e.g. remote) to the field device (e.g. no jumper engaged). In my opinion, it's bad engineering practice to allow such access to field devices however secure their connections are believed to be.

William (Bill) l. Mostia, Jr.
ISA Life Fellow, TUV FS Engineer
WLM Engineering
[email protected]

Verhappen responds

You're correct about the jumper, or in many cases, the need to use the "good old screwdriver" with zero and span pots. The concern that I and others have is with devices that can communicate with others, with HART being the most basic form of such communications.

In the broad context of cybersecurity scope, configuration errors are considered "events," and in this context, indeed represent the majority of incidents. But external events are the ones that get the most attention, and what most folks consider when discussing cybersecurity.

I also agree that controlling access to the systems (DCS, AMS, etc.) is the most important way to protect not just field devices but the system as a whole. Proper system design IS the key, and hopefully by sharing these ideas with our readers, we can get them to at least think about them.

Ian Verhappen
Senior Project Manager/Automation
CIMA+
[email protected]

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.