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.

IoT
7/20/2020
10:00 AM
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comments
Threaded  |  Newest First  |  Oldest First
RyanSepe
50%
50%
RyanSepe,
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.
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27621
PUBLISHED: 2020-10-22
The FileImporter extension in MediaWiki through 1.35.0 was not properly attributing various user actions to a specific user's IP address. Instead, for various actions, it would report the IP address of an internal Wikimedia Foundation server by omitting X-Forwarded-For data. This resulted in an inab...
CVE-2020-27620
PUBLISHED: 2020-10-22
The Cosmos Skin for MediaWiki through 1.35.0 has stored XSS because MediaWiki messages were not being properly escaped. This is related to wfMessage and Html::rawElement, as demonstrated by CosmosSocialProfile::getUserGroups.
CVE-2020-27619
PUBLISHED: 2020-10-22
In Python 3 through 3.9.0, the Lib/test/multibytecodec_support.py CJK codec tests call eval() on content retrieved via HTTP.
CVE-2020-17454
PUBLISHED: 2020-10-21
WSO2 API Manager 3.1.0 and earlier has reflected XSS on the "publisher" component's admin interface. More precisely, it is possible to inject an XSS payload into the owner POST parameter, which does not filter user inputs. By putting an XSS payload in place of a valid Owner Name, a modal b...
CVE-2020-24421
PUBLISHED: 2020-10-21
Adobe InDesign version 15.1.2 (and earlier) is affected by a memory corruption vulnerability due to insecure handling of a malicious .indd file, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.