The Internet of Things

[Ed Note: Clever graphic of Thing 1 and Thing 2 from “The Cat in the Hat” networking omitted, since The Cat in the Hat is public domain everywhere, except the United States. Please view replacement graphic below.]

  -------------------------      -----------------------
  | Thing 1 (192.168.1.12)|------|(172.16.0.1) Thing 2 |
  -------------------------      -----------------------

Via Network World comes an article about the “top five” threats to Internet of Things (IoT) devices. The article is somewhat unfocused, really more a collection of five different IoT use cases, but to be fair the entire IoT concept, and much of the security posturing around it, is also somewhat unfocused. Let’s try my lens.

As with all new buzz-cepts, IoT means different things to different people: the five examples given in the article in question are in-car WiFi, mobile medical devices, wearable tech/Google Glass, inventory control devices, and drones; quite a variety! In order to bound the scope a little bit, I’m going to decree that my definition of a Internet-enabled Thing is a device that both has a physical function and has a network interface that provides either command/control or telemetry of that physical function. In other words, I view the IoT as fully analogous to SCADA technology; the issue is that we are exposing management of physical functions to remote compromise.

Mobile medical devices, inventory control devices and drones pretty clearly meet my definition. I’m not as sure about wearable tech, since it’s really just a differently-shaped and functioned computer. But one could argue that it provides visual, audio and potentially other telemetry of the user’s physical environment…that’s probably good enough for me, but to be consistent you’re going to have to throw in all portable tech with a camera, microphone, or even a GPS chip.

The in-car WiFi is a tougher sell for me. To the extent that sensors and actuators for the physical vehicle utilize this network I’m tracking, but the article seems to argue that the risk is that your mobile tech might be compromised on your insecure in-car WiFi. That’s a different problem, so I’m going to chuck this one from consideration.

If one accepts my definition, then what is the risk? I’m not a big believer that compromising a device itself is necessarily a risk; certainly such a compromise is undesirable, but if an attacker can’t do anything with that access, who cares? I always consider my Mom’s computer as a use case; she used to email, occasionally surf the web and play Yahtzee. A dozen hackers could have been on her machine, and the only potential harm would have been using that machine as a zombie for a DDoS attack, or manipulating the random number generator so that my Mom never got a Yahtzee, which would have caused an apoplectic fit.

Anyway, to me the biggest risk with IoT is that it allows remote attackers to interact with the local physical environment. I don’t care that IoT devices tend to have poor to no security per se; I care because we are creating devices that are simultaneously less secure and more capable from a physical perspective. Stated this way, what are the potential solutions?

  1. Administratively ban this crap.
  2. Make the devices more secure.
  3. Provide a more secure environment on the network side to reduce risk of a compromise.
  4. Provide mitigating controls on the physical side to reduce the severity of a compromise.

As we learned with BYOD, administrative bans don’t work. Users will circumvent the ban, and given the added value that IoT can provide, security is going to lose the ultimate showdown anyway.

When an outright ban doesn’t work, the next line of defense is “we’ll consider it when certain security controls are in place,” i.e., make the devices more secure. This is certainly desirable, but needs to be tempered by realism. With the speed of technology, security is always going to lag capability so each new wave of devices is going to bring new vulnerabilities. Also the form factor and power requirements of certain sensors/devices is going to limit the amount of on-board processing, and thus security capability, of the devices themselves.

So what’s left is mitigation, or in other words, everything old is new again. Good old security design is going to be a critical component of integrating IoT into the enterprise…and probably the home too, as IoT penetrates your kitchen. But don’t forget the physical side of things too; the best thing to do when you aren’t using your IoT toaster is to unplug the dang thing. Somewhat more advanced, the devices should include physical controls to mitigate risks as well.

I think IoT is a manageable technology from a security perspective. But it’s not going to be easy or free, and in particular it is going to require real engineering to accomplish in a secure manner. The challenge for security professionals is to sell the need for additional resources, but actually IoT is your friend here. Senior executives may not fully grasp buffer overflows, but toilet overflows they can understand.

Comments are closed.