How to secure tomorrow’s connected industrial systems
By Alan Grau, VP of IoT/embedded solutions, SectigoElectronics Cybersecurity data firmware industrial systems security
There is a lot of chatter and concern about how to protect our smart homes and cities, our cars and planes, in short, all of our connected and IoT devices and systems against cyberattacks. The best way to protect these application spaces is by building security into the devices, starting at the factories and the assembly plants where these devices and sensors are developed and made.
Manufacturers of control systems for industrial systems have long been aware of the need to address safety in their designs, but the focus on security has often lagged. However, by ignoring security, safety is compromised.
Developers designing connected industrial systems and IoT devices face a host of challenges in addition to security. Which of the emerging IoT standards should they embrace? Which IoT protocols should be used? How can they distinguish their IoT and IIoT products in this competitive emerging field? How can they meet time-to-market challenges?
As a result of these basic connectivity and design challenges, and a lack of clear standards for cybersecurity, building security into the device is often just an afterthought. However, security need not be an overwhelming challenge. By including a few basic security capabilities, manufacturers can develop connected machines with essential security protections while establishing a strong security foundation on which additional security features can be added in the future.
Vulnerabilities in embedded devices
Developers need to understand the basic types of security vulnerabilities, especially as they relate to embedded devices. Most vulnerabilities in embedded devices can be divided into one of three categories:
* implementation vulnerabilities
* design vulnerabilities
* deployment vulnerabilities
Deployment vulnerabilities pertain to issues introduced by the end user during the installation and operation of the device. These include not enabling security features, not changing default passwords, using weak passwords, and other similar errors. Unfortunately, for many connected devices, it is difficult for end users to implement effective security solutions.
Implementation vulnerabilities occur when coding errors result in a weakness that can be exploited during a cyberattack. Buffer overflow attacks are a classic example of implementation vulnerabilities. Another common error is improperly seeding random number generators, resulting in security keys that are easy to guess. Adherence to software development processes, such as the OWASP Secure Software Development Lifecycle, or Microsoft’s Security Development Lifecycle, along with thorough testing processes, help to address implementation vulnerabilities.
Design vulnerabilities are weaknesses that result from a failure to include proper security measures when developing the device. Examples of design vulnerabilities include use of hard-coded passwords, control interfaces with no user authentication, and use of communication protocols that send passwords and other sensitive information in the clear. Other less-glaring examples include devices without secure boot, which allow unauthenticated remote firmware updates, or that include “back doors” intended to allow remote access for debugging and maintenance of the device.
Four Essential Components of a Secure Connected Device
Secure boot utilizes cryptographic code signing techniques to ensure the device only executes code that was produced by the device OEM or other trusted party. In a device with secure boot capability, the bootloader computes a cryptographically secure hash on the firmware image prior to loading the image. This hash value is compared with a stored hash value to ensure the image is authentic. Cryptographic signing of the stored hash value prevents malicious third parties from spoofing the software load, ensuing that only software from the OEM is allowed to execute.
Secure Firmware Update
Secure firmware updates ensure that device firmware can be updated, but only with firmware from the device OEM or other trusted party. Like secure boot, cryptographically secure hash validation is used to verify the firmware before it is stored on the device. In addition, machine-to-machine authentication methods can be used by the IoT device to authenticate the upgrade server before downloading the new firmware image, thereby adding another layer of protection.
IoT devices, by definition, support communication with other devices. The communication mechanisms will vary by device but may include wireless protocols ranging from BLE and ZigBee to WiFi, cellular data, as well as Ethernet. Regardless of the transport mechanism and communication protocol, it is important to ensure that all communication is secured. Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) should be used when possible. For common wireless protocols, such as ZigBee or BLE, which have encryption built into the protocol, but that have known encryption vulnerabilities, encrypting at the application layer provide additional protections.
Engineers should consider encrypting any sensitive data stored on the device. Many large data breaches have resulted from data recovered from stolen or discarded equipment. Security protocols provide protection for data while it is being transmitted across networks but do not normally protect the data while it is stored on the device.
Implementing Security for Sensor Networks
Implementing security in industrial networks presents some additional unique challenges. Many connected sensors are low-cost devices designed with the bare minimum resources required for the core device operation and do not have additional computing power to implement sophisticated cybersecurity solutions.
As these devices are often deployed “in the field,” they may also be subject to physical and proximity-based attacks. Hackers can physically access the device, then attempt to attack it using available communication ports. Hackers can also physically acquire (buy or steal) a similar device, take it to their labs, and then tear it down or monitor communication buses looking for vulnerabilities. Proximity-based attacks target wireless protocols but require the attacker to be within the range of the wireless protocol.
One alternative is to bite the bullet and utilize hardware platforms capability of supporting core security services in the sensor itself. While this will increase the cost of building the device, sacrificing security to save a few dollars is often a short-sited tradeoff.
In addition to securing sensor devices, manufacturers and suppliers must address the security of the overall network or factory. IoT sensors often communicate with a gateway or edge device that performs data collection or analysis. The gateway or edge device must provide high levels of security, both for itself and to provide protection for the sensors from which it collects data.
Security is a requirement for all connected machines and devices and must be prioritized during the initial development process, regardless of how small or seemingly insignificant the device or the data it captures. By adding a few basic capabilities, including secure boot, secure firmware update, secure communication, data protection, and user authentication, the security of any device can be significantly increased.
A comprehensive security analysis will identify attack vectors and define security requirements. Engineers can then use this information to prioritize development of security features.
Only by including security into the devices themselves can we ensure that connected machines and IoT devices will be protected from cyberattacks.
Alan Grau has 30 years of experience in telecommunications and the embedded software marketplace. Grau is VP of IoT/Embedded Solutions at Sectigo, a commercial certificate authority and provider of purpose-built, automated PKI solutions.