Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

10:00 AM
Connect Directly
E-Mail vvv

What Organizations Need to Know About IoT Supply Chain Risk

Here are some factors organizations should consider as they look to limit the risk posed by risks like Ripple20.

As organizations let billions of connected devices into their corporate networks, do they really know what those devices are made of and the risk they may pose? The answer is likely: not really.

That's because of the complicated supply chain of Internet of Things (IoT) and operational technology (OT) devices. While a company may buy a device from a manufacturer it knows and trusts, it may not realize that some of the underlying software and components that could be used to compromise those devices are likely made by another manufacturer.

In the case of the recently disclosed Ripple20, 19 vulnerabilities were discovered in the TCP/IP networking stack made by Treck that can be found in millions of common devices from major vendors, including industrial control systems, medical devices, enterprise networking equipment, and printers.

This is not the only case of supply chain vulnerabilities in IoT and OT devices in recent years and the issue has been gaining widespread attention in the cybersecurity community. Further concerns have been raised in the past year over where devices and their individual components are manufactured, with the US government banning multiple Chinese device manufacturers, citing national security concerns. More recently, President Trump signed an executive order that prohibits the acquisition, importation, transfer, or installation of bulk-power system electric equipment connected to any foreign adversary and calls for identifying this kind of equipment already in use.

The risk these devices pose is magnified by the scale of IoT and OT overall, with Gartner predicting there will be 25 billion connected devices by 2021. A single vulnerability in one component of the supply chain could affect a large chunk of those devices across multiple manufacturers. Ripple20 alone is estimated to affect hundreds of millions of devices.

Here are some factors organizations should consider as they look to limit the risk posed by this type of vulnerability:

Challenges of Identifying Devices with Supply Chain Risk
When it comes to IoT, IT, and OT devices, there is no software bill of materials (SBOM), though there have been some industry calls for one. That means the manufacturer has no obligation to disclose to you what components make up a device. When a typical device or software vulnerability is disclosed, an organization can fairly easily use tools such as device visibility and asset management to find and patch vulnerable devices on its network. However, without a standard requirement to disclose what components are under the hood, it can be extremely difficult to even identify what manufacturers or devices may be affected by a supply chain vulnerability like Ripple20 unless the vendor confirms it.

For organizations, this challenge means pressing manufacturers for information on components when making purchasing decisions. While it is not realistic to solely base every purchasing decision based on security, the nature of these supply chain challenges demand at least gaining information in order to make the best risk calculus.

One Risk, Many Devices
What makes supply chain risk unique is that one vulnerability can affect many types of devices. Ripple20, for instance, affects a wide range of devices across IT and OT networks, including industrial control systems, medical devices, enterprise networking equipment, and printers. In total, JSOF, the company that discovered the vulnerabilities, estimates that it could affect many manufacturers and hundreds of millions of devices around the world. While this is just one example, this phenomenon magnifies the risk from this category of vulnerabilities.

What this means for an organization is that the risk from the Ripple20 vulnerabilities is likely already inside of its environment. While the list of manufacturers affected is still a work in progress, organizations can begin by identifying those known affected devices and taking appropriate risk mitigation measures.

Difficulties of Issuing Patches
When a vulnerability of this type is found, it's up to the software or component manufacturer to issue its patch. However, the device manufacturer itself is responsible for distributing the patch that should be applied by end users. That means a patch needs to be issued by one manufacturer, then recognized and incorporated by at least a second one, then pushed out to end users, who have to apply it themselves — a complex supply chain of its own.

All these steps assume that the device manufacturer is still in a position to implement these fixes. It is entirely possible that the manufacturer may be out of business or may no longer support the device in question, which would mean the necessary security updates would not be passed onto the end user. In these cases, organizations will need to take the initiative to isolate these devices by segmenting their network or remove them from their network entirely.

The Challenge of Applying Patches
Even if all these hurdles are met to deliver a patch to the end user, it may still be impossible to remedy the security flaw. This can happen for many reasons, including an inability to tolerate downtime, an inability of the device to update or an inability to run legacy applications alongside patched software. Whatever the reason, it's up to the organization to mitigate that risk with security solutions like network segmentation that can limit the impact of vulnerable devices to other parts of a network.

What Can Organizations Do About Supply Chain Risk?
The first steps that organizations can take to protect themselves have been described above and are similar to the ones taken when mitigating other kinds of cybersecurity risk: inventory and patch known vulnerable devices, segment the network to prevent initial access or lateral movement via risky devices, and continuously monitor the network for signs of breaches.

Before connecting any device to the network, organizations should also evaluate its manufacturer by asking the following questions:

  • Does it use a secure development life cycle, including source code reviews and penetration testing, which can reduce the number of vulnerabilities in IoT devices? Does it include third-party components in this testing process?

  • Does it implement exploit mitigations, such as address space layout randomization (ASLR) and data execution prevention (DEP), which can reduce the impact of vulnerabilities that still happen in their devices?

  • Does it have a security update program, which can fix vulnerabilities when they are discovered? Are these updates securely delivered? Can I control when these updates are applied?

  • Can I know what software and hardware components are present in the manufacturer's devices?

  • Can I trace the origin of the manufacturer and its suppliers? (This is increasingly important, especially for government organizations.)

Based on the answers to these questions, organizations can make informed risk decisions and more effectively monitor the security posture of their IoT devices.

Related Content:



Register now for this year's fully virtual Black Hat USA, scheduled to take place August 1–6, and get more information about the event on the Black Hat website. Click for details on conference information and to register.

Daniel dos Santos holds a PhD in computer science from the University of Trento, Italy, and has published over 30 journal and conference papers on cybersecurity. He has experience in software development, security testing, and research. He is now a Research Manager at ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
7/20/2020 | 1:08:55 PM
Patching is Key
I'm glad that this article identifies some of the complexities of patching IoT devices. To find the best solution, first you must correctly define the problem.
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in GitHub Enterprise Server that allowed authenticated users of the instance to gain write access to unauthorized repositories via specifically crafted pull requests and REST API requests. An attacker would need to be able to fork the targeted ...
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user with the ability to fork a repository to disclose Actions secrets for the parent repository of the fork. This vulnerability existed due to a flaw that allowed the base reference of ...
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in the GitHub Enterprise Server GraphQL API that allowed authenticated users of the instance to modify the maintainer collaboration permission of a pull request without proper authorization. By exploiting this vulnerability, an attacker would b...
PUBLISHED: 2021-03-03
A remote code execution vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. User-controlled configuration of the underlying parsers used by GitHub Pages were not sufficiently restricted and made it possible to execute commands on the Gi...
PUBLISHED: 2021-03-03
Pug is an npm package which is a high-performance template engine. In pug before version 3.0.1, if a remote attacker was able to control the `pretty` option of the pug compiler, e.g. if you spread a user provided object such as the query parameters of a request into the pug template inputs, it was p...