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.
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/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
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-17
Hirschmann HiOS 07.1.01, 07.1.02, and 08.1.00 through 08.5.xx and HiSecOS 03.3.00 through 03.5.01 allow remote attackers to change the credentials of existing users.
PUBLISHED: 2021-05-17
An authentication brute-force protection mechanism bypass in telnetd in D-Link Router model DIR-842 firmware version 3.0.2 allows a remote attacker to circumvent the anti-brute-force cool-down delay period via a timing-based side-channel attack
PUBLISHED: 2021-05-17
Incorrect access control in zam64.sys, zam32.sys in MalwareFox AntiMalware where IOCTL's 0x80002014, 0x80002018 expose unrestricted disk read/write capabilities respectively. A non-privileged process can open a handle to \.\ZemanaAntiMalware, register with the driver using IOCTL 0x8000201...
PUBLISHED: 2021-05-17
Incorrect access control in zam64.sys, zam32.sys in MalwareFox AntiMalware allows a non-privileged process to open a handle to \.\ZemanaAntiMalware, register itself with the driver by sending IOCTL 0x80002010, allocate executable memory using a flaw in IOCTL 0x80002040, install a hook wit...
PUBLISHED: 2021-05-17
Intelbras Router RF 301K Firmware 1.1.2 is vulnerable to Cross Site Request Forgery (CSRF) due to lack of validation and insecure configurations in inputs and modules.