Are you thinking about the Internet of Things (IoT)? Maybe you should be — a whole new class of devices with previously unthought of capabilities is beginning to appear on the market. Corporate juggernauts and lean startups can both play the game, with home and personal devices from names like Google, Amazon, and Apple shelved alongside smartwatches from Pebble, connected LED bulbs from LIFX, and doorbell cameras from August.
The age of the Personal Area Network and the fully-connected, automated home is on the horizon, with some estimates expecting 26 billion IoT devices connected globally by 2020. Other estimates say 40 billion. Consumers and businesses have proven that they’re interested, and there are some exciting possibilities emerging for a company with a good idea.
So, now that you’re thinking about the Internet of Things, are you thinking about security for your IoT devices?
You most definitely should be.
As more of the things we carry, wear or have installed in our homes or businesses become inter-connected — to one another, and to the world at large through the Internet — the greater the importance of each and every device being as secure as possible.
Consider the consequences if an installed thermostat, a smartwatch worn by one of your employees, or even a connected lightbulb could become the gateway into your corporate network allowing an attacker to install malware and control or disrupt your operations — critical infrastructure is already being subjected to control and disruption by malware, and connected IoT devices pose a tempting target.
Even without exposing networks to penetration by hackers, some insecure devices have left consumers subject to gross breaches of their privacy. Such insecure practices have garnered significant fines and decades of mandated oversight for companies that haven’t put security first, or made security promises they then didn’t keep.
To keep your product from being the next one targeted by hackers, ridiculed by the press, or rejected by smart, security-conscious businesses and consumers, you need to take security seriously. The following are some of the key elements for a secure IoT device:
1. Security must be considered from the very outset of development, and be a critical part of all decisions made as to the functionality of the device.
This is easy to agree with, but harder in practice — it’s much easier to say “security is important to us,” than to give up on a desired feature in your product when your development team tells you it can’t be done in a secure manner.
Your engineers, especially the ones working on the firmware for your device and the software for any application(s) that interacts with that device, should be aware of all the common mistakes, pitfalls, and issues that surround creating secure software, and how to avoid them.
Missing or incomplete input validation that allows injection attacks, buffer overflow/underflow allowing arbitrary code execution, cross-site scripting attacks leading to stolen credentials, path manipulation allowing access to supposedly off-limit files, privilege escalation via any number of means. . . the list of common issues goes on and on. Your development team needs to be battle tested and security focused to get this right.
Don’t rely on your customer to configure your product for security, or allow an emphasis on ‘easy-to-setup’ or ‘easy-to-use’ get in the way of establishing secure defaults. Document for the customer what security measures have been taken, and how to use the device in a secure manner. Features that allow for remote access to the device should be disabled by default, passwords should be random, complex, and unique to each device, etc. A good, security-minded development team will be able to offer you a list of recommendations on how to make the defaults of a device and its software secure.
Even with competent, security-minded developers, there will be bugs in any complex software. Before releasing your product to market, you’ll want to have a full security audit done by a trusted, security-focused individual or team (who isn’t part of your development team) to take on the role of a malicious hacker and try and exploit any lingering security issues in your software. If any problems are found, they should be fixed before release — only when the software is as watertight as you can make it is it safe and responsible to put that product on the market.
A project with security-conscious developers, that has been run through a security audit and come out clean, is secure forever — right? Unfortunately, no — even if every line of code was secure to the best of your knowledge at the time of release, new bugs may be found in software at a later date — in your product’s code, or in the code of the various packages your software may rely on.
This means you need to establish from the beginning how the firmware in your device or the software that interacts with said device is going to be updated. In some cases, you’ll be able to take advantage of existing secure channels, such as an App Store. In other cases, however, plans should be made to ensure that your device can connect with a secure update point, is as secure as you can make it against having it’s secure channel subject to redirection (where the device is convinced to connect to a malicious endpoint) or MitM attacks (where the secure channel can be snooped on or subverted by a third-party), and is able to update itself only with signed updates (to certify that the files used for an update with are coming from a trusted source).
The final commitment to making your device secure is keeping your device secure. This means supporting your device for years to come, and being careful to communicate with your customers when the end-of-life for a product is approaching, to give them enough time to safely migrate to another product.
If you’ve managed to keep your customer, their data, and their privacy safe, and proven your commitment to security, that new product will likely be another of yours!