The What, Why and How of Medical Device Cybersecurity

In an age where hospitals face crippling ransomware attacks and life-saving medical devices fall prey to cybercriminals, many medical device manufacturers find themselves in the middle of a digital battleground. With the continuous increase in cybersecurity threats, regulatory scrutiny on medical device cybersecurity has been rapidly intensifying worldwide. Cybersecurity has become the hot topic in the medical device industry, bringing a slew of new terminologies into the daily lexicon of product managers, development engineers, and regulatory and quality specialists. These terms often seem “foreign” and mysterious to professionals new to cybersecurity, and it is not immediately clear how they fit into established medical device development frameworks such as ISO 14971. One such term is threat modeling. What is a cybersecurity threat? Why do we need to model it? What is STRIDE exactly, and how do we use it? 

In this blog post, we will dive into threat modeling with the aim of providing clarity and actionable recommendations on this key concept in medical device cybersecurity.

Understanding Medical Device Cybersecurity Threats and Their Relations with Vulnerabilities

A cybersecurity threat is defined as the potential for a security violation, arising from circumstances, capabilities, actions, or events that could breach security and cause damage to confidentiality, integrity, and availability of information assets (IEC 81001-5-1). In simpler terms, it is what could go wrong with information assets. A security violation only occurs when vulnerabilities are present and exploited by a threat actor. Vulnerabilities are weaknesses or flaws in a system, application, network, or device that can be exploited to compromise the system's confidentiality, integrity, and availability. These vulnerabilities can exist in software code, configurations, protocols, or even human processes and can be introduced either inadvertently or intentionally.

The Importance of Threat Modeling in Medical Device Cybersecurity

What is threat modeling, and why do we need to model threats? What do we gain from it? Threat modeling is an approach for analyzing threats a device faces in a structured way so that possible vulnerabilities (or bugs) associated with each threat can be identified, enumerated, and prioritized. In simple terms, once we understand what could go wrong (i.e. threats), we model threats, based on a device’s design, to see how threats can manifest in a device and its connected IT system. For example, consider a device that uses Bluetooth to transfer health data wirelessly. A foreseeable threat in this context is the disclosure of health information. By modeling this threat, we identify that unencrypted Bluetooth data transmission is a vulnerability an attacker could exploit to carry out this threat. Consequently, we add a design requirement for Bluetooth data encryption to mitigate this vulnerability and, in turn, the threat. This simplified example illustrates that threat modeling is about understanding the modus operandi of threats within a device's design, aiming to identify and address vulnerabilities to ensure the device's security and safety. 

Laying the Groundwork Before Start: Depicting Device Functions

The next logical question is, how do we do threat modeling? Well, let’s hold back for a second for some essential preparation. A crucial step before the start of any threat modeling exercise is to have a good depiction of how the device in question operates. Without this understanding, it becomes challenging to comprehensively identify and model threats, taking into account all vulnerable attack surfaces, data flows, and critical components. This depiction should be in a format that is easy to use since threat modeling is a group exercise that requires the participation of a cross-functional team. A highly detailed but lengthy text description of the device design might not be the most productive choice for a threat modeling session.

A commonly used method for device depiction in threat modeling is the Data Flow Diagram (DFD). This method provides the threat modeling team with an effective way to visualize the device. Version 3 of DFD uses five simple symbols to enable a user to depict the internal and external components involved with the functioning of a device, how they interact (i.e. how data flows between), and their trust boundaries which are imaginary lines that separate components based on the level of trust afforded to them. 

The figure below illustrates the DFD of a fictional device: a sensor that measures a physiological parameter from the patient’s body and then transmits it to an app on the patient’s mobile phone. The mobile phone app uploads the patient’s measurement data to a cloud storage system, where the patient and their healthcare provider can access it via a web interface.    

The DFD above is not exhaustive, as it does not capture all possible data flows and interactions, and the system components are depicted at a high level rather than in detail. However, this level of detail is sufficient for the start of a threat modeling exercise. Like many aspects in medical device development, threat modeling is an iterative process. As the threat modeling team delves deeper into identifying threats, additional components, flows, and details will be incorporated into the diagram.

Initiating Threat Modeling with STRIDE

With a working system diagram in place, we can now begin threat modeling. This is when the concept STRIDE comes into play. STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. These six categories represent common types of threats that IT systems face, similar to hazards in ISO 14971 for medical devices. Developed by security researchers at Microsoft in 1999, STRIDE is perhaps the most widely used structured threat modeling technique.

When applying STRIDE, the modeling team should consider the potential presence of each of the six types of threats within the device. This can be approached in various ways, such as per element, per data flow, per interaction, per workflow/use case, or per trust boundary crossing. For the initial threat modeling iteration for the fictional device, we will use the STRIDE per boundary-crossing approach. This method allows us to focus on vulnerable attack surfaces awhile temporarily setting aside the internal complexities within a trust boundary.

The table below lists several threats identified for data flows crossing trust boundaries in the fictional device as shown in the DFD above after the initial round of brainstorming in a threat modeling session. The first table indexes threats for each boundary-crossing data flow according to the STRIDE categories. The subsequent table provides descriptions for each threat. 

It is important to note that the description of each threat may seem generic and lack technical details. This is often the case for threat models after an initial round of modeling or at the early stages of the R&D process when the design info is limited. This indicates that further analysis is needed to substantiate these threat models with identified vulnerabilities, if any. For an already-designed device, relevant elements on the DFD should be expanded for further analysis. For a device still in the design phase, threat modeling should be iterated to incorporate new design details as they become available, and the derived threat information should be fed back into the design process to address or prevent any vulnerabilities.

The Ongoing Process of Threat Modeling and Next Steps

Threat modeling is an iterative process that should continue throughout the entire lifecycle of a device. Each iteration incorporates additional information, such as new design details, design changes, and newly discovered vulnerabilities from various sources such as penetration testing, post-market surveillance, and public threat repositories and vulnerability databases. Additionally, threat models can be enhanced by using additional modeling methods that provide different perspectives of a given threat.

For instance, Attack Trees can be used to complement STRIDE by exploring multiple attack vectors, assessing the exploitability of vulnerabilities, and analyzing high-risk components or workflows. Similarly, the Cyber Kill Chain is often used alongside STRIDE to understand the full lifecycle of potential attacks, particularly for advanced persistent threats targeting devices, and to analyze threats from sophisticated threat actors who might employ multi-stage attacks.

Threat modeling does not end with the identification of threats and their associated vulnerabilities. In the next episode of this cybersecurity series, we will delve into the crucial next steps in the threat modeling process: assessing and prioritizing identified threats and vulnerabilities and integrating threat information into a device’s risk management system. Stay tuned as we continue our mini-introduction journey into the world of medical device cybersecurity.

For more information on threat modeling methodologies and their application in medical device development, a good resource is the Playbook for Threat Modeling Medical Devices written by the MITRE organization, under the support of the US FDA.