Would you deploy an IoT device if you knew it could be hacked? Surprisingly, the answer is usually “yes.” Even though security exploits are frequently reported, billions of devices are deployed every year because, in most cases, the tangible benefits of IoT solutions outweigh any perceived risks. However, a big increase in device breaches would change the risk-reward ratios driving these business decisions. Unfortunately, attacks are already on the rise. Last month, Kaspersky provided evidence of this trend by reporting that its honeypots detected 105 million IoT device attacks coming from 276,000 unique IP addresses in the first six months of this year—an alarming 7x increase over the same period in 2018. With IoT risks growing faster than IoT deployments, increasingly unfavorable risk-reward numbers will limit IoT growth unless device security is improved industry-wide.
Three industry trends offer the best prospects for reducing IoT security risks over the next few years. First, after many years of divergence, IoT device operating systems are beginning to consolidate. It’s a good bet that fewer, more widely adopted OS platforms will be more secure than many smaller ones. Second, mainstream IoT gateways and routers are becoming more trustworthy. This is critically important because routers and gateways are always exposed to the Internet and hacking them can open up unrestricted access to less secure devices that sit behind them. Symantec reported that in 2018 75% of IoT attacks targeted routers. If you think your home WiFi router is secure, you might want to run a web search on “router vulnerabilities” (Yes, now would be a good time to patch your router and review its security settings). Third, “big cloud” IoT ecosystems are increasingly focused on security and data trustworthiness. Controlling IoT ecosystems from end-to-end simplifies secure solution development by reducing the variability of system components. All three of these trends are pushing the risk-reward ratio in the right direction. In this blog, I’ll dig into the first one, device OS consolidation. I’ll cover the other two in subsequent blogs.
The first servers, PCs and smartphones had diverse platform architectures running a plethora of operating systems. Over time, Darwinian forces converged this chaos down to just two operating systems per platform type. Today, almost all PC clients run Windows or Mac OS, servers run Windows or Linux and mobile devices use iOS and Android. These mainstream platforms are trustworthy enough for worldwide deployment because massive investments in security threat modeling, architecture, hardware abstraction, system software, testing, patching, updating and monitoring are amortized over hundreds of millions of devices. Application developers deploy solutions on top of these platforms without tampering with the underlying security architecture. Security is therefore robust and consistent industry-wide.
Although the same kind of convergence is beginning to happen for IoT, the process will take much longer because embedded systems span a wide range of capabilities—from tiny sensors powered by coin cells to computationally intensive edge devices such as cameras with built-in AI-based image recognition. Each IoT application has unique characteristics that determine device requirements for compute power, physical size, network architecture, sensor interfaces and cost. Platform diversity drives IoT developers to build custom software stacks with unique implementations for OSs, system services, networking, security and software update. The cost of securing and updating these one-off stacks is spread over a relatively small number of systems so the overall trustworthiness of IoT devices is usually much lower than for mainstream platforms like phones and PCs.
The good news is that OS convergence is already taking place, particularly for larger IoT devices that run variants of Linux. Today, there are about a dozen mainstream embedded Linux distributions and some consolidation is expected. However, embedded programmers often need to build their own custom versions of Linux by selecting only the features actually needed for their application. Yocto (Linux Foundation) is a standards-based set of tools and procedures that uses the OpenEmbedded build automation framework to create customized Linux OSs for a wide variety of hardware from a common code base. Standardizing the Linux customization process is a big step towards OS defragmentation for microcomputer-based IoT devices.
Unfortunately, platform convergence for microcontroller-based IoT devices is much more challenging because these small platforms have strict limits on memory, flash, processing power, network bandwidth and cost. Since the dawn of embedded programming in the 1960s, these constraints compelled developers to squeeze every last byte out of the software stack. Moore’s Law will eventually relieve the pressure by providing more capable constrained platforms but it’ll take many years. Today, there are dozens of OS options such as FreeRTOS, Zephyr, ThreadX, Mbed OS, Keil RTX, Contiki, TinyOS, QNX, VxWorks and Micrium, to name a few (in no particular order). Over the next few years, this space is likely to consolidate around investments by big cloud IoT platforms and the open source community. For instance, ThreadX is now part of Microsoft, Amazon uses FreeRTOS, Arm offers Mbed OS and RTX and Zephyr is an open-source RTOS project from the Linux Foundation.
Consistent with the history of other mainstream platforms, IoT OSs are finally beginning to consolidate. This is great news for the IoT industry because device developers can simply write application code on top of increasingly secure, broadly adopted OSs rather than building unique, high-risk device stacks from the silicon up. This trend will help keep the IoT risk-reward ratio within an acceptable range as IoT growth accelerates.
On PCs and phones, developers write application code on top of mature, mainstream OSs. Now, the time has come for embedded developers to do the same. Device programmers should start by measuring the amount of effort spent actually writing application code vs. working on the underlying platform software. Building and testing an OS, writing low-level drivers, debugging a network stack, adding security features, coming up with a secure onboarding scheme and updating software in the field are all platform-level tasks that are now “table stakes” in the IoT game. Building custom system software creates new vulnerabilities without adding competitive business value. If your suppliers can’t hand you a broadly adopted platform where the entire system software stack is already built and tested then maybe you need new suppliers.
In future blogs I’ll cover specific options for embedded OSs, “big cloud” full-stack solutions, routers and gateways and the future of sensor networks.