IoT at Scale: Device Security

IoT has taken the world by storm, and it's only getting started. Driven by market trends like security improvements, Software as a Service, edge computing, analytics, smart cities, Industry 4.0, smart homes and innovations in healthcare, IoT is changing the competitive landscape in every market vertical. 

Fortune Business Insights predicts that the IoT market will grow from USD 250.72 billion in 2019 to USD 1463.19 billion by 2027, a compound annual growth rate of 24.9 percent.

All that opportunity comes with some significant challenges, especially when it comes to scaling IoT systems up to thousands of devices. It's easy to overlook the scaling problem when you start the IoT journey because every IoT system starts with one device. It's easy to provision one device. It's easy to walk over and update it when you have a new firmware image. It's easy to control access to it. 

This is not the case with systems that aim to scale beyond a few devices. Systems that aim to deploy large numbers of devices across a wide range of tenants and geographic locations have many different concerns that need to be addressed to ensure they can be managed in a secure and efficient way.

Over the next few articles in this series, we'll discuss important scaling topics like provisioning, configuration, hierarchy management and optimizing your device management strategy for getting IoT data out of your system in a performant way. These are all very important topics, but none of that matters if your system is compromised. Security isn't one of the things that can grow along with your business. IoT is a prime target for all sorts of nefarious IT behavior, and security must be air-tight, no matter where you are on the IoT journey.

The device security situation

There are number of common factors and practices that contribute to IoT's security woes. IoT devices are often small embedded systems with limited resources that simply cannot run some of the more feature rich operating systems. The devices are often located in "the wild" where they can be physically accessed by bad actors. They use password security that can easily be brute force hacked and lack update capabilities crucial for patching vulnerabilities discovered after deployment. They don't use encryption or individual device credentials, and forgo device hardening, leaving ports open for even the novice hacker to exploit. 

This lack of security would not be tolerated in a traditional IT environment, so why do we tolerate it in IoT? Perhaps we consider IoT less critical? Nothing could be further from the truth. In fact, in many cases the criticality of IoT systems is even higher than traditional IT systems. If a PC is compromised or a backend service is infiltrated in a traditional IT infrastructure, typically the worst thing that can happen is that data is stolen or communication prevented. 

Unlike traditional IT systems, IoT systems often integrate with and control heavy machinery, motor vehicles, healthcare systems and public transit. If systems like these are compromised, public safety can be put at risk, and that is not acceptable.  For a real world example, check out how vulnerabilities in wireless medical implants open patients up to attacks.

How are hackers attacking IoT devices?

Vulnerability points on an IoT system are broad, ranging from manufacturing and provisioning, through the boot process on the device to its integration points with the host and command-and-control systems.

There are three main goals for compromising an IoT device.

1. Place malicious files on the device to disrupt or alter the behavior of the device and it's intended function.
2. Gain access to the device's credentials for the host platform so that malicious files can be sent there to disrupt or alter the behavior of the host platform, or to launch Distributed Denial of Service (DDOS) attacks on it.
3. Intercepting and/or modifying operational data being exchanged by devices and the host platform to cause problems or steal data.

Boot time attacks usually work by modifying boot loaders or key OS files called during the boot process. Similar attacks can be launched on files used at runtime. The files are modified or replaced entirely to create malicious outcomes.

Poor device security can do more than expose the devices themselves to attack. If an attacker gains access to the security credentials the device uses to connect to the host platform it can use those credentials in a number of different ways, depending on how the system is designed to function. Malicious files can be uploaded to the host platform. Operational data can be spoofed, and DDOS attacks can be launched.

If operational data exchange between a device and the host platform is allowed to be intercepted the system is open to man in the middle attacks. This allows attackers to eavesdrop on communication between the endpoints in the system, and even modify data being exchanged between those endpoints on the fly.

The key to preventing these kinds of attacks is hardening the IoT device so that hackers can't gain access to the file system or memory, encrypting all communications, and enabling in-service updates so that bugs and vulnerabilities can be patched. However, our security experts at WWT recommend a security posture that considers these kinds of breaches inevitable, so it is also recommended that key operating files be regularly checked for corruption, encryption at rest be used for sensitive data, and security keys and access policies to the host platform be managed in a way that allows easy revocation and rotation.

How can we prevent these attacks from succeeding?

The good news: this isn't a new problem. Traditional IT teams have had these same vulnerabilities with IT infrastructure for decades. It's taken the IoT world a while to catch up, but in recent years there's been a major acceleration of the adoption of mitigation techniques created to solve these same problems in the IT world, and the practice of IoT security has improved drastically because of it. Below you will find a comprehensive list of such security principals.

