How to secure your IoT deployment in 10 steps
In nearly all cases, IoT has become almost too easy. Commodity sensors and radios make it technically simple to slap together a device and put it in the wild. Your average IT administrator would have a heart attack if you left a laptop configured to access your corporate networks, and a password of 'default' in the local coffee shop, yet this is effectively what occurs with many IoT deployments.
At the end of the day, you're essentially shipping a tiny computer that presumably has access to your intellectual property. Consider the security implications just as seriously as you would any other connected device. Here are 10 ways to do that.
1. Make security a feature
Perhaps the biggest security risk to an IoT deployment is considering security as an afterthought. Plan for security as you design the features and functionality of your IoT products and services, and you'll address and resolve important technical and product questions early, rather than at the last minute.
2. Don't buy into 'security through obscurity'
I've seen a variety of initiatives where 'security through obscurity' was the prevailing attitude, basically suggesting that the devices in question were deployed in small numbers, or so unappealing to hackers in the context of the connected universe, that security could be largely ignored. This is a recipe for disaster, especially since IoT devices can often access non-public networks, contain personal data, or are connected to critical infrastructure ranging from medical devices, to industrial controls, to devices sitting in our child's bedroom. Your deployment may only be a couple of dozen IoT devices, but that's no excuse to hardcode passwords as 'abc123'.
3. Consider security as cheap insurance
You would probably avoid specifying a component in your IoT device that's known to burst into flames, even if that component saved a few bucks, as it would obviously create significant long-term risks and expensive mitigations ranging from recalls to legal costs. Make a similar calculation with IoT security. There are plenty of real-world examples of the significant costs of poorly planned IoT security that demonstrate that it's often a much cheaper proposition to invest in security during the design phase rather than after your IoT devices are 'in the wild'.
4. Play hacker
During your design process, consider what aspects of your IoT deployment might be of interest to hackers. A connected car would obviously attract people attempting to unlock or remotely start the vehicle, while a connected camera would interest someone attempting to view video and photos. Consider in your planning that IoT devices are essentially tiny computers. If a hacker could gain access to one of your IoT devices would he or she have access to a secured network? Could he or she marshal the resources of thousands of your devices to launch a Denial of Service attack?Might a compromised device reveal aspects of your product or intellectual property? With an understanding of what's at stake, you can better plan your mitigation.
5. Go for the minimum
It's always tempting to gather and record as much data as possible. With cheap sensors, it's easy to capture more than you intend to use. However, the more data your IoT device collects, the higher the stakes should the device be compromised. Just because you can capture information doesn't mean you should.
6. Check all your components
Perhaps you've built a bulletproof application, tested it extensively, and closed all the likely attack vectors. That's all well and good, but if your IoT device runs a dated OS riddled with well-known vulnerabilities, all your work may be for naught. Again, consider your IoT device as a tiny computer, where security could be compromised at the network, OS, or application layer. Furthermore, those libraries and toolkits that sped your development along could also introduce their own vulnerabilities that must be monitored and mitigated.
7. Provide an update capability (as long as it doesn't present a backdoor)
No-one can develop a completely secure system, especially one that's connected to a public network, and invariably new risks will be identified long after your product is released. Therefore, build an update capability into your product that allows you to push security updates as necessary, and depending on the IoT application, without manual intervention at the device. Be sure to consider the security risks of this capability as well. Done poorly, an update capability is the perfect opportunity for nefarious actors to take over your devices.
8. Use the right hardware
Ideally, your IoT platform will embed security into the physical hardware, with everything from tamper-resistant packaging to trusted platform modules that incorporate security in the silicon. Where this is not possible due to cost or technical limitation, vet the vendors of your core components and look at their track record of responding to security incidents. If a problem is identified in a core hardware component, can you mitigate it through application code or firmware updates? If not, how is the burden of physical updates handled?
9. Map your system, end to end
IoT security doesn't end at the device, and you should consider the backed platforms and applications that connect with your devices as part of your overall security planning. Map out every system, the underlying OS and hardware, and versions of each. Ideally, you'll already have this level of diligence and supporting infrastructure in place, and if not, consider it a cost of entering the IoT space. Regularly track vulnerabilities to this 'IoT inventory' and mitigate accordingly.
10. Perform some 'IoT estate planning'
No one likes to think about their demise, but even in the realm of IoT devices you should consider what happens to these devices when the product or deployment reaches its end of life. Too many companies think that sending an email or two notifying customers that their devices are no longer supported is the perfect excuse to stop monitoring and updating them. Communicate with your customers what happens when the product reaches the end of its lifecycle, or your company discontinues support of the product. You may even consider disabling devices that are no longer supported, or requiring users to explicitly 'reactivate' the device in an unsupported mode with full awareness of the security implications. Reading up on the difficulties Microsoft had discontinuing Windows XP should provide some measure of awareness before you release your 100-million device product upon the world.