Many of the concerns about the cybersecurity of the IIoT match those of the wider IoT ecosystem and specific markets such as the automotive or medical sectors. These include concerns about the creation, handling and storing of private data; the ability to communicate securely; the opportunities for mayhem if a device is hacked, and so on. The particular concern about the IIoT is that it often sits at the interface between what some call the operational technology (OT) of a business i.e. the equipment that controls industrial processes, and its information technology (IT) i.e. the computers and mobile devices through which the business operates. The fear is that connecting a company’s IIoT estate to its IT systems in this way vastly increases the opportunities for misuse (the ‘attack surface’, in the jargon). If your central payroll computers are vulnerable to a hacked sensor node that you’ve forgotten exists in a factory halfway around the world, you’ve got problems.
Consultancy McKinsey argues that this sort of concern about cybersecurity is holding back the development of the IoT and that if they were fully addressed, companies would spend between 20 and 40% more on it. It forecasts that the total available market for IoT equipment could be $500 billion by 2030, with $120 billion of that being spent by the manufacturing and industrial sector. If all cybersecurity concerns are successfully addressed, McKinsey says the IIoT sector could be worth $145 billion instead. This would make the IIoT the most valuable part of the whole IoT market. McKinsey asked IoT buyers and providers what they cared most about in the development of IoT systems and the joint top concerns, with 61% of those surveyed calling the issues critical, were privacy and ‘digital trust’, in other words the extent to which users felt that IoT systems could be relied on to work as planned and to be robust against accidental or deliberate misuse.
IoT regulators, standards bodies, and industry associations, are aware of the importance of cybersecurity for the safe and rapid development of the IIoT sector, and are developing standards, recommendations and guidelines designed to help IIoT suppliers and users to achieve effective cyber security. Many of these set IIoT issues in the wider OT context, with layered models that try to achieve robust security in every layer.
NIST SP 800-82r3
NIST’s Guide to Operational Technology Security, published in September 2023, “provides an overview of OT and typical system topologies, identifies common threats and vulnerabilities to these systems, and provides recommended security countermeasures to mitigate the associated risks.”
The layered model it uses in the cybersecurity strategy it outlines is as follows:
- Layer 1 – Security Management
- Layer 2 – Physical Security
- Layer 3 – Network Security
- Layer 4 – Hardware Security
- Layer 5 – Software Security
The Guide says that hardware security protection mechanisms provide the foundation for supporting security and trust for the devices within an environment. It lists some of the hardware security capabilities available to enhance endpoint security including:
- Root of trust
- Monitoring and analysis
- Secure configuration and management
- Endpoint hardening
- Integrity protection
- Access control
- Device identity
- Physical security
In a later section (5.3.7.1) on Application and Infrastructure, The Guide recommends that “Organizations should consider the following endpoint security capabilities of the IIoT devices being deployed”:
- Endpoint tamper resistance capabilities
- Endpoint root of trust
- Cryptographic techniques
- Capability to harden endpoints
- Endpoint identity
- Endpoint access control
- Endpoint integrity protection
- Endpoint data protection
- Endpoint monitoring and analysis
- Endpoint configuration and management
CSA IoT Device Security Specification 1.0
The Connectivity Standards Alliance, an industry group promoting open standards for the IoT, launched an IoT Device Security Specification 1.0 in March 2024. It’s an effort to consolidate requirements from the three most popular baseline definitions of IoT cybersecurity from the United States, Singapore, and Europe, into one specification and certification program. You can ask for a download of the specs, as they relate to various aspects of the IoT, here. The Technical Requirements section of the IoT Device Security Specification Version 1.0 is written in the rather strident language of such documents, includes statements such as that:
- 1.1.1 Unique Identity – The IoT Device SHALL be uniquely identifiable for cybersecurity purposes.
- 2.1.1 Authentication for Configuration Changes – If the IoT Device makes or allows Security-Related Configuration changes, including Critical Security Parameters and passwords, via a network or other interface, the related configuration changes SHALL only be accepted after authentication and authorization. Best Practice Cryptography SHALL be used.
- 2.3.2 Security Best Practices –If the IoT Device makes use of Critical Security Parameters, including passwords, they SHALL conform with Security Best Practices, including, length, complexity, generation of keys from passwords, secure management processes, and secure storage. Best Practice Cryptography SHALL be used.
- 2.3.5 Cryptographic Agility – The IoT Device SHOULD support updating Cryptographic Algorithms and primitives.
- 4.1.1 Restricting Access to Security-Relevant Information – The IoT Device SHALL require authentication and authorization when exposing Security-Relevant Information via the network interfaces of the device.
- 4.1.2 Confidentiality Protection – The IoT Device SHALL, by default, ensure the confidentiality of Security-Relevant Information and Sensitive Data exchanged with IoT Devices and IoT Associated Services. Best Practice Cryptography SHALL be used.
- 4.1.3 Remote Trust Relationships – For two-way communication, the IoT Device SHALL establish a trust relationship ensuring that both parties at each end of a network connection are authenticated. Best Practice Cryptography SHALL be used.
This is just a sampling of the requirements that must be met to achieve certification to the IoT Device Security Specification. You can sense that much of the document is about codifying basic steps that designers should take (e.g. don’t leave unused interfaces active, remember to validate all inputs), which are often overlooked. You can also see the emphasis that the specifications’ authors have attached to the use of up-to-date cryptography to enable authentication and to protect information at rest or on the move in IoT ecosystems.
AWS Ten security golden rules for Industrial IoT solutions
Back in September 2021, cloud services provider AWS published a much less formal Ten security golden rules for Industrial IoT solutions. Number three on its list is another take on this imperative, arguing for the use of hardware to provide an anchor or root for cybersecurity tools such as authentication schemes and cryptography:
- Provision modern IIoT devices and systems with unique identities and credentials and apply authentication and access control mechanisms
- Assign unique identities to modern IIoT devices such that when a device connects to other devices or cloud services, it must establish trust by authenticating using principals such as X.509 certificates, security tokens or other credentials.
- Create mechanisms to facilitate the generation, distribution, rotation, and revocation of credentials.
- Establish Root of Trust by using hardware-protected modules such as Trusted Platform Modules if available on the device.
- Ensure least-privilege access controls for OT/IIoT devices, edge gateways and agent software accessing local and cloud resources.
- Avoid hard coding or storing credentials & secrets locally on OT/IIoT devices.
IIC Endpoint Security Best Practices
The Industry IoT Consortium, another body which is trying to accelerate the uptake of the IIoT and which has just merged with the Digital Twin Consortium, has produced its own guidance for endpoint security in IIoT applications. It defines three levels of security: basic, enhanced, and critical, which correspond to security levels 2, 3, and 4 as defined in IEC 62443 3-3. It then defines the endpoint security functions needed to meet each level of threat:
- To counter basic threats, endpoint security functions should include:
- Root of trust
- Secure boot
- Endpoint identity
- Cryptographic services
- Secure communications
- To counter enhanced threats, add:
- Endpoint configuration and management
- To counter critical threats, add:
- A policy and activity dashboard connected to the Endpoint configuration and management system
- Security information and event management
The guidance then elaborates on each of these functions.
The Root of Trust (RoT) provides security functions such as:
- Endpoint identity
- Attestation of software and hardware identity and integrity
The strength of the RoT determines to what extent the device can be trusted and depends on how it is implemented. The RoT should be simple and well-protected against compromise to ensure its integrity.
“For enhanced or critical security levels, the RoT should be implemented in hardware. To obtain protection against physical hardware tampering, a discrete hardware security chip or an integrated hardware security block with tamper resistance may generally be needed.”
Endpoint identity is essential for most other security measures. Public key infrastructure (PKI) support is mandatory.
Secure boot attestation of the firmware and bootloaders for multi-stage boot may be performed using PKCS standards based cryptographic key hashes. This extends the platform-level attestation from bootstrap to OS startup, and helps prevent unauthorized firmware, bootloader or boot image updates.
Cryptographic services: Comprehensive endpoint security requires proper implementation of cryptography across transport protocols, storage, and applications
