Stop the insanity. Stop sensationalism of medical device security.

I am tired of hearing about medical device security "news" chuck full of sensationalism and hyperbole.  You don't have to shout that the sky is falling.  It's not.  Yes, there are real cybersecurity problems for medical devices that need innovative engineering and policy solutions.  But there is no reason to panic or run for the hills in fright.  Even though it's Halloween.  The latest example is an abstract at the Medical Device Connectivity Conference that I did not write.  I was aghast when I read what the conference had written as a placeholder for my talk on medical device security, as I have no intention to play the doom-and-gloom card about hacking medical devices.  Yes, medical devices can be hacked. Surprise. Yes, it's important to share the facts for science and engineering. But let's focus our attention on improving public health rather than what sells headlines.  Here's the revised abstract that will appear in a reprint.

Medical Device Cybersecurity: The First 164 Years

By Kevin Fu, 4th Annual Medical Device Connectivity Conference & Exhibition, Joseph B. Martin Conference Center at Harvard Medical School, Boston, MA, Nov 1, 2012. 

We've all seen the news stories about hacking implanted pacemakers and patient worn insulin pumps.  However, what keeps me up at night is a more mundane security problem: unavailability of patient care.  When conventional malware shuts down a cath lab, seriously ill patients can be subjected to unnecessary risk of transport.  When a medical system is not available for use, patients do not receive the quality of care they deserve.  This presentation will explore the risks, realities and countermeasures of medical device system security. Systems considered will range from purpose-built systems like pacemakers and programmers to embedded system medical devices interconnected on enterprise wide IT infrastructures. The effectiveness of current methods, tools and countermeasures will be discussed, with an emphasis on continuing gaps and vulnerabilities. Best practices for manufacturers and providers will be presented, as well as predictions on emerging risks.

If you can't wait until Thursday, then you can skim a related talk on regulatory responsibilities for medical device security that I gave yesterday at the Regulatory Affairs Professionals Society in Seattle.  There's no reason to panic.  Just be informed and commit to improving the cybersecurity of increasingly interconnected medical devices.

False: FDA does not allow software security patches

[Note the sarcasm in my title.  In fact, FDA guidelines promote keeping COTS software up-to-date.]

[Update: Way to go, NBC and TechNewsDaily!  Congrats on spreading false information that "under the current law, software used to run medical devices...must remain static." Totally false.  NBC should admit and correct the mistake. Hire some fact checkers or journalists! And get some more J.J. Abrams shows too. They can help you fact check.]

Manufacturers ought to provide regular software updates to address known security risks in medical devices that utilize off-the-shelf software like Windows XP, OS2, Linux, etc. Some do.  Some don't.  The next time a manufacturer refuses to issue a software update for a known security problem in your hospital computing systems, send them this blog entry.

False: FDA does not allow software security patches

I often hear complaints based on half-truths that "FDA does not allow software security patches."  False. (See my previous rant about compounder software.)  Let me get to why I say "half" true in a moment. Cybersecurity documents from FDA state that:

