1660238324073 Ian

Cybersecurity for field devices

June 18, 2020
Current field device networks—including wireless ones—lack adequate protection

All of us are aware of the importance of cybersecurity as an important element of any control or automation system. Control readers are also aware of how digital communications are part of most of the end devices (field sensors and actuators) installed for the past 20 years. Like other parts of the control system, because they have a microprocessor and communicate digitally, they too are at risk.

Simon Clarke, Herman Storey and Joe Weiss have been working on this issue for the joint cybersecurity and safety working group in ISA84 and ISA99, and they presented their work at the most recent ISA-84 meeting. Weiss summarized some of this in his Unfettered blog post (www.controlglobal.com/blogs/unfettered/an-assessment-of-presidential-executive-order-13920-securing-the-united-states-bulk-power-system) on how it might impact safety systems. Safety systems, though critical, are only one part of the control puzzle.

Control and safety system field devices require direct (unrestricted) access for provisioning, configuration, commissioning and maintenance, including calibration and troubleshooting. As it presently stands, unrestricted means no authentication or authorization is possible other than the profiles assigned to workstations used to provide system access. The portable handheld devices used for most work with field devices provide direct access, and their users have no login capability or authentication. Meanwhile, portable tools used with unrestricted access require metadata and executable files from the Internet.

Granted, the primary cyber threat is from personnel assigned to work on devices, who have physical access, access tools and no malicious intent. Accidents do happen after all, and in some cases a simple typo can lead to negative consequences. However, because of the lack of cyber forensics, it may not be possible to identify device anomalies as being cyber-related.

The installed base of field devices are part of unsecured networks that were not designed to adequately address cybersecurity. Products, including safety products, have no protection for control system field devices, and most sensor-level protocols have no network security protection.

The basic AAA requirements of cybersecurity management are authentication (identifying a user), authorization (user has the authority to make requested changes) and accounting (monitoring the resources a user consumes). The challenge is how to meet these requirements with minimal impact to the control system, while also providing some protection for the installed base.

As indicated above, the most likely source of cyber threat is internal; initial controls can be managed through administrative procedures, with Clarke, Storey and Weiss suggesting:

  • Access control be provided by policies and procedures that substitute for system-level tools;
  • Continuous and intermittent monitoring supplement the tools that are available;
  • Configuration management, including archiving;
  • Management of metadata file downloads and installation must include handheld devices.

Procedures inadequate

This list of compensating countermeasures being largely procedural can be upgraded at any time, and should be managed so they're adequate for risk management needs.

Unfortunately, procedures aren't enough. Existing devices and protocols do have noted gaps in cybersecurity risk management capabilities, and as we know from many decades-old field devices in service, once installed, devices and protocols are generally not subject to upgrade processes and therefore remain as possible back doors, until they fail and require replacement.

One concept to introduce cybersecurity to the field level is like that of the “black channel” used for safety protocols, where appropriate code with messaging checks is installed at both ends of the communication path like a VPN. This won't address the issue for existing field devices but could be a future enhancement, though industry would have to agree on how to implement and certify it for interoperability.

About the author: Ian Verhappen

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®.