Saturday, April 20, 2024

Security Challenges For The Industrial IoT

- Advertisement -

The Industrial Internet of Things (IIoT), a subset of the IoT evolution, is quite the rage within automation companies as they seek to add a high-margin software component to their traditional businesses. Since Maxim Integrated chips are used to build these automation systems, they get a unique perspective on how automation system design has to evolve or, in some cases, change as companies attempt to put their automation systems online to take advantage of the IIoT. This article briefly introduces the IIoT and focuses on the security challenges in IIoT that must be solved to implement secure IIoT-capable end systems.

The IIoT in manufacturing

Manufacturing can get the most leverage from the IIoT because of the sheer amount of data it can capture and process; data is the underpinning of the IIoT since it can be analysed and visualised to help optimise operations and costs. Within manufacturing, security solutions provided by intelligent sensors, distributed control and complex, secure software are the glue for this new revolution.

To realise the promise of the IIoT, chip vendors have to put a lot of their systems, including legacy systems, up in the Cloud. This has profound security implications since security implementation for industrial control systems has not kept pace at best and, in some cases, is non-existent. This will change as actors (malicious or otherwise) realise that a factory or a plant is effectively online, and exploit different attack opportunities.

- Advertisement -

Security will have to be a combination of software as well as embedded hardware to protect critical control systems from a variety of attacks. Three key challenges are: hardware authentication with secure keys, secure communications using TLS and secure boot. Since connectivity (the thing that enables the IIoT) completely exposes all of their security shortcomings, security cannot be an afterthought if they are to realise the benefits of the IIoT.

Benefits of the IIoT at work

A good example of the IIoT at work is General Electric’s newest US$ 170 million plant in upstate New York. It opened about a year ago to produce advanced sodium-nickel batteries used to power mobile phone towers. The factory has more than 10,000 sensors spread across 16,722.5 square metres (180,000-square-feet) of manufacturing space, all connected to a high-speed internal Ethernet. They monitor activities such as which batches of powder form the battery ceramics, how high a temperature is needed to bake these, how much energy is required to make each battery and what local air pressure is being applied. On the plant floor, employees with tablets can pull up all data from Wi-Fi nodes set up around the factory.

Another good manufacturing example is Siemens Amberg electronics plant that manufactures Simatic programmable logic controllers (PLCs). Production is largely automated, and machines and computers handle 75 per cent of the value chain on their own—the rest of the work is done by people. Only at the beginning of the manufacturing process is anything touched by human hands, when an employee places the initial component (a bare circuit board) on a production line. From that point on, everything runs automatically. What is notable here is that Simatic units control the production of Simatic units. About 1000 such controls are used during production, from the beginning of the manufacturing process to the point of dispatch.

The IIoT harnesses sensor data, machine-to-machine (M2M) communication and automation technologies. Smart machines are better than humans at accurately and consistently capturing and communicating data used to fix inefficiencies and solve problems in terms of up-time, scheduled maintenance, power efficiency and more efficient utilisation, sooner.

Maxim Integrated has broken down the IIoT in terms of a stack as shown in Fig. 1. At the very bottom of the IIoT stack, they have the devices (systems) on the factory or process floor. These can be field sensors, controllers, industrial PCs and so on. All of these are hardware systems and can include aspects of hardware security. These end devices must have useful data to communicate and are generally hooked up to communication hubs, gateways and switches so that data can be put in the Cloud (or an intranet) as Big Data.

The IIoT stack from an automation perspective
Fig. 1: The IIoT stack from an automation perspective

But that is not all. The promise of the IIoT is that this data can be integrated within the ERP and CRM software of the firm to not only efficiently plan and cost out a manufacturing process, but also to use customer/market information to change assembly lines and process parameters.

The top of the stack impacts software development and integration, whereas the bottom impacts the system design perspective.

Primarily, the benefits of IIoT can be broken down into three groups (Fig. 2): asset, process and enterprise optimisation. It is easier to optimise a motor than it is to optimise a drilling operation, which, in turn, is easier to optimise than the manufacturing lines of a large enterprise. But optimising at every level is the dream of the IIoT.

Potential IIoT benefits
Fig. 2: Potential IIoT benefits

The first level of analysis and interaction occurs at the edge—data is collected from a sensor (for example, a wind turbine sensor, a motor encoder or a vibration signature). This is processed locally to help understand how to tweak parameters that would give the highest efficiency or provide an early indicator of a potential failure.

The next level of analysis is done at the control room or plant level where sensor data from multiple end devices and even multiple assembly lines is aggregated to make decisions that would increase the efficiency of the factory or a process; for example, a control room making idling or sleep decisions of various end devices to reduce the overall power profile of the process.

