IoT best practices for securing the industrial edge

Register now

The biggest challenges to the Internet of Things are security, complexity and lack of end-to-end solutions. Among those major challenges, security far outweighs the others as the No. 1 concern. Unfortunately, the fear around security is absolutely a fair point.

IoT’s reach is far—it encompasses consumer products, the enterprise, and operations technology. We’ve seen the poor security in IoT consumer products that led to multiple cyberattacks. Obviously, those types of devices are out of the question for the enterprise and Industrial IoT (IIoT).

What is in question is how enterprise IoT and IIoT will co-exist, and getting the security right is an imperative. For the first time, enterprise IT and operational technology (OT) are crossing paths to identify where and how they can work together to improve the business.

The operational networks in IIoT operate with safety and reliability as their primary concern, they don’t use encryption for communication or integrity, and they communicate over proprietary protocols. Older Programmable Logic Controllors (PLC) often run on Windows XP, an OS notorious for its security problems. Network segmentation within OT networks is rare to non-existent. And while there is ideally a strong separation between the IT and OT networks (so-called “airgapping”), IIoT is pushing to bridge the IT and OT divide. Because of these factors, “Industrial Internet of Things” raises a good number of security concerns.

There are many viable areas where enterprise IT can apply existing security best practices. And in an interesting turn of events, the nature of the machine-to-machine communication in IIoT opens up options that are extremely difficult with human users.

These seven best practices will help you secure the edge of your IIoT environments and define an overall security strategy. For this discussion, the main application environment and platform are out of our scope of analysis, as is the web front end. They are important, and deserve their own set of best practices. The attention here is on securing the different IoT devices and the data they transmit to the infrastructure on the network edge.

Keep in mind that these recommendations are intended for manufacturing, heavy industry, big assets, and machines with sensors and devices connected to a central location. Low-powered devices, wearables, consumer IoT and other scenarios will most likely require a different approach.
Another factor that makes the edge infrastructure unique is that it tends to be highly heterogeneous and varied, and often includes equipment from multiple suppliers. The focus here is on five typical device classes:

  • “Dumb” 32-bit+ device: these are full “general computers” that typically run Linux, but are primarily communicating in a single-direction to read a value and transmit the value to the end point
  • Smart/Edge Processing 32-bit+ device: run Linux (or a gateway OS), likely aggregating data from multiple devices, or batching readings after initial analysis, before sending on to end point. These will require a writable file system and often require bi-directional communication
  • GSM/telephonic connected 32-bit+ device: any device with criteria of the first two device sets but where the communication channel is through a mobile phone network
  • Microcontrollers (typically < 32-bit) communicating over low-power networks
  • SCADA/ICS, PLC systems (OT environments, industrial systems)
  • As you begin designing your network edge, you will need to first consider the devices that are capturing and transmitting data (see Figure 1 for an understanding of the range of IoT devices in an industrial environment). Security starts here and following these seven best practices will help you protect your environment from cyber threats and attacks.

Figure 1

Security at the Edge

1. Add end-to-end encryption. Security begins the moment the device accesses a protected resource, and you will need trusted and encrypted communication at every point in the data’s path. This protection is possible through certificates. In an IIoT environment the certification process is different from when humans access a resource, such as a website.

The human and website tend to have multiple interactions. Humans will be asked to log on for access over an HTTPS connection. Once the approved username and password is applied, or some other means of credentials, the requestor gains access to the resource.

When devices access a protected resource, all credentials tend to be in the same request. These requests are likely to be on a regular frequency and from a fixed physical location. While a browser takes care of certificate verification, for IoT devices it is up to the developer to ensure this is done correctly. Unfortunately, failing to verify certificates is a common mistake. Unverified certificates will work and provide encryption, but man-in-the-middle attacks are highly feasible (See Figure 2).

Figure 2

Verified server certificates prove the device is talking to the correct end point, and client certificates give a means to the server to verify that the device is indeed the device it says it is. Client certificates are better than tokens and username/password combinations, as those by themselves can be spoofed if the connection is tapped. A private key is never communicated.

2. Whitelist device actions. With whitelisting, you explicitly allow devices to only connect with legitimate end points and supporting infrastructure, like the domain name, time, and certificate servers. Once you know exactly what the device should do, you can disable everything else. You can set rules that allow only specific communications.

