[From the last episode: We saw how we can attest to the legitimacy of IoTThe Internet of Things. A broad term covering many different applications where "things" are interconnected through the internet. device softwareIn this context, "software" refers to functions in an IoT device that are implemented by running instructions through some kind of processor. It's distinct from "hardware," where functions are built into a silicon chip or some other component..]
It’s really important to keep your IoT device software up to date. I know, it’s a pain on laptops and such, when you have to shut everything down and restart and all of that. It’s kind of the same process with an IoT device, except that it’s much more limited, and it probably doesn’t involve you at all except perhaps to allow the update to proceed.
They’re called over-the-air updates, or OTA updates. We call them that because so many IoT devices are connected wirelessly. That means that new software arrives wirelessly, which makes it like they’re arriving over the air. But don’t let the name fool you: if you have a device that’s plugged in instead of wireless, then it still has to be updated. Larger-scale industrial installations – like meshes of lightbulbs, or perhaps security cameras – may communicate over EthernetA very common Layer 1 and 2 standard for wired network connections. or the power lines instead of wirelessly. Doesn’t matter: they still need to be updated.
Are Updates Important? (Spoiler Alert: YES!)
First of all, why bother with all the updates? Well, the official reason is this: security folks are always discovering new vulnerabilities, and they need to patch them. If the original software that came with the device isn’t perfect (pro tip: it never is), then, at some point, it might be vulnerable to an attack.
But there’s another reason: competition and features. Everyone wants to be out with a device first. So there are couple of newish development philosophies that govern how developers write software. The first is the MBA notion of the minimum viable product, or, MVP.
Let’s say you’ve got a great idea for a device for home gardens that will help determine when to water and when to fertilize. It’s a lot of work to build both of those features. But, if you think that just testing for the need to water has value all by itself, then that product would be viable, and you can get it out much faster. You can then work on adding the fertilizing bit afterwards.
But here’s the catch: you have to think through what hardwareIn this context, "hardware" refers to functions in an IoT device that are built into a silicon chip or some other dedicated component. It's distinct from "software," which refers to instructions running on a processor. you need – specifically, which sensorsA device that can measure something about its environment. Examples are movement, light, color, moisture, pressure, and many more., and how they connect and communicate with the rest of the systemThis is a very generic term for any collection of components that, all together, can do something. Systems can be built from subsystems. Examples are your cell phone; your computer; the radio in your car; anything that seems like a "whole.". That has to be in the box when you ship it. The hardware used for fertilizer won’t do anything at first because there’s no software yet that will exploit their capabilities.
The magic happens after you’ve installed the device and are happily figuring out when (and when not) to water. One day, an update comes, and – voilà – your device is now testing for fertilizer with the new software. So in addition to plugging securityRefers to whether or not IoT devices or data are protected from unauthorized viewers. holes, an update may add new features. (Of course, it might not…)
Product Refinements
Finally, there is another reason that maybe sounds a little messier, and I honestly don’t know how much of this really happens with IoT development. Sometimes referred to with the name agile, there’s this notion – essentially – of throwing things against the wall to see what sticks. Developers would probably not like me saying that, and, done properly, it’s not as bad as that sounds. But, then again, it’s not always done properly.
The idea is that you just write some software quickly and get it out there to see how it goes. You then see what works and what doesn’t work, make some quick changes, and put it out there again. Rinse and repeat. So the developers are gradually refining the way the product works. There might even be a version A that some people get and a version B that other people get, and they test to see which is better.
This works much more effectively for applications that reside up in the cloudA generic phrase referring to large numbers of computers located somewhere far away and accessed over the internet. For the IoT, computing may be local, done in the same system or building, or in the cloud, with data shipped up to the cloud and then the result shipped back down., or perhaps for websites. It works better there because developers can update as often as they want and no one will notice (except perhaps that things work differently after the update).
With an IoT device, you’re likely to have to respond to a message that there’s an update ready, and you may need to give permission for the update. (It could also happen silently, without you knowing it.) If that’s happening every day, you’re going to get frustrated. That’s why this way of doing things is probably going to be much more moderate for devices that you own.
So… what does this have to do with IoT security? That we look at next.
Leave a Reply