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.
Additional information
This article on regulatory requirements regarding the IT security of medical devices will provide you with an overview of laws, directives, standards and other requirements that you have to follow.
Learn more on the regulatory requirements specific to threat modeling below.
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:
- These measures are actually implemented
- This implementation as well as the effectiveness of the measure is verified
Tip
You can find not only a comprehensive introduction to medical device IT security but also a series of videos on threat modeling, including a comprehensive list of measures for each threat type, in the training videos on Auditgarant.
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 (German) 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
You can largely outsource post-market surveillance to the Johner Institute. Our Post-Market Radar continuously checks IT security databases and alerts you if there is an entry relevant to you among the thousands of notifications per month.
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
Ask the Johner Institute's IT security experts if you need assistance with penetration testing. You can contact us easily using the web form.
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.
Author:
Prof. Dr. Christian Johner
Back To Top
Privacy settings
We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.