IoT Medical Device Security

The landscape of medical device security is governed by a mix of domestic and international standards, including The NIST Cybersecurity Improvement Act and IR 8259 Series, FD&C Act sections 524B and 3305, IEC 62443, AAMI TIR57, and the EU Cyber Resilience Act. These guidelines, while essential, often lack harmonization and detail primarily on the “what” rather than the “how” of securing devices. The guidelines are often written from the Health Delivery Organizations (HDOs) perspective, which are large medical system integrators, who play a crucial role assembling devices from various manufacturers to deliver comprehensive healthcare services. This perspective underlines the fact that medical device security transcends technology, delving into the realm of structure, practices, processes, and procedures. The emphasis is on creating a secure environment that extends beyond mere technological solutions to include the entire ecosystem surrounding medical devices.

HDOs now adopt a broader ecosystem view, considering the security of not just medical devices but all ancillary devices and services that could pose risks, including networked elevators, refrigeration systems, point-of-sale (POS) systems, lighting, and more. This expanded view is crucial in a world where cyber threats are increasingly sophisticated and pervasive.

In response to the evolving cybersecurity threats, the FDA cybersecurity guidelines for medical devices have been updated, emphasizing a lifecycle approach to securing devices from premarket development to post market management. This includes the introduction of a Secure Product Development Framework (SPDF) to reduce vulnerabilities and a detailed risk management process. The guidance, which supersedes the 2014 premarket cybersecurity document, aims to ensure devices are designed with robust security measures to protect against current and emerging threats. This approach is crucial for maintaining the safety and effectiveness of medical devices throughout their lifecycle.

The Consolidated Appropriations Act of 2023 (Omnibus), was signed into in December 2022, introduces explicit cybersecurity requirements for medical devices. For the first time, the FDA has been granted statutory authority to enforce certain cybersecurity measures for specific devices. This landmark legislation mandates that premarket applications for medical devices include comprehensive cybersecurity plans, processes, and documentation, highlighting the increasing recognition of cybersecurity’s critical role in medical device safety and efficacy. Additionally, the FDA could now start refusing submissions based on cybersecurity concerns. Pre-market submissions must now include sections on cyber security as section 3305 of Omnibus requires a vendor to provide plans to “monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity issues.”

Section 3305 of the Act requires persons who submit premarket applications for medical devices (i.e., PMA, 510(k), or de novo submissions) to include additional information to ensure the device meets cybersecurity requirements that include:

1. 1. submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits.
   2. design, develop and maintain processes and procedures to provide a reasonable assurance that the device and related systems are “cybersecure,” and make available postmarket updates and patches to the device and related systems to address certain cybersecurity vulnerabilities.
   3. provide a software bill of materials, including commercial, open-source, and off-the-shelf software components.
   4. comply with other requirements the FDA may require through regulations to demonstrate a reasonable assurance that the device and related systems are cybersecure.

The requirements also create a new prohibited act stating “the failure to comply with any requirement under section 524B(b)(2) (relating to ensuring device cybersecurity.)” This new section comes with significant teeth and enables the government to prosecute violations of cybersecurity requirements criminally.

The updated security risk management section of the new guidance contains two new sub-sections, the first regarding “Cybersecurity Risk Assessments.” Cybersecurity risks are difficult to predict. The guidance recognizes that it is impossible to assess and quantify the likelihood of an incident occurring based on historical data or modeling. Accordingly, cybersecurity risk assessment should focus on the exploitability of vulnerabilities within a device or system, and any likely present in the deployed environment. FDA recommends that the cybersecurity risk assessment capture the risks and controls identified from the threat model. It should also include how risks are scored, pre- and post-mitigation, and associated acceptance criteria. It must also include the method for transferring security risks into the safety risk assessment.

The risk management section also contains a new section on “Interoperability Considerations,” addressing cybersecurity issues that may arise from interoperable functionality, including:

• Other medical devices and accessories
• “other functions” as identified in FDA’s guidance titled: Multiple Function Device Products: Policies and Considerations
• Interoperability with health care infrastructure; and General Purpose computing platforms.

The guidance notes that properly implemented cybersecurity controls will help ensure the safe and effective exchange of information (see Design Considerations and Pre-market Submissions Recommendations for Interoperable Medical Devices).  Cryptography is a foundational security element and Appendix 1 Section C highlights the need to utilize NIST FIPS 140-3 validated implementations.

Appendix 4 provides a checklist of documents the FDA recommends be submitted in premarket submissions.

The final guidance also adds and defines new key cybersecurity terms in  Appendix 5. While many of the added terms are new to the guidance, they are adapted from existing definitions from recognized sources, including NIST, the Joint Security Plan, ISO/IEC and CNSSI 4009-2015.

