Key considerations for deploying software updates to IoT devices
December 13, 2016
In light of the Mirai botnet attack that enslaved poorly secured connected embedded devices and a new strain of Mirai that has caused network outages...
In light of the Mirai botnet attack that enslaved poorly secured connected embedded devices and a new strain of Mirai that has caused network outages to about a million Deutsche Telekom customers due to poorly secured routers, the importance of addressing security before bringing your embedded device online is more apparent than ever. A secure and robust deployment of software updates to your connected device fleet is one of a myriad of security considerations before your device fleet goes into production.
According to Steve McConnell in Code Complete, there will be 1-25 bugs and vulnerabilities per 1,000 lines of code. The need to deploy new features over-the-air (OTA) without recalling an entire device fleet would save manufacturers substantially on costs associated with issues such as the large DDoS Mirai botnet attack by securing devices remotely once a vulnerability has been found.
We launched our open source updater project, Mender.io, in response to a large number of conversations we’ve had with embedded developers. The vast majority informed us they had built their existing software updater from scratch, the implication being that they had approached updating their devices as an afterthought and rushed to build something that didn’t consider all the security nuances required. Those key considerations ensure the device…
… is robust and secure.
There are two primary approaches to updates – image-based updates and package-based updates – and both have their tradeoffs. Image-based updates are atomic and consistent, while package-based updates are fast, easy to develop, and use less network bandwidth. To meet the top requirement for robustness and security, an atomic installation is required.
Deployments need to be homogeneous across devices and test must equal prod. There needs to be a sanity check after the update to ensure another update can be applied – “it boots” is not enough. This also means that custom checks are required to ensure the devices can reach servers and the services are running, etc. And lastly, there needs to be a way to verify the authenticity of the update.
… integrates into existing environments.
The updater needs to integrate to existing environments. Few projects have the luxury of starting from scratch, but have existing development tools and build/test environments. Others include the hardware and operating systems, as well as simply having devices already in the field. It should be extensible to have custom update actions, sanity checks, pre and post install scripts, as well as custom installers.
… is easy to get started.
The ease of getting started is also important. How long does it take to test the updater on a reference board? Is the updater of high quality and well tested? Is it well documented?
… uses appropriate bandwidth consumption and minimizes downtime during updates.
The lower the bandwidth and downtime during the update the better – but requirements vary widely between embedded systems. If it is a safety critical embedded device, does it need to always be up? What is the maintenance window and how long and frequent are the updates? The network type needs to be considered as well, whether it is Wi-Fi, cellular, SigFox, etc.
These are the high-level considerations you will need to consider for your embedded design. 2017 is fast approaching, thus efficiently deploying updates to remote devices is a necessity. To help with the management, the updater should have a server that can connect and manage all client updaters and be able to group devices (e.g. by customer). Campaign management and device health reporting are also key considerations. Take all of these elements into consideration in order to address one of the many baseline security needs of connected embedded fleets.