Five Catch-22s for IoT security

In Joseph Heller’s novel Catch-22 the paradoxical conflict of the title is that airmen who were mentally unfit to fly did not have to, but anyone who applied to stop flying was demonstrating a rational concern for their safety, and therefore could not be mentally unfit to fly.

Here are five catch-22s for Internet of Things (IoT) security, each of which is effectively a paradox created by conflicting requirements.

1. Secure remote access to firmware: how to update/patch/reflash devices without enabling an intruder to patch/reflash them

As vulnerabilities and other bugs in a device are discovered, it is essential that they can be fixed by patching the device’s firmware. Devices which have been attacked are also likely to require replacement of their firmware by reflashing before they can resume operation.

Unlike computers and smart phones, many IoT devices have no human interface, and there is no way for them to obtain user authorisation to update themselves: instead, the support server needs to push updates and patches for automatic installation.

If an agent outside the local network is able to perform such updating, patching, or reflashing, then that makes inevitable the opportunity for an attacker to use the same process to install malicious code on the device, possibly rewriting its entire firmware.

2. Waking the near-dead: how to recover from denial-of-service attacks

An obvious aim in a denial of service attack is to shut sensors and IoT systems down, and lock them in such a shut down state, perhaps crashed and frozen. If this is successful, the sensor or device will be unreceptive to attempts to communicate with it over the network, as its network service is likely to be shut down too. Once it has lost its network connection, it is inaccessible for attempts to restart or reflash it, and can only remain in that shut down state.

One workaround, to connect directly to the sensor or device through a hardware port or UART, would also be open to an attacker who had gained physical access. Furthermore it would require physical access to the sensor or device, which could be difficult or costly.

3. No weak link: how to make simple, low-power devices as secure as all other networked devices

Any network is only as secure as the least secure device on that network. If there is one device on a network which is, for example, running unencrypted wireless communications, then it can and will be used by attackers to gain access to the network.

Accordingly, every IoT sensor or device needs to meet the same high security standards as any other device on that network. Those devices which need to operate for long periods on limited battery power cannot also support sophisticated and robust security protocols, which entail encryption and more.

This is already a serious issue for IoT doorlocks and the like, which cannot be provided with wired power supplies. It also means that those networked devices which might themselves appear to be unattractive or uninteresting targets, perhaps a kettle or supplementary lighting, cannot have weak security protection, or they could be used as points of entry into the network.

4. Together we fail: how to defend against remote server attacks, and limit access to data on remote servers.

Few days pass between successful attacks on major server systems. Remote servers which give access to individual IoT networks are more likely to be targets for attack than the individual networks themselves, as they offer an attacker a potentially greater yield of payment and other personal information.

Inevitably some users of these remote servers will not protect their accounts as robustly as others, e.g. using weak passwords, or accessing their account in circumstances in which they could be eavesdropped, and those compromised accounts could allow an attacker to gain access to others. Any compromise of the server would compromise all the data on it, and every user.

The consequences of a successful attack on a server supporting IoT systems are also much more serious. Servers accessed by computers can normally be shut down safely, and all affected users can change their access credentials. Once an intruder has gained access to IoT devices through a server, downing the server would have significant effects on millions of systems, and it would be a colossal (perhaps impossible) task to change the access credentials used by all those IoT devices.

5. Monitoring the autonomous: how to detect that a sensor or device has been attacked.

Successful intrusions in systems which are used by humans often pass undetected for days or even months.

A domestic appliance which appeared to continue to function normally would be assumed not to have been attacked, and could sit intercepting network traffic, for instance, for a long period before there might be any suspicion. Networks of IoT devices would appear to be in dire need of a system to detect network intrusion (NIDS), but making that effective is a major challenge.

The more autonomous the IoT device is, the more difficult it would be to monitor.