Securing the Three Families of IoT
Credit to Author: William “Bill” Malik (CISA VP Infrastructure Strategies)| Date: Thu, 11 Jan 2018 14:01:44 +0000
Securing the Internet of Things is difficult. One reason is the Internet of things consists of three different groups of technology. Each group has radically different architectural constraints. Securing each group requires a distinct approach.
IoT 0.9 The primitive group contains all legacy Operational Technology (OT) and Industrial Control Systems (ICS) that use some form of networking, but not the OSI model. These tools use simple protocols because they do not have much power, memory, bandwidth, or CPU available. Traditional ICS devices have an in-service life of 15 to 25 years. They may be in remote or inaccessible locations.
How Remote? The Voyager 1 spacecraft has just under 70K of storage, three processors with an aggregate processing capacity of 130,000 instructions per second, and a 22.4 watt radio transmitter. Voyager’s remaining 249 watts of power (down from 470 watts at launch) come from three plutonium-powered radioisotope thermoelectric generators. See https://voyager.jpl.nasa.gov/ for information on this most remote ICS device. Voyager 1 cannot afford the power or time to authenticate incoming messages. A radio wave takes about 19 hours to travel from Earth to Voyager 1. If Voyager 1 used TCP/IP, setting up an IPsec VPN would take five days.
Figure 1: Voyager 1, now 13 billion miles from the Sun.
Securing IoT 0.9 devices is hard. Few individuals have the necessary skill mix to do this job. It requires deep engineering knowledge of the device’s design and operational constraints, and the capabilities and limitations of the network protocols, to build network-based information protection around the device. Processing limitations prohibit any conventional authentication, authorization, encryption, or digital signature capabilities on-board. Traditional ICS vendors do not have integrated information security teams. ICS customers may have an information security team, but they understand conventional IT security architectures, not ICS architectural constraints.
The most effective way to secure IoT 0.9 devices is isolation – putting the devices on a segmented network, not linked to the corporate backbone. This tactic runs counter to the drive to network everything, making near-real-time device status available to the entire organization. While that approach supports management desire for “more and better information” (or in this case current raw data), it establishes a flat, unprotected network open to attack. Firewalling off IoT 0.9, or running them on a separate network entirely, will at least provide isolation. Out-of-band sensors on that isolated network can detect and report on suspicious traffic without impeding device responsiveness or safety.
IoT 1.0 We will call the middle group IoT 1.0. These hybrids consist of devices that network using some of the OSI stack. These hybrids present the largest problem. They fulfill their OT requirements (typically safety and reliability) well. Their fundamental architecture insures that. However, they usually do not incorporate network security capabilities in their design. Their architecture does not address information security.
Hybrids are constrained. IoT 1.0 devices have limited bandwidth, scarce processing power, short battery life, and not much memory. They use what resources they have to provide real-time responsiveness and high availability, not to encrypt data, authenticate incoming messages, validate access control requests, download signature files, or scan for malware.
Networked hybrids are easy to discover using Shodan or Censys. They lack firewalling or filtering. They respond to network requests efficiently, rapidly, and naively. These early devices assume the integrity and privacy of the network they are on. They assume that any incoming signal is correct and intended for them. The underlying model is mechanical – if I push on the brake, the vehicle should slow down. If I flip the switch, the light should go on. Authentication takes time and could delay a critical correction. As with IoT 0.9, network segmentation, isolation, and out-of-band monitoring, can mitigate some risk. Beyond that, IoT 1.0 can adopt network analysis techniques and tools from the IT security domain.
IoT 2.0 describes contemporary IoT devices built from the ground up, with full internet capabilities. These are the most securable – if security is an overt design criterion. IoT 2.0 devices may be much less constrained. Enhancements in battery capabilities, recharging techniques, low power operations, efficient processor design, advanced networking architectures, improved antenna design, and ample memory give IoT 2.0 a more IT-like system architecture. These devices are coming closer to conventional IT devices that can use contemporary information security technologies – with some adaptations. Logging to a non-critical channel or storage device, for instance, may be possible without compromising reliability, responsiveness, and safety objectives. Designing information security into IoT 2.0 is possible, but by no means guaranteed.
IoT 2.0 manufacturers can use a more mature information security model. The chip manufacturer ARM designs its current processor line with a secure kernel. This runs security processes, including encryption and system updates, with authentication, authorization, and logging. With power, these devices can maintain near-real-time responsiveness while providing core security functions in parallel. But the implementation has to be correctly architected and designed, and properly tested. Fortunately contemporary device manufacturers already have high-quality design and development process that can embrace the information security elements (and other non-functional requirements) of any contemporary SDLC.
IoT security is very hard. The nature of the difficulty, and the approach to its solution, depends on the provenance of the IoT device. Understanding these fundamentals will make it easier.
Let me know what you think! Add your thoughts in the comments below, or follow me on Twitter: @WilliamMalikTM.