Security in the IoT Supply Chain

The Internet of Things (IoT) ecosystem is somewhat infamous for its lack of security. In this article, part of our series on IoT security foundations, we will analyze the IoT supply chain, and examine how some of its elements affect IoT security, focusing on devices. We will then use this analysis as a basis to propose some industry and regulatory solutions.

Any IoT product or service is made up of several elements: device software, device hardware, connectivity elements (such as gateways or cellular networks to carry communications) and cloud servers. Products are largely built from multiple existing components, provided by different vendors, and integrated together by yet another vendor; this process is reiterated all along the supply chain, until the finished product ends up in the hands of its user, and presumably connects to other devices, gateways, a remote service provider or an IoT management cloud. Here we will examine the structure of the supply chain and show how some of the incentives it creates result in poor security, with vendors placing a low priority on security concerns.

Before delving into the details, let us look at a simplified view of the IoT supply chain:

In this diagram, the ODM (Original Device Manufacturer) creates the device hardware, the OEM (Original Equipment Manufacturer) bundles it with the necessary software, and the Service Provider (SP) offers the user a service which includes the IoT device. From the user’s point of view, either the OEM or the SP may be the ‘brand’ responsible for the product they are being sold. Viewed this way, the IoT supply chain is very similar to that of the ‘traditional’ embedded device market, except with more emphasis on the service side. This emphasis accelerates the IoT development cycle, shifting vendors’ deployment model away from the multi-year cycle common in the established embedded industry, and closer to the rapid schedules of web and cloud products. For embedded vendors, this shift causes a break away from many of the elements assumed as part the development process, including established security practices. Along with the fierce competition that favors a short time to market, this causes products to be rushed, with security checks and controls being pushed aside as an afterthought or skipped outright.

The production model above implies a trust relationship between the parties involved, as each link in the supply chain must trust the one before (its suppliers) to provide components of adequate quality. Any supplier who intentionally or accidentally breaks this trust can introduce security issues downstream, quite possibly for multiple vendors. For a software example, the GoAhead web server is a popular open-source package for IoT devices. It was found to be vulnerable in early 2017, in a way that targeted IP cameras, and the vendor issued patches. Later in 2017, other vulnerabilities in the same web server were found, again leading to a potential remote code execution attack on hundreds of thousands of devices, primarily network routers and printers. In this case, the same level of vulnerability on a single software package compromised diverse IoT products down the supply chain, spreading from an open-source component to multiple proprietary firmware images.

In practice, the supply chain is far more complex. The following figure illustrates the relationships in the IoT ecosystem in greater detail, with the hardware and software obtained separately and built by integrators from in-house and third-party components. The service side similarly includes standard and custom components from several parties. For example, the open-specification Raspberry Pi device uses a CPU designed by ARM and integrated in a system-on-a-chip by Broadcom, on a PCB with an Ethernet chip by SMSC and other hardware components. The Raspberry Pi can run a variety of embedded operating systems, such as Ubuntu, which comes packaged with numerous third-party software components. Finally, an OEM provider installs their own application code and communication stack to turn the hardware package into a fully-fledged, purpose-built IoT client device.

Zooming in further reveals even more complexity: there are multiple parties involved in hardware manufacturing (design houses, chip manufacturers, module manufacturers, CMOS and sensor vendors, OEMs and ‘brand’ firms) and software design (operating systems, frameworks and SDKs, libraries and open-source packages). The service side has its own ecosystem: distributors, resellers, network operators, cloud service providers (SaaS, IaaS and PaaS and, application service providers (back-end, analytics, CRM, billing, etc.). However, from a security perspective, this level of detail is not necessary, so we will not address these components individually here. A very comprehensive description of the roles and players in the IoT supply chain can be found in a technical report by Oleksiy Mazhelis et al.

We may also note that the IoT industry is geared toward single-purpose devices. Security measures for these should be built with specific focus on their application and industry vertical, putting in more effort than required for more generic measures taken in the mobile and PC markets. On the other hand, the security controls commonly applied in PC and mobile, such as application signing, process compartmentalization, trusted execution environments and secure boot, are often unavailable to IoT vendors due to the low target cost of the device.

The presence of service providers, such as management cloud vendors, plays a beneficial role in IoT. By necessity, the SPs usually provide client devices with a connectivity stack that bundles many security features, starting with a TLS library and the prerequisite cryptography, and including (in high-end offerings) foundational security features such as key storage, device identity and authentication, and secure boot and update mechanisms. Even so, the OEM is left with the responsibility of integrating and correctly configuring these features on their devices.

Each of the multitude of software components making up a device can be used to violate the user’s trust, if it is outdated, flawed or contains an intentional ‘back door’. As discussed above, IoT systems tend to lack security controls like environment isolation, user authorization or even process isolation, therefore a successful attack on a single component can break the entire system. Software is the usual culprit, and by some estimates around 90% of an application’s code comes from a third-party source. Given that the operating system does not count as part of the application, the overwhelming majority of all code running on a platform comes from upstream in the supply chain. This is equally true for the end user, the service provider, and intermediate links such as the OEM and integrators.

The hardware supply chain is yet another factor in product security, since hardware support is necessary for many features, such as secure key storage and secure boot. Even when ODMs such as chip vendors provide the necessary security features, OEMs may be unaware of these and have little incentive to implement them, leaving many security features unused or misconfigured on the final device. While many vendors claim that security is among their top concerns, in practice the security features offered by chips rank very low among the factors used to choose the chip supplier.

So far, regulators have not enforced a security standard on the supply chain. While governance standards on supply chain management do exist (NIST SP800-161, IIC Security Framework), they are largely ignored by the industry. Some market verticals, such as automotive, make use of existing standardization and regulation – largely thanks to the link to personal safety, in addition to the fact that the industry is already heavily regulated across the board – but that is the exception, not the rule. It is up to government bodies to speed up work on IoT regulation and put explicit liability for security incidents on those suppliers who disregard basic security practices. Non-profit organizations and alliances can put together standards for IoT security, including supply chain management, but with many competing standards, it can be difficult for vendors to understand which requirements apply to their particular vertical or application. Additional industry effort must be put into mapping security controls to specific use cases.

Worst of all, the IoT supply chain suffers from a lack of visibility. There is no simple way for a buyer to check which software and hardware components go into the device, or whether the supplier has enabled the security features available on their platform.  Again, this is true for the end user as much as it is for the intermediate links in the chain, the OEM and the integrators. Manual checking and pen-testing is simply not on the right scale to deal with the sheer volume of IoT software components available, not to mention the frequency of their update cycles. The security industry should step in to provide easier ways for any party in the supply chain to check their supplier’s components. Automated scanning can help detect outdated components and known vulnerabilities. Source code scanning products can only cover in-house components and open-source code; binary scanning products are needed to scan closed-source, third-party code and identify known software components included in a product, along with their vulnerabilities. OEMs, who are largely liable for vulnerabilities found in their final product, could use such products to make educated decisions when selecting their component suppliers. In turn, users could employ automated scanning products to choose OEMs. Competition is abundant on the supply side in IoT, but transparency is missing. The visibility provided by automated scanning will provide the incentive for individual suppliers to update and secure their offerings, and as a result, help the entire IoT industry to itself to rights.