Why Assessing Security Risk in Compute Lifecycle Development Should Be a Community Effort

Supply chain risks continue to be a major concern for manufacturers, and the organizations and customers they serve. According to recent research, software supply chain attacks are up 650 percent in the past year alone and ENISA expects these types of attacks to quadruple by the end of 2021. 

But assessing supply chain risks can be a complex task for product teams. And when not done properly, can have devastating impacts. Just look at the SolarWinds attack and the recent blog from Microsoft showing that the group behind that attack, Nobelium, has since targeted 140 additional resellers and service providers. 

Supply chains can be vulnerable across the entire lifecycle of a product. Companies often rely on compute lifecycle development frameworks that break down development into phases such as Build, Transfer, Operate and Retire. These stages are designed to analyze and address security risks associated with the supply chain. Today there are strong standards and community support around the Transfer and Operate stages, but not as much shared knowledge around the Build stage. This is often the result of concerns regarding intellectual property, differences in process technologies, and information leakage. In this article, I’d like to explore how developers working in hardware compute can better assess security risks (and share best practices) in the Build stage of compute lifecycle development. 

Determining the risk of an attack and how to mitigate it is typically a four-step process within the Build stage that includes establishing a lifecycle, identifying threats, determining mitigations, and investment. This is a constantly recurring process. Let’s dive into each step in more detail. 

The First Step in the Process Is To Establish a Lifecycle

It’s worth noting that the Build stage of compute lifecycle development also has its own substages, which further complicates matters, resulting in a multi-level structure of threats. Most manufacturers, such as Intel, have their own defined stages based upon their own processes. Other manufacturers might use an approach based on whether they’re creating a component of a product or the end product itself. When determining what that lifecycle is, organizations need to consider what aspects of the lifecycle are within their purview and recognize what threats are in and out of scope as a result.

Step Two in the Process Is To Identify the Threats

These might include insider threats, malicious firmware, improper device settings, and much more. Unfortunately, there’s no single source of supply chain threats today, such as the MITRE ATT&CK framework and knowledge base. But the reality is that every manufacturer and supplier faces threats, as attackers look to focus on the weakest link across a supply chain. The challenge is amplified by the fact that finding these threats in the Build stage is a very manual process with limited automation – although some advances are being made with tools such as Tortuga Logic’s Radix solution. Despite the differences across manufacturers’ processes, the community faces a standard set of problems. 

As manufacturers and suppliers look to understand the possible threats and apply them to stages, they should consider the applicability of the threats to each of the stages, the sophistication of the threats, and the availability or exposure of their product during each stage.

Step Three Involves Determining the Mitigations

This allows teams to clearly and concisely understand exactly what threats are already protected against and which are still a concern. These teams should consider creating a list of the mitigations and overlaying it with the attacks. This will allow them to measure success and analyze whether they have the proper mitigation for an attack (and if it’s complete or partial). For example, two-factor authentication (2FA) could be required for submission of design files into a corporate repository. But if forgery or theft of the needed credentials is trivial, the mitigation is not sufficient. Similarly, verification of third-party modules, when they first reach a corporate network, helps to ensure their authenticity. 

However, if they’re not also checked at the time they’re inserted into the design, a malicious insider or attacker on the network could replace or alter them and thereby defeat the mitigation. Keep in mind that mitigations can have an impact on other areas of development, so it’s crucial to coordinate with other teams. 

The Final Step Is Investment

No single strategy offers the silver bullet for success. Organizations must consider multiple criteria such as the risk to the company, the impact to customers, the likelihood of an exploit, and the cost of partial or complete mitigation. The sequence of these investments is often driven by current events. For example, the recent supply chain attacks against critical infrastructure and supply chain suppliers may result in an extensive focus by another company on a common attack point to prevent attacks on their own networks. Teams should consider looking first for low-hanging fruit or “best bang for your buck” opportunities. Then establish timelines for tackling larger investments, and be transparent with the investment and strategy – and plan for uncertainty. 

Tackling supply chain security is a community effort. The industry needs more professionals to get involved and practice transparency. For example, by encouraging suppliers to share more information about their supply chains (along with manufacturers). There needs to be more effort to support standard bodies such as the Global Semiconductor Alliance Security Working Group, the Trusted Computing Group, ISO/IEC SC 27 WG4 TR6114, SEMI, NIST, IIC, Accellera, and more. And finally, organizations need to engage in policy and US Government (and international) efforts. For example, NIST is working to update 800-161 on supply chain risk management practices but needs more input. And more professionals need to spend time understanding new executive orders and compliance requirements, such as Section 889 from FY19 NDAA. 

Supply chain attacks are not going away; in fact, according to predictions, they’re going to increase and become more complex. The community needs to work together to create standard lifecycles and resources that can be used to more easily identify threats and mitigations.