Beth Israel Deaconess has been outspoken about the risks of malware on FDA 510k approved medical devices such as radiology workstations, echocardiogram machines, and patient monitors.
Although these devices appear to be "appliances" that you simply plug into the network and use for patient care, they are actually sophisticated computers, often running outdated versions of operating systems and applications that are not resilient against purposeful attacks.
For example, we have devices from a major manufacturer that internally use Windows NT as the operating system and Apache 1.0 as the web server. Patches are no longer available for these old versions of software and they cannot be updated to protect them from malware. Instead, we build hardware firewalls around the devices, creating "zero day" protection which mitigates risk by preventing internet-based attacks from reaching the devices.
In the past, manufacturers have claimed they cannot upgrade or patch software to enhance security because changing the device would trigger a new FDA 501k approval process.
Hence they have left the protection of the devices to the CIOs who manage hospital technology infrastructure.
In the past, when I've asked major device manufacturers to provide me a functional diagram of the ports and protocols used by their products that would enable me create tightly controlled firewalls, I've been told that the manufacturers do not have this information.
I've spoken to the FDA about this issue and they have advised me that device manufacturers have a responsibility to secure their products and there is no 510k re-certification needed when security patches are added. The FDA has wisely stated that there is shared responsibility. Device manufacturers must coordinate the updates and changes with hospital IT leaders and business owners. We have had circumstances where manufacturers serviced devices without IT knowledge and left them in a vulnerable state.
In November 2009, the FDA issued Reminder from FDA: Cybersecurity for Networked Medical Devices is a Shared Responsibility that reminded device manufacturers, hospitals, medical device users facilities, healthcare IT and procurement staff, medical device users, and biomedical engineers of the 2005 guidance as well as simple ways to protect against cybersecurity threats.
I've also talked to the FDA about including security penetration testing in the 510k process so that devices cannot be brought to market unless they are secure at baseline.
They have assured me that such regulations are in the planning phase. It is true that existing FDA regulations for device safety and efficacy never presumed that purposeful malware attacks would be an issue.
Here are other valuable references from the FDA
FDA issued guidance in 2005, Guidance to Industry – Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software which answers question about pre-market review as well as other manufacturer responsibilities, such as validating software changes before releasing them.
At the same time as the guidance, the FDA issued Information for healthcare organizations about FDA’s “Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” that describes FDA’s concerns about cybersecurity and what the guidance document covers.
In April 2005, the FDA hosted a webinar on the cybersecurity. The transcript is available here.
If your device manufacture claims the device cannot be patched due to FDA restrictions, refer them to these references and demand that devices be secured in collaboration with hospital IT staff and business owners. It a world of escalating malware, manufacturers have a duty to keep devices secure and safe.
Good topic indeed. A few years ago I ran into a CT scanner that had an NT workstation on premise where I was writing some custom apps to pull the data and integrate. It was an older 16 bit and new models were updated but yes the manufacturer did not have an update for the software which ran through a DOS link. Newer systems of course don't have this configuration but the work station was on the company network, so you isolate as best you can and restrict via group policy but not bullet proof at all.
ReplyDeleteThe manufacturer of the CT was an acquisition of another company and had no real intentions to sink any money into their older installations, so yes a concern with some of the older workstations out there.
This is an excellent post and is massively overdue. As a former healthcare IT worker in a small community hospital, I can confirm the extreme aversion of manufacturers - whether of hardware, software, or both - to accept the responsibilities which come through the use of off-the-shelf components.
ReplyDeleteI found the following sentence in the linked MIT Technology Review article particularly galling: "The computer systems at fault in the monitors were replaced several months ago by the manufacturer, Philips; the new systems, based on Windows XP, have better protections and the problem has been solved". Has Philips (or Mark Olsen) checked Microsoft's end-of-life schedule? (http://windows.microsoft.com/en-us/windows/products/lifecycle#section_2) Windows XP will no longer receive support (i.e., patches) after April 8th, 2014.
Why is a vendor being allowed to roll out an already-obsolete and soon to be ineffective "fix?" It is the responsibility of institutions to fact-check their vendor's actions and demand realistic solutions to what are very real problems.
I am interested if your Health Systems BioMed and Clinical Engineering Department report to you or to the COO via facilities?
ReplyDeleteWhen we do HIPAA risk assessments and help Health Systems work through their risk management program around medical equipment, it can be a challenge to get departments to agree on a course of action.
Excellent! We've gone through the same issue with modalities and received the same line from vendors about fictitious restrictions placed on them by the FDA.
ReplyDeleteNever one to enjoy being lied to, I found the same references you helpfully provided here and called the FDA to receive confirmation from their application security folks.
In further negotiations with vendors we leveraged our talks with the FDA to achieve...nothing.
Why? Because without leadership buy-in like exists at Beth-Israel, all we can do is make ourselves aware of the risk and present it to those who will then own it.
Still, would have been cool if we could have really achieved something
This hits close to home. I always felt it is one of perspective. The manufacturers typically sell around IT and directly to physicians and department heads. They view their value is providing a turnkey system where IT doesn't have to be involved and provide support. When IT wants to introduce some control, the manufacturers cite root access is needed in order to support the system, which essentially lets them bypass change control. If these ran on proprietary OS's impervious to malware, I would feel better about those scenarios. Most manufacturers are not agile/flexible/setup to support the IT diversity and needs of their customers IT departments. Unfortunately, the typical end-user only cares about system functionality and not the underlying plumbing, security, infrastructure, etc. We always weighted these things to provide an overall picture to ensure a fully educated decision was made re: system selections.
ReplyDeleteWe did quite a bit of vendor-independent work at HIMSS on this topic in the mid-2000's and created the Manufacturers Disclosure Statement on Medical Device Security (MDS2). Currently MITA/NEMA is organizing an update to the MDS2.
ReplyDeleteA couple of years back I ran directly into a CT scanner which had some sort of NT workstation upon principle just where I ended up being authorship some custom apps to extract the data and incorporate. It ended up being some kind of older 16 bit and brand new versions had been up-to-date but yes the manufacturer would not have a update for the software which ran thru a 2 link. Newer systems naturally don't have this setup but the work station ended up being in the business system, so you isolate because ideal you can easily and additionally restrict via group policy yet not bullet proof at every.
ReplyDeletemore information
Nice write-up and straight to the point.
ReplyDeleteThe 510(k) argument used by medical devices manufacturers is not completely unfounded. The need for a 510(k) re-submission is dependent on the "magnitude" of the operated change. While a security patch does not warrant a re-submission, other type of changes to accommodate security concerns might require that.
Another issue for the manufacturers would be the compatibility of the OS with their device SW application and the amount of verification and validation required to ensure the device remains safe and effective.