Category

Blog

FDA Seeking Additional Legislative Authorities

FDA is seeking “legislative authorities” to enable the office to require medical device manufacturers to adhere to strict cybersecurity policies, including the development of a Software Bill of Materials (SBOM).

The Minimum Elements for a Software Bill of Materials (SBOM)

Yesterday, the United States Department of Commerce released The Minimum Elements for a Software Bill of Materials (SBOM), in accordance with President Biden Executive Order 14028 on Improving the Nation’s Cybersecurity. For those who have been following the National Telecommunications and Information Administration (NTIA) SBOM work, you won’t find any surprises in the release. The document thoroughly describes the SBOM, provides motivation for the SBOM as a standard security document, and makes the point that the SBOM is only one piece of an effective security ecosystem. 

Data Fields

The suggested baseline data fields of the SBOM should provide sufficient information about the components of the SBOM to enable further investigation into associated information about the components, including vulnerabilities. The document suggests the following minimum elements:

Supplier Name – the name of the entity that creates, defines, and identifies components, for example, Microsoft

Component Name – designation assigned to a unit of software defined by the original supplier, for example, Windows 10

Version of the Component – identifier used by the supplier to specify a change in software from a previously identified version, for example, version 1607

Other Unique Identifiers – other identifiers that are used to identify a component, or serve as a look-up key for relevant databases, including the Common Platform Enumeration (CPE) that can be used to find vulnerabilities for the component in the National Vulnerability Database (NVD), for example, cpe:2.3:o:Microsoft:windows_10:1607:*:*:*:*:*:x64:*

Dependency Relationship – characterizing the relationship that an upstream component X is included in software Y, for example Notepad is included in Windows 10 version 1607

Author of SBOM data – the name of the entity that creates the SBOM data for this component, for example, Vigilant Ops

Timestamp – record of the date and time of the SBOM data assembly, for example, 7-JUL-21 09:15

Data Fields Comments and Key Points

Given that a function of the baseline information contained in the data fields of a component is to enable discovery of additional sources of information about that component, such as vulnerabilities, the document acknowledges some inherent gaps and issues.

The supplier name and component name may or may not be leveraged to uniquely identify a component, as there are likely multiple versions in use. For example, Microsoft Windows 10 could also be referred to as MS Win 10. This is not a shortcoming of the SBOM, but rather a longstanding problem in the world of software. The document recommends that the naming task be left up to “A decentralized model, where suppliers identify and manage their own software namespace…”. The negative consequences of this approach are illustrated in the monumental effort needed to manually search and match component information with Common Platform Enumeration (CPE) information.

In addition, the document acknowledges that the dependency relationship information will be challenging to collect and include, due to “…existing requirements with subcomponent suppliers.” Eventually, as SBOM becomes integrated into the software supply chain, subcomponent information will be available. At the outset, however, depth beyond the top-level components is not likely. In this case, the document recommends that the SBOM identify these “known unknowns” to differentiate between components for which no dependencies exist and those for which the dependencies are unknown.

Automation Support

There are three data formats suggested as standards to support the generation and consumption of the SBOM:

  • Software Package Data eXchange (SPDX)
  • CycloneDX
  • Software Identification (SWID) tags

According to the document, “The SBOM must be conveyed across organizational boundaries in one of these formats.”

Practices and Processes

To integrate the SBOM into a secure software development lifecycle, the document calls out a number of elements that organizations will need to address.

Frequency – at a minimum, new software builds, or releases require that a new SBOM be created. In addition, new information about components or errors in existing SBOMs can also trigger the creation of a new SBOM.

Depth – an SBOM should contain all primary (top-level) components with their dependent components, but an SBOM must contain primary (top-level) components with enough detail to “…seek out the transitive dependencies recursively.” This statement is another acknowledgement of the problem of including dependency relationship as a baseline data field.

Known Unknowns – the SBOM author must explicitly include information in the dependency relationship field to indicate that either there are no further dependencies for the given component or the dependencies for the given component are unknown. IMPORTANT NOTE – “To avoid erroneous assumptions, the default interpretation of the data should be that the data is incomplete…”

Distribution and Delivery – the SBOM should be made available in a timely fashion, and appropriate access permissions must be in place to protect the contents of the SBOM. The document suggests that the distribution and delivery of the SBOM will not be a “one-size-fits-all” approach but acknowledges that SBOM producers must have a way to make them available to SBOM consumers.

Access Control – in the cases where access control is desired by the producers of the SBOM, the terms must be specified, however the details of this specification are “…outside the scope of this document”.

Accommodation of Mistakes – the document allows that the initial implementation of the SBOM will not be perfect, so consumers of the SBOM should be “…tolerant of the occasional incidental error.” SBOM producers should be encouraged to share updates and corrections to SBOMs “…without penalty when offered in good faith.” These updates or corrections should trigger the creation of a new SBOM, as mentioned in the Frequency discussion above.

Beyond Minimum Elements

The document addresses additional inclusions that “…expand transparency in the software supply chain…”, however we will not detail those in this summary, except for the section on Vulnerabilities. It is recommended that the actual document be reviewed for additional details about the other sections.

Vulnerabilities and SBOM

The document acknowledges that the primary use case for SBOM is “…to identify known vulnerabilities and risks in the software supply chain.” The document then goes on to describe that the data contained in an SBOM is primarily static, while vulnerability information related to the SBOM data is dynamic. This seeming conflict, however, “…does not limit the value of providing vulnerability, software weaknesses, and risk information to the consumer of the software…”

Vulnerability and Exploitability in Dependencies

While it is true that not all sub-component vulnerabilities create risk in the component, as the document points out, this determination requires analysis by the SBOM producer to reach a reliable conclusion regarding vulnerability impact. To avoid unnecessary concern from the SBOM consumer, the SBOM producer should have an efficient way to communicate the vulnerability impact. The document refers to the term Vulnerability Exploitability eXchange (VEX) as the “…communication of whether or not a given piece of software is affected by a given vulnerability.” The document recommends including this VEX information in the SBOM analysis.

Summary

“Ultimately, SBOM should not be seen as a unique security phenomenon, but yet another practice that can support the broader effort to secure the supply chain.”  In keeping with Executive Order 14028, The Minimum Elements for a Software Bill of Materials (SBOM) provides input to the next step of developing specific SBOM guidance. It is recommended that the “…Federal Government should encourage or develop resources on how to implement SBOMs, potentially involving sector-specific or technology-specific details.”

Clearly, the SBOM ecosystem is continuing to evolve, but it is encouraging that the Federal Government decided to act now versus waiting to get it perfected.

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: [email protected]

Ken Zalevsky
[email protected]
412-704-4600

NIST Workshop on Supply Chain Security

On May 12, 2021 President Biden signed the Executive Order on Improving the Nation’s Cybersecurity, which we previewed in a recent post, into law. The fifteen-page document includes various cybersecurity enhancement recommendations such as the Software Bill of Materials (SBOM) and review and revision of governmental procedures, such as the Federal Acquisition Regulation (FAR), all with associated timelines for completion.

Biden Signs Cybersecurity Executive Order

On May 12, 2021 President Biden signed the Executive Order on Improving the Nation’s Cybersecurity, which we previewed in a recent post, into law. The fifteen-page document includes various cybersecurity enhancement recommendations such as the Software Bill of Materials (SBOM) and review and revision of governmental procedures, such as the Federal Acquisition Regulation (FAR), all with associated timelines for completion.

How To Prepare for the Cybersecurity Executive Order

On May 12, 2021 President Biden signed the Executive Order on Improving the Nation’s Cybersecurity into law. In spite of being only fifteen pages in length, the executive order is detailed and complex. It’s quite easy to become overwhelmed by the dependencies between requirements and deadlines for completion. In this document, we have attempted to reduce this complexity by highlighting certain key aspects of the executive order and suggesting actions that can be taken now to help prepare your organization.

Why 2021 is Shaping Up to be the Year of the SBOM

The software bill of materials (SBOM) is on its way to being recognized as a key security document and the primary enabler of software transparency across all industries. In healthcare, FDA (US Food and Drug Administration) included the SBOM in the first draft of their Premarket Guidance in 2018, but they referred to it as a CBOM (Cybersecurity Bill of Materials). Today, SBOM, which is a detailed list of software components found in a product or system, has become the more accepted terminology.

As more cybersecurity breaches are announced, almost daily it seems, business leaders, industry experts, and regulatory agencies are looking to SBOM as an important element of a sound cybersecurity strategy. The SBOM is gaining so much momentum, that some have found it necessary to caution that the SBOM won’t solve all security woes, and that it is just one piece of the larger cybersecurity puzzle, albeit an important piece.

SBOM references have appeared across a wide variety of security-based content, including the recent news of an imminent Biden administration executive order. The order aims at strengthening the nation’s security posture and includes reference to the SBOM. From a regulatory perspective, FDA has prioritized the 2021 release of the final version their Premarket Guidance, mentioned above, which recommends that medical device manufacturers provide an SBOM with their products. In other SBOM news, Tag Cyber’s 2021 Security Annual – 2nd Quarter, includes an article titled “The Time Has Arrived for Software Bill of Materials”.  The article includes a reference to the important SBOM work currently happening at the National Telecommunications and Information Administration (NTIA) under Allan Friedman.

When it comes to protecting software-based products and systems, it seems  almost common sense that a lack of visibility into software components utilized in the product or system is a massive impediment. So, on one hand, the SBOM should seem inevitable and key security document. On the other hand, some industries are slow to change and adapt and only do so with the appropriate motivation. Unfortunately, or fortunately for the SBOM, the recent spate of cybersecurity attacks is providing that motivation.

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: [email protected]

Vigilant Ops

GENERATE YOUR OWN SBOMs FOR FREE!

Fill out the form with your information, including a valid email address, and we will contact you to start your Free SBOM Trial. During your Free SBOM Trial , you will be able to generate and view your SBOMs, plus you’ll have access to our team of cybersecurity experts, to help you make sense of your generated SBOMs.


Vigilant Ops
8085 Saltsburg Rd., Pittsburgh, PA 15239
(412) 704 - 4600
[email protected]

Copyright © 2021 Vigilant Ops. All rights reserved.