The need to be alert and responsive to cybersecurity issues is part of the device manufacturer’s obligation...Software patches and updates are essential to the continued safe and effective performance of medical devices. Typically, FDA approval is not required before install changes, updates, or patches that address cybersecurity issues (see question #10 of the guidance).

Ok, you're with me right?  FDA explicitly says that manufactures should issue software patches to address cybersecurity problems.

Most cybersecurity patches fall below the threshold for FDA review

In 2005, FDA issued what I consider "basic survival" guidance on cybersecurity of medical devices that depend on "off-the-shelf" software.  It's not perfect, but it's explicit on some topics.  John Murray of FDA's Office of Compliance later said:

Another question that always comes up is; I’ve gotten calls from users and they’ve said they’ve call the device manufacturer and the device manufacturer says, “I can’t do anything, I have to get FDA approval.” So we went back and examined this question and the answer is that pre-market review of a software patch or a cybersecurity update, usually does not require and FDA pre-market approval.

In 2004, John Murray spoke before a special HHS committee on medical device cybersecurity, the risks/benefits of network connectivity, and the cybersecurity challenges facing FDA:

FDA premarket review is rarely required prior to implementation of a software patch.  FDA has previously published detailed guidance on when FDA review of a design change is required, and most cybersecurity patches fall below the threshold for FDA review. 

True: Software updates are still complex to manufacture and manage

Ok, so why do manufacturers make the dubious claim that "FDA rules" prevent them from issuing software updates?  I think there are at least a couple rational reasons.

First, regression testing, validation, and other good manufacturing practices are non-trivial. It can take a heck of a lot of work to perform testing. The last thing a manufacturer wants to do is accidentally brick a medical device with an errant update. Remember back in college when getting code to compile was the last step of success? Yeah, well good manufacturing goes a wee bit further. Back when I worked in the software industry, the savvy software engineers ran automated regression tests every night and sometimes even after each new commit of code to the source repository. I imagine most medical manufacturers have such automated testing suites, but it still poses non-trivial challenges. How do you automatically validate things that connect to non-deterministic patients? Moreover, how do you perform testing on a component that will interoperate with other unknown components from different manufacturers? On modern medical devices, it's not feasible to "check the behavior of a complicated device to every possible, conceivable kind of input." A whole discipline of system engineering exists to help tame such complexity.

A second likely reason is that guidance documents are peppered with conditional language open to interpretation.  If you want to scare a regulatory affairs specialist, just add a bunch of implicit "if" or "unless" conditional branch statements.  So what happens when a risk-averse decider sees a statement like "rarely does..." or "if X, then cybersecurity updates do not require pre-market review"?  Ah, to be safe, let's just assume !X.  Therefore, the dubious claim comes true.  Not sure how to fix this one. Manufacturers: listen to your engineers. FDA: make your guidance less fuzzy.

I hope legislation is not necessary to solve these engineering and economic incentive problems.

Do the right thing.  If.  Unless.  So report me, maybe.

In summary, the absolute claim that "FDA rules prevent software security patches" is false. But there is a half truth hiding behind the sentiment. The rules are sufficiently fuzzy to cause misunderstandings and unintended interpretations. A manufacturer needs to plan ahead for these foreseeable cybersecurity risks, and budget for the inevitable software updates and regular maintenance.   Hospitals need to ask for and pay for the services for regular and timely security patches.  There's no perfect engineering solution, but not issuing any security patches for medical devices running on antiquated Windows XP is a decidedly unhelpful approach.

Your Homework

Go read the presentations from FDA on the topic of software updates.  I know of one hospital that uses these slides to confront manufacturers unwilling to issue security patches.

• "ECRI Audio Conference. Virtual Patient Safety: Worms, Viruses and Other Threats to Computer-Based Medical Technology" by Alford Taylor, FDA CDRH, November 2003.
• "FDA Regulatory Perspectives: Presented to the Philadelphia Area Medical Instrumentation Association" by Alford Taylor, FDA CDRH, February 2004.
• "Medical Product Software Development and FDA Regulations" by Cark Wyrwa, IEEE Orange County Computer Society, March 2006.

Malware in hospitals? Time to come clean.

I receive phone calls from hard working clinical engineers, physicians, and IT specialists in hospitals asking what they can do about the relentless malware in their "user facilities." Some relay anecdotes as gallows humor, others are downright fed up. At some point in every call, I raise the provocative question: "So, how many voluntary MedWatch Form 3500s did you file on these security problems on medical devices that could lead to patient harm?"

In all cases, the callers cite various disincentives for reporting.  The reasons range from despair to workload to fear.  Despair because there's a feeling of hopelessness that reporting a problem would have little chance of being read (well, that's self-fulfilling).  Workload because it's unrealistic to expect a health care professional to interrupt the busy clinical workflow to file a voluntary and tedious MedWatch report on an engineering problem.  Fear because whereas there's elements of immunity for reporting "near miss" safety issues in the avionics community, there is no such immunity for voluntarily reporting a "near miss" in the medical world.  There are plenty more reasons that contribute to FUD and the classic bad-news diode, but unfortunately there are few incentives to officially report security problems other than "patients deserve better."

So...all my frustrated and overworked colleagues in healthcare delivery who wish to see safety and security improvements in medical device software for patient care: send me your security anecdotes!  Tell me about what devices are prone to infection in your user facilities.  Tell me what devices are more resistant.  Tell me what manufacturers you feel do a good job at implementing a total lifecycle management for medical device software.  I have already received database entries of malware infections in clinical settings, and this data is helping to raise awareness to the most problematic devices.  It sure would be nice to have some positive examples too.

I'm also looking for photographs of interesting security failure modes on medical devices to help illustrate the problem.   A radiology workstation with a BSOD or Windows 95 logo?  Virus warnings on a compounder? A cath lab shutdown for decontamination of malware?  If you see a malfunctioning or compromised medical device, consider sending me a photo.  Your report of medical device security problems can make a difference in improving patient outcomes!

Symantec speaks out on GAO medical device security report

Axel Wirth of Symantec has written an article about the recent GAO medical device security recommendations.  While praises the execution of the study, he points out that the problems identified in the report represent just the tip of the iceberg.  Here's a snippet from Symantec:

However, there is another set of risks to consider. As discussed above, the GAO report analyses the security risks of these compact, resource-restrained implantable devices. This is, of course, critical given the device’s impact on patient health and potentially, life or death. But the medical device infrastructure of healthcare systems and hospitals is far more complex. It includes a wide range of medical devices from simple to complex, from small to large, built on proprietary platforms or based on commercial, off-the-shelf software (COTS). The latter introduces its own set of risks through a “PC under the hood” design approach since the commercial operating systems or other software can easily become an entry point for malware, whether it targets the specific device or generally exploits a vulnerability specific to the chosen platform with the device then becoming “collateral damage”.

In effect, Symantec is asking whether the scope of the GAO report was too narrow to capture a generalizable set of lessons about the ecosystem of medical device security risks.  The implication?  The medical device security iceberg is much bigger that the GAO report would indicate.

Ask experts about improving security for medical devices

What questions do you have for the GAO, FDA, and hospitals regarding recent GAO recommendations to improve medical device security?

I will be moderating a federal panel that will brief the NIST ISPAB (Information Security and Privacy Advisory Board) on the recently published GAO report on security of "certain" medical devices. See the ISPAB agenda or the Federal Register for details on this October 11 panel in DC.  The panelists include:

• Vijay D'Sousa, Assistant Director, U.S. Government Accountability Office (GAO) Information Technology
• Brian Fitzgerald, Deputy Director, U.S. FDA CDRH OSEL Division of Electrical and Software Engineering
• Kevin Fu, Associate Professor, University of Michigan/Massachusetts Computer Science & Engineering (moderator)
• Mark Olson, Chief Information Security Officer (CISO), Beth Israel Deaconess Medical Center

If you have a burning question, please post it in the comments here.  Or if you are bashful, send your question to me directly.  I will attempt to raise the suggested topics during the panel, and post the discussion audio on a later blog post.