1660238328261 Jimmontague0609

Device-level security coming within reach

Nov. 19, 2020
System integrator Matrix and Control's Unfettered blogger Joe Weiss show how cybersecurity is reaching down to cover sensors and instruments

Because most cybersecurity threats emerged from Ethernet networks and microprocessor-based devices on the Internet, most responses began with information technology (IT) trying to protect those networks and applications. However, this left many industrial manufacturers and process applications to play catch up in recent years, and typically try to patch IT-style software without interrupting or halting production. Plus, as Ethernet and microchips pushed down to device-level sensors, they brought along cyber-threats to I/O points, instruments, motors and other analog hardware that were wide open, vulnerable and prime targets for catastrophic attacks.

Similarly, because sensors and other device-level instruments were historically analog, used serial communications hardwired to I/O, or weren't networked, many only began to need cybersecurity when they gained microprocessors, Ethernet ports and Internet connections.

"Device-level components are like nerve endings and muscles—the inputs and outputs—of the overall system that is the body. Lack of trust in what our senses are telling our brain, or the inability of the muscles to respond to commands from the brain, results in some very difficult challenges," says Daniel McKarns, senior industrial systems engineer at Matrix Technologies Inc. in Maumee, Ohio, and a certified member of the Control System Integrators Association (CSIA). "There's an inherent need for trust between these bodily systems. In a control system, the controller(s) must also establish or assume a certain level of trust to get information from and send outputs to I/O devices. With the advent of a network sitting between controllers and sensors, the need to create attestation and assurance has grown. It's no longer adequate to assume trust. It must be explicitly and proactively established. However, because many current network devices can't digitally identify themselves, the only way to establish that level of trust is to add some intermediary hardware that can independently verify the security of the communication channel by sitting at each end of the communication path.  Devices of this type create an encrypted overlay network between endpoints." 

McKarns adds the best solution is to have a fully compliant key infrastructure that all endpoint devices can support natively, eliminating the need for intermediary devices to form an overlay network. "By using cryptographic communication methods already used in secure communications between computers, such as mutual authentication, an I/O device and a controller can communicate securely with an extremely high degree of trust," he explains. "One example of this would be using CIP Security protocol between two supported devices, such as Rockwell Automation's ControlLogix 5580 controller and Kinetix 5700 drive. By using certificates and a central policy engine such as FactoryTalk Policy Manager to distribute rules and policies to endpoints, and a means to manage the lifecycle of those certificates, a very robust framework can be established that's much harder to compromise. It’s a perfect example of adding security in the lowest layers of the control system where they’ve been traditionally considered most vulnerable."

Joe Weiss, managing partner at Applied Control Solutions (ACS) and producer of Control's Unfettered blog, has long argued that device-level threats must not be ignored because it's difficult to protect components at the edge of networks or beyond. Now, he and others report progress is being made to achieve cybersecurity at the device level.

"The biggest issue right now is that China may have performed a Stuxnet-like maneuver on the U.S., which led to a new presidential executive order (Executive Order 13920)  requiring cybersecurity for hardware and control system equipment," says Weiss. "This began when a U.S. power utility during factory acceptance testing of a  435-kVA, 500-ton, 27-foot-high transformer from China found electronics inside it that should not have been there. As a result, the DoE intercepted the next large Chinese-made transformer at the Port of Houston, and sent it to Sandia National Laboratories to be evaluated.

"My supposition is this may be an effort to remotely control the transformer by sending spoofed sensor signals to the transformer equipment. The talk that these electronics are intended to exfiltrate and steal data, like with Stuxnet, doesn't make sense because there's no data to steal inside the transformer. The theory is that China is trying to insert remote command and control capabilities behind the utility's firewalls and other cybersecurity protections."

In part due to these events, Weiss reports President Donald Trump signed Executive Order (EO) 13920, "Securing the U.S. bulk power system (BPS)," on May 1, which authorizes U.S. Energy Secretary Dan Brouillette to work with federal partners and the energy industry to secure the nation's BPS.

"While most executive orders are high-level and don't get down to low-level specifics, this latest order specifically addresses cybersecurity for pumps, valves, turbines, relays, capacitors and other components, and even includes safety instrumented systems (SIS) and other control system equipment," explains Weiss. "However, as it's specifically concerned about electrical generation and the distribution grid, the scope specifically excludes networks, firewalls and routers, which is what the electronics in the transformers from China were likely trying to bypass."

Despite the prevalence of this and other hardware-based threats, Weiss adds the operations technology (OT) networking community continues to largely ignore them. "They do network monitoring, which is necessary, but not sufficient," says Weiss. For the first time, the government is saying, "If you want to protect your facility, then you must protect your equipment,' which is still zero addressed by network security providers."

To break this network-vs-hardware deadlock, Weiss reports a new method is being developed that will make it possible to detect what's really going on at the process sensor level. "It involves physics analysis of sensor, instrument and device communications at the lowest level which can't be hacked," explains Weiss. "This will allow users to trust their measurements by determining the origin of the sensor signal, as well as detecting sensor drift at the sensor, enabling greater reliability, safety and cybersecurity."

About the author: Jim Montague
About the Author

Jim Montague | Executive Editor

Jim Montague is executive editor of Control. 

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