The daily news on cyber attacks and system vulnerabilities have become overwhelming. Recently, the US FDA decided to force a recall on a pacemaker. The firmware of the device in question was found to be vulnerable to cybersecurity exploits, which could allow an unauthorized user to access a patient's device using commercially available equipment. Such access could be used to modify programming commands to the implanted pacemaker, resulting in patient harm from rapid battery depletion or from administration of inappropriate pacing. As part of the recall, the firmware of the pacemaker needs to be updated via an in-person patient visit with a health care provider. (Read more)
Another demonstration of hacking into a medical device, taking over its control, was performed by Barnaby Jack. He demonstrated taking control of a wireless insulin pump of his diabetic friend. In a test set up with the same pump model, he obtained complete control of the pumps. He set the pump to repeatedly deliver its maximum dose of 25 units until its entire reservoir of 300 units was depleted. Real life delivery into a typical patient would exceed many times the lethal dose.
The above examples show the impact that exploiting vulnerabilities of medical devices over IT-networks can have on patient’s safety. I could not agree more with the statement that a well-designed device and IT-network architecture is key for the continuity of virtually all organizations today. Attacking medical devices over IT-networks will not stop.
In my latest blog on the impact of the GDPR on medical devices in IT-environments that process personal data, the three domains in which manufacturers must perform risk management activities for their medical devices were debated. As said, manufacturers must now act in the following domains:
- security; and
In this blog, I will go into the integration of safety and security risk management in your design of medical device connected to IT-networks.
How to integrate security and safety Risk Management?
The easiest way to integrate security and safety might be to apply AAMI TIR 57 - Principles for medical device security - Risk management.
TIR 57 suggest a security risk management process that fully matches the risk management process from ISO 14971:2007, adopting the principles of IEC 80001 1 Application of risk management for IT-networks incorporating medical devices. TIR 57 recommends the creation of a separate risk analysis process focused specifically on impacts that are identified by a security analysis. I personally think, however, that the security risk management process can just as easily be integrated into your existing safety risk management process, adopting security into your current risk management file, i.e. plan, hazard analysis and report.
TIR 57 nicely explains the interrelation of the security and safety risk processes: when the safety risk process arrives at the stage of implementing risk controls, the impact on the security risks should be analyzed and vice versa. By using step 6.6 (risks arising from risk control measures) of ISO 14971 for this purpose, security risks can be integrated into for example your existing FMEA.
Security risk estimation follows the same principle as safety risk estimation. A security risk is the result of the likelihood of a vulnerability (hazardous situation) being exploited and the likelihood of this vulnerability breach (hazardous situation) leading to an impact (severity) on your critical assets, like health data in databases, computer hardware or patients.
What are Security Risk Controls?
The IEC 80001 series of Technical Reports provide a rich source for this purpose. Particularly, TR 2 2 Guidance communication security needs, risks, and controls provides a wealth of information that could make life easier for manufacturers. TR 2 2 provides a solid base for implementing security capabilities into your medical device application.
TR 2 2 creates a structured framework and naming convention for the disclosure and communication between the manufacturer, the health provider and the IT-vendor. The capabilities present an informative set of common, high-level security-related capabilities, useful in understanding the user needs, the type of security controls to be considered and the risks that lead to the control. The controls support the maintenance of confidentiality and the protection from malicious intrusion that might lead to compromises in integrity or system/data availability.
The US FDA has recognized TR 2 2 (Recognition #13-42). TR 2-2 is applicable for
any product code which describes a networkable medical device. In the FDA guidance for Premarket Submissions for Management of Cybersecurity in Medical Devices Guidance Issued on:
October 2, 2014, TR 2-2 is also referenced. This guidance provides a means for medical device manufacturers to write their premarket submissions. Manufacturers need to include a Manufacturer Disclosure Statement for Medical Device Security (MDS2), see HIMSS/NEMA HN1 clause 1.1.2, in their premarket submissions. The MDS2 is aligned with IEC 80001 1and TR -2-2. The MDS2 form addresses all 19 security capabilities defined in TR 2-2.
How does cybersecurity relate to GDPR?
As said, this blog is part of a series of blogs and in an upcoming blog, I will go deeper into the Data Protection Impact Assessment (DPIA) required by the General Data Protect Regulation (GDPR (EU) 2016/679). Controls defined in the DPIA can also be (cyber)security risks controls as I have discussed above. Security risk controls can thus be part of privacy risk management.
In my next blogs, I will go deeper into that subject and other related fields:
- Privacy Risk Management and Data Protection Impact Assessment;
- Processes that define the responsibilities and trigger the activities that generate your GDPR compliance files;
- Contract requirements of the GDPR.
If you require support or resources, do not hesitate to contact Qserve’s team of experts.