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
Newest First  |  Oldest First  |  Threaded View
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.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: They said you could use Zoom anywhere.......
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
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
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-14483
PUBLISHED: 2020-08-13
A timeout during a TLS handshake can result in the connection failing to terminate. This can result in a Niagara thread hanging and requires a manual restart of Niagara (Versions 4.6.96.28, 4.7.109.20, 4.7.110.32, 4.8.0.110) and Niagara Enterprise Security (Versions 2.4.31, 2.4.45, 4.8.0.35) to corr...
CVE-2020-11733
PUBLISHED: 2020-08-13
An issue was discovered on Spirent TestCenter and Avalanche appliance admin interface firmware. An attacker, who already has access to an SSH restricted shell, can achieve root access via shell metacharacters. The attacker can then, for example, read sensitive files such as appliance admin configura...
CVE-2020-13281
PUBLISHED: 2020-08-13
For GitLab before 13.0.12, 13.1.6, 13.2.3 a denial of service exists in the project import feature
CVE-2020-13286
PUBLISHED: 2020-08-13
For GitLab before 13.0.12, 13.1.6, 13.2.3 user controlled git configuration settings can be modified to result in Server Side Request Forgery.
CVE-2020-15925
PUBLISHED: 2020-08-13
A SQL injection vulnerability at a tpf URI in Loway QueueMetrics before 19.10.21 allows remote authenticated attackers to execute arbitrary SQL commands via the TPF_XPAR1 parameter.