(I)IoT security is not SCADA security

The other day, at the annual Worldwide Threats hearing of the Senate Armed Services Committee (SASC) – the literal sum of all fears of the intelligence community and the US military -, the testimony of DNI James Clapper made notice of the emerging threats of hacking the Internet of Things:

“Smart” devices incorporated into the electric grid, vehicles—including autonomous vehicles—and household appliances are improving efficiency, energy conservation, and convenience. However, security industry analysts have demonstrated that many of these new systems can threaten data privacy, data integrity, or continuity of services. In the future, intelligence services might use the IoT for identification, surveillance, monitoring, location tracking, and targeting for recruitment, or to gain access to networks or user credentials.[1]

It’s good to hear a degree of concern for safety where IoT applications are concerned. The problem is, they come in two flavours, neither of which is helpful.

One is the “I can’t see your fridge killing you” approach. Beloved of Silicon Valley, it is generally a weak security approach based on the fact that for what it’s worth, most of IoT is a toy you can live without. So what if your internet-connected egg monitor stops sending packages to your MQTT server about your current egg stock? What if your fridge misregulates because some teenager is playing a prank on you?

The problem with this approach is that it entirely ignores the fact that Industrial IoT exists. Beyond that, you find a multiverse of incredibly safety-critical devices with IoT connectivity. This includes pain pumps, anaesthesia and vitals monitors, navigation systems, road controls and so on. A few of these are air-gapped, but if Stuxnet is anything to go by, that’ll be of little avail altogether. In other words, just because some IoT devices are toys doesn’t mean all of them are.

The other does take security seriously… but it smacks of SCADA talk. Yes, the dangers that affect interfacing a computer with the controls of any real world object, up to and including fridges, cat feeders and nuclear power plants, mean that there are particular dangers, and whether that interface is a 1980s protocol or the Internet of Things makes no great diference. But the threat of this perspective is that it ignores the IoT specific part of the risk profile. This includes, for instance, the vulnerabilities inherent in the #1 carrier medium of non-industrial IoT traffic – 802.11b/g. Any vulnerability in the main wireless protocols is in turn a vulnerability of IoT connected devices. I’d wager that wasn’t much of an issue back when Reagan was President.

Moreover, a scary part of IoT is that a lot of the devices interface directly with customers, rather than professionals. You cannot rely on anything that’s not in the box. The wireless network will be badly configured, the passwords will be the user’s birthday and generally, everything will be as unsafe as it gets. Of course, this isn’t even true for a minority of users, but it is the worst case scenario, and that’s what determines the risk profile of a component.

The bottom line is that if you ignore the incredible diversity of devices caught by the new favourite buzzword IoT has become, you get a slanted risk profile, towards toys (IoT connected floating thingies in your pool that measure your cannonballs? Are you serious?) or towards an aging system of industrial control protocols that some hope will be revived by, rather than supplanted by, IoT.

That’s a problem if you scratch anything but the top layer. Below the very specific layers, a number of fairly generic interconnection layers lie. And the consequence of that is that is that every layer, protocol or method of communication that can conceivably be used for IoT data transmission eventually will be used for that, and as such must have a defensible risk profile.

And in turn, every (I)IoT application must consider, in its risk profile, what the risk profiles of the stack it is based on is. Every element of the stack contributes to the risk, and quite often these risks are encapsulated in vendor risk estimates of higher-up layers sold as composite. Thus for instance an entire IoT appliance might be sold with a particular risk profile, but in reality, its risk profile is the sum of the risk profiles of all of its layers: its sensors, its hardware (especially where sex via hex is concerned – something that might arouse older engineers entirely the wrong way), the radio frequencies, the susceptibility of the radio hardware to certain unpleasant hacks, heck, even the possibility of van Eck phreaking on screens.[2] As a recovering lawyer, I entirely foresee that the expected standard from non-private users of IoT devices, as well as those who build IoT devices, will be examining the whole stack rather than relying in previous promises. It may be turtles all the way down, but you’re expected to know all about those turtles now. Merely subscribing to one of the two prevalent risk models will not suffice.

References   [ + ]

1. Testimony of DNI James R. Clapper to the Senate Armed Services Committee, 9 February 2016. Available here.
2. A few years ago, a large and undisclosed metallurgical company was concerned about information leaking onto the open market that indicated possible hacking of their output values at one of their largest plants, values that were, due to some oddities in the markets, quite significant in global commodity prices. After an enormously long hunt and scouring through the entire corporate and production network, they were about to give up when they found a van Eck loop antenna curled to the backside of a subsidiary monitor that an engineer has ‘hacked’ never to go into power save.