The first two aspects of using data to positively impact operations is what you are familiar with and use in some way, shape or form. However, what the IIoT envisions is not just an increase in data collection and analysis at the first two stages, but integrating process data with enterprise data to make really interesting decisions that so far have not been made before.

Consider a company enjoying a market explosion. The assembly line can be programmed to manufacture higher volumes of the product, or completely bypass sub-assemblies adding features not valued by the market. Now, combine both the operating and financial data to provide more insight to the chief financial officer. The agility of the company and its ability to pivot, change and continue to grow can be exponential. Indeed, it is an attractive proposition, and many are eager to move forward, quickly. So quickly that security has not been keeping up with the new IIoT systems.

The IIoT exposes system vulnerabilities

There are a few ways that IIoT systems are vulnerable to attacks. Among the two most prominent are Cloud storage and network architecture.

Putting data on the Cloud (public or private) is an integral component of the IIoT. But this comes with huge security implications. Traditionally, industrial control system (ICS) vendors have maintained that their systems have a built-in air gap. This is no longer true when these systems have a direct or indirect connection to the Internet. The IIoT is going to drive the understanding that ICSes need to have embedded authentication and security features.

Let us now look at the network architecture that enables the IIoT. Fig. 3 provides a top-level view of how field devices in a factory or a manufacturing process are ultimately connected to the network.

Mapping security by plant network levels
Fig. 3: Mapping security by plant network levels

There has always been a control network, a host of field sensors, actuators or servo drives (and other such devices) connected to PLCs or distributed control systems. Typically, this control network is a bunch of isolated networks. But increasingly, control networks that manage different sections of a factory or process are connected together, creating the plant network.

A plant network lets supervisors see the entire plant operation and deduce how the different sections of a plant interact with each other. Information at this level allows for optimisation of the entire plant or an oil field. Ultimately, this plant network information is integrated with the enterprise/business network to enable the real promise of the IIoT.

Each level of operation within the control network needs to have its security needs assessed—security is different at each level. If you start at the top, the domain of IT, you have secure switches and servers that are (hopefully) updated with the latest software and patches as explained below.
• At the plant level, security is not up to date. However, IT still has some control.
• At the control network layer, PLC architectures are decades old. Generally, updates are rare, and frequent patches cannot be applied to systems that are responsible for 100 per cent factory uptime. Security is generally weak here.
• At the field level, which is generally never discussed, security is virtually nonexistent. Field devices are open, trusted and cannot really have any encryption implemented because interoperability is paramount. If you look at field slave devices, such as sensors and actuators, these systems have zero security features (for the most part) and work on protocols developed almost 30 years ago during the 1970s through the 1990s.

Addressing risks in ICSes at the field level

When you look at the field level in more depth, two primary points that present risk to the ICS are remote field sensors and I/O modules. At stake are uptime, predictable maintenance and overall industry efficiency—the cornerstones of the IIoT.

Risks with remote field sensors.

Physical security of all sensors may not always be possible, especially when the sensors are very remote like those used to monitor oil and natural gas fields. Inaccessibility further makes these vulnerable to physical attacks, so it is essential to authenticate all sensors before their data is accepted. However, in most cases, field sensors, even those used in critical infrastructure systems, are both open and trusted. This vulnerability of the field sensors has not gone unnoticed.In 2014, the well-known Black Hat conference featured a paper by Russian researchers who concluded that attacking an enterprise system directly is too much trouble. Instead, they concocted and described a ‘Man in the Middle’ attack by spoofing and replacing an open and trusted HART modem based field sensor. They have described the process in detail and even made the software libraries available for download.

Focus on secure systems for the IIoT must begin with a trusted sensor that is sending data to the Cloud or the PLC. Implications of a security breach on these remote devices can be profound.

Risks with I/O modules.

Another way to get access to an open trusted system is by using cloned I/O modules to deliver malware. Factory owners are used to replacing I/O modules within their PLCs. There have been cases in Asia where cloned I/O modules (with a fake corporate logo of some of the top automation vendors) are available in the market. Again, since this is a trusted system with traditionally little to no embedded security, it can be an effective vehicle for delivering malware to the main PLC CPU. Physical security (making sure that PLC system updates are limited to a select set of people) can deter this, but keep in mind that this does not need to be a malicious act. You might not even know whether this is a cloned or a fake I/O module.

Implementing hardware authentication with a field sensor.

