Medical Device Cybersecurity: Best Practices, FAQs, and Examples

Introduction 🔗

The FDA has become increasingly focused on medical device cybersecurity, as can been seen by the frequency of their guidance (2014, 2016, 2018, 2022, and 2023) and their increasing length. This has only accelerated when, in 2023, congress gave FDA additionally authority to regulate the cybersecurity of medical devices.

We’ve also seen a large up-tick in the FDA’s requests for additional information in medical-device submissions.

For groups who are less experienced with cybersecurity, reading the FDA guidance and the various standards can be overwhelming. Fortunately, when you boil down these abstract documents into the concrete actions you need to take, it’s actually much simpler. In this article, we collect a variety of best practices, questions, and examples related to cybersecurity. Our goal is to be as concrete and specific as we can.

If you like this article, you may also be interested in our other “FAQ, Best Practices, and Examples” style articles:

If you have medical-device cybersecurity questions that aren’t answered here, feel free to reach out to us in the website chat and we’ll get back to you.

We are a software development and regulatory consulting firm that specializes in SaMD. We help manufacturers with cybersecurity, regulatory strategy and submissions, and provide end-to-end SaMD development.

FAQs 🔗

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

Basics 🔗

What is cybersecurity? 🔗

With regards to medical devices, the FDA defines cybersecurity as the process of preventing

unauthorized access,
modification,
misuse or denial of use, or
the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient.

Do all medical devices need to comply with the cybersecurity guidance? 🔗

If your device has wireless connectivity or can has external ports (e.g., USB ports), then it probably does.

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.

In our experience interacting with the FDA, they interpret “has the ability to connect to the internet” broadly. For example, devices that only have a USB port are still considered cyber devices. So are docker images which do not connect to the internet but are expected to be run in an environment where they can connect.

What cybersecurity activities must be done when creating a medical device? 🔗

The guidance suggests incorporating security into the full development life-cycle. The FDA guidance is written in a somewhat abstract way. Here, I’ll list the key activities as they fall within a typical software development lifecycle process:

Planning
- Identify the personnel responsible for security activities
- Define how the likelihood, severity, and acceptability of security risks will be assessed
- Identify the methods that will be used to identifying security risks, including at least threat modeling
- Identify the threat-modeling methodology that will be used
- Identify the any secure coding standards or static code analysis tools that will be used during development
- Plan for how the development environment will be kept secure (e.g., requiring two-factor authentication in GitHub)
- Plan for how software updates will be delivered in a timely fashion to the device
Architecture
- Document key security views (these will be used in threat modeling)
- Security risk assessment - given the initial architecture, analyze likely security risks
Development
- Implement the security controls that are identified through the security risk assessment
Labeling
- Generate an SBOM to be shared with customers (and used to monitor for vulnerabilities)
- Cybersecurity documentation in labeling
Design Verification
- Penetration Testing
- Vulnerability Testing
- Verification of all security controls
Design Validation
- If applicable, validate that customer IT Staff have sufficient information in labeling to understand their security responsibilities
Maintenance
- Reporting security vulnerabilities that are identified
- Monitoring your SBOM for vulnerabilities
- On-going vulnerability testing
- On-going penetration testing
- Security updates

Security Risk Management 🔗

What is security risk management? 🔗

Security risk management is similar to safety risk management

TODO

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.

Venn diagram showing the relationship between security risk and safety risk. The FD&C Act, effective March 29, 2023, gave FDA jurisdiction to consider non-safety security risks.

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

Figure showing the relationship between a TIR57-compliant security risk-management process and an ISO 14971-compliant safety risk management process.

Is it okay to incorporate security risk management into safety risk management? 🔗

How should security risks be assessed? 🔗

Threat Modeling 🔗

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.

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 security risk management activities, as shown in the following diagram.

Not everyone would agree, but in our opinion, there’s not a useful distinction to be made between threat modeling and security risk management.

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.

Which threat modeling methodologies you suggest using? 🔗

In the FDA says the “rationale for the methodology(ies) selected should be provided with the threat modeling documentation.”

We suggest following the STRIDE or STRIDE + Attack Trees method for doing threat modeling. This is because the FDA-sponsored Threat Modeling Handbook mentions these methodologies, and thus, when justifying the threat-modeling methodology in your security management plan (which the FDA requires you to do), you can say that these were the methods suggested in the FDA's Threat Modeling Handbook.

