IoT: the four tiers, and the patching vulnerability nobody is to blame for

Four generations, and which one people mean

The devices we now call the Internet of Things arrived in four waves, and the exam-relevant point is which wave the phrase actually names.

1. Information technology — PCs, servers, routers, firewalls. Bought by enterprise IT staff, primarily wired.
2. Operational technology — machines and appliances with embedded IT, built by non-IT companies: medical machinery, SCADA and process control, kiosks. Bought by enterprise operational-technology staff, primarily wired.
3. Personal technology — smartphones, tablets, eBook readers. Bought by consumers, exclusively wireless and often in several wireless forms.
4. Sensor and actuator technology — single-purpose devices bought by consumers, IT and OT alike, exclusively wireless, generally in one wireless form, and deployed as part of larger systems.

The fourth generation is what "IoT" normally means. Note what changed across the four: the buyer stopped being a specialist, the count went up by orders of magnitude, and the device stopped having a screen someone looks at.

Five components of an IoT-enabled thing

A sensor measures a physical, chemical or biological parameter and emits an analogue voltage or a digital signal, normally into a microcontroller. An actuator takes a signal from a controller and acts on the environment. A microcontroller is the deeply embedded part that makes the object "smart". A transceiver provides the transmit and receive electronics, almost always wireless — Wi-Fi, ZigBee, Bluetooth. RFID tags and readers identify objects, with readers that acquire and sometimes rewrite tag data at ranges from a few inches to several feet.

The sensor/actuator pair matters for a reason beyond bookkeeping. Compromise a sensor and the attacker injects false data — your view of the world is wrong. Compromise an actuator and the attacker moves machinery. Those are different classes of harm, and a security argument that treats "an IoT device" as one thing has already lost the distinction.

Edge, fog, core, cloud

Rideau Library instruments its shelving with weight sensors and its doors with counters. Four tiers stand between a sensor reading and the analytics that use it.

Edge — the sensors and actuators themselves, sometimes aggregating among themselves, plus gateways that interconnect the devices to higher-level networks, translating protocols and performing basic aggregation.

Fog — also called edge computing. It converts raw network data flows into information fit for storage and higher-level processing, near the sensors. Five operations are named, and they are worth learning as a set because they are what "fog" concretely does: evaluation (is this worth escalating at all?), formatting (normalise it for consistent higher-level processing), expanding or decoding (add context — origin, units, calibration — to otherwise cryptic data), distillation or reduction (summarise, to cut both traffic and higher-level load) and assessment (threshold and alert detection, possibly redirecting data to extra destinations).

Core or backbone — very-high-performance routers and high-capacity, redundantly interconnected lines joining geographically dispersed fog networks and reaching outside the enterprise, possibly to large database servers and a private cloud.

Cloud — storage and processing for the aggregated data, hosting both the applications that manage the devices and the applications that analyse what they produce.

Why the fog tier exists at all is a matter of volume: an offshore oil field or refinery can produce on the order of a terabyte a day, and an aircraft multiple terabytes an hour. Shipping that to a central site and deciding there what mattered is neither affordable nor fast enough. The general contrast is centralised-and-few against distributed-and-many: the cloud has high latency, full centralised control and tens or hundreds of millions of users; the fog has low latency, distributed and partial control, and tens of billions of devices.

The patching vulnerability

Here is the causal chain, and the reason to trace it link by link is that no single party in it is behaving irrationally. That is what makes it a structural problem rather than a moral one, and structural problems do not respond to being deplored.

Chip vendors produce and sell the low-cost, low-power processors these devices are built on. They compete on price and on speed, so they optimise the firmware they ship for exactly that, and they have no ongoing relationship with anybody who will eventually own a device. Device makers select chips on price and features, and touch the supplied firmware barely at all — their concern is that the device performs its function, and rewriting a vendor's firmware is cost with no visible feature attached. So the firmware that ships in the finished product is essentially the firmware the chip vendor wrote, for a device the chip vendor never saw. The end user then often has no patching mechanism at all, and frequently no information about whether patching is possible, when it would be needed, or how it would be done. Multiply by a market: hundreds of millions of connected devices stay vulnerable indefinitely, and they stay in service for years because a sensor that still senses looks like a working device.

The consequence became concrete in 2016, when the Mirai botnet assembled hundreds of thousands of compromised IoT devices and used them to disrupt Internet access across the United States east coast. Mirai's technique was not sophisticated — largely default credentials on devices whose owners did not know they had credentials — which is precisely the point. The vulnerability is not clever; it is unpatchable.

One framework detail is worth carrying alongside it. In the four-level architecture — smart objects and embedded systems, the fog or edge network, the core network, and the data centre or cloud — level 1 is the most vulnerable tier, and for reasons that stack: the devices are not physically secure, they are expected to run for years, their availability is at risk, and on top of that sit the authenticity and integrity of sensor data, protection of actuators from unauthorised use, and privacy and eavesdropping concerns. Level 2's distinctive problem is different — protocol and technology heterogeneity against a uniform security policy — and levels 3 and 4 are conventional network and data-centre problems made hard chiefly by endpoint count. Naming the right problem at the right level is what separates a full-marks answer from a plausible one.