Executive Order 14028 – Improving the Nation’s Cybersecurity

Executive Order 14028, issued by the U.S. government, aims to enhance national cybersecurity measures across federal departments and agencies. This directive emphasizes the importance of creating and managing secure software, including the development and utilization of Software Bill of Materials (SBOM) and analysis of Software of Unknown Pedigree (SOUP).

SBOM Formats

SBOMs provide a comprehensive inventory of software components within a device or application. Understanding and utilizing standardized formats for SBOMs is crucial for effective cybersecurity management.

• SPDX (Software Package Data Exchange): This standard format for communicating the components, relationships, and licenses of software packages facilitates the sharing and analysis of software bill of materials.
• CycloneDX: Designed for use in application security contexts and supply chain component analysis, CycloneDX offers a lightweight SBOM standard compatible with modern development tools and practices.
• SWID (Software Identification Tags): SWID tags help manage and inventory software products, offering a standardized method for software identification that supports cybersecurity and asset management efforts.

Cybersecurity threats in the healthcare sector, including malware, data breaches, insider threats, ransomware, and phishing attacks, significantly disrupt patient care and financial operations by compromising the confidentiality, integrity, and availability of sensitive health information. These threats can delay critical treatments, leading to potential life-threatening situations for patients.

Compromised medical IoT devices can serve as entry points or “springboards” for broader network infiltration, allowing attackers to move laterally within healthcare IT systems to access sensitive data and systems.

Medical IoT Threat Modeling

Medical device cybersecurity is of utmost importance in today’s world. One way to ensure the safety of medical devices is through threat modeling. By using threat modeling, we can build secure devices, eliminate preventable errors, reduce development costs, speed up development, and implement proactive controls to eliminate, mitigate, accept or transfer threats. Additionally, the design artifacts created through threat modeling can be used throughout the total product life cycle.

It’s important to note that there is no one-size-fits-all approach when it comes to threat modeling. One common starting point is to consider the four key questions outlined in “Threat Modelling: Designing for Security” by Adam ShoStack, John Wiley & Sons in 2014. These questions are as follows: What are we working on? What could go wrong? What are we going to do about it? Did we do a good enough job? Additionally, it’s generally better to work in groups when conducting threat modeling, as unstructured discovery tends to be the most effective approach.

Question 1: What are we working on? 

The first step is to develop a common and concise representation of the medical device, its deployment environment(s), its true value proposition, the flow of data to and from the device, operating states, and general use cases.

When developing a threat model, data flow diagrams (DFD) can be used to break down the system into five key elements: External Entity, Process, Data Store, Data Flow, and Trust Boundary. Additionally, cross-functional diagrams and state diagrams can also be helpful.

Question 2: What could possibly go wrong?

Now, with a representative system view, it is time to identify potential threats based on the medical device functionality and the underlying architecture. Microsoft’s STRIDE structured threat modeling paradigm is a common approach and provides robust results.

Using the structure STRIDE method for enumerating and assigning threats to the following classes:

Attack Class	Description	Example
S – Spoofing	Pretending to be someone else	A hacker pretends to be an authorized user
T – Tampering	Modifying data or code	Code or data is changed without notice by malware
R- Repudiation	Denial	A user denies they have treated a patient with a device
I – Information Disclosure	Confidential is disclosed to an unauthorized people	A nurse can see the diagnosis of a “Special” patient she is not authorized to see
D – Denial of Service	DOS attack	A bot or botnet floods a network with unusable packets causing data services to fail
E – Elevation of Privilege	Someone obtains privileges they should not have	A user makes themselves an admin on the system.

The goal of using the STRIDE strategy while referencing the representative model of the medical device is to generate and classify a list of potential threats.

However, as the Software Engineering Institute points out in “Threat Modeling: A Summary of Available Methods, ” other threat modeling techniques could better fit your use case and overall focus.

The guiding principle is to select a threat modeling methodology and enumerate and categorize threats from multiple angles.

Question 3: What are we going to do about it (the threats)?

Once there is a list of potential threats against the medical device and a system representation of the medical device, the team next decides how to address each threat best. Adam Shostack provides the four common actions that can be taken with each risk:

• Mitigate. Take action to reduce the likelihood that the threat will materialize.
• Eliminate: Simply remove the feature or component that is causing the threat.
• Transfer. Shift responsibility to another entity such as the customer.
• Accept. Do not mitigate, eliminate, or transfer the risk because none of the above options are acceptable given business requirements or constraints.

When mitigating a threat, the strategies must be identified as a category or individual threats and adequately documented as system requirements. This provides a lasting design artifact to be continuously reviewed during the total product life cycle.

