Business Insights readers are certainly well aware of the sorry state of connected medical device security. We’ve covered it in posts such as St. Jude Takes Steps to Secure Vulnerable Medical Implants and U.S. DHS and FDA Face Medical Device Security Woes. In the later post we covered how the FDA is working to foster a culture of continuous quality improvement.
This is something the FDA appears to be very dedicated to encouraging.
In my view, medical device makers had better foster their own culture of continuous device security improvement. If they don’t do this on their own, eventually, governments are going to do it through regulation.
As for now, the FDA is pleading with the industry to do voluntarily what the broader software industry has yet to be able to do on its own — and that’s ensure products are designed, built, and managed securely. “A computer virus or hack resulting in the loss of or unauthorized use of data is one thing. A breach that potentially impacts the safety and effectiveness of a medical device can threaten the health and safety of an individual or patients using the device,” says the FDA’s Suzanne Schwarz in her essay FDA’s Role in Medical Device Cybersecurity.
“A computer virus or hack resulting in the loss of or unauthorized use of data is one thing. A breach that potentially impacts the safety and effectiveness of a medical device can threaten the health and safety of an individual or patients using the device,” she continues in the FDA blog, FDA Voice.
I couldn’t agree more.
As Schwartz explains in her essay, because cybersecurity threats are a constant, manufacturers, hospitals, and other facilities must work to prevent them. There is a need to balance protecting patient safety and promoting the development of innovative technologies and improved device performance.
This must start with medical device makers. And they must bake it into their DNA. Device makers have to not only design devices that can’t be readily hacked, and can be authenticated so that only authorized users can access the device; and they must be designed to be easily supportable in the field. They have to be designed in a way so, when necessary, the software and firmware can be updated so that the device is adequately hardened.
The FDA agrees, as Schwartz wrote: “This means taking a total product lifecycle approach, starting at the product design phase when we build in security to help foil potential risks, followed by having a plan in place for managing any risks that might emerge, and planning for how to reduce the likelihood of future risks.”
This is absolutely essential when it comes to medical devices. Security researchers and criminals alike will likely find flaws in these devices long after they shipped. And many of these devices are embedded in the bodies of patients. Having a plan in place to manage and secure these devices in the field is essential.
Late last year the FDA wrote a guide for the industry to do just that, Postmarket Management of Cybersecurity in Medical Devices [.pdf]. In addition to the specific recommendations contained in this guidance, manufacturers are encouraged to address cybersecurity throughout the product lifecycle, including during design, development, production, distribution, deployment and maintenance of the device.
The FDA postmarket management guide emphasizes that manufacturers should monitor, identify, and address cybersecurity vulnerabilities and exploits as part of their postmarket management of medical devices. The guidance also claims to establish a risk-based framework for assessing when medical device changes related to vulnerabilities are reportable back to the FDA.
Hopefully, those in the industry not only read it, but learn to live it. Somehow, however, I don’t think that’s how medical device security and the after-market handling of security issues will play out in the future. The software industry, for instance, has forever been used to supporting software after-market and has had a very challenging time getting this right.
This is a Security Bloggers Network syndicated blog post authored by George V. Hulme. Read the original post at: Business Insights In Virtualization and Cloud Security