Why SBOMs are critical to your present and future
By having an SBOM that represents the current state of your product, you now have a catalog of all of your “ingredient lists”, creating visibility and transparency across your software security supply chain and ensuring that your software is updated and patched on a regular basis. You can then quickly identify any potential exploitable vulnerabilities you need to assess and mitigate.
What is an SBOM?
SBOMs are a critical component for operationalizing software supply chain security; they are key building blocks in your software supply chain cybersecurity programs. SBOMs act like a list of ingredients for the software that makes up applications. You may call these individual software “components” or “dependencies”. Helm enables you to provide transparency to your own company, your auditors, and even your customers, depending on your company policies, on your software supply chain, ensuring that stakeholders are aware of otherwise invisible dependencies on proprietary, open source and licensed, Commercial Off-the-Shelf (COTS) libraries.
Common elements of an SBOM include:
Open-source libraries.
Plug-ins, extensions, and add-ons
Custom source code created in-house
Information about versions, licensing status, and patch status of dependency components
SaaS: Third-party services and API information required to run the SaaS application.
SBOMs are critical to secure your present and future
SBOMs are critical to realizing a better and more secure future for your company, your customers, and their patients. It is the latest step in the path to ensure that through making your software dependencies visible, you can then manage vulnerabilities of this software, ensuring that you are focusing on the highest-risk and most critical vulnerabilities first. Per the FDA, it’s no longer sufficient to rely on “security through obscurity”, as medical device manufacturers, you need to take responsibility and realize your pre-market and post-market liability for insecure software being used in your devices and systems, which are then passed down to customers and patients.
According to Gartner, by 2026, at least 60% of companies with mission-critical software solutions will mandate SBOM disclosures in their license and support agreements.
Recent cybersecurity attacks and changing economic conditions
Over the past few years, there have been a number of high-profile software supply chain attacks. Today’s connected devices rely on many software libraries, including home-grown, third-party, and open source projects. As a result of the pandemic, there have been a number of business-critical supply chain shortages, which have forced device and product manufacturers to expand outside their network of trusted suppliers, adding another layer of risk to the software supply chain. Here are a few of the more recent and most impactful attacks, although there are many more:
SolarWinds
In 2020, the SolarWinds attack on the software supply chain has a deep and lasting impact on the US governmental infrastructure and many companies across the US, Europe, Asia, and the Middle East, as IT networks were hacked by intruders over a months-long operation against SolarWinds, which supplied the hacked companies with a network monitoring and management platform. It cast a sobering spotlight on the extent to which medical device manufacturers know about the software that is used in their devices.
Log4Shell (Log4j)
In 2021, a critical remote-code execution vulnerability was discovered in the ubiquitous Apache Log4j open-source Java logging library. Its widespread usage combined with its ease of exploitation for even inexperienced hackers makes it especially dangerous, putting any Java applications with a user interface at risk of a Log4Shell attack. It made the risk inherent in using open source components in devices painfully clear. Systems and services that use the Log4j library include Twitter, Tesla, Apple, Minecraft, and many others.
WannaCry
In 2017, the WannaCry (also known as WannaCrypt) ransomware attack targeted computers running the Microsoft Windows operating system by using the EternalBlue exploit to encrypt data and the DoublePulsar tool to install and execute copied of itself, then demanding cryptocurrency payments to unencrypt the data. While Microsoft had released patches to close the exploit, many organizations had not applied these patches or were using older Windows operating systems that were past their end-of-life. According to Europol, WannaCry infected over 200K computers across 150 countries, impacting the National Health Service and a myriad of other companies.
Is my company impacted by Log4j or WannaCry?
You can easily check that once you’ve generated and uploaded your SBOM into Helm!
For Log4j, you can search for “log4j” in our global search to return all dependency components that are potentially impacted, or you can search on the vulnerability ID CVE-2021-44228. If you think you are impacted, refer to CISA's Log4j Vulnerability Guidance for more information.
For WannaCry, you can search for older Windows operating systems (e.g., Windows XP and upwards) to make sure that they have been patched. You can also search for associated vulnerability IDs: CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147, and CVE-2017-0148. If you think that you could be impacted, refer to CISA's WannaCry fact sheet for more information.
Meet government requirements
According to Gartner, by 2026, at least 60% of companies with mission-critical software solutions will mandate SBOM disclosures in their license and support agreements.
By having an SBOM that represents the current state of your product, you now have a catalog of all of your “ingredient lists”, creating visibility and transparency across your software security supply chain and ensuring that your software is updated and patched on a regular basis. You can then quickly identify any potential exploitable vulnerabilities you need to assess and mitigate.
Secure your company's present and future
SBOMs are critical to realizing a better and more secure future for your company, your customers, and their patients. It is the latest step in the path to ensure that through making your software dependencies visible, you can then manage vulnerabilities of this software, ensuring that you are focusing on the highest-risk and most critical vulnerabilities first. Per the FDA, it’s no longer sufficient to rely on “security through obscurity”, as medical device manufacturers, you need to take responsibility and realize your pre-market and post-market liability for insecure software being used in your devices and systems, which are then passed down to customers and patients.
The US government published Executive Order 14028 for Improving the Nation’s Cybersecurity in 2021, after which federal agencies were subsequently required to adopt NIST guidelines, including using SBOMs to conform with NIST secure software development practices.
Meet hospital requirements
Hospitals, the consumer of medical devices, are increasingly requesting a detailed SBOM as part of their Business Associate Agreements (ex. Mayo Clinic), with expectations including the device or application name, the vendor and product name based on the NIST CPE dictionary and the version, as well as who is responsible for providing and applying any software updates, how often the software will be updated, how often security patches are applied (particularly when there is a known vulnerability), whether the software is critical for the device to function, how the MDM will notify the Mayo Clinic in case of updates, and expected end-of-life date for the device or application. Due to their need to reduce operating expenses while maintaining the highest quality of healthcare, health systems like the Mayo Clinic will continue to reject supplier price increases, pass-thru taxes (e.g., the Medical Device Tax), or other loss of value. They have asked that MDMs continue to streamline processes and increase efficiencies.
Recent cybersecurity attacks and changing economic conditions
Over the past few years, there have been a number of high-profile software supply chain attacks. Today’s connected devices rely on many software libraries, including home-grown, third-party, and open source projects. As a result of the pandemic, there have been a number of business-critical supply chain shortages, which have forced device and product manufacturers to expand outside their network of trusted suppliers, adding another layer of risk to the software supply chain. Here are a few of the more recent and most impactful attacks, although there are many more:
SolarWinds
In 2020, the SolarWinds attack on the software supply chain has a deep and lasting impact on the US governmental infrastructure and many companies across the US, Europe, Asia, and the Middle East, as IT networks were hacked by intruders over a months-long operation against SolarWinds, which supplied the hacked companies with a network monitoring and management platform. It cast a sobering spotlight on the extent to which medical device manufacturers know about the software that is used in their devices.
Log4Shell (Log4j)
In 2021, a critical remote-code execution vulnerability was discovered in the ubiquitous Apache Log4j open-source Java logging library. Its widespread usage combined with its ease of exploitation for even inexperienced hackers makes it especially dangerous, putting any Java applications with a user interface at risk of a Log4Shell attack. It made the risk inherent in using open source components in devices painfully clear. Systems and services that use the Log4j library include Twitter, Tesla, Apple, Minecraft, and many others.
Meet government requirements
To further support this, the US government published Executive Order 14028 for Improving the Nation’s Cybersecurity in 2021, after which federal agencies were subsequently required to adopt NIST guidelines, including using SBOMs to conform with NIST secure software development practices.
Meet hospital requirements
Hospitals, the consumer of medical devices, are increasingly requesting a detailed SBOM as part of their Business Associate Agreements (ex. Mayo Clinic), with expectations including the device or application name, the vendor and product name based on the NIST CPE dictionary and the version, as well as who is responsible for providing and applying any software updates, how often the software will be updated, how often security patches are applied (particularly when there is a known vulnerability), whether the software is critical for the device to function, how the MDM will notify the Mayo Clinic in case of updates, and expected end-of-life date for the device or application. Due to their need to reduce operating expenses while maintaining the highest quality of healthcare, health systems like the Mayo Clinic will continue to reject supplier price increases, pass-thru taxes (e.g., the Medical Device Tax), or other loss of value. They have asked that MDMs continue to streamline processes and increase efficiencies.
What can I use SBOMs for?
You can use SBOMS to proactively understand and prevent or reduce risks, as well as to respond to incidents when they do occur.
By having an SBOM that represents the current state of your product, you can create a catalog of all of your “ingredient lists” to create visibility and transparency across your software security supply chain, as well as identifying any potential exploitable vulnerabilities you need to assess and mitigate.
Meet Mayo Clinic requirements
If you’re doing business with the Mayo Clinic, they often request a detailed SBOM as part of their Business Associate Agreements, including the device or application name, the vendor and product name based on the NIST CPE dictionary and the version, as well as who is responsible for providing and applying any software updates, how often the software will be updated, how often security patches are applied (particularly when there is a known vulnerability), whether the software is critical for the device to function, how the MDM will notify the Mayo Clinic in case of updates, and expected end-of-life date for the device or application. Due to their need to reduce operating expenses while maintaining the highest quality of healthcare, the Mayo Clinic will continue to reject for supplier price increases, pass-thru taxes (e.g., the Medical Device Tax), or other loss of value. They have asked that MDMs continue to streamline processes and increase efficiencies.
Pre-market dependency and vulnerability tracking
Per the FDA guidance in Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, manufacturers should be addressing cybersecurity during the design and development of their medical device, which often results in more robust and efficient mitigation of patient and operator risks. Medical device manufacturers also need to establish design inputs for their device related to cybersecurity, as well as establishing a cybersecurity vulnerability and management approach as part of the software validation and risk analysis required by 21 CFR 820.30(g). This approach should address the following:
Identification of assets, threats, and vulnerabilities
Assessment of the impact of threats and vulnerabilities on device functionality and operators/patients
Assessment of the likelihood of a threat and of a vulnerability being exploited
Determination of risk levels and suitable mitigation strategies
Assessment of residual risk and risk acceptance criteria.
Medical devices that can connect (wirelessly or hard-wired) to another device, to the internet, to another network, or to portable media (e.g., USB or CD) are more vulnerable to cybersecurity threats than devices that are not connected. The extent to which security controls are needed depends on the device’s intended use, the presence and intent of its electronic data interfaces, its intended environment of use, the type of cybersecurity vulnerabilities present, the likelihood the vulnerability will be exploited, and the probable risk of patient harm due to a cybersecurity breach. To determine whether your device is considered a cyber device, refer to the What does the FDA classify as a cyber device? section.
Post-market dependency and vulnerability tracking
Per the FDA guidance in Postmarket Management of Cybersecurity in Medical Devices, due to constantly changing nature of cybersecurity risks to medical devices, manufacturers cannot completely mitigate risks through pre-market controls alone. Thus, it is critical that manufacturers implement comprehensive cybersecurity management programs and documentation consistent with the Quality System Regulation (21 CFR part 820), including complaint handling, quality audit, corrective and preventive action, software validation and risk analysis, and servicing.
Cybersecurity risk management programs should address vulnerabilities that will potentially allow the unauthorized access, modification, misuse or denial of use, or the unauthorized use of information stored, accessed, or transferred from a medical device which may result in patient harm. This program should include:
Monitoring cybersecurity information sources for identifying and detecting cybersecurity vulnerabilities and risks.
Maintaining robust software lifecycle processes, including mechanisms for:
monitoring third-party software components for new vulnerabilities throughout the device’s lifecycle
design verification and validation for software updates and patches that are used to remediate vulnerabilities, including for off-the-shelf software
Understanding, assessing, and detecting the presence and impact of a vulnerability
Establishing and communicating processes for vulnerability intake and handling.
Using threat modeling to clearly define how to maintain safety and essential performance of a device by developing mitigations that protect, respond, and recover from cybersecurity risk
Adopting a coordinated vulnerability disclosure policy and practice
Deploying mitigations that address cybersecurity risk early and prior to exploitation.
Participation in an ISAO to share vulnerability and threat information
Per the FDA guidance in Postmarket Management of Cybersecurity in Medical Devices, it is strongly recommended that medical device manufacturers participate in an ISAO that shares vulnerabilities and threats that impact medical devices. Sharing and disseminating cybersecurity information and intelligence pertaining to vulnerabilities and threats across multiple sectors is integral to a successful post-market cybersecurity surveillance program.
In case you weren’t aware, Medcrypt owns an ISAO, MedISAO - we’d love to have you join us in sharing information!
Threat modeling
As part of your cybersecurity program, FDA post-market guidance states that manufacturers should define the safety and essential performance of their device, the potential for and severity of patient harm should the device be compromised, as well as the risk acceptance criteria, all of which will enable you to quickly triage vulnerabilities for remediation and mitigation. Threat modeling is critical to helping to you understand and assess the exploitability of a vulnerability, as well as ensuring that your vulnerability remediation can reasonably control the risk of patient harm. Acceptable mitigations will vary depending on the severity of the potential patient harm.
Handling a data breach
Having a complete SBOM is critical during a data breach, enabling you to quickly detect and analyze the impacted software and to understand the impact of the data breach and which other dependency components might be affected so that you can act quickly to limit the impact to your company, your customers, and their patients. It also helps you identify what critical areas you need to address and what to prioritize first in your cybersecurity plan.
Detect and analyze
SBOMs are very useful during the detection and analysis phase, providing visibility into what is in the software for context and details that inform the analysis. This drastically reduces wasted time spent gathering information from binary files, which is especially critical during a data breach.
Commit and recover
By shifting the process of providing transparency to your entire software supply chain to the left, you can get requisite information from your vendors and third parties to determine their impact in your device’s particular environment. This also enables you to proactively identify necessary patching and communicate that to your customers before exploits occur.
If your SBOM is complete and accurate, your incident response team can more easily understand how an application or API works, enabling them to put an attack in context. It can also help them track down repositories and which people are involved in the project, shortening response time. If your SBOM contains information about services, such as backend connections to databases, queues, APIs, and directories, they can use this to calculate the impact of a breach while it is occurring. They can also seek out impacted or affected components or dependencies in areas that they haven’t begun investigating yet, enabling them to more quickly ensure that they’ve eradicated a particular attack.
Post-incident response
After dealing with an exploit, you can use your SBOM in your post-mortem analysis to identify critical areas to address and what needs to be prioritized for the near and longer-term future.
Last updated