Depending on the complexity of the system, the nature of threats identified, and the process used for identifying threats (STRIDE or another method), mitigation responses may be applied at either the category or individual threat level. Mitigation strategies must be actionable and not hypothetical. They must reflect measures that can be built into a medical device under development.

Question 4: Did we do a good enough job (this time)?

At this point the threat model must be reviewed by all stakeholders and not just the development, quality, and security teams. Areas to focus on include:

• Does the model accurately reflect the actual system (data flows, state diagram representations, etc.)?
• Are there additional threats that can be identified?
• What should trigger a specific re-evaluation of threats? How often should threat modeling be reviewed?
• Is there a traceability matrix that identifies the source of threats, how the medical device team has chosen to address each threat, results from testing against identified threats, etc.?
• Has the threat model been properly documented and stored for future use by ongoing maintenance and support teams? What are the artifacts, how are they stored, and who has access?

Medical IoT device security extends beyond the deployment of the device in hospital settings. Comprehensive security measures must be integrated throughout the entire device lifecycle, from initial design and development through to decommissioning.

Secure Product Development Framework (SPDF)

The SPDF offers a structured approach to integrating security into the product development process. It encompasses practices and procedures designed to minimize vulnerabilities and ensure that medical devices are designed, developed, and maintained with cybersecurity as a central focus. Implementing an SPDF is essential for addressing the dynamic nature of cybersecurity threats and ensuring the ongoing protection of medical IoT devices and the data they handle.

By addressing these critical areas—SBOM and SOUP analysis, understanding medical IoT threats, and ensuring security throughout the device lifecycle—stakeholders in the healthcare and technology sectors can significantly enhance the cybersecurity posture of medical IoT devices, safeguarding sensitive data and ensuring the continuity of care.

A Lifecycle Perspective

Our approach to medical device security encompasses the entire lifecycle of a product, from design to decommissioning. This perspective is essential for understanding how to effectively secure devices at every stage of their existence. It involves a systems-level understanding of security, ensuring that protection measures are in place throughout the product’s life.

Securing medical devices requires a cyber-focused development strategy that incorporates a secure product development framework, attention to the supply chain, including product and software bill of materials (BOM/SBOM), and the creation of multiple chains of trust through documentation and artifacts.

Understanding Risks & Modeling Threats

Every company faces a unique risk profile influenced by regulatory requirements and risk tolerance. This profile guides the security measures implemented in the end product. Threat modeling, as recommended by the FDA, is a critical component of understanding and mitigating risks associated with medical devices.

The MITRE Corporation has developed a playbook for threat modeling medical devices, offering guidelines and best practices to identify, assess, and mitigate cybersecurity threats throughout the device lifecycle. This resource is instrumental for manufacturers and healthcare providers in understanding and addressing potential vulnerabilities.

Challenges in Securing Data

In the healthcare sector, the management of vendor-supplied systems, ranging from medical devices to infrastructure like elevators and HVAC, presents significant security challenges. Many hospitals lack a comprehensive understanding of their networked device inventory, with medical devices constituting the majority of connected assets but only a fraction being directly managed by IT departments. The disparity in device management and oversight, combined with the longevity of medical equipment and a lack of cybersecurity training among medical staff, exacerbates these challenges. Furthermore, the integration of AI and ML in healthcare necessitates human oversight to prevent data corruption or tampering.

Medical device manufacturers are increasingly required to focus on cybersecurity elements such as the Software Bill of Materials (SBOM) and vulnerability management in their premarket submissions. The FDA’s evolving stance emphasizes not just the inclusion of these elements but a comprehensive approach to ensuring devices and their ecosystems are secure against cyber threats. This involves a detailed examination of a device’s threat model, its capability for secure remote updates, and the integrity of its software supply chain.

The IEEE Medical Device Cybersecurity Certification Program, including IEEE 2621 standard represents a significant advancement in the cybersecurity certification of medical devices, initially focusing on devices critical to diabetes management such as blood glucose monitors and insulin pumps, with the potential for application across a broader range of medical devices. This initiative underscores the critical need for robust cybersecurity measures in medical technology, reflecting a growing awareness and response to the vulnerabilities these devices face.

On another front, the evolution of data processing from batch to real-time streams signifies a paradigm shift in how data is handled, particularly in the context of generating and utilizing large language models (LLMs) like GPT. This shift towards real-time processing and online machine learning emphasizes the importance of immediate, dynamic data analysis and application, highlighting the limitations of traditional batch processing methods.

Additional Resources:

• Standard for Premarket Guidance for Cybersecurity in Medical Devices
• Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software