How do you create a threat model? 🔗

Identify all major system items
- Examples: Backend Django App, AWS S3 Bucket, PACS, PostgreSQL Database
Create a system diagram, including connections
- These diagrams should show all the connections to external systems or networks
- We suggest also creating a flow diagram that shows how
- Example (from )
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
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.
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
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 are tightly integrated with design controls and safety risk management, and thus an external group will typically have a hard time incorporating their findings into the rest of the documentation.

What is the difference between a threat-oriented, asset/impact-oriented, and vulnerability oriented risk analysis approach? 🔗

Penetration Testing 🔗

What is penetration testing? 🔗

A penetration test (pen test) is an authorized simulated attack performed on a medical-device system to evaluate its security. Penetration testers act as if they were attackers to find and demonstrate the business impacts of weaknesses in a device. Penetration tests usually simulate a variety of attacks that could threaten a device, using the same tools, techniques, and processes that real hackers use.

Do all cyber devices need penetration testing? 🔗

No. FDA doesn’t require penetration testing, but they suggest considering it. We’ve not yet had FDA require it on a submission when we haven’t included it. If your device has higher security risks (e.g., it holds a lot of PHI or its used in a time-sensitive clinical workflows), then we suggest doing penetration testing.

Can we do the penetration testing ourselves? 🔗

FDA suggests that the penetration testing have a level of independence from the team that developed the software. The best way to accomplish this is to use a separate firm.

How should we evaluate vendors to do our penetration testing? 🔗

Here are some questions you may want to ask:

How much lead time do you need before you can do pen testing?
- This is important, since ideally you’ll do pen testing just before your submission and you don’t want a big delay to be a bottleneck.
Can you provide us a sample report?
- You will want to check that the pen testing report will include the following elements required by FDA:
  - Independence and technical expertise of testers;
  - Scope of testing;
  - Duration of testing;
  - Testing methods employed; and
  - Test results, findings, and observations.
Do you have discounts for doing repeated tests?
- Keep in mind you’ll likely be repeating the penetrating testing (e.g., annually), so it’s often helpful to have a single vendor you use.

Who are some good vendors to consider? 🔗

We’ve had clients use the following vendors:

Cobalt
- Quick startup time
Synopsys

How much does penetration testing cost? 🔗

It varies from vendor to vendor and based on the scope of the testing, but you can expect between $7k and $22k.

When should we do our penetration testing for a premarket submission? 🔗

Ideally, your penetrating testing will be done on the final version of the software that you’re submitting to FDA. This is because FDA recognizes that the results of penetration testing degrade over time. It’s never happened to us, but it’s possible that FDA could reject results that were done too long ago.

How often should we do penetrating testing? 🔗

We suggest documenting in your Security Management Plan when and how often you plan to do penetration testing. In the FDA guidance, they suggest repeating it periodically:

After release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually) to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited.

We generally suggest that if you need penetrating testing that you repeat it annually. That said, this would most likely be a finding in an audit, and wouldn’t affect your pre-market submissions.

How to Learn More 🔗

What FDA guidance apply to medical-device cybersecurity? 🔗

There are two essential FDA guidance documents that apply to medical devices:

2023 FDA Guidance - Cybersecurity in Medical Guidance: Quality System Considerations and Content of Premarket Submissions This guidance is a good place to start.
2016 FDA Guidance - Postmarket Management of Cybersecurity in Medical Devices This guidance goes into more detail about post-market surveillance, but there is overlap between the two.

There is also a short, older guidance about cybersecurity of OTS software.

What standards apply to medical-device cybersecurity? 🔗

The FDA has recognized several standards (search the FDA database using the “security” keyword and you can see most of them). The two we feel are the most relevant are:

AAMI TIR57:2016 Principles of medical device security—Risk management It describes how to create a security risk management process that’s similar to ISO14971 and interacts with the safety risk management process.
IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle It defines the activities you need to follow to build a secure device, similar to how IEC 62304 defines the activities you need to follow to build a safe device. The FDA suggests following a standard such as this in their 2023 guidance.

Medical Device Cybersecurity: Best Practices, FAQs, and Examples

Introduction 🔗