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:
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:
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)