Why Cybersecurity in Medical Devices?
With the increasing number of connected services and the advent of IoT era, the risk of cybersecurity attacks is higher than ever (some key statistics: https://www.varonis.com/blog/cybersecurity-statistics/). Medical devices and services are not spared by this threat (https://www.nbcnews.com/tech/security/cyberattack-hits-major-u-s-hospital-system-n1241254) and consequences of an attack on your device can be disastrous:
- Risks for patients’ safety
- Risk of patient data theft
- Recall of your product (e.g., https://www.fda.gov/medical-devices/medical-device-recalls/medtronic-recalls-remote-controllers-minimed-insulin-pumps-potential-cybersecurity-risks) with dramatic consequences for your company’s reputation and return merchandise authorization (RMA) costs.
After being neglected for a long time, Cybersecurity is now a critical part of every project. When starting a new project, you must now keep in mind that Cybersecurity is not a feature that you can add (or forget to add!) at the end, it must be considered at a very early stage of your product design and integrated into your development process.
A lot of companies do not know where to start when dealing with Cybersecurity. The US Food and Drug Administration (FDA) published several guidance:
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
- Postmarket Management of Cybersecurity in Medical Devices
but today’s most complete reference is UL 2900-1 Cybersecurity Standard for Medical Devices.
Based on our experience, we will share a series of articles that provide some best practices which can be applied to develop more secure medical systems.
Threat Modeling: A Method to Identify, Communicate, and Understand Threats and Mitigations of Your Medical Systems
The first step is to list and quantify potential threats in order to identify and implement the mitigations that will protect your system. This is done by creating a Threat Model, a means to visually represent all the elements that will affect the security of a system.
Threat Model must include physical ports, internal and external communications mechanisms, and more generally all valuable assets of your device. For each of them, you need to identify threats relevant to your system. A typical approach consists in using an existing model such as STRIDE or alternatives like LINDDUN or CIA Triad for example.
When using STRIDE, for each identified asset, you must evaluate the consequences of:
- Spoofing: The device/service/user is not the one it’s supposed to be, like in Man-in-the-Middle attacks
- Tampering: Illegal access to your device, with hardware or software modifications)
- Repudiation: Claiming to have not performed an action
- Information disclosure: Expose sensitive information about your device or private data
- Denial of service: The device doesn’t work as expected
- Elevation of privilege: Gaining capabilities without authorization
Then for each threat, a severity score must be determined to prioritize and mitigate them. Among existing scoring systems, the most broadly used is the Common Vulnerability Scoring System (CVSS), a standard commissioned by US National Infrastructure Advisory Council (NIAC) in 2005 and maintained by the international Forum for Incident Response and Security Teams (FIRST). Another usable scoring system is DREAD, simpler than CVSS but it will provide a less detailed image of the exact nature of the vulnerability and risk.
Dedicated tools exist to help with the threat modeling process, like “Microsoft Threat Modeling tool” or OWASP “Threat Dragon”. These tools will help you to graphically model your system, identify threats using STRIDE and generate a report.
Figure 1: Threat model example using MS Threat Modeling
Figure 2: Threat identification and mitigation
Risk Management and RCMs
In your Risk Management File, we suggest to clearly distinguish the management of the risks related to safety and the management of the risks related to security. The new draft of the IEC 62304 actually requires this distinction, and introduces a separate process “for managing RISKS associated with SECURITY“ along with the term “RISK CONTROL (SECURITY) measure”.
The list of threats that will need to be addressed depends on your Security Risk Management process: you could decide to address all of them, or only the ones above a certain scoring. This process must be defined as early as possible and be integrated into your development process.
The reports generated during the threat modeling phase shall be used as an input to your risk management assessment and guide you through the definition of your Risk Control Measures (RCM) and Software Requirement Specifications (SRS).
Preview of Part 2
In the second part of our series of articles on cybersecurity in medical devices, we will talk about Common Vulnerabilities and Exposures (CVEs). If you use off the shelf software in your medical device, the CVE analysis is an essential activity that you must perform in order to reduce the chances of an attacker being able to break into your device. Stay tuned!