There is a wide and growing concern for the security of the Internet of Things (IoT). It's abundantly clear that the Internet is infested with neer-do-wells who thrive on hacking into networked devices. But many embedded development teams have never had to deal with security issues before, and are still trying to decide what, if anything, they need to do.
To get the perspective of someone “in the trenches” of IoT design, I spoke with Hugo Fiennes, CEO and co-founder of IoT platform maker Electric Imp, who will be speaking at the upcoming ESC Boston on Best Practices for Designing IoT Security from the Ground Up. He had a number of suggestions, many of which he has put into a Slideshare presentation on “rules” for IoT design. The first three of his rules will get a development team well started on the road to IoT security.
First, plan on making your device able to have its firmware remotely updated in a secure manner. The security landscape is undergoing continual change. What keeps attackers at bay today may not work tomorrow. But customers have the reasonable expectation that the equipment they purchase will provide good service for a long time, and without a lot of bother. So, it's almost certain that an IoT device will need security updates over time, so the facility for making those updates needs to be a fundamental part of its design. The era of sell-and-forget is over for IoT.
This rule has many ramifications. The product will need some form of support service to create, manage, and provision the needed updates as well as a secure channel to that service, and that service needs to be planned for as part of product development. The product will also have to be designed to validate the updates it receives before accepting them, be able to continue operating while the updates are loading, and ideally be able to roll back to a known good state if for some reason the update creates a problem for the user. The whole process should also be pretty much automatic.
Second, start thinking about security from the earliest design steps. Security is not something you can bolt onto a working system and have it be effective. It cannot be treated as an afterthought. It must be integral to the device design, not a wrap-around armor plate. Otherwise, the design will have avenues for attack that you don't know about. Look at things like data flow, feature sets, and the setup process to make sure you have considered the security needs and implications for every aspect of the design.
To read the rest of this article, visit EBN sister site EDN.