The Industrial Internet of Things, often referred to as IIoT, is making an impact across all industrial segments, including manufacturing, the energy production, transportation and logistics, and related industries. Many analysts are studying the potential upside to IIoT, with some estimates in the trillions of dollars of contributed value throughout the next decade.
The adoption of IIoT technologies will result in reduced costs, improved efficiencies, new customer acquisition and retention, and new products and services. In some cases, entire new market segments are being created.
In the industrial sector, the IIoT is often referred to as Industry 4.0, or the Fourth Industrial Revolution, characterized by cyber-physical systems that are connected and intelligent from the lowest levels of the industrial environment up to the enterprise and into the cloud. We’re at the beginning of this trend, which will evolve as the technologies, processes, infrastructure, and people begin to realize the promise of next-generation industrial systems.
One obvious application of technology is the creation of smart, connected devices that interact directly with the physical world. These devices can be built with smart sensors and are capable of real-time decision-making. Combining this capability with AI, analytics, and cloud-based systems, operators of industrial plants will be able to realize and extract great value.
For example, a plant can be designed to adapt production levels in real time in response to external changes in demand, supply of parts, or other factors. Predictive maintenance is another application with tremendous potential. Systems can be instrumented to avoid downtime or catastrophic consequences related to previously unanticipated failure of critical systems.
As yet another example, a smart system could route electricity from on-shore generation facilities, such as a wind farm, to an offshore facility when there’s excess electricity available. This can help reduce carbon emissions related to offshore electricity generation from diesel generators.
To achieve the potential of the IIoT, devices must be protected from cyberattacks. New attacks against IoT devices, industrial facilities, and the electric grid continue to make headlines. In many cases, the root cause of attacks that succeed and cause damage are devices built with weak or non-existent security
Companies building IIoT and other connected devices must ensure that their devices are protected from these attacks. But where do they start? What steps can the device manufactures take to ensure their devices are hardened?
Building Security into the Device
IIoT security can only be achieved by building protection directly into the device itself. This provides a critical security layer—the devices no longer depend on the corporate firewall as their sole layer of security. This is especially important for endpoints deployed in remote locations, but also critical for devices deployed within an industrial facility.
As shown by ongoing cyberattacks making news headlines, reliance on the corporate firewall is no longer sufficient.
A security solution for IIoT devices must provide protection against a wide range of cyberattacks. It must ensure the device firmware hasn’t been tampered with, secure the data stored by the device, secure the communications in and out of the device, and detect and report attempted cyberattacks.
While there’s no one one-size-fits-all security solution for embedded devices, solutions are available that provide a framework for OEMs. A security framework provides OEMs with the core security capabilities required to secure their devices. It provides the flexibility needed to customize the solution to the specific requirements of their device, while ensuring that critical security capabilities are included (Fig. 1).
Device Security Requirements
Before selecting an IIoT Security Framework, it’s important to step back and look at the security requirements at both device and system levels. Security requirements for IIoT devices must consider the cost of a security failure (economic, environmental, social, etc.), the likelihood of attack, possible attack vectors, and the cost of implementing a security solution.
Security capabilities that need to be considered are (Fig. 2):
- Secure boot
- Secure firmware updates
- Secure communication
- Data-at-rest protection
- Embedded firewall
- Intrusion detection
- Secure key storage
- Certificates and device identity
Secure Boot and Secure Firmware Updates
Secure boot and secure firmware update capabilities are used to ensure that an embedded device is running authorized code from the device manufacturer. This prevents the installation of malware or code that has been modified by hackers.
Secure boot begins with a first stage bootloader that’s programmed into a protected or non-writable storage location on the device (Fig. 3). This first-stage boot loader validates the authenticity of the second-stage boot loader. The second-stage boot loader, which is often more complex and can be stored in reprogrammable flash memory, then repeats this process to verify that the operating system and applications are valid.
Secure boot relies on digitally signed code images to enable validation of the image during the secure-boot process. The code images are signed by the device OEM using the OEM’s private code signing key. The OEM’s corresponding public key is used by the device to validate the signature for the firmware image.
Secure firmware updates, like secure boot, validate that new code images have been signed by the OEM before applying the code update. If a downloaded image doesn’t pass the validation process, it’s discarded, and the upgrade isn’t performed.
Secure Communication
In recent years, many embedded devices have added support for secure communication protocols such as TLS, DTLS, and SSH. Though these protocols provide a critical first level of defense against cyberattacks, they leave a number of attack vectors unprotected.
Security protocols are designed to protect against packet sniffing, man-in-the-middle attacks, replay attacks, and unauthorized attempts to communicate with the device, providing a good starting point for building secure devices.
Data-at-Rest (DAR) Protection
IoT devices, unlike enterprise servers, aren’t locked away deep in a data center. Many are located “in the field,” with the risk of theft or physical attack. Any sensitive data stored on these devices should be encrypted to ensure it’s protected from attempts to read from the device, either by copying the data from the device or by physically removing the flash drive and reading data directly from the flash drive.
Data-at-rest (DAR) protection encrypts data stored on the device, providing protection for sensitive data stored on the device. Many IoT devices don’t have the computing power to support full disk encryption, but sensitive data such as credit-card numbers or patient information should always be encrypted. Care must be taken to store the encryption key in protected memory on the device.
Embedded Firewall
Embedded firewalls reside directly on the embedded device, integrated directly within the TCP/IP stack. Like the familiar firewalls often used in enterprise and business networks, they control which packets the device can process. A firewall applies filtering rules to control what packets are processed by the device, blocking unwanted and potentially malicious packets before they’re passed up the protocol stack to be processed by an application. This capability provides an effective defense against cyberattacks.
An embedded firewall can implement several filtering stages, depending on the embedded device’s requirements.
- Stateful packet inspection (SPI) filtering accepts or discards packets based on the state of the connection. It protects against “Christmas tree attacks,” SYN flood attacks, and other assaults that attempt to exploit the stateful nature of protocols such as TCP.
- Static filtering blocks packets by IP address, port number, or protocol type. It can enforce network segmentation and is particularly useful in static networks where an IIoT device communicates only with a small, defined set of other devices. Because any communication from an unknown device might be the result of a cyberattack, the filter will reject it.
- Threshold filtering protects against packet flooding and other denial-of-service (DoS) attacks.
- Protocol- and application-specific filtering can protect networked embedded devices against application-specific attacks. These filtering methods can be added to implement access control in legacy protocols that lack security control mechanisms.
For example, adding protocol-specific filtering would be a good security strategy to apply to an embedded device that uses the ModbusTCP industrial control protocol. ModbusTCP doesn’t provide access control; it processes any command it receives, regardless of who or what sent it. The security upgrade can include a whitelist of authorized IP addresses. This would enable the filter to block Modbus commands sent from any source other than the trusted ones on the list.
Intrusion Detection
Most cyberattacks occur in phases, beginning with hackers probing a network looking for, finding, and exploiting a vulnerable device. Once this initial beachhead is established, hackers use the exploited device to probe deeper into the network. The cycle then repeats with hackers gradually expanding their reach within the network.
Stopping these attacks begins with detecting that they’re happening. IDS, as the name implies, detects when a system is under attack or being probed. These solutions can take many forms and detect many different types of attacks. But, regardless of form, they’re in the main, largely absent for embedded devices.
Adding IDS capabilities to embedded devices is critical to provide early warning of a cyberattack. The ability to detect and report potentially malicious activity enables system administrators to take action to block attacks, quarantine compromised systems, and protect their networks. If embedded devices can support basic IDS, they will no longer be such easy targets for hackers.
Secure Key Storage
Secure communication protocols, DAR protection, secure boot, and secure firmware updates all rely on encryption and certificate-based authentication. A security framework must provide the ability to securely store the encryption keys and certificates used to encrypt data, authenticate firmware, and support machine-to-machine authentication.
Secure key and certificate storage is a critical requirement. If a hacker can discover the encryption keys, they can completely bypass an otherwise robust security solution. Secure key storage can be provided using a TPM or other hardware secure element. If the device doesn’t have a hardware module available, a software-based secure-key-storage method can be utilized.
Hardware Security Module Support
Many new IoT platforms include a TPM or other hardware secure element that provides secure key storage, protected memory regions, and cryptographic acceleration. A security framework must be designed to allow for easy integration with these hardware-based security features.
PKI for IIoT Authentication
PKI (public key infrastructure) is a set of technologies and services for managing authentication of computer systems. PKI is based on a mechanism called a digital certificate. Digital certificates are sometimes also referred to as X.509 certificates or simply as certificates. Think of a certificate as a virtual ID card.
In the real world, people use ID cards such as a driver's license, passport, or an employee ID badge to prove their identity. A certificate does the same basic thing in the electronic world, but with one big difference. Certificates aren’t just issued to people (users, administrators, etc.). Certificates can also be issued to computers, software packages, or just about anything else needing proof of identity.
Certificates are very useful in high-security situations. For example, suppose that you needed to securely transmit data between two networked devices. How do you really know you’re transmitting the data to the intended device and not to an imposter? One way of ensuring the integrity of the transaction is to use digital certificates to prove the identities of both machines.
PKI provides the tools and methods required to issue certificates to all IIoT devices on a network and to manage those certificates throughout the life of a device. A certificate can be likened to a driver’s license. It provides an identity and a set of permissions and was issued by a trusted entity. My driver’s license identifies me (Alan Grau), provides a picture to show that I’m the proper bearer of the license, and defines my permissions as a driver of a motor vehicle. I’m authorized to drive any standard passenger motor vehicle, but not certain commercial vehicles. And the license was issued by a trusted entity (the government of the State of Iowa).
In many ways, a certificate is similar. A certificate is issued by a trusted entity (a certificate authority), contains permissions, and is used to identify the holder of the certificate (Fig. 4). A driver’s license contains information allowing the holder of the license to be verified, just as a certificate contains the public key allowing it to be used only by the entity that holds the associated private key.
Without getting into the details of the public/private key cryptography technology that makes such certification possible, an IIoT device can verify the certificate holder is the entity specified by the certificate. These services are enabled using public/private key cryptography providing the technical underpinnings of PKI. The result, which is what really matters, becomes a device that can verify, with cryptographic certainty, the holder of the PKI certificate is really who it claims to be and not an imposter.
Certificates, like a driver’s license, provide the basis for identifying IIoT devices. PKI provides the technology and systems to issue, renew, revoke, and manage certificates.
Summary
Security for IIoT devices is no longer a nice-to-have feature—it’s essential! Cyberattacks are on the rise, cybersecurity legislation for IoT devices is being passed with more on its way, and network operators are beginning to require higher levels of security. To remain competitive, OEMs must address security in all of their products, no matter how small or complex.
The new rule is that security must be built into devices from the early stages of product design.
Alan Grau is VP of IoT/Embedded Solutions at Sectigo.