IoT system attacks are making headlines and continue to showcase the security vulnerabilities of networks, edge nodes, and gateways. A recent Mirai botnet infected over 2.5 million IoT nodes by logging into devices running telnet servers in which the default password had not been changed.¹ Mirai later was able to invoke a denial of service for servers that disrupted internet access for a large portion of the world. The Reaper Botnet attacked over a million IoT devices by exploiting software vulnerabilities and infecting them. An internet connected fish tank provided the entry point into a casino’s network, leading to the theft of 10 GB of data. Smart televisions have been exploited and used for espionage and surveillance.

Embedded sensor systems are just starting to be connected and exposed to the internet. As part of the Industrial Internet of Things (IIoT), these sensors lack the past two decades of evolution that web servers have had in this hostile environment. Hence, the industry is witnessing many of the attacks commonly seen in the 1990s and earlier in these systems. The lifecycle of an IIoT system is often much longer than one in traditional computing. Some devices may continue operating for decades after they are deployed, and with unknown maintenance schedules.

While servers and PCs are complex enough to allow for security provisions, IIoT nodes are usually low in power consumption and processing power. This leaves a small power budget for intentional security measures. Security is largely a tradeoff, as there are development costs involved. Although IIoT may have higher costs than consumer IoT, it will still face challenges in cost for scalability. If security is ignored there are hidden impacts that will arise after products are deployed, and these costs will eventually need to be addressed.

Sensors and actuators allow IIoT devices to interact with the physical world. Cyber attacks have been mostly limited to the loss of data, although an IIoT hack allows potential entry into the physical world easier than it has in the past. Attacks now have the potential to cause physical harm. This is even more significant in IIoT, where a failure could potentially shut down or destroy a multimillion dollar industrial process or lead to a life threatening situation.

A connected world

IIoT devices are generally connected to some network and often the internet. This connectivity is what exposes them the most to an attack. Similar to the realm of epidemiology, infection is spread by contact with other machines. Attack vectors exist where systems interact with the outside world. Attackers are able to interact with systems strictly due to their connected access. The first system design security question to be asked is: “Does the device really need to be connected to a network?” Connecting it to a network dramatically increases the security risk.

The best way to secure a system is to prevent it from connecting to a network or limiting it to a closed network. Many IIoT devices are connected to networks solely because they can be without much reason. Does the benefit of having the device connected to a network outweigh the security risks associated with it? In addition, any other legacy systems that interact with the internet facing system can also be put at risk.

In many cases, an otherwise secure network and secure nodes must also interoperate with a legacy incumbent network that could be far inferior in its own security. This poses a new problem in that the weakest security risk could be outside the influence of the IIoT system. In that case, the IIoT system also needs to protect itself from within the network.

Security considerations at the node:²

• Confidentiality—protection from data disclosure to unauthorized people, such as from a spoof attack
• Authentication—use of digital certificates to validate the identity between two machines
• Secure boot—ROM bootloader storage validates authenticity of second-stage bootloader
• Secure firmware updates—only authorized code from the manufacturer is permitted
• Authorization—only authentic nodes should be able to gain network access
• Integrity—protecting data from being altered
• Accounting—proper accounting of data, node counts, and timestamps can help prevent unwanted access to IIoT networks
• Secure communication—encrypted protocols that can reside on a low power node
• Availability—ensuring users have access when they need it
• Nonrepudiation—assurance that authentic communication requests cannot be denied
• Reliability—even in harsh electrical environments, access needs to be reliable

[Figure 1 | A spoof masquerades as a known node to a gateway.]

Isolation

Isolating systems from each other can reduce the attack surface and limit the spread of malware. Isolate systems that do not require network connectivity from systems that are exposed to networks. Consider setting up a separate air-gapped or tightly monitored network that is separated from other networks for high risk systems. Ideally, critical systems should be completely isolated from the outside world.³

The infotainment system of a connected car can expose the vehicle to many new attack vectors not previously seen before. The main engine control unit (ECU) has nothing to do with the infotainment system and there should be no way to interact with it through the infotainment system. Though there are typically two separate CAN busses in vehicles separating the most critical systems from the rest, they are still connected together in some way. It is still possible to compromise one and gain control of the other. If there was total isolation between these networks, the risk of compromise would be reduced from potentially life threatening to something far less serious.

[Figure 2 | Various types of malware that can potentially infect an IIoT system.]

Moving to the edge

Many IIoT systems connect to a cloud server that collects and processes information sent to it by the device and also manages the device. As the number of devices scales to large numbers, the cloud can have difficulty keeping up with all of them. Many systems are moving processing out to the edge on the IIoT devices to reduce the amount of traffic to the cloud.

We often think of data as an asset. Data is mined and sold to find hidden patterns in large data sets. However, the bulk of collected data is usually not very useful, though it may be useful to an attacker. Sensitive data creates a target for attackers and creates a liability. Collected data should be filtered down to only what is needed, and the rest should be deleted as soon as possible. This not only improves security, but also the utility of the collected data. It is important to identify potentially sensitive information and eliminate or limit its collection.

Processing data at the edge can reduce the amount of data sent and exposed to the cloud. The more locations data is sent, the more difficult it is to keep it confidential. Each new node is another potential compromise where data can be leaked. The attack surface can grow exponentially.

Keeping sensitive data contained at the edge can limit the attack surface specifically on confidential data. If it is confined to one edge node, it is less likely to be stolen. A parking occupancy sensor that detects and only reports the presence of a vehicle through a binary signal after image processing will not stream video. It eliminates the large amount of unnecessary data contained in an image. This reduces the burden on the receiving server so that it cannot be reused maliciously for surveillance.

Similar to consumer IoT systems, industrial IoT systems also have proprietary and confidential information that must be maintained:

• Proprietary algorithms
• Embedded firmware
• Customer information
• Financial information
• Asset location
• Equipment usage patterns
• Competitive intelligence
• Access to a larger network

Through the fog

Some IIoT devices still lack the power and performance to be edge-based. Another topology emerging, the fog model, is a hybrid between cloud- and edge-based systems. In the fog model, the edge nodes first connect to a gateway that receives data and does some processing before sending it to the cloud. There may be one gateway for many IIoT devices. The gateway does not need to operate on battery power, can afford a much higher budget in processing power, and costs more than constrained IIoT devices.

The fog has risen more from scalability issues, but could also come to play a role in security. The gateway device could help protect vulnerable edge nodes that may be too constrained to provide security on their own, but it may be better to provide some level of protection instead of none. The gateway can be used to help manage all the nodes underneath it instead of managing each individual node directly. The fog model can also allow for incident response in IIoT while avoiding disruption of service. For example, security may respond by interacting with the gateway instead of shutting down a mission critical manufacturing line.

Provisioning and deployment

Among the greatest challenges in IIoT is the deployment and management of large numbers of devices. Wide reaching IIoT systems are notoriously difficult to set up and configure. With the long lifecycle of IIoT, systems may be deployed by one team and still be operational years later when yet a different team supports it.

IIoT systems are often insecure with weak authentication mechanisms by default. As seen with the Mirai botnet, most users never log into IIoT devices to configure them. They may even be unaware that they are supposed to be configured. Most IIoT users assume things just work out of the box. Systems must be made secure by default. A system expectation should be set that the user may never configure the device other than the default. Weak default passwords are a common mistake.

References

1. Mirai botnet leaked source code.
2. Ross Yu. “Security and Reliability Are Key in Wireless Networks for Industrial IoT.” Analog Devices, Inc., 2017.
3. Patrick Nelson. “Organizations Must Isolate IoT from Regular IT, Says Telco.” Network World, March 2016.

Ian Beavers is a product engineering manager for the Automation Energy and Sensors Team located at Analog Devices, Greensboro, NC. He has worked for the company since 1999. Ian has over 19 years of experience in the semiconductor industry. Ian earned a bachelor’s degree in electrical engineering from North Carolina State University and an M.B.A. from the University of North Carolina at Greensboro. He can be reached at [email protected].

Erik MacLean is a hardware engineer at the Trusted Security Solutions group of Analog Devices in Tampa. He has six years of experience in embedded hardware design and security. He received a B.S.E.E. from the University of Florida in 2009 and an M.S.E.E. from the University of South Florida in 2011. He can be reached at [email protected].

eletter-05-17-2018

eletter-05-18-2018