Why not homegrown over-the-air software capabilities?
According to Gartner, there will be almost 3 billion new internet-connected devices in 2018. Unfortunately, most of these devices lack basic security features, making them susceptible to hacking and being compromised. A few days ago, California took the first steps in making connected devices more secure with its “SB-327 Information privacy: connected devices” bill. This is a step in the right direction.
One basic security feature for connected devices is the ability to remotely and over the air (OTA) do firmware and software updates to patch security vulnerabilities. According to McKinsey, in the medical sector there will be product recalls worth more than $1.6 billion this year due to software vulnerabilities and the inability to remotely update and fix them. The same dire situation exists in most other industries.
In addition to the lack of OTA capabilities for connected devices, another worrying fact is that among devices with OTA capabilities, most are made in-house by the device vendors themselves. This article will focus on why, if you are about to develop a homegrown OTA, you should stop doing it, and if you already have a homegrown OTA, why you should consider moving away from it for your next-generation products.
Not designed from scratch with security in mind
Most homegrown systems erupt from a last-minute realization that a new, soon-to-be-launched product needs a way to be updated and reached. From this emerges an insecure and fragile OTA solution made in a hurry by in-house developers. This initial version runs the risk of becoming the core of an ever more complex and ad-hoc OTA system, developing like a Frankenstein.
At Mender.io, we have talked to many developers of homegrown systems, and it is scary to discover how many have created a backdoor, just in case. Homegrown OTAs are seldom created with security in mind. The security ignorance remains an Achilles heel throughout the lifetime of the devices for which it was made.
Not made by system management developers, but product developers
Homegrown systems emerge from product developers who typically lack basic system management insight.
The result can be seen in OTAs with no or very hard to use operational and management capabilities. Secure bootstrapping, encrypted communication, logging, monitoring and device grouping are just a few examples of basic system management features alien to most homegrown technologies.
Not open source
The code behind homegrown solutions is often closed source because the system is specific to the company and considered unique. Consequently, the code remains inspected and reviewed only by few people, sometimes even only one person! This poor scrutiny and reviewing of the code makes it a less secure and solid system than if more developers would have contributed.
Undesirable bus factor
Not considered core to the company, often only few or even a single person stand behind the homegrown OTA. In such cases, the company runs a great risk if its developer resource(s) suddenly disappears. With few or no one else knowing or understanding the code, the company might even lose their ability to do OTA at all.
Not optimized for CI/CD pipelines
Homegrown technologies, being an afterthought, are seldom API-driven. According to our findings, homegrown OTA systems normally take form as standalone applications serving a very specific need for a specific product.
Modern DevOps software development processes require API access to the OTA updating process. Reengineering a standalone application to support a suitable API schema will be both costly and time-consuming.
Not suitable for mergers and acquisitions
As homegrown systems typically grow organically and without a longer-term product roadmap, they risk ending up being extremely product-centric. Serious reengineering will be required in order to adapt the OTA for another product.
As companies with homegrown OTAs acquire new companies and technologies, they cannot rely on their existing OTA, and over time end up with a myriad of various OTA and device lifecycle management implementations.
Not brick safe
Device bricking is costly. Creating an OTA that can recover from a fatal update, for instance, due to sudden loss of power, is not trivial. In interest of cost and time, developing a solid and automic OTA seldom makes it to the world of homegrown OTAs.
Not satisfactory documentation
Documentation normally suffers as homegrown OTAs stem from one or a very few number of developers. Since the system also is operated by the same people, the need for documentation among these super users remains non-existent. If any documentation exists, it is often in the form of out-of-date wikis or other unmaintained documents.
Not high quality
A homegrown OTA, being an afterthought and monolithic application, seldom has high code test coverage. Born out of a last-minute urgent need, the system typically was developed in a hurry to meet the minimum acceptable criteria. Testing and test coverage never made it to the top of the list. Unfortunately, as the system matures, test coverage continues to suffer.
Being closed source and with few eyes contributing and reviewing it makes it easier for the homegrown OTA developer to continue having low test coverage.
Conclusions
In this article, a series of arguments have been made for why owners of homegrown OTA solutions should migrate away, and why for new products your organization should consider using a vendor-provided OTA.
In addition to all the arguments listed, the most obvious argument remains: You don’t differentiate your product at the system level. Product companies should spend all of their resources creating new revenue-generating features, not undifferentiated system management services. These services customers take for granted anyway, and are not reasons for buying your products in the first place. Products succeed because of their features and promise, not their ability to be remotely updated and stay secure.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.