Editor’s note: This article is part of AspenCore Media’s IIoT Cybersecurity Special Report.
By Nitin Dahad, EE Times European correspondent
We’ve all heard of the internet of things (IoT) and the industrial internet of things (IIoT). We know that the two are different: IoT is commonly used for consumer usage, and IIoT is used for industrial purposes.
But how does a professional group like the Industrial Internet Consortium (IIC) actually define the IIoT?
The group sees IIoT as a system that connects and integrates operational technology (OT) environments, including industrial control systems (ICS), with enterprise systems, business processes, and analytics.
These IIoT systems differ from ICS and OT because they are connected extensively to other systems and people. And they differ from IT systems in that they use sensors and actuators that interact with the physical world, where uncontrolled change can lead to hazardous conditions.
The benefits of IIoT are the ability of sensors or connected devices, as part of a closed-loop system, to collect and analyze data and then do something based on what the data reveals. The very connectivity, however, also grows the risk of attack — and, increasingly, cyberattacks — by those who may want to bring down the system.
One of the many projects under a Department of Energy (DoE) program to reduce cyber-incidents is being driven by Intel, looking at enhanced security for the power system edge.
Because grid edge devices communicate with each other directly and through the cloud, the research is developing security enhancements to emphasize interoperability and provide for real-time situational awareness.
First, this needs to be done in the form of a secure gateway for brownfield, or legacy, power system devices, then as an internal field programmable gate array (FPGA) upgrade designed as part of greenfield, or present-day, devices.
The goal is to reduce the cyberattack surface in a way that doesn’t impede the normal functioning of the critical energy delivery functions.
Sven Schrecker, chief architect of IoT security solutions at Intel and co-chair of the security working group at the IIC, said that security should not be the sole consideration when designing and deploying devices for IIoT systems, but developers should be thinking more broadly about five overall key factors:
- safety
- reliability
- security
- privacy
- resilience
While design engineers might have to implement security elements into a chip, software, or platform, they may not necessarily be aware of how their work fits into their company’s bigger-picture security policies. “The security policy must be authored by both the IT team and the OT team together so that everyone knows what device is allowed to talk to what,” said Schrecker.
Building a chain of trust
A common theme is to establish a security policy and chain of trust from the outset and then ensure that it is maintained through design, development, production, and the entire lifecycle of a device. Trust must be built into the device, the network, and the entire supply chain.
Haydn Povey, a board member of the IoT Security Foundation and CEO and founder of Secure Thingz, said that security needs to be addressed at four levels:
- CxO level
- security architect
- development engineer
- operations manager
The development or design engineers are the ones that need to take the company’s security policy. They may also define factors such as how to identify and verify that a product is theirs and how to securely provide software and hardware updates and implement this in chips or software.
The fourth part of the chain is where OEMs are involved in manufacturing products for IIoT networks, or in deployment of those products. Here, the production or operations manager needs to ensure that every electronic component has its own unique identity and can be securely authenticated at every point in the supply chain.
In discussing the lack of a chain of trust in hardware and software, Robert Martin, senior principal engineer at the MITRE Corporation and a steering committee member of the IIC, said, “Connected industrial systems have so many different tech stacks.”
In fact, he cautioned, “A small change in a microprocessor can have an unintended impact on the software running on it. If we recompile the software and run it on a different OS, it will work differently, but no one will be accountable for software failures resulting from the changes.”
He added, “Compare this to the building trade, where you would be penalized for making changes that affected safety — there’s regulation, certification. But we just don’t have the same regime in software-based technologies.”
Design considerations for IIoT security
So where does one start with designing security for the IIoT, and what design considerations must be looked at?
Various industry guidelines exist, such as the IIC’s IoT Security Framework together with its manufacturing profile providing details for implementing the Framework in the plant or the National Institute of Standards and Technology Cybersecurity Framework .
The main task for the design engineer is determining how to translate a security policy or security framework into the design and lifecycle management of a device that forms all, or part of, an IIoT endpoint.
The considerations range from enabling devices with unique identities to being able to protect the device, identify an attack, recover from it, remediate it, and patch the device.
“The process is no different from safeguarding other systems,” said Chet Bablalk, vice president of solutions for IoT devices at Arm. “We need to think about security from the ground up.”
He explained, “The first part is the analysis — what are the threat vectors and what are you trying to protect?”
Arm introduced its own platform security architecture (PSA) last year to support developers of IoT devices. Babla says that the PSA is device-agnostic because the company is trying to encourage the industry to think about security.
Analyze, architect, implement
The PSA framework comprises three stages — analyze, architect, and implement. “Analysis is the core part of what we are trying to stress,” said Babla.
This means, for example, conducting a threat model analysis, and Arm has introduced three analysis documents for common use cases in asset trackers, water meters, and network cameras. This analysis is essential and echoed by others.
MITRE Corp.’s Martin commented, “We need to start talking about what the potential weaknesses are in the hardware and be able to emulate attack patterns and make test cases.”
Design engineers need to think about the whole ecosystem, from chip to cloud, in terms of implementing a system that comprises an immutable device or one with a non-changeable identity; enabling trusted boot; and ensuring that over-the-air (OTA) updates and authentication can be carried out securely. “Then you can think about mitigation in silicon, the access points, and the cloud,” said Babla.
Arm’s PSA framework encourages designers to first consider the threats and then look at design and implementation. (Source: Arm)
Lifecycle management
An important consideration that some say differentiates IIoT security from traditional IoT security concerns is the lifecycle management (LCM).
Secure Thingz’s Povey said that LCM has an impact on when software updates or configuration changes are deployed to IIoT devices. In IIoT environments, typically the connected devices, sensors and control systems will not, or should not, be connected to the open internet.
Therefore, some type of device LCM control layer needs to be part of IIoT devices. This can be complex software for the reporting, configuration, and management of devices.
But security needs vary in an IIoT network depending on the endpoints in the system because it may comprise both an offline internal network of non-IP-based smart controllers and some type of protection or isolation from the external internet, and there will also be wireless devices and sensors that may or may not be IP-based.
All of the endpoint devices need to be managed and controlled in an industrial system as part of the LCM function.
This allows the industrial factory to control the introduction, configuration, and management of endpoint devices/products that are added to the internal factory network.
Some high-level objectives of a security solution for IIoT are:
- Product endpoint authentication (device, sensor, control system) — Is the endpoint product authentic, not a clone? Provides traceability back to product manufacturer, manufacturing date, and any other pertinent information.
- Product endpoint configuration and usage control — Secure management and configuration control of the endpoint with various rights and usage models controlled or limited.
- Secure control of the endpoint control state
- Maintenance of the endpoint — This includes secure software updates.
- Secure communications between control systems and the endpoints and secure storage of control system data.
- Advanced security protection — Intrusion detection and security monitoring.
Fundamental to enabling this endpoint product security at a lower level are the following requirements for the endpoint device:
- Immutable device identity — The device has to have a non-changeable/protected identity, which must be verifiable by cryptographic means. This allows a product to identify itself and authenticate who made it, pertinent dates, and other information.
- Immutable root of trust (RoT) — Besides the device identity, there also are RoTs provisioned into the product. These include low-level secure boot loaders, certificates, and asymmetric key pairs that allow the device to support bilateral authentication and also enable secure software updates. Some parts of the RoT require that keys and other items are protected in some type of secure storage area so that they cannot easily be extracted from the product.
- Immutable secure boot loader — Some type of low-level secure boot manager that verifies all firmware and configuration updates to the device/product before they are applied. Only the secure boot manager can install and apply low-level configuration updates to the endpoint device/product.
- LCM software/services — Some type of low-level LCM control service that enables management of the endpoint product, including software updates and configuration changes.
Security enclaves
Secure Thingz’ Povey said, “Device procurement is influenced by factors like enabling standard mechanisms to push out updates, how the update will be stored on an edge device, and the device and memory resource impacts.”
He added, “You need to think about the security enclaves, where to hide the secrets and the base keys, how to watermark the device.” Engineers should consider a development environment that allows these factors to be considered independently from silicon vendor and architecture.
The general industry consensus is that the secure elements really need to be in hardware to ensure embedded trust because chip-level encryption can be enforced and protected.
Rich Carpenter, general manager for control and edge platforms for GE Power, Automation and Controls, said, “We try to establish the root of trust that starts at the hardware level. Our ‘defense-in-depth’ approach requires that if a compromise occurs, it won’t propagate through the system.”
He says that GE uses off-the-shelf trusted platform modules (TPMs) and is working with Intel and AMD processors.
Expectedly, Intel is focused on the hardware approach. Schrecker said, “Having a hardware root of trust is vital. Hardware-based identity is burned into the system and having identity at the chip level means that it can be tracked. But the key is to be able to assure that the chips are genuine to be able to authenticate and for updateability.”
He adds that hardware-based security doesn’t replace software security; it just augments it.
In summary, the key considerations when designing for security in IIoT devices are making the devices immutable, being able to provide trusted and secure boot, and managing device security over the entire lifecycle, which includes OTA software updates and patches.
In case of an attack, there needs to be a way of accurately identifying the device, reinstating it to a previous known good state, and then being able to resolve the issue at the point of attack as appropriate. Taking these principles into account is a good start for going to the next step — hardware implementation.
Check out all of the stories inside this IIoT Cybersecurity Special Project:
The Day When the Industrial IoT Gets Hacked
Real-Life Industrial IoT Cyberattack Scenarios
Advertisement
Learn more about Electronic Products Magazine
