In this article, we will provide a general overview of Threat Modelling (why medical device manufacturers should use it, how it works and what the regulatory requirements are). Nowadays, Threat Modeling is a topic for all medical devices with embedded software or standalone software. This is because threat modeling is a structured process to analyse the cybersecurity risks that auditors consider to be “state of the art”.
Why should you use threat modeling?
There are several reasons why you should use threat modeling to analyze the IT security of your medical device.
Develop Secure Device
Threat modeling is a structured process that helps you to evaluate and mitigate cybersecurity risks and guarantee the IT security of your device.
Fulfilling legal requirements
IT security is not only an ethical question but also from the legal point of the view, the manufacturers are obligated to guarantee the security of their medical devices.
Speed up development and reduce costs
Usually, IT security costs money, and it becomes more expensive when vulnerabilities are found in a late stage of development or even when the device is already on the market. The sooner the manufacturer discovers vulnerabilities, the sooner it is more economic to fix them. This means manufacturers should integrate threat modeling as mandatory activity into their development process.
How does threat modeling work?
Scope and target
The first step is to define the scope and the subject of the threat modeling. This step is very important to analyze at a great level of detail, the possible vulnerabilities of the medical device developing a secure architecture.
Creating the model
The manufacturers need to put together all the elements of the medical device’s ecosystem, such as:
- System process
- Data flows
- External entities
- Data store
- Trust Boundaries
Picture: Threat Modeling
The table below explain all the type of entities that can be used to create a model:
Notation Element | Reference | Example |
 | External Entity | People (ex: users) Systems (ex: other devices) Cloud Services |
 | Process | DDL EXE Web Services Virtual Machine |
 | Data Storage | File Database Registry Cache Cookie |
 | Dataflows | Http Request CAN Bus UDP Communication Serial |
 | Trust Boundaries | Device boundary Process boundary |
The manufacturers should consider all the possible entities involved and usage scenarios of their devices, in this way the model can be considered effective.
Identify Threats
Once the model has been created, the identification of all the possible threats can start. Usually, this exercise is made using one of the most popular tool on the market Microsoft’s Threat Modeling Tool.
| Treat | Desired Property | Description |
| Spoofing | Authentication | Tricking a system into believing a falsified entity is a true entity |
| Tampering | Integrity | International modification of a system in an unauthorized way |
| Repudiation | Traceability/ Non-repudiation | Disputing the authenticity of an action taken |
| Information disclosure | Confidentiality | An attacker accesses data from the device while not begin authorized to see it |
| Denial of Service | Availability | An attacker absorbs or destroys resources of the devices needed to provide the intended service |
| Elevation of Privilege | Authorization | An attacker accesses functions of the device while not begin authorized to do it |
This step generates a list of threats that should be evaluated.
Vulnerabilities & Countermeasures
Not every potential threat has to result in measures begin taken. However, the manufacturer should provide a statement to justify the missing counter measure for that threat.
In case the risk is not acceptable, the manufacturer should define and implement a counter measure. There are standards actions for each threat according to the STRIDE classification:
| Mitigation Technique | Stride | Mitigation Control |
| Authentication | S | External devices have to authenticate themselves using X.509 certificates |
| Digital Signature | T | Secure Boot |
| Authorization | E | Device role is part of the certificates |
| De-identication | I | Pseudonymization |
| Filtering | I, T, D | Allow-List |
| Message authentication code | T | Append an HMCA to each Log Record |
| Physical tamper resistant | T | Protect the chassis of the device |
| Protect secrets and secret data | I, T | AES-256 Encryption |
| Input sanitization | I, T, D | Sanitize data received from external device |
| Least privileges | E | Role concept |
| Audit trail | R | Security Event Log |
It is in the responsibility of the manufacturer to define the correct measure for each possible threat.
Reviewing full implementation
Before releasing the medical devices, the manufacturer should ensure that all the defined counter measures have been implemented and their effectiveness demonstrated. This means that the counter measure should be easily tracked into the technical file and the effectiveness can be demonstrated having the relative penetration tests executed.
Continuous process
Threat modelling is not a straightforward one-time task, it should be an iterative process and after each iteration a retrospective should take place to check the completeness and effectiveness. The manufacturers should take in account that new threats and new attack techniques emerge over time.
What are the regulatory requirements for threat modeling?
Neither the MDR nor the FDA require explicitly manufactures to perform threat modeling, however they do require manufacturers to minimize IT security risks. A list of guidelines and playbook currently available:
- FDA sources on cybersecurity
- Playbook for Threat Modeling (FDA sponsored, but not official FDA guidance)
- MDCG 2019-16 rev. 1 “Guidance on Cybersecurity for medical devices”
- ISO/IEEE 11073-40101:2022 Health informatics — Device interoperability — Part 40101: Foundational — Cybersecurity — Processes for vulnerability assessment
- ISO/IEEE 11073-40102:2022 Health informatics — Device interoperability — Part 40102: Foundational — Cybersecurity — Capabilities for mitigation
All these documents mention threat modeling. This means manufacturers will have a hard time justifying not using threat modeling.
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: Alessandro Vitiello
Head of Software & Hardware at D.med Software