Today's computing systems are up against an extraordinary volume of threats, and many of them target where these systems originate — in the supply chain and around critical integrated circuits (ICs). In fact, according to the ITRC, supply chain attacks impacted 694 entities in 2020, which ultimately affected more than 42 million individuals. Therefore, you can't overstate the importance of understanding and addressing supply chain risks proactively. The best way to do this is to assess all potential attack vectors throughout the life cycle of an IC and a computing system.
There is a wide range of possible attacks throughout every stage of the IC life cycle. This can make ensuring the integrity of a computing system from end to end extremely challenging. To better understand these challenges, let's explore some key IC supply chain threats and how to protect against them.
Four Lesser-Known Supply Chain Threats
There are a variety of known supply chain threats, and they continue to evolve quickly. These attacks can happen across the various stages of the component life cycle, from design, integration, and fabrication to testing, provisioning, and deployment. While some are more commonly known — such as insider threats, malicious third-party plug-ins or design tools, design network attacks, malicious hardware and firmware, reverse engineering of components, physical alteration in transit, and fictitious recycling — let's focus on some of the lesser-known vectors.
1. Design Alteration — Design modifications might occur during several different stages by various actors. A supplier might suggest a seemingly innocuous change that can induce an undefined state of execution in the system. An integrator might make a covert change to the design files provided as part of an integration effort. Some believe that design alteration was the end goal of the AutoCAD malware, and more recently, it played a role with SUNSPOT in the SolarWinds attack.
How can you mitigate this threat? Consider isolating design networks from traditional corporate networks, restrict third-party plug-in usage to trusted sources, and cryptographically validate all design tools, updates, and plug-ins before installation. Also, companies should use internally maintained repositories of design tools and use blockchain technology (or some other auditing tool) to create a ledger of all access events and modified design files.
2. Trojan Circuitry Insertion — While still mostly an academic case, there's evidence that multiple hardware Trojans exist but are not yet activated. Activation would expose the Trojan, so an attacker would wait to produce the biggest impact before triggering it. Trojan circuitry might occur during one of several different phases. Beyond Trojan circuitry in malicious hardware, other circuitry modifications could be made directly to printed circuit boards (PCBs). The result might be disclosure of sensitive information, control of the system, or part of a larger, multistep Trojan activation sequence. You can learn more about hardware Trojan insertion on IEEE or in this recent DEF CON presentation.
How can you mitigate this threat? Consider the following mitigations: Use X-ray or other imaging tools to verify individual layers of PCBs to ensure authenticity and integrity. Create power analysis tests to look for significant variations in consumption across a broad set of operations. Create logic tests to look for changes in execution across a broad set of operations. Reverse engineer a small group of devices from each manufacturing facility and analyze them for variations. Use multiple manufacturing facilities or at least one separate trusted facility for a set of "golden" reference products.
3. Trojan Component Insertion — If an attacker cannot directly impact the original component or authorized third-party parts, they might resort to attacking the supply chain of authorized, third-party partners or fabrication facilities. An attacker might create a Trojan component and insert it into a product created by the third party or at the fabrication facility. There have been several proofs of concept over the last few years to illustrate how easily this can happen. Check out this IEEE paper for more information.
How can you mitigate this threat? The latest research supports using visual inspection tools, both manual and automated, to verify there are no extraneous or unexpected components on the end device. Additionally, you can test multiple systems looking for variations such as function, power, and boot time. And again, consider using multiple manufacturing facilities or a separate facility to produce trustworthy reference products.
4. Component Replacement — A Trojan component is a device that has been made to look and function identically to a valid component but has some level of additional functionality that performs a malicious action when triggered. These devices might be easily distinguishable when powered on due to power draw or throughput deviations from the norm, yet can easily slip through during stages involving visual validation. This could cause partners responsible for populating PCBs to receive a mixture of malicious and benign components. Depending on the complexity of the component, someone with physical access to completed products could do this either during the original manufacturing of the overall product or at any point during distribution. This is something that DARPA has been fighting against for some time.
How can you mitigate this threat? Consider using both manual and automated visual inspection tools to test for deviations in product characteristics, such as the font and location of product labels or physical dimensions of the product. And don't forget to test components periodically and randomly to look for significant differences in power, timing, or functional performance.
Supply chain attacks are one of today's most pressing threat categories. Unfortunately, they're not always immediately obvious or detectable. That said, you can address many of them through stricter internal supply chain policies, more expansive monitoring, and more significant requirements on integrated logic.
This is the first part of a two-part article. The second part is here.