The IoT Security Imperative – Part 2: Device Security Requirements

In Part One, Physical-Cyber Risk Landscape, we examined some of the unique characteristics of IoT security — specifically how IoT-enabled products and services have access to and control over physical objects/machines, people, and environments which makes IoT security different and in many cases more critical than traditional information system security. In this article (part two), we take the perspective of someone building or implementing an IoT system or solution and ask what security characteristics and attributes they should look for in IoT devices. In Part Three, we look at the security requirements for IoT development platforms.

IoT solutions are comprised of many components. ChainLink’s IoT Platform Framework (Figure 1) provides a way to understand these components and the role each plays within an overall IoT security architecture.

Note how the security component on the right spans the entire stack, implying that security needs to be included throughout all of these different components. Ideally the security within each component is coordinated and well integrated with the other components as well. That can be challenging to achieve in practice, as often the components come from a number of different providers and may include legacy components as well.

Device-level Security

One of the most central characteristics differentiating IoT solutions from conventional software technology is IoT solutions’ access to and control over physical devices, sensors, and actuators. Securing this base of physical devices is a crucial piece of the IoT security puzzle. In some cases, these devices are outside of your control. However, to the extent you have the ability to specify the security characteristics of these devices, here are some of the elements needed:

• Secure boot — One of the foundations for security in a device is secure boot. The initial software executed upon boot of the device should be immutable code¹ that verifies that the firmware/software OS it is about to run has a valid digital signature and has not been compromised.² This requires a number of capabilities external to the device, such as PKI³ and a trusted OS/firmware provider.⁴ Secure boot and many of the other attributes listed here require encryption capabilities on the device which can be provided via a secure cryptoprocessor (such as a TPM-compliant chip) or via software encryption.
• Trusted path mechanisms — The device should support cryptographically secured links providing secure communications channels.
• Secure updates — Secure and authenticated roll out of firmware and software updates and patches. Only digitally signed, trusted code should be allowed to run.
• Embedded firewall and intrusion detection/prevention — The device should continuously monitor network traffic, identify any malicious activity, attempt to block it, and record and report information about the attempted attacks.⁵ Further it should continuously monitor critical files, data, and firmware/executables for any unauthorized modifications.⁶
• Authentication and identity management — This is bidirectional — the device should be able to authenticate itself to the network and services it connects to. In addition, the device should have a means to authenticate any entity communicating with it.
• Access control – Access should be restricted based on the verified identity and privileges of the requesting entity. Ideally this provides fine-grained control for both the things being protected (files, applications, etc.) and the privileges granted.
• Quotas — Device and system quotas can help thwart distributed denial-of-service (DDoS) attacks.
• Residual information protection — Ensuring that memory/storage is always deleted when freed.
• Security management system integration — Many of these capabilities require integration into the external security management systems being used. In some cases, this requires specific agents or other software functionality running in the device itself. This includes integration with PKI management systems, IoT/device security management systems, and enterprise security management systems.⁷
• Physical security — The various physical ports on the device, such as the USB ports or SD card slots, should be physically secured. This can include things like secure port covers, locks, tamperproof security screws and other means to prevent unauthorized access of the memory slots and communication ports. Further, there should be some tamper-detection, so that an alert is generated when someone has for example pried open a cover or in other ways compromised the physical security. It is also good policy to keep devices in a locked enclosure and/or secure room whenever it is practical.
• Resource frugality – key challenge is providing all of these functions in embedded systems that have significantly less storage and processing power than desktops and mobile systems. Solution providers serving this environment have stepped up to the plate, for example employing ECC encryption, which uses about a tenth the processing power of the traditional RSA encryption algorithms to achieve the same level of protection. The resource constraints of your devices are important to consider when selecting an OS and security capabilities.

Examples of providers of device-level security functionality and services include Wind River, Icon Labs, Symantec, Axeda/PTC, Mocana, Allegro, ARM mbed, Infineon, IBM, KORE, and others. There are also providers of tools that can be used to improve security in the development of device code, such as Veracode, Klocwork, HP Fortify, and Coverity.

Security for Legacy and/or Limited-resource Devices

In many cases, an IoT solution may be connecting up legacy devices (such as SCADA/industrial control systems) or devices with much more limited resources (such as passive RFID). In either case, many of the capabilities listed above will not be available in the device itself due to the device’s existing inherent architecture and constraints. In this case, adequate protections must be made in the gateways, readers, and network connections for these devices.

Gateway and readers should include virtually all of the security features listed in the section above “Device-level Security,” such as secure boot, trusted communication paths, firewall, and so forth. Further features to look for in a gateway include:

• Segmenting and Quarantining — The gateway needs to be able to segment the network, quarantine individual devices or segments that may have been compromised and then provide for secure authorized management of the quarantined devices (such as the ability to remotely wipe the device and reload trusted firmware).
• Handling insecure devices — The gateway should be able to connect and provide security for legacy devices that themselves may not have security protection. For more on this, see Isolating Insecure Devices and Networks below.
• Handling secure devices — The gateway should be able to verify the identity of devices⁸ and establish secure connections to the device using the protocols available in the device.⁹

The overwhelming majority of existing passive UHF RFID tags lack any encryption capabilities, making it difficult for tags to verify the identity of readers and vice versa. Therefore, companies should avoid putting confidential data on insecure RFID tags. Instead they can use data that is meaningless on its own, but can be used to look up meaningful data in a secure database. The confidential data is thus protected by securing the database, rather than the RFID tag.

Isolating Insecure Devices and Networks

The approach advocated by the Trusted Computing Group for legacy industrial control systems is to isolate insecure devices and networks using a ‘Virtual Private LAN’ overlay. This approach isolates the legacy devices, but lets them communicate through secure channels to authorized systems and users using VPN technology.

It has also been suggested that machine learning can be used to monitor and learn the normal patterns of traffic and interactions between devices. In this way, anomalies can be spotted to detect when a device has potentially been compromised. Then the device should be rapidly quarantined until it can be investigated and restored or removed.

In Part Three of this series, we will look at security requirements for IoT Development Platforms.
_ _ _ _ _ _ _ _ _ _ _ _

For more research on the Internet of Things, see our IoT library.

For an excellent HBR article on how IoT is changing manufacturers (including a section on security), see How Smart, Connected Products Are Transforming Companies.

__________________________________________________________________________
¹ This means the immutable code is stored in memory that cannot be modified. Not all processors are set up this way. — Return to article text above
² For more on secure boot, see Securing the IoT: Secure boot as root of trust — Return to article text above
³ Public Key Infrastructure. See also Symantec’s Roots of Trust for the Internet of Things (IoT) — Return to article text above
⁴ I.e. whoever creates the device OS, device firmware, and any updates to it should be a trusted party that has taken the necessary precautions to ensure that all the engineers on the team and code being used can be trusted and have not introduced any malware into the code. — Return to article text above
⁵ For more on IoT firewalls and IDS/IPS, see The Internet Of Things Needs Firewalls Too and Intrusion prevention system (Wikipedia). — Return to article text above
⁶ If data or files have been compromised, the system should report on those as well as potentially disabling the specific application or the entire device and/or quarantining or deleting the suspect files/data/code. — Return to article text above
⁷ Examples of security management systems include IBM Tivoli Security Management, HP ArcSight ESM, RSA Archer ESM, McAfee ePO, Lumension Security, Symantec, Kaseya and many others. — Return to article text above
⁸ For example devices can be authenticated using EPID (Enhanced Privacy ID) — Return to article text above
⁹ For example, ZigBee devices may use IEEE 802.15.4 security features and CCM — Return to article text above

To view other articles from this issue of the brief, click here.