To create a whitelist, you should know the end point that will receive the data. You will want to have a connection to a certificate authority (CA) to validate server certificates. You will probably need admin access, for instance through SSH, as well as over-the-air (OTA) firmware updates. This is a limited list of legitimate end points, and it opens lots of options, from aggressive firewalling (explicitly allowing only known end points and drop everything else), to removing all root certificates from the device other than the ones from the whitelisted end points.

Even if the attacker gets access to the device and changes it, the environment is still safe because communication parameters are baked into the kernel.

One other option is to extend whitelisting from the device level to the larger networks. Network segmentation severely hinders possible attacks from spreading by isolating them from each other. An interesting way to add IoT sensors to an OT environment is to use low-power devices that communicate over an LPWAN low-power network that operates completely outside the OT and IT networks, and where data is only received, combined with OT and other data sources, and analyzed in the cloud, through entirely different network paths.

3. Give devices digital identities. When designing IoT environments, use modern PKI client certificates and devices that support them to provide authentication and identity. Each device should have its own X.509 PKI client certificate so that it has a unique digital identity to prove it is a trusted source. Many environments place the same certificates on the devices. While that is less complicated and does provide verification that the device is talking to the right server, it’s not as secure as giving each device a unique digital identity.

Before data is transferred, both the devices and backend server will contact a certificate server to verify the server and client certificates. It is important that the device itself contains the certificate to ensure an end-to-end trusted communication. Certificates could also be placed on the gateway, but that is not ideal, as it causes a trust issue between the device and gateway.
If you are concerned about where the device data is coming from, placing the certificate directly on the device itself is the way to go. If the device infrastructure doesn’t allow it, make sure that the communication between device and gateway (usually doing protocol translation) is secured.

Chip manufacturers are working on plans to add unique identities directly into the device chip. In this design, the TPM module will be the only device able to access the secret key in the chip. The key can be used to create a unique key pair, and you will not need to add certificates to individual devices.

One other requirement you will need is a mechanism to suspend and revoke certificates as well as replace them, such as OTA.

4. Use OPC-UA in industrial networks. Open Platform Communication-Unified Architecture (OPC-UA) is specifically for SCADA/ICS and PLC systems, and it adds encryption and digital signing of OPC devices. While industries have relied on OPC for some time, OPC-UA is new, but critical for devices in IIoT environments.

These devices are responsible for exchanging messages between the IT and OT (the industrial) network layer. Whereas most devices will read data, and maybe run some analytics or data processing on that data, Industrial Control Systems (ICS, of which SCADA – Supervisory Control And Data Acquisition systems – are a large subset) operate in systems that control critical infrastructures like energy generation, transportation systems, oil refineries and chemical plants, manufacturing factories, and so on.

Connectivity between the IT and OT layer typically is some sort of secure communication channel like a VPN. There isn’t much protection added to the OT. Communication between components inside the OT network is typically in clear text – be it proprietary protocols – and no encryption (or even signing) is implemented nor does much of this communication require authentication. That means, as long as an expected response comes back, each component is happy to talk to any other – including potential devices and machines under the control of an attacker.

Let’s be explicit about what that means: if the attacker is in the OT network (or the IT network), is reasonably aware of the landscape and network traffic (which could be harvested from network monitoring and scans), and understands the proprietary protocols, the attacker could send messages to other components in the landscape pretending to be a legitimate sensor, machine, or even PLC.

Similarly, an attacker could trap messages sent by other components by pretending to be a legitimate component in the landscape, thereby stopping them from being received by that component.

Finally, such messages could be altered along the network path, and thereby change the outcome of the communication. Since there is typically no network segmentation, this could jeopardize the entire OT network.

A number of startups are trying to address this problem. But, given the strong focus on safety and being non-disruptive to communication in OT networks, this means they only monitor, and do not intervene. They tend to be protocol-aware, so they can understand what is going on in the communication, and obviously can create a network map of what communicates with what, including any unauthorized hosts.

These tools monitor the traffic and flag anything that looks out of the ordinary. Some of them can poll the configuration of the PLC periodically to see if it has changed. Any events can be sent to a central SIEM tool.

While this provides a degree of protection – and generally seems to be a good idea to implement such a solution – it doesn’t solve the problem. It doesn’t provide integrity between machines, nor does it protect against wiretapping or tampering. At best it gives a warning that something bad has happened.

OPC-UA is a service-oriented architecture framework that integrates all the functionality of the individual OPC Classic specifications and adds new features on top of that. Developed by the OPC Foundation, it includes these security capabilities:

  • Session encryption (using modern PKI)
  • Message signing ( cryptographically signed for integrity)
  • Sequenced packets, providing some level of protection against replay attacks
  • Authentication, through the use of certificates
  • User Control (ACLs)
  • Auditing, as activities by users and systems are logged

These capabilities provide the required end-to-end encryption between each component in the landscape. Even if encryption is not used, you can use message signing, which ensures the communication comes from the correct machine or device.

Additionally, authentication and user control allows further protection by only allowing machines that should be communicating with each other to do so. Finally, having a detailed audit trail (even in addition to any network traces by other OT security tools) will enable forensics to go to work once strange or malicious behavior is detected.

OPC-UA is strongly supported by large OEMs, manufacturing industry groups in Germany, as well as nations like China. Another option for these environments is to add IoT-specific devices separated completely from the OT. These would gather and communicate the necessary data but not interact with existing OT network.

5. Apply an encryption scheme for low-powered devices in environments that don’t support encryption naturally. As mentioned earlier, encryption is a priority for IIoT environments. Encrypting low-powered devices in LoRA and Sigfox networks, however, is difficult. For those environments, consider a newly developed encryption scheme from SAP’s Security Research team or other encryption techniques that require very little power and enable end-to-end encryption.

In the SAP encryption scheme, each device is issued a secret key that is never shared. It uses CMAC, a block cipher-based Message Authentication Code algorithm, to create intermediary keys (to allow for key revocation). This key is used, together with the sequence number of the message and the device ID, to create an encryption key and a hash key. The latter is used for integrity checks. The result is that each message for each device will have a unique encryption key. The message that is sent to the end point contains the encrypted data, a hash of the message with the hash key, the sequence number of the message, and the device ID.

On the server-end, this series of events is replayed when the message is received. The root key is retrieved (the server must know this) based on the device ID, and computes the steps the client has gone through to 1) only check the integrity of the message without decrypting, or 2) check and decrypt. If the integrity check fails, the message is discarded.

This provides data encryption in a very power-efficient way. CMAC functions are light compared to PKI, and similar in that way to hash functions. Think of password hashing in web applications, where often thousands of passes of the hash function are used, without slowing down the logon process.

Moreover, it provides an ability to store encrypted data and only decrypt it on use or time of analysis. Since the integrity check through the hash key verifies the message without decrypting it, once this check has been achieved, the message can be stored while still encrypted. In fact, in a pilot project for a water and gas pipeline network, the messages were decrypted on visualization of the data in the end user application.

6. Threat model your planned environment. Threat modeling analyzes the application or landscape for potential threats from an attacker’s point of view and identifies where the weaknesses might be and how an attacker might gain access, steal, or manipulate the assets that are managed by the system.

To remember the types of threats, apply the STRIDE mnemonic:

  • Spoofing
  • Tampering
  • Repudiation
  • Information disclosure
  • Denial of Service
  • Elevation of privilege

The repudiation threat, by the way, is an interesting one in IoT, since there isn’t a human actor involved. It is relevant in IoT, as an outcome of the use of predictive modeling. Since it is often hard to trace back the way a data feed trained a predictive model, an audit trail is still highly relevant. In many cases, this will be in combination of spoofing or tampering threats.

7. Find hardware providers with open devices. To follow these best practices, you will need to have control over the device’s firmware. You will want an open device that you can configure to the level necessary to protect your environment from threats. Enabling certificates, whitelisting, encryption, validation and all the requirements for IIoT security require open devices.

As you review devices, look for ones that are open, give you admin access to the device, and provide source code or allow scripting without the manufacturer’s involvement. You will want to be able to run code that doesn’t have to be validated through the manufacturer. Be sure that you can look inside the devices or don’t buy them from the manufacturer.

Organizations are experiencing another fear around IoT, and it’s the fear of missing out. Everyone knows that change is coming, and IoT will lead to more automated process, predictive learning, and better business outcomes. This is the Industrial 4.0 that excites businesses across all markets and industries.

If we can build security into the IIoT during these early stages, we can have much more elegant designs than current network security. More importantly, we can avoid the threats of data theft that plague so many organizations. These seven best practices are an excellent start, and you can expect more to be added as the IIoT matures and more use cases are deployed.

For reprint and licensing requests for this article, click here.