Labelling for End-of-Life Consumer IoT

Yesterday, Rob and Tod dug into the details of some proposed language for IoT labelling for End-of-Life (EOL) and End-of-Service (EOS) devices proposed by our friends at the Center for Democracy and Technology (CDT) and other consumer advocacy groups.

The language is especially concerned about labelling for kidtech and medtech, and wants vendors to be more responsible for letting people know when their IoT toys, medical gear, and assorted other internet-connected doo-dads won't be supported with security and usability patches and updates.

You can read lots of opinions on this topic, including ours, at the Dark Reading article by Arielle Waldman, but to expand a little more on our concerns here, I wanted to jot down some things to keep in mind when thinking about how EOL/EOS actually works when it comes to labelling and handling it in your environment.

Notionally, it's a good idea to label consumer tech with an EOL/EOS date, but the devil will absolutely be in the details of how that will actually work. After all, you probably want to know that your Thing of the Internet will be vendor-supported tomorrow if you buy it today. Practically, though, it gets complicated, and fast. Every such Thing made today has a software stack, that in turn is often drawn from dozens to hundreds of open source projects. These software sources, the hardware assembler (who is usually the "vendor"), and the retailer all have to agree on pushing out a patch or update.

Here in infosec, we need to really internalize the idea that just because something is missing a patch doesn't mean it stops working, so it's a sneaky fail case that's hard for consumers to even notice. At the same time, your home network and all the stuff attached to it is now often also touching your employer network, so keeping up on patching at home is becoming a corporate IT problem. With work-from-home, IT is responsible for the PlayStation in the CEO’s living room. Sophisticated attacks can target developers at home, and have, by subverting the usual write code-compile-ship workflow at the "write code" part.

As far as the actual notification mechanism is concerned, while physical labelling on docs and the device can be helpful, we need to appreciate that the secondary market -- selling your stuff on eBay or donating it to Goodwill -- will break the relationship between customer and vendor, making timely notification (such as by warranty card) that much more difficult. Besides, just because a vendor tells you when the EOL date is doesn’t mean they have to tell you how to keep patched, or make it easy. Autoupdates can help, until the autoupdate service itself goes EOL. And these EOL/EOS dates aren't set in stone -- some vendors will backport patches (Microsoft) past EOL if it's really serious. Some don't (F5 nginx), and require you to update.

So, I'm super curious to see where this model language goes and if we'll make some headway in being open and transparent about the realities of maintaining old tech on your home network. Of course, that's an especially relevant question if your home network is so close to your employer's network. After all, if you're a knowledge worker in America today, your aging internet devices are really starting to become your CISO's problem.