IoT: we need to get a grip on things

The network is all around us

Not so long ago, networked systems were secured by means of physical constraint. Preventing access to the network on which the devices resided provided airtight security in a ‘walled garden’ model. The ubiquitous connectivity brought by the IoT means this inscrutability is lost, as physical constraints are torn down in the name of user inconvenience. Networked devices can no longer depend on their being isolated in a benign network – the network is all around us, increasingly soaked into the very fabric of society, and, sometimes, it isn’t a very friendly place.

Sadly, software and systems engineering hasn’t kept pace with this paradigm shift. Distributed networked hardware is supported by abstracted infrastructure originally developed in friendlier times. The sheer ubiquitousness of these networks makes the prospect of failure untenable, with societal impact far in excess of the direct technical damage – think of the consequences of an attack on gas stations rendering fuel unavailable, for example. Taking down power grids by attacking infrastructure has already been demonstrated.

Managing security from deployment to disposal

So what to do? Most importantly, the entire lifecycle of the connected device urgently needs to be recognized and securely managed. Starting with development and provisioning, followed by deployment, bringing into service and operational use. Exception branches covering updates, field failure/repair and other events must also be taken into account. By far the most glaring omission today is the lack of structural end-of-life processes; taking out of service, decommissioning and disposal are mandatory phases that can’t be ignored.

Almost all IoT deployments today only focus on provisioning, deployment, bringing into service and operational use and, perhaps, some of the exception branches. Very few cover the costly, but essential, elements that ensure ongoing secure and reliable operation, such as vulnerability recognition and mitigation, bringing out of service, decommissioning and disposal. Current IoT systems demonstrate poor security hygiene: devices with known vulnerabilities remain in the field, data are leaked during the disposal process and, worst of all, networked devices remain active, unmaintained, unmonitored and unrecognized, long after their intended utility has ceased. The consequence of this ‘long tail’ of networked equipment not being adequately managed can’t be overemphasized: it represents a clear, present and ongoing risk to the integrity of any network with which the asset was, or is, associated.

The above is an abstract way of presenting risks that we all empirically understand; no one would countenance selling a laptop on without erasing the hard drive first, and the more astute recognize the equivalent risk with a mobile phone. But what about the data you left in the rental car you hired last weekend (destinations and routes, music, call numbers and durations, preferred seat position and temperature)? Extend that further to lightbulbs, washing machines and toasters, which can both leak our data and provide a beachhead for an attacker into our homes, and the risk becomes very obvious.

To expand on this lifecycle concept, we consider the life of an IoT asset in three distinct phases: bringing into service (BIS), management of service (MOS) and bringing out of service (BOS).

1. Bringing Into Service (BIS)

When a new device is brought into service, a ‘zero trust’ approach is essential. The source, identification and configuration of the candidate device need to be unambiguously established, as must its ‘base state,’ before it’s filled with secure material (program code, keys and other assets) to support its mission and enable communication back to networked supporting systems.

2. Management of Service (MOS)

In fairness, it’s this phase of the lifecycle that’s best supported by contemporary IoT frameworks, albeit incompletely.
During the lifetime of an IoT embedded system, new attack vectors and surfaces emerge. New compromise techniques will be developed, there may be changes to the platform software, environmental circumstances will change and, in the case of AI-embedding devices, the operation may be compromised through input data manipulation. No matter how good the verification and validation of the device was at BIS, the only way we can be sure it continues to operate correctly is by monitoring it to detect misoperation.
The response to this misoperation is graduated. As a minimum, it must be possible to render the effect of the endpoint invalid so it can’t impact the correct operation of wider systems or create a local problem. Ideally, the fault should be reported to back-end systems, preferably with supporting data such as triggering stimuli, configuration checksums, post-mortem memory dumps and other information that will be useful to better understand the root cause. Field-sourced information is essential to understand problems that arise during active use.
The final step is dependent on the type of device. Perhaps it’s appropriate to throw it away or render it for recycling, but it would certainly be preferable to be able to recover it back to an active state. Doing this requires that the device can be returned to a verifiably correct base state so that a new BIS process can be executed. The capability to do this can be designed into the device but can’t easily be retrofitted later.

3. Bring Out of Service (BOS)

Eventually, the useful lifetime of the IoT device will expire. There’s little money to be made by vendors during this part of the lifecycle, so it’s hardly surprising that it receives precious little attention. It’s a huge, and growing, problem. Assets insecurely discarded may contain keying material or, worse, operational data that would be of use to an attacker. It must be possible to easily, affirmatively and certifiably render a device ‘clean’ before disposal. Ideally, this process should be automated to reduce the possibility of error or omission.
Even worse than a device being simply discarded at end of life is the device that remains in the network as some kind of ‘zombie.’ This represents a compelling attack vector; it’s an unmaintained and unmonitored launch point toward other network-connected assets. For years, there have been stories of forgotten network servers plastered behind walls. Imagine how the risk multiplies when we start having to consider every lightbulb and temperature sensor.
There’s a negative consequence to this active-BOS approach for consumers: the hardware they’ve purchased suddenly becomes worthless. This has happened in the past, and sometimes companies have been forced to back-pedal on their intentions due to user demand. We therefore may need to consider how users can continue to enjoy the devices they’ve purchased even when supporting back-end systems are terminated.