Last month, Linux Journal published an online article on key considerations for software updates for embedded Linux and IoT. The article was written by our own Eystein Stenberg.
Below are the key takeaways from the article.
There are two main reasons for ensuring you are be able to update your embedded devices.
Software bugs inevitably exists in your device. Steve McConnell in Code Complete states there are 1–25 bugs and vulnerabilities per 1,000 lines of code. This is a reality the world has come to live with.
Security breaches can seriously harm your company financially. The recent Equifax breach has shown how a widespread vulnerability not only results in layoffs, but also serious brand damage and potential huge penalty fees. The Linux Journal article points to Mirai and how this affected about a million Deutsche Telekom customers due to software vulnerabilities.
According to interviews of more than 30 embedded engineers conducted by our company Northern.tech, 45.5% of the respondents said that updates were never being deployed to their products. Their only way to get new software into customer hands was to manufacture hardware with the new software and ship the hardware to the customers. Roughly the other half, 54.5%, said that they did have a way to update their embedded products, but the method was built in-house. One of the key findings here was that virtually nobody reused a third-party software updater—they all reinvented the wheel!
Our survey reveals a concerning state of affairs:
• Approximately half of all the products can not be updated
• The other half mainly uses home-grown solution to do updates
The silver lining is that almost 50% do have a way to update their devices. However, looking further into these homegrown solutions they are often developed last minute before product launch and therefore poorly designed. They tend to be unreliable, insecure, and often include a backdoor “just in case.”
Creating a reliable and secure embedded software updater calls for careful planning and several aspects should be taken into account. The next section highlights the most important considerations.
Several options exist, ranging from full image update to package to individual files. They all come with their own pros and cons.
Embedded devices by nature live oust in the field where recalls generally are very expensive and to be avoided. Items to consider include unreliable power, unreliable network, expensive physical access and expected long device lifetime
When designing a security product like an updater, several important criteria should be included. In the article Mr. Stenberg talks to items like robustness, application security, atomic/non-atomic updates, consistent deployments, authenticity checks before updates, sanity checks after updates, integration with existing development workflow, bandwidth, downtime during update, as well as deployment management.
Every connected device should have a way to be updated because its software most likely is or will be vulnerable at one point. Combine this fact with the cost of a breached device that can be devastating for your company, and you should have all the arguments needed.
Creating a robust and secure updater solution is very time-consuming and requires careful planning. A strong recommendation would be to use an open source solution like Mender.
If you decide to develop your own software updater solution there are several key considerations to take into account. This blog post has pointed out some of the most important ones.
If this blog was of interest, please go to Linux Journal to read the full article here.