In a prior post, I poked a bit of fun at some IoT fails. Some might not be so funny. And so far, I’m not aware of anything resulting in a great deal of personal injury or death. So far. But here’s the thing… we’re getting ahead of ourselves here. The rush to market and possibly the industry mantra of Minimal Viable Product (MVP) is going to dump some more bad products on the market. Unfortunately, security is still very poor across the IoT marketplace. There’s a lot of reasons for this. Not the least of which is there’s not a lot of value to building it in; just costs. The sad reality is that security costs are often a so-called “negative externality.” That is, any impact is suffered by a third party. This will likely change once some more lawsuit hungry lawyers get more deeply involved.
So what can you do for now? That very much matters whether you’re a Consumer or a Maker of such items. As a Consumer, I’ve got a bunch of this stuff rattling about. As a Product Manager, I’ve only worked briefly on one effort, so hardly an expert. But here you go…
For Consumers
Do you really need the device? Personally, I love tech and gadgets. But does the thing you’re getting really make things better? Or just more complicated? If it’s not really providing core value, just don’t get it!- Don’t connect systems that don’t really need to be connected.
- Change default user names and passwords. This is the simplest thing you can do and the thing so many people are too lazy to do. Yes, you have too many ids / passwords. There’s multiple ways you can manage this. Write down the new ids / passwords on the manual and put the manual in your lock box for important papers. (You do have one, don’t you?) This should be reasonably secure in that you assume your home is secure. If someone breaks into your house, they probably won’t be changing your Smart Thermostat, but if this happens, just change the passwords. Or use a secure password manager. But the bottom line: Change the Defaults! This eliminates all the “not really hackers at all” from just mischievously getting into your stuff. Remember, your most valuable security asset is that chances are no one is really targeting YOU in particular. But if you leave things out there easy to sniff, then you invite the casual neighborhood kid who’s playing around.
- Change default user names and passwords on your router equipment. And stop broadcasting the SSID, (which is the name of your network), so it’s so easily seen by anyone in range. Yes, some devices and anyone intent on doing so might still be able to pick it up, but it makes things just a little more challenging.
- Remember that no matter what you do, as a typical home or small business user, chances are you’re going to be somewhat insecure. The cost / benefit of fully securing everything probably isn’t worth the risks. But doing the basics is kind of the same as just locking your doors, not having bushes blocking windows, having lights, and just making your stuff look a little less appetizing then the folks next door.
- For critical devices, consider backups. We have ‘net connected fire / carbon monoxide sensors in our house. The benefit of this is that if the one in the basement goes off, (which we should hear anyway), it will nonetheless alert other devices to go off as well. There’s also a voice component that will tell us where the problem is. Still, we keep some of the old fashioned fire / CO alarms in place as well. Because we just don’t fully trust the connected devices yet.
For IoT Makers / Builders / Producers / Product Managers
Decide to care about security. Even if you’re slammed to get something to market, consider the brand and legal risk implications of potentially worst case failures of your devices. Then re-consider if better security is worth the time / effort / money after all.- Recognize that you’re probably operating within a System of Systems environment. Security could involve more than what you’re doing at the edge. That is, IoT devices are typically going to be edge devices. They’re hanging off some network somewhere doing their little thing. Maybe they work directly with another device or two or a controller. Maybe they just phone home for updates or data squirts. But they’re part of something more. You might need to look beyond just your own APIs for vulnerabilities.
- Build in Error Processing and some means to recover. This could mean there needs to be some physical reset button. If a device bricks itself, gets bricked by a failed update or a hack, how will end user reset? The cost to your company in terms of reverse logistics, (returns, refunds, resets, whatever), could be a company killer. (Note: to “brick” a device means something happens to it to basically turn it into a useless brick.)
- Check for Performance Failures and Cascade Effects of such. If an update or some other function within the device might slow it down, does this affect other components? Maybe a 10 second update to a fire alarm sensor is a low risk thing. But if you end up with a large installed base, chances increase that one day you’re going to do an update right when a fire starts. What about devices that control others? If your device opens a door as something approaches and there’s a delay, maybe something not smart enough to look with its own sensors smacks into that door. Whatever. The possibilities are endless. Check for common Use Cases as best you can.
- Avoid rookie mistakes like not encrypting important channels or leaving default passwords right on devices in plaintext files.
- Do third party penetration testing. Another cost in time and dollars.
- Roll out updates in segments. It might not even be fair to do so, but maybe roll out intentionally to those most physically close to your reverse logistics endpoints just in case of a hard failure. If you do this, then no matter how good your testing, if you screw up, at least it won’t effect everyone.
Links to more…