A systems solution for the potential risks described can be simple. If you are going to trust the data from a slave sub-system, the data must be authenticated. There is a simple embedded hardware approach to keeping these kinds of trusted systems secure. An authentication scheme was instituted many years ago for medical and consumer products such as printer cartridges. These systems traditionally employ a standards based authentication process, using a custom secure device.

This authentication scheme is based on the challenge-response exchange between the host and the slave device (Fig. 4). The host system sends a challenge used by the slave system to compute a response. This response is validated by the host system to make sure the slave system is not cloned or counterfeited. Only after validation does the host communicate with the slave system.

Authenticating the slave module—can be used with both a field sensor and an I/O module
Fig. 4: Authenticating the slave module—can be used with both a field sensor and an I/O module

A simple conceptual block diagram of a hardware based authentication scheme similar to the symmetric SHA-256 algorithm is shown in Fig. 5. The SHA-256 protocol, based on a challenge-and-response exchange between authorised devices, authenticates the sensor before its data is accepted and read. SHA-256 authentication makes it almost impossible for an attacker to connect to a network, to pretend to be a sensor or to replace the sensor system with a compromised system, unless the hacker has an identical authentication device with the same programmed-in private key.

Sensor authentication with SHA-256 (private key)
Fig. 5: Sensor authentication with SHA-256 (private key)

Vendors provide the key programming service at an American facility and then ship a programmed authentication device to you. This device has a unique key that is known only to you. Devices that store the key are tamper-proof with a range of active and passive tamper protections built-in.

Risks with PLCs, CPUs and solutions

What controls your plant or process is the PLC and the main CPU that is running all control algorithms. But these systems are never designed to withstand security attacks and breaches. Hence, once these systems are connected online, there are many ways to compromise the main CPU of the PLC. Some of the attack surfaces can be applications software, operating systems or hardware, but the most vulnerable surface is firmware. If the firmware can be modified or infected, any change due to malware is not only hard to detect but also, if found, is very difficult to ascertain the intention or purpose behind it.

Most PLCs lack source and data authentication on firmware uploads. Some PLCs even lack checksums for validating the correct transfer of the firmware. If the attacker can modify the PLC firmware, he or she can:
• Take complete control over the infected system
• Learn about the production process
• Selectively sabotage the manufacturing operation (aka Stuxnet)
• Propagate to the enterprise from a trusted manufacturing system

Not everyone wants to take control of your system to destroy your plant. The risks can be more subtle. There is a lot of intellectual property embedded in a manufacturing setup, and sometimes the intent is merely to get this intellectual property. This kind of malware will not manifest itself by creating problems in your manufacturing setup.Automation World once reported, “The interesting thing about Dragonfly is that it targeted ICS information not for the purpose of causing downtime, but for the purpose of intellectual property theft. Potential damage could include the theft of proprietary recipes and production batch sequence steps, as well as network and device information that indicate manufacturing plant volumes and capabilities.”

The system solution to mitigating something like this is to implement secure boot for the main PLC CPU. This is a way of authenticating the firmware and only accepting software that has a valid digital signature. Depending on the requirements, you could also encrypt the firmware.

Security processing demands can easily overwhelm the MIPS of a traditional PLC CPU or even create latency issues. This is best done by off-loading the security functions to a low-cost, off-the-shelf secure microprocessor that is built for these functions, as shown in Fig. 6. The system shown here uses an external secure microprocessor to validate the firmware’s digital signature.

Secure boot of the main PLC CPU
Fig. 6: Secure boot of the main PLC CPU

All the above examples use keys to enable authentication, but this raises the question of key protection. Physical security of an encryption key is of prime consideration in many applications, since there is no security once the key is compromised.

To properly address physical security, several issues must be considered. These include a physical mechanism for generating random keys, a physical design that prevents covert electronic interception of a key that is being communicated between authorised agents, and a secure method of storing a key that protects against clandestine physical and mechanical probing.

Various secure key-storage devices provide system designers a host of features that range from package design to external-sensor interfaces and internal circuit architectures. These requirements were developed by American military in the form of FIPS 140 standard, and many chip vendors provide very comprehensive tamper-proof capabilities that can be used in ICSes.

The future of the IoT security

There may be other approaches to security as well, and as you begin to realise how important security is in a connected factories environment, you will eventually coalesce around a few approaches.

The IIoT in manufacturing is in high demand, and is a growing trend. Security will also eventually grow to cover vulnerabilities, but the need is already here.


1 COMMENT

SHARE YOUR THOUGHTS & COMMENTS

Unique DIY Projects

Electronics News

Truly Innovative Tech

MOst Popular Videos

Electronics Components

Calculators