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.