In an era of healthcare digital transformation, organizations utilize various connected IoT devices to improve patient care outcomes. Globally, 2 million different kinds of IoT devices across 7,000 generic categories exist in the market. As businesses add these devices to their network, they increase the number of access points that threat actors can use during an attack. Additionally, for many organizations, the devices become a series of “black boxes,” rife with vulnerabilities in their software components but providing little visibility into them. 

By understanding what a Software Bill of Materials (SBOM) is and how it enables security, you can more effectively use it to improve IoT device security.

Every device consists of various hardware and software technology components. Security issues in the software components, known as vulnerabilities, create cybersecurity risks as threat actors can use them as entryways during an attack. However, most organizations need help accessing information about what these components are to get started on their risk management process. 

As attackers increasingly seek to poison software supply chains, they look for vulnerabilities and ways to maliciously manipulate open source code. Open source code consists of publicly available and reusable code that developers use to create proprietary software. As a best practice, software and application developers often use open source code because trusted codebases have been tested for quality, enabling them to speed up their product’s time-to-market. For example, research found that across healthcare, health technology, and life sciences:

• 90% of codebases contained open source code
• 80% of code in codebases was open source

However, despite the vast amount of open source code used in healthcare technologies, most organizations need insight into the underlying components or their vulnerabilities. 

The “Consolidated Appropriations Act, 2023,” signed into law on December 29, 2022, seeks to reduce these software supply chain risks with Section 3305 of the Omnibus “Ensuring Cybersecurity of Medical Devices” to mandate that all medical devices create and maintain a Software Bill of Materials (SBOM). 

What is a Software Bill of Materials?

A Software Bill of Materials (SBOM) provides detailed information about the various software components that the manufacturer used. With this information, organizations can know to seek new vulnerabilities in a software component, because that vulnerability may affect the product they operate that uses that newly vulnerable software component. 

An SBOM provides visibility into the following:

• Component hash: unique identifiers that verify the component’s authenticity and integrity
• Open source components: source code freely available for developers to modify and incorporate into their software and applications
• Open source licenses: the legal terms and restrictions around how developers can use the open source components to protect the authors’ intellectual property
• Versions: information about the variant of the code in the device (very helpful to identify if a vulnerability applies)
• Vulnerabilities: security weaknesses in the code that attackers can use to exploit
• Nested inventories: list of relationships between different software components and resources that help the program function as intended

What are the elements of an SBOM?

Manufacturers use software composition analysis (SCA) tools to analyze their products’ source code. After scanning the source code, the tool generates a list of all components and dependencies organizations can use to prioritize their vulnerability remediation activities. Every SBOM consists of the same data types.

Data Fields

The data fields contain all the information about the software components, dependencies, and vulnerabilities.

Automation Support

This section of the SBOM enables organizations to automate component tracking. The available formats are:

• CycloneDX: information formatted in XML, JSON, and Protocol Buffers format consisting of metadata, components, services, dependencies, compositions, and vulnerabilities
• Software Package Data Exchange (SPDX): common format communicating software name, version, components, licenses, copyrights, and security references
• Software Identification (SWID) Tags: information formatted in XML that identifies and describes components, requirements, patches, and supplemental data that augments the other elements

Practices and Processes

This section communicates the following standards for updating and supplying SBOMs:

• Updating SBOM with a new build or release
• Including top-level components and transitive dependencies
• Offering a complete dependency tree or explanation of why one isn’t offered
• Distributing in a timely manner to the proper roles with the appropriate access rights
• Identifying any information that must be kept secret
• Suggesting that those relying on SBOMs forgive accidental faults or omissions

Why is an SBOM important?

With insight into the technologies incorporated into devices, organizations can improve their cybersecurity by “looking under the hood.” For example, SBOMs could provide visibility into whether a device runs Apache 3.16, leaving it vulnerable to a Log4J-based attack. 

As companies increasingly incorporate IoT devices into their complex environments, SBOMs enable:

• Component visibility: identify all code sources so they can more rapidly identify hidden vulnerabilities
• Vulnerability management: identify vulnerabilities within the device manufacturer’s underlying source code
• Supply chain security: mitigate security risks arising from third-party libraries and components and hold vendors accountable for supplying updates
• Collaboration and patch management: work across health technology management (HTM) and security team to prioritize remediation activities
• Regulatory compliance: comply with new requirements mandating that organizations maintain SBOMs for all software and use them to mitigate risks

How Organizations should incorporate SBOMs into IoT device security practices

As part of a robust device security program, organizations should consider using SBOMs to mitigate risks. They can choose to do this work manually or seek a software platform that incorporates SBOM analysis into their offering. In either case, they can expect the following benefits.

Identify Vulnerabilities

Since IoT devices incorporate proprietary and open source components, SBOMs list the software in the supply chain so the user can identify the vulnerabilities embedded within. SBOMs enable organizations to identify and respond to vulnerabilities hidden within the software supply chain. With this information, companies can take proactive risk mitigation steps by contacting the manufacturer for a software security update or other remediation actions.

Gain Visibility into Exploitability

While organizations can use SBOMs to identify software containing vulnerabilities, they need visibility into whether attackers can actively use or are likely to them use during attacks. Otherwise, the remediation process becomes overwhelming for organizations that can maintain thousands of IoT devices. For example, Asimily includes SBOM information in its exploitability analysis to evaluate which vulnerabilities are actually exploitable. With this information, companies can prioritize the patches or other clinically validated actions, enabling them to improve their software supply chain security posture by focusing on source-code vulnerabilities that attackers are likely to exploit.

Prioritize Remediation

Remediating vulnerable devices is critical to patient safety. With visibility into exploitability, they can identify threats to their environments. SBOMs enable organizations to combine exploitability data with vulnerabilities across their device software supply chain to prioritize previously unknown risks within the context of their device source code. Knowing the vulnerabilities attackers are likely to use enables HTM and security teams to collaborate and focus on securing these high-risk devices first.

Incorporate into Procurement and Due Diligence

The FDA noted that organizations can use SBOMs as part of their proactive risk mitigation strategies by evaluating risks arising from known and exploited vulnerabilities before taking devices online. By leveraging SBOM data during the procurement and due diligence processes, organizations can plan and deploy their technology investments with an eye toward cybersecurity risk and potential patient impact. When they can generate a comprehensive risk report before purchasing a device, they can make more informed procurement decisions and deploy the technologies using device hardening recommendations.

Asimily: Leveraging SBOM Data into IoT Device Security Practices

Asimily provides holistic context into an environment when calculating Likelihood-based risk scoring for devices. Our vulnerability scoring considers the compensating controls so you can more appropriately prioritize remediation activities.

Organizations efficiently identify high-risk vulnerabilities with our proprietary, patented algorithm that cross-references vast amounts of data from resources like EPSS, Manufacturer Disclosure Statements for Medical Device Security (MDS2s), Software Bills of Material (SBOMs), Common Vulnerability and Exposure (CVE) lists, the MITRE ATT&CK Framework, and NIST Guidelines. It understands your unique environment, so our deep contextual recommendation engine can provide real-time, actionable remediation steps to reduce risk and save time.

Asimily customers are 10x more efficient because the engine can pinpoint and prioritize the top 2% of problem devices that are High-Risk (High Likelihood of exploitation and High Impact if compromised). Asimily’s clinically validated recommendations can easily be applied in several ways, including through seamless integration with NACs, firewalls, or other network enforcement solutions.

To learn more about Asimily, download our Total Cost of Ownership Analysis on Connected Device Cybersecurity Risk whitepaper or contact us today.