How Deep Does the MITRE Supply Chain Security System of Trust Framework Go?

Despite high-profile attacks like Log4j and SolarWinds increasingly starring in the breaches hit parade, supply chain security has remained, until now, a hard-to-define and difficult-to-measure concept. This lack of agreed-upon methodology and metrics to evaluate supply chain security has led MITRE to create a framework prototype to facilitate risk management for risks associated with supply chains attacks.

MITRE Supply Chain Security System of Trust (SoT) Framework addresses 14 top-level decisional risk areas associated with trust that agencies and enterprises must evaluate and make choices about during the entire life cycle of their acquisition activities.

These 14 risk areas are subdivided into around 200 risk sub-areas evaluated with the help of about 2200 questions that aim to provide a scalable, repeatable, evidence-based, and customizable supply chain risk assessment process.

The lion’s share of these questions is related to non-digital due diligence questions related to the supplier’s reliability from multiple angles, ranging from financial stability to organizational stature, external influence, and maliciousness, including organizational security.

Still, in a prototype phase, MITRE SoT is a wide-ranging supply risk evaluation framework that covers both the physical and the digital world. It intends to cover the software supply chain risk assessment in detail.

MITRE SoT Software Supply Chain Risk Management

Already at the CAPEC Program User Summit in February 2022, Robert Martin, Senior Principal Engineer at MITRE Corporation and Chair of the Steering Committee of the Industrial Internet Consortium, was expanding on the issues at hand with software supply chain risk management.

In the absence of statistics on which to base probabilities, the crux of the effort in facilitating the risk evaluation for the software supply chain revolves around the Software Bill of Materials (SBOM), a first step to answering the growing need for insight into the supply chain. In section 4 about Enhancing Software Supply chain Security, last May’s Executive Order 14208 mandates providing an SBOM either directly or by publishing it on a public website. It defines SBOM as “a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components,” similar to a list of ingredients on food packaging.

Pursuant to that executive order, NTIA published “The Minimum Elements for a Software Bill of Materials (SBOM)”, which defines its minimum constitutive elements and reiterates its goal to increase the potential to track known and newly emerged vulnerabilities and risks.

Those minimum elements are:

• Data Fields: Documenting baseline information about each component that should be tracked
• Automation Support: Allowing for scaling across the software ecosystem through the automatic generation and machine readability
• Practices and Processes: Defining the operations of SBOM requests, generation, and use

SBOM is a central factor in the cybersecurity practice section of MITRE SoT as it provides deeper insights into the software and the potential risks it carries.

In due time, SoT will provide a consistent way of running assessments with standardized risk scoring processes but still be customizable. That customization is critical in allowing for organization-specific risk aversion profiles to tailor their security requirements to match their risk appetite. This flexibility cannot be attained through a list of approved products.

A more in-depth understanding of the exact nature of the taxonomy of SoT will soon be made possible when MITRE publishes it for public scrutiny.

SoT Software Supply Chain Risk Management Limits

As pointed out by Robert Martin during CAPEC Summit, despite their undeniable value, SBOMs lack some critical elements. It neither detects potential breaches at the supply chain level nor includes immediate disclosure of such a breach when detected by the supplier.

SBOMs would help for emerging critical vulnerabilities such as Log4j, as the end-users could immediately see that the supplied software is at risk of being impacted by a newly publicized vulnerability and could therefore patch in time.

Yet, for a SolarWinds type of attack, the SBOM would be of little to no use, as the stealth techniques used by supply chain attackers would not show up on that list. Nor would it be of much use to protect against supply chain vulnerabilities such as Follina, for which a patch was still missing two weeks after the vulnerability publication.

Reaching an adequate level of supplier certification would require a continuous security validation of the supplier’s security posture and the integrity of the software they provide. At this stage, such capabilities are not on the horizon, but, in due time, they might be considered for inclusion in the organizational security part of MITRE SoT.