How to Secure Tomorrow's Connected Industrial Systems

From a recent explosion at an Iranian nuclear facility that experts suggest may have been caused by a cyberattack to a Las Vegas hotel that was hacked through a smart thermometer used to monitor the water temperature in an aquarium, attacks against IoT devices are on the rise.

Malware attacks targeting IoT devices are up 50% over the past year. These attacks now target IoT devices in manufacturing processes, the electric grid and connected cars. IoT security is no longer just about protecting data; a successful cyberattack on these systems now risks health and safety. Cyber terrorists and cyber criminals are using ransomware to shut down cities, hospitals, and other large institutions.

Cyberattacks against power control and management systems have already made headlines.  A blast furnace in a German steel mill was destroyed after operators lost control of the system due to a cyberattack.  Massive power outages occurred in the Ukraine as the result of a cyberattack, leaving hundreds of thousands of people without power during the middle of the winter.  A cyberattack against the US power grid left operators without visibility into large portions of the US electric grid on March 5, 2020. 

We are now starting to see the rise of ransomware attacks against critical infrastructure.  While ransomware in and of itself is not new, the trend of ransomware attacks against control systems is a relatively new but growing reality.

Protecting against these attacks starts by building security into the power control devices themselves.  OEMs building these devices must ensure security is included from the early stages of design. 

Developers designing connected industrial systems and IoT devices face a host of challenges when building security into their devices. These devices are special purpose devices built using specialized hardware and software that often lacks the built-in security capabilities common in higher end devices.  Engineers must take it upon themselves to ensure appropriate levels of security are built into their devices.

As a result of these basic connectivity and design challenges, and a lack of clear standards for cybersecurity, unfortunately 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 the essential security protection while establishing a strong security foundation on which additional security features can be added in the future.

Vulnerabilities in Control Devices

Click image to enlarge

Figure 2. Security vulnerabilities can result from implementation flaws, design flaws, or failure to properly enable and use security features.

Developers need to understand the basic types of security vulnerabilities, especially as they relate to control systems and embedded devices. Most of these vulnerabilities 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.

Click image to enlarge

Figure 3: Four Essential Components of a Secure Connected Device

Secure Boot

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 can 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 connected control device to authenticate the upgrade server before downloading the new firmware image, thereby adding another layer of protection.

Secure Communication

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.

Data Protection

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 for the sensors 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 capable 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 facility, 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.

Summary       

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.