Hardware security modules (HSM)

HSMs are physical electronic computing devices that use standards such as Trusted Platform Module (TPM) 2.0 to help safeguard computing platforms from intrusion and assist in detecting intrusions when they happen. They provide capabilities such as crypto key generation, encryption/decryption signature engines and secure key storage, and can be used as a root of trust for platform integrity. They are designed to be very difficult to extract security keys from without destroying the device and provide tamper detection that allows for security keys contained within to be erased when an attempt to tamper is detected. HSMs are a key enabler of device security because they provide a secure way for the software systems running on the platform to store secrets with a high level of trust that they won't be compromised.

Secure boot

This Unified Extensible Firmware Interface (UEFI) feature verifies that each software component used in the boot process has not been altered since the last known "good" state. This process uses an onboard HSM module as a chain of trust for the cryptographic signatures of each piece of software in the boot process, and will only handoff control to the operating system if the signatures are validated.

Boot attestation 

Uses measurements taken during the secure boot process to communicate the trustworthiness of the software running on the device to a host platform, and attests to the integrity of the system.

Runtime attestation

Similar to boot attestation, the runtime attestation uses tools like the Linux Integrity Measurement Architecture to detect if key software files used at runtime have been altered since the last known "good" state and acts on the results of the evaluation.

Authenticated connections & encrypted communication

Many IoT devices communicate to host systems over the public Internet, where communication can be intercepted by bad actors. But even if your IoT system isn't communicating over the public network, it's best to have an authentication and encryption scheme for all device communications. Mutual TLS is a recommended standard that uses x.509 certificates and asymmetric key cryptography provisioned both on the host system and on the IoT device to authenticate and encrypt communications between them. Whatever protocol is decided upon, it's important that asymmetric keys (dual public/private key solution) are used as they are more secure than symmetric keys (single key solution).

Individual authentication credentials

As mentioned above, using x.509 or other asymmetric key standards is highly recommended for authentication and encryption, but it's also important that a key is not distributed to multiple devices. Each individual device should have its own identity with the host platform, and thus its own unique authentication and encryption credentials with the host platform. Individual credentials are important because if multiple devices share the same set of credentials and those credentials fall into the hands of a bad actor who uses them to do something like launch a DDOS attack, you will be forced to revoke those credentials, effectively cutting off communication to all devices sharing them. It is considered a best practice to enable key rotation as well, allowing for expiration dates on all security keys and forcing devices to retrieve new credentials prior to their expiration.

Individual or group authorization policies

It is a best practice to have an individual authorization policy attached to each individual set of authentication credentials or at least have group policies that can be applied to subcategories of devices. This allows for the principal of least privilege to be applied.

Brute force attack prevention

Brute force attacks are primitive hacks that employ computer algorithms to guess passwords and try them in an infinite loop until they guess correctly. They are far from innocuous and can be very effective. Common methods for combating brute force attacks include locking out an account for a specified period of time after a certain number of incorrect login attempts, not using default ports, two-factor authentication and limiting privileges over SSH to prevent root access.

Device in-service updates

IoT devices aren't perfect, and just like other IT equipment they need to be updated from time to time to fix bugs and to implement security patches. Having an in-service ability to update the software and files is critical. Using code signing techniques so that devices can verify the source of the updated files is considered a best practice.

Threat modeling

An architectural and data flow exercise designed to identify risks and potential vulnerabilities in IT systems. This is typically an evaluation done by a security professional who is aware of the structural weak points in IoT devices and can probe for and identify those weaknesses. The output of a threat model is a set of safeguards that should be implemented to better protect the system.

Device hardening

In general, hardening is reducing attack surface vulnerabilities based on the findings of a threat model assessment. It often includes implementing many of the above mentioned techniques but could also include things like configuring firewalls with specific port rules, creating stronger passwords, implementing security patches, updating logging practices and tightening access policies. The idea is to make the device as hard to break into as possible before sending it out into the wild.

Be prepared

Because of the diversity of technologies used in IoT devices and the breadth of applications that they will service there is no one-size-fits-all approach to applying the security principles we've discussed in this article. It is important to take these principals and apply them in a way that acknowledges both the criticality of the work these devices do and the fact that this makes them high value targets.

Improving device security will arm the IoT revolution with the tools we need to bring first class safety to a brave new world. Be safe. Have fun. And be sure to keep an eye out for the next article in this series by following our Internet of Things (IoT) focus area.