MITRE Creates Framework for Supply Chain Security

Supply chain security has been all the buzz in the wake of high-profile attacks like SolarWinds and Log4j, but to date there is no single, agreed-on way to define or measure it. To that end, MITRE has built a prototype framework for information and communications technology (ICT) that defines and quantifies risks and security concerns over supply chain - including software.

MITRE’s so-called System of Trust (SoT) prototype framework is, in essence, a standard methodology for evaluating suppliers, supplies, and service providers. It can be used not just by cybersecurity teams but across an organization for assessing a supplier or product.

“An accountant, a lawyer, [or] an operations manager could understand this structure at the top level,” says Robert Martin, senior software and supply chain assurance principal engineer at MITRE Labs. “The System of Trust is about organizing and amalgamating existing capabilities that just don’t get connected right now” to ensure full vetting of software as well as service provider offerings, for example.

The SoT will make its official public debut next month at the RSA Conference (RSAC) in San Francisco, where Martin will present the framework as a first step in gathering security community support and insight for the project. So far, he says, the initial feedback has been “very positive.”

MITRE is best known in the cybersecurity sector for heading up the Common Vulnerabilities and Exposures (CVE) system that identifies known software vulnerabilities and, most recently, for the ATT&CK framework that maps the common steps threat groups use to infiltrate networks and breach systems.

Martin says he’ll demonstrate the SoT framework and provide more details on the project during his RSAC presentation. The framework currently includes 12 top-level risk areas - everything from financial stability to cybersecurity practices - that organizations should evaluate during their acquisition process. More than 400 specific questions cover issues in detail, such as whether the supplier is properly and thoroughly tracking the software components and their integrity and security.

Each risk is scored using data measurements that are applied to a scoring algorithm. The resulting data scores identify the strengths and weaknesses of a supplier, for example, against the specific risk categories. An enterprise could then more quantitatively analyze a software supplier’s “trustworthiness.”

**SBOM Symmetry
**Martin says that with software supply chain security, the SoT also goes hand in hand with software bill of materials (SBOM) programs. “SBOMs can give you deeper reason into understanding why you should trust,” for example, a software component. Among several risk factors in the SoT, SBOMs can actually mitigate those risks or, at the least, provide better insight into the software and any risks.

“If the SBOM has pedigree information, that information would allow for assessment of the tools and techniques used to build the software - whether reproducible builds were used to build the software, memory protection methods [were] invoked during the build” and other details, he notes.

So how does the SoT framework differ from risk management models? Traditional risk management employs probabilities, Martin says. With SoT, there’s a list of risks that can be evaluated and scored to determine whether there is risk in specific areas and, if so, just how bad it really is.

“We want to help provide a consistent way of doing assessments … and we would like to encourage data-driven decisions wherever we can” in supply chain evaluations, he says.

The next steps: introducing the concept of the SoT and offering the live taxonomy for public comment and scrutiny. “Then we can see what parts can be automated and where,” and ensure that it can be integrated into the acquisition process. Vendors, too, could use SoT terminology in their product materials.

“’Supply chain’ has a lot of different meanings,” Martin explains. “We’re not talking microelectronics in the US versus overseas. We’re not trying to solve port issues. We’re trying to get a culture of organizational risk management that includes supply chain concerns as a normal part of that. We want to bring some consistencies, automation, and data-driven evidence so there’s more understanding of supply chain risks.”