Medical Device Threat Modeling: Best Practices, FAQs, and Examples

FAQs 🔗

Please note that threat modeling is used in many industries. This article discusses threat modeling medical devices and focuses on the US regulations.

This article is a work in progress.

Basics 🔗

What is a threat? 🔗

The FDA defines a threat as follows:

A threat is any circumstance or event with the potential to adversely impact the device, organizational operations …, or other organizations through an information system via

• unauthorized access,
• destruction,
• disclosure,
• modification of information,
• and/or denial of service.

What is threat modeling? 🔗

The FDA defines threat modeling as follows:

Threat modeling is a methodology for optimizing Network/Application/Internet Security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. For medical devices, threat modeling can be used to strengthen security by identifying vulnerabilities and threats to a particular product, products in a product line, or from the organization's supply chain that can cause patient harm.

A key output of the threat modeling process is a threat model.

What is a threat model? 🔗

A threat model is a approximate representation of your software system and the surrounding environment with regards to security.

We usually have a single document that we call our threat model that contains, or references other documents that contains, the following items:

• Assumptions about the system and environment of use
• Your security assets
• An analysis of expected threat actors
• Architectural diagrams showing
  • The key components of your device
  • All external systems
  • Their connections
  • The process by which software updates go from source code to deployment
• An analysis of the main threats (often enumerated following a few methodologies, such as STRIDE)
• A listing of the implemented mitigations

There’s not a standard format for threat models. We will provide examples of how we format our threat models below.

How is security risk management related to safety risk management? 🔗

Safety risk management focuses on harm to patients and device users. Security risk management considers harm to assets due to cybersecurity breaches more generally, including business reputations, PHI, and other assets not accounted for in safety risk management. (As an aside, risk management is useful model anytime you’re trying to anticipate harm more broadly, including harm to business profitability, regulatory submission risk, and so on.)

Security risks are sometimes, but not always, related to patient safety risks.

Safety risk management is clearly defined in the widely-adopted ISO-14971 standard.

Security risk management for medical devices is described in the AAMI TIR57 “Principles for medical device security—Risk Management” Technical Information Report, which the FDA has recognized as a consensus standard.

There is a very useful diagram, which I’ve copied from TIR57, that shows the relationship between the processes:

How is threat modeling related to security risk management? 🔗

In our opinion, there is not a clear distinction between threat modeling and security risk management. We suspect this is because threat modeling was developed outside the medical device industry and had its own terminology developed apart from of ISO 14971. In any event, it is straightforward to map the components of the Threat Modeling Manifesto to the AAMI TIR57, as shown in the following diagram.

If we were forced to make a distinction, we would say that “threat modeling is a loose collection of methodologies used to systematically identify, mitigate, and document security risks.”

According to this distinction, threat modeling is to security risk management as FMEA is to safety risk management. FMEA is a structured way of identifying safety risks related to parts of your system breaking down. Unlike FMEA, which will rarely sufficient to identify all of the safety risks for a device because it misses process- and usability-related risks, threat modeling is in theory sufficient on its own. Thus, even this attempt at a distinction isn’t very useful.

Do we have to create a threat model for our 510(k) submission? 🔗

Here’s the simple answer: If your device connects to the internet, then yes, you need to provide a threat model in your 510(k) submission.

Really? I want to know the fine print. 🔗

If your device is not considered a “cyber device” then you don’t need to do a threat model.

Here is the regulatory definition of a “cyber device”:

A ‘cyber device’ means a device that—
(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;
(2) has the ability to connect to the internet; and
(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

This may sound simple enough, but even here there is ambiguity. For example, if you have a docker file that runs an AI model that doesn’t need to connect to the internet, yet in practice will likely run on a server that’s connected to the internet, is that a cyber device? If this is your situation, contact us and we can help you sort through it.

If your device is a cyber device, then technically speaking, you may be fine with just doing security risk management, however, as discussed below these are basically the same thing. Furthermore, the 2016 FDA Postmarket Cybersecurity Guidance, which is primarily focused on what you need to do after your device is on the market and not what goes into the premarket submission, says:

The FDA recommends that manufacturers conduct cybersecurity risk analyses that include threat modeling for each of their devices and to update those analyses over time.

On top of that, the 2022 Draft FDA Guidance - Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions says you should include a threat model in the submission, however this is draft guidance. It shows the FDA’s current thinking. It isn’t in effect, but it could go into effect at anytime.

The 2014 Cyberecurity guidance does require a cybersecurity hazard analysis. Furthermore, the new FD&C Act has language that also hints that it will be required.

In summary, if your device connects to the internet, then yes, you almost certainly need to provide a threat model in your 510(k) submission.

How do you create a threat model? 🔗

1. Identify all major system items
   • Examples: Backend Django App, AWS S3 Bucket, PACS, PostgreSQL Database
2. Create a system diagram, including connections
   • This diagram should show all the connections to external systems or networks
   • We suggest also creating a flow diagram that shows how
   • Example (from )
3. Identify all major cybersecurity assets
   • Assets can include data, user accounts, security keys, configuration files, the source code, and more.
   • Examples: PostgreSQL Database, AWS credentials, Configuration files
4. Create threat lists for each system item using STRIDE
   • STRIDE (Spoofing, Tampering, Repudiation, Info Disclosure, DDoS, Elevation of Privileges). See and for more examples.
     • Spoofing: Pretending to be something or someone you’re not
       • Example:
         • Threat: Malicious actor brute forces the clinician’s username and password.
         • Mitigation: Temporarily block login after 5 incorrect attempts.
     • Tampering: Changing something in a malicious way (on the disk, db)
       • Example:
         • Threat: Malicious actor modifies PostgreSQL Database via SQL injection.
         • Mitigation: Implement input validation on frontend and backend.
     • Repudiation: Doing something bad and claiming to not have done it
       • Example:
         • Threat: Malicious actor denies that a certain treatment has been prescribed.
         • Mitigation: Track all prescription actions in centralized logging system.
     • Information Disclosure: Having sensitive data leaked.
       • Example:
         • Threat: Malicious actor performs man-in-the-middle attack and steals data.
         • Mitigation: Use encryption in transit (HTTPS).
     • DDoS: Denial of service
       • Example:
         • Threat: Malicious actor overwhelms backend with abnormal traffic.
         • Mitigation: Configure AWS Web Application Firewall for common exploits.
     • Elevation of Privileges: Gaining unauthorized access
       • Example:
         • Threat: Malicious user changes their role to admin via API.
         • Mitigation: Only allow admins to change user roles and enforce this.
5. Eliminate or refine threats that are highly improbable or impossible to verify.
   • Rule of thumb when pruning threat lists:
     • If a threat is likely to impact patient safety, keep it even if it’s hard to verify.
     • If a threat is unlikely to impact patient safety, and is difficult to verify, consider removing it.
     • If you have already implemented the mitigation for a threat and it is relatively easy to verify, keep it.
   • Keep this diagram in mind
6. Convert threats/mitigations into risks/requirements and trace them
   • Example:
     • For the threat/mitigation pair
       • Threat: Malicious actor brute forces the clinician’s username and password.
       • Mitigation: Temporarily block login after 5 incorrect attempts.
     • You might have to create a new requirement to implement the threat mitigation
       • REQ-035: Throttle User Authentication
     • And add a new risk to cover the threat
       • RSK-025: Brute Force Attack

Who should create the threat model? 🔗

Software engineers who are familiar with the system should be able to perform the threat modeling.

Unlike with penetration testing, where we do suggest using an external firm, we don’t typically suggest having an outside firm put together a threat model. This is because the security risks and

The FDA 🔗

Does the FDA have a threat modeling standard they want device manufacturers to follow? 🔗

• No

Resources 🔗

What other resources exist for threat models? 🔗

• MITRE’s “Playbook for Threat Modeling Medical Devices”
• https://www.promenadesoftware.com/white-papers/a-step-by-step-guide-to-cybersecurity-threat-modeling
• Threat Modeling: Designing for Security
• Threat Modeling Manifesto
• OWASP Cheatsheet
• The Ultimate List of STRIDE Threat Examples

Examples 🔗