IoT: we need to get a grip on things

From traffic lights to bridges, doorbells to power switches, everything, everywhere seems to be getting connected. The benefits of such connectivity are evident from the vending machine that never runs out of stock to the pump that never fails in a building that’s always at just the right temperature. It can no longer be argued that the IoT doesn’t deliver benefits. Computing power is cheap and power consumption low. The possibilities are seemingly infinite, but with power comes responsibility, and today the full scale of those responsibilities isn’t widely understood.

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.

These visceral risks will only continue to multiply as we deploy more and more networked systems. In fairness, state-of-the-art IoT frameworks do pay close attention to device security but largely limit themselves to deployment, identity and communication concerns. Lifecycle management, vulnerability mitigation, ongoing management oversight, out-of-band monitoring, secure update, compromised device neutering/recovery and end-of-life disposal are at best given lip service.

Already the impact of this neglect is tangible: in 2021, ransomware payments were estimated at a staggering 20 billion dollars, while cybercrime costs amounted to an even more shocking 6 trillion dollars globally. To date, the majority of the attacks have been via desktops and servers, but the increased prevalence of IoT infrastructure offers whole new attack surfaces with a much more physical consequence of failure. Continuing to ignore these risks is quite literally sowing the seeds of future disaster.

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). 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. 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.

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.

Developing embedded systems

Virtually all IoT devices contain embedded software with varying and sometimes high levels of intelligence and functionality. This software is at the heart of the device. It controls the hardware, processes data and communicates information to the back-end. The embedded part is where the greatest vulnerabilities arise.

For developers, security of the embedded functionality of networked devices should therefore always be top of mind. This begins at the development stage, but it remains a factor throughout the lifecycle. Developers must avoid the mentality that their responsibility for device security ends once the sale is made and it’s equally essential for customers to understand that there’s an ongoing cost to maintaining the hygiene of their networks, especially when IoT assets are connected to them.