Threat modeling – An introduction

Threat modeling is a “mandatory” topic for all manufacturers of medical devices that contain or are software. This is because threat modeling is a structured process for the systematic analysis of IT security risks that auditors consider to be the “state of the art.”

1. Why should you use threat modeling?

Reason 1: To develop secure devices

Threat modeling helps you systematically find and eliminate cybersecurity risks and, therefore, enables you to guarantee the IT security of your devices.

As a result, you fulfill your ethical duties and ensure the security and safety of users, patients, and third parties. 

Reason 2: To fulfill legal requirements

You are not only ethically but also legally obligated to ensure the IT security of your devices.

Because threat modeling is a systematic process, using it in your submissions to authorities and notified bodies will help you convince them you have not overlooked any vulnerabilities.

Reason 3: To speed up development and reduce costs

IT security costs money. But it becomes even more expensive when vulnerabilities are identified too late and have to be fixed. In this case, there are additional costs for:

• The subsequent analysis of the vulnerabilities
• Eliminating the vulnerabilities (in the worst case, this involves a re-design of the device)
• Compensating any injured persons
• The legal consequences
• Restoring your own reputation

The sooner manufacturers discover vulnerabilities, the easier, quicker and more economic it is to fix them. This means manufacturers should be using threat modeling even during the development phase of a device.

Reason 4: Transparency and “peace of mind”

Threat modeling’s traceable and visual methodology creates transparency with regard to the security of your own device. This systematic approach allows you to be sure that you have fully identified and eliminated any risks. And that gives you “peace of mind”.

2. What notation elements are used?

As the name suggests, threat modeling works with models.

These models use few notation elements that are easy to learn:

Notation element	Reference	Examples
	External entity	People (e.g., users), systems (e.g., other devices), cloud services, browsers
	Process	DDL, exe(D)COM, web service, virtual machine, threat
	Data store	File, database, registry, cache, cookie
	Data flow	http request or response, remote procedure call, UDP communication
	Trust boundary (inside you trust the processes and data stores, outside you don’t)	Device boundary, process boundary

3. How does threat modeling work?

Stage 1: Establishing the scope and target

First of all, you have to define the scope and object of the threat modeling. Are you trying to model the vulnerabilities of a web service or those of the whole server? Is the threat modeling intended to demonstrate the security of a device or to help you design a secure system architecture?

Stage 2: Creating the model

Manufacturers need to put together all the elements to create the model. Specifically, these are:

• System processes
• System data stores
• Intended and all undesired external entities (e.g., attackers)
• Possible, i.e., intended and undesired, data flows between entities, processes, and data stores

Manufacturers should then use trust boundaries to separate the system elements (processes, data stores) from the other elements they consider trustworthy. For a physical medical device, all the elements within the device are generally considered trustworthy.

This step will result in a model like the one shown in Figure 1.

Stage 3: Identifying potential threats

Once you have created the model, you can use it to automatically work out the potential threats using a tool like Microsoft’s Threat Modeling Tool.

Otherwise, manufacturers have to identify the threats themselves manually. The threats can then be assigned to the following classes following the STRIDE model:

	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	Malware encrypts data
R	Repudiation	Denying having done something	A user denies that they treated the patient with the device using certain parameters
I	Information disclosure	Confidential information is displayed to unauthorized people	A nurse can see the diagnosis of a VIP patient whose treatment she is not involved in and whose data she should not be able to see
D	Denial of service	DoS attack	A bot network floods a web server with http requests
E	Elevation of privilege	A person or system obtains privileges they/it should not have	A user manages to make themselves an administrator of a system

This step will result in a list of threats.

Stage 4: Evaluating threats

Not every potential threat has to result in measures being taken. However, as a manufacturer, you have to be able to provide a justification if you decide not to define any measures for a potential threat.

A possible justification could be that a compromised system cannot result in harm to a patient or third party. The probability of a device actually being compromised being negligible could also be used as a justification.

Stage 5: Defining and implementing countermeasures

If the risks are not acceptable, you need to define countermeasures. There are standard actions for each threat class (according to STRIDE):

Attack class	Examples of actions
Spoofing	Authentication, e.g., with Kerberos
Tampering	Digital signatures
Repudiation	Secure audit logs
Information disclosure	Encryption
Denial of service	Request filtering
Elevation of privilege	Access control lists (ACLs)

It is the responsibility of the manufacturer to define these measures, for example, as system or component requirements. This will ensure:

1. These measures are actually implemented
2. This implementation as well as the effectiveness of the measure is verified

Stage 6: Reviewing full implementation

Before releasing your medical device at least, you should ensure that all the defined measures have been implemented and their effectiveness demonstrated.

This does not mean checking the IT security of your device again but rather checking the conformity of your IT security process (also known as the secure development lifecycle).

You should reflect on your approach at this point. If necessary, adapt your process, procedure and work instructions and tools, and/or improve your team’s training. The seminar on IT security may be helpful for ensuring that your employees’ skills meet the legal requirements.

4. What do you need to take into account when threat modeling?

Tip 1: IT security is a continuous process

Threat modeling is not a one-off activity. It should be repeated regularly, especially if you modify your device or data (e.g., from post-market surveillance) suggest it.

Tip 2: Don’t forget analytical quality assurance

Threat modeling is part of constructive quality assurance. This is the part of quality assurance (QA) that focuses on preventing errors. Constructive QA must be complemented by analytical QA, which focuses on finding errors. This includes, for example, penetration testing of devices.

Tip 3: Use tools

Tools, such as Microsoft’s Threat Modeling Tool, help you systematically find potential threats to your devices and systems. They also make it easier for you to document and track your decisions regarding countermeasures.

We recommend using ALM tools, e.g. the tool of Medsoto to track and verify defined countermeasures.

5. What are the regulatory requirements for threat modeling?

Neither the MDR nor the IVDR nor the Food Drug and Cosmetic Act in the USA require manufacturers to perform threat modeling. However, they do require manufacturers to minimize IT security risks.

For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

MDR Annex I Paragraph 17.1

This “state of the art” is described in standards and guidelines such as:

• The Johner Institute’s IT Security Guideline
• FDA sources on cybersecurity
• Playbook for Threat Modeling (FDA sponsored, but not official FDA guidance)
• Standard IEC 81001-5-1 on health software and health IT systems safety, effectiveness and security
• MDCG 2019-16 rev. 1 “Guidance on Cybersecurity for medical devices”

All these documents mention threat modeling. This means manufacturers will have a hard time justifying not using threat modeling.

6. Conclusion

The fundamentals of threat modeling can be learned quickly, in part because there are good tools and the modeling language only involves few notational elements.

The system provides manufacturers, as well as notified bodies and regulatory authorities, with the necessary confidence in the IT security of the medical device.

Therefore, threat modeling should be an indispensable part of the secure development life cycle for all medical devices that are or contain software.