Category

News & Events

Vigilant Ops Announces Partnership with BeanStock Ventures

Vigilant Ops, an innovator in medical device cybersecurity and developer of the Software Bill of Materials (SBOM) automation platform InSight, announced a partnership with BeanStock Ventures of San Diego, California.

BeanStock Ventures is a medical device software product development organization with regulatory expertise. It is one of only nine FDA-Recognized 510(k) Third Party Review Organizations (3P510K), enabling the fast-track of medical devices for 510(k) clearance, which is a premarket submission made to FDA to demonstrate medical device safety and effectiveness. BeanStock’s designation provides medical device manufacturers with an alternative review process which can significantly reduce the average FDA wait time.

“Partnering with BeanStock Ventures enables one-stop shopping for medical device manufacturers looking for both pre and post market regulatory compliance support,” said Ken Zalevsky, CEO at Vigilant Ops. “Our InSight Platform automates the generation of the device Software Bill of Materials (SBOM) and the documentation to submit with the 510(k) application to FDA. Our InSight Platform also provides continuous monitoring and maintenance of the SBOM, enabling medical device manufacturers to adhere to FDA postmarket surveillance requirements.”

“BeanStock Venture’s Software Product Development expertise allows us to approach execution strategically with our regulatory and product development expertise infused. Our team holds expertise in working with legacy software and creating new software to ensure a product platform can be built for cybersecurity.” said Shawnnah Monterrey, CEO at BeanStock Ventures.

The Vigilant Ops InSight Platform uses various techniques to interrogate medical devices and automatically generate SBOMs, which are then continuously monitored and updated. By leveraging natural language processing techniques and patented machine learning algorithms, vulnerabilities associated with device components are found and communicated in near real-time.

Press release on EINPressWire can be found here.

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]

Matt Lentine
[email protected]
412-704-4602

Using SBOM to Identify Vulnerabilities and Impacted Devices

| vigilantops | , ,

Last week, CISA (the U.S. Cybersecurity and Infrastructure Security Agency) issued an advisory about critical vulnerabilities in embedded software that opens the door to possible security breaches. No breaches have been reported to date, but the potential impact spans multiple industries, including healthcare. This short summary discusses how SBOM can help manufacturers respond and take action.

SBOM Can Help with Vulnerability Discovery

The Software Bill of Materials (SBOM) has been getting a lot of publicity as of late, and it is a critical piece of the cybersecurity puzzle. Generating an SBOM for a specific device is the first step in deployment. Next, those discovered components in the SBOM must be researched and all associated vulnerabilities found. This process of discovery must be continuous so that the SBOM remains updated and evergreen. One of the benefits of a continuously maintained SBOM is the ability to find newly released vulnerabilities more quickly, such as CVE-2021-31886 relating to this current vulnerability in embedded software.

SBOM Can Help Identify Impacted Devices

Organizations with the ability to generate SBOMs for their fielded products have a decided advantage because they can immediately identify impacted systems and deploy critical security patches targeted at only those systems that are impacted. This saves a tremendous amount of time spent sifting through customer records or calling customers trying to determine fielded system profiles.

SBOM Automation is Effective and Efficient

While SBOM is a critical security document, organizations should not make the common mistake of assuming the effort involved to generate and maintain is similar to existing security documentation, such as the Manufacturer Disclosure Statement for Medical Device Security (MDS2). The SBOM is much more involved, and if the manufacturer is responsible for multiple versions of multiple systems, the effort involved to generate and maintain SBOMs could easily require a full-time engineering resource, or substantial effort from several resources. Small manufacturers simply can’t afford it, while larger manufacturers are discovering that the opportunity cost of dedicating development resources to a maintenance task is just too high.

Summary

If you have not started to dig into the SBOM yet, you should.  You can start with a search on SBOM or Executive Order 14028 or National Telecommunications and Information Administration (NTIA) Software Transparency. There are lots of great resources and good information is readily available.

If you have started down the SBOM path and are concluding that your effort won’t scale, check out automated SBOM solutions. Be on the lookout for SBOM generation functionality and continuous vulnerability monitoring. Automated alerts and sharing with authorized end users are also helpful features.

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]

Matt Lentine
[email protected]
412-704-4602

U.S. House Passes Supply Chain Security Bill

| vigilantops | , ,

As part of the response to recent hacks, the United States House of Representatives voted on and passed the DHS Software Supply Chain Risk Management Act of 2021 on October 20, 2021, by a vote of 412-2. The Act covers both new and existing contracts with the Department of Homeland Security (DHS).

As a Condition on the Award of Contracts

Contractors must submit a bill of materials, defined in this Act as “a list of the parts and components (whether new or reused) of an end product or service, including, with respect to each part and component, information relating to the origin, composition, integrity, and any other information as determined appropriate by the Under Secretary.”

Continuous SBOM Updates Required

As information in the SBOM changes, contractors are required to submit updates to SBOMs. “…in the case of a change to the information included in a bill of materials…each contractor shall submit…the update to such bill of materials, in a timely manner.”

SBOMs Certified Using the National Vulnerability Database (NVD)

Items listed on the bill of materials must be “…free from all known vulnerabilities or defects affecting the security of the end product or service identified in the National Institute of Standards and Technology National Vulnerability Database…”. In other words, product risk analysis must include investigation into component vulnerabilities and their potential impact on the security of the product and software supply chain risk.

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]

Matt Lentine
[email protected]
412-704-4602

FDA Seeking Additional Legislative Authorities

| vigilantops | , ,
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.