Washington Post investigates cybersecurity issues for health care

To ring in the holidays, the Washington Post discusses security vulnerabilities in health care computing.  While all computing systems have risks and benefits, this article describes the risks in the context of other sectors such as the financial industry.

“I have never seen an industry with more gaping security holes,” said Avi Rubin, a computer scientist and technical director of the Information Security Institute at Johns Hopkins University. “If our financial industry regarded security the way the health-care sector does, I would stuff my cash in a mattress under my bed.”

Let's not run for the hills yet though.  The good news is that, in private, many stakeholders agree there's a problem that needs fixing.  It's a start.  Time to make some New Year resolutions for improved medical device security.

Dr. Fu Goes to Washington

This morning, I testified in Congress on technology to combat waste, fraud and abuse in the Medicare program. My testimony focused on the expectations of smart cards. The testimony can be downloaded from the House website. I noticed an odd filename that legislators assigned to my testimony. Seems reminiscent of Arnold Schwarzenegger, but hopefully unintentional.


Here are some summaries:

• GOP lawmaker calls for tougher fight against Medicare fraud
• Uncle Sam Wants To Stop Healthcare Fraud, But Smart Cards Are No Panacea

Videos:

• Video of testimony
• Video of Q/A

Earlier thoughts.

U.S. House Hearing on Smart Cards and Health Care Fraud

This Wednesday, I'll be testifying in a U.S. House hearing to examine options to combat health care waste, fraud and abuse. This service has rustled up memories of my time as a tech gopher at Holland Community Hospital in the 1990s when the hospital deployed second-factor authentication tokens for clinicians (i.e., 2nd factor = something you have rather than something you know). One of my tasks was to write software to quickly and effectively detect incorrect entries in the hospital's voluminous general ledger. Medical billing records. So exciting. I remember replacing lost "authentication keys" for nurses and physicians who would visit my tiny time-shared desk next to machine room for the soon-to-be-retired VAXen, line printer, and reel-to-reel backup. At the time, the authentication keys were literally shaped as plastic keys. Each clinical computer had a key reader connected via serial port. Clinicians would insert and twist the key in order to access the clinical computing systems. Removing the key resulted in automatic log out.  I am told that the system lives on today in some form nearly 17 years later.

What's changed across the nation in terms of health care cybersecurity since the 1990s? Malware spreads by USB sticks and IP networks rather than 3.5" disks. Medical devices depend much more on networks and software. There are now so many layers of software dependencies, it's hard to even inventory what's in the trusted computing base.

I still have the wooden shoe presented to the staff who helped "go live" with this clinical computing system in Holland. Stored on a shelf right above my IHTFP propeller hat.

First graduate course in the nation dedicated to medical device security

Semmelweis is credited as a pioneer of antiseptic technique. 

How do we begin to improve the information security of increasingly interconnected and wirelessly controlled medical devices?  Starting with highly trained engineers who also appreciate the complexities of human factors and regulatory affairs.  My upcoming Winter 2013 course at the University of Michigan on Medical Device Security will be the first of its kind in the nation to teach students about this topic.  Students will learn the timeless concepts and cutting-edge skills in computer engineering, human factors, and regulatory policies that determine the safety and effectiveness of manufacturing software-controlled medical devices.

Students will apply the newly learned concepts and skills by analyzing the security of a real-world medical device in a hands-on term project. Interdisciplinary teams will consist of students from complementary backgrounds to mimic the composition of teams at medical device manufacturers and regulatory bodies. Occasional guest speakers from medical device manufacturers, hospitals, and government will complement the classroom activities with critical lessons from the front lines.

False Part 2: FDA does not allow software security patches

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

Hurricane Sandy gave me to opportunity to try out some drawing programs while stranded in Minneapolis.  Here's my artistic interpretation to expand upon my earlier post to encourage regular cybersecurity patches for medical devices that depend on COTS software like Windows XP.  You can download the PDF poster here.  Consider posting near your hospital CIO's office.  This poster has been verified and validated by smart engineers from the medical device manufacturing community (they liked it, so I am sharing it).

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.

GAO issues long-awaited report on medical device security

Today, the U.S. Government Accountability Office (GAO) issued a set of recommendations to improve the information security of certain medical devices.

Congressional lawmakers who requested the GAO review issued the following response.  In August 2011, the lawmakers had asked GAO to investigate the topic.

In April 2011, I submitted a document on software issues for the medical device approval process at a Senate hearing on "A delicate balance: FDA and the reform of the medical device approval process."  The document raises questions about how to improve the trustworthiness of medical device software.  A more in-depth survey on trustworthy medical device software was commissioned in 2010-2011 by the Institute of Medicine for a panel investigating the FDA 510(k) clearance process.

Your medical device is secure as long as you don't plug it in. To use it, first plug it in.

Mark Olson, the Chief Information Security Officer (CISO) at the Beth Israel Deaconess Medical Center, offers an interesting analogy to summarize how hospitals feel they are being treated when it comes to security of medical devices they purchase:

"I equate this to buying a high-end automobile - such as a Mercedes Benz - and having it delivered with old-style drum brakes and no power brake system, and the salesman advising, "Keep it under 20 mph and you should be able to stop with no problem." The risks presented by this would simply not be accepted by the customer base; no one would purchase the vehicle, and it would soon no longer be offered."   

-Mark Olson

It's an interesting analogy to ponder as hospitals and manufacturers struggle to reach consensus over (1) what exactly are the problems facing medical device security, and (2) what are the most effective approaches to systematically improve security.  No more wack-a-mole approaches, please.  These security issues are really hard to solve because of both technical and managerial reasons, among others.

The good news is that some manufacturers (especially in the cardiac rhythm management and diabetes management markets) are beginning to integrate security thinking earlier in the medical device manufacturing processes.  I've met some really smart medical device engineers who are excited about improving security and privacy.  Manufacturers playing catch up should take a page from the companies who are succeeding at integration of security processes into manufacturing, but a danger is that it's often hard to distinguish good security from bad.  Beware of snake oil.  We owe it to patients to improve security of connected medical devices.  Security is an important public good!

The full article by Mark Olson appears at Healthcare Info Security.

MedCOMM presentations streamed live on August 13

Live Free or Hei.

We have a nice set of folks registered to attend ACM MedCOMM in person, but we also want to make sure that others unable to fly out to Helsinki can watch the talks too.  So we have arranged to webcast the talks LIVE with Regis.  Well, Regis wasn't available.  Kevin will introduce the distinguished speakers on medical communication systems.  There are experts from the medical device industry, government, and academia on topics ranging from wireless neural interfaces to electromagnetic compatibility to security and technology ranging from wireless power to body area networks.

Carefully sip your favorite caffeinated beverage that isn't linked to serious health consequences, wear your fire-retardant pajamas, and join us from 9AM-5PM Helsinki time on August 13 at http://spqr.cs.umass.edu/events/2012-medcomm/.  That's 2AM-10AM Eastern time.  Viewers can submit questions via twitter.   Get an early start on your day before your supervisor expects that completed safety case for your next generation medical device!

Security and Privacy Qualities of Medical Devices: An Analysis of FDA Postmarket Surveillance

Today, the PLoS ONE journal has published our analysis of a decade's worth of public FDA data to gain insight into the security and privacy qualities of medical devices.  The technical paper appears at PLoS ONE.

Google and Bing can help you find our analysis translated into layperson terms.  Here are some links:

• Medical device security info lacking
• Medical device security isn't tracked well, research shows

This interdisciplinary research was made possible by the DHHS SHARPS project and the Trustworthy Computing/Secure and Trustworthy Cyberspace program at NSF.  This work was sponsored in part by Health and Human Services (HHS) Grant Number 90TR0003/01 and National Science Foundation award CNS-0831244. The contents of the paper are solely the responsibility of the authors and do not necessarily represent the official views of the Department of Health and Human Services. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript. Any opinions, findings, and conclusions or recommendations expressed in these materials are those of the authors and do not necessarily reflect the views of NSF.

Webinar on Medical Device System Security at ACCE

Clinical engineers and biomedical engineering staff who are wondering about the extent of the problem of medical device system security can participate in my upcoming webinar with the American College of Clinical Engineering on July 19th.   I'll talk about security issues often associated with medical devices, common roles and responsibilities of both the provider and the vendor, identification methods of vulnerabilities and best practices to minimize those vulnerabilities.  Come hear the bad news and good news about medical device system security.  A question/answer period will follow the presentation.

Find out more from the ACCE website or the ACCE Facebook page.

ACM MedCOMM from Start to Finnish

Tule mukaan Helsingissä!

Join us at the ACM Workshop on Medical Communication Systems!

We don't just love repeating letters mid-word—we are practicing our Finnish for the first ACM SIGCOMM Workshop on Medical Communication Systems (ACM MedCOMM) to be held in Helsinki, Finland on August 13.

MedCOMM brings together scientists, engineers, standards-committee members, patient advocates, security researchers, pickled herring, students, and medical experts to evaluate the state of the art in communications for medical applications.  We'll talk about how to build systems with better security, spectrum utilization, interference properties, power consumption, and patient-friendliness than what exists today.  We'll draw people and insights from the SIGCOMM community, where last year's "best paper" concerned medical-device security and involved software radio, jamming, and some fundamental full-duplex radio action.

Check out the lineup of invited talks and papers and join us for this full-day event in Helsinki on August 13!  The draft PDF program complete with visuals provides further details on speaker bios, implants, etc.

You can register by July 9 to save €40 off the registration fee—and you'll also get a week's free passage on public transportation in Helsinki.

Täytyy harjoitella enemmän suomenkieltä!

Baxa's Non-Approved Software Policy: That's Your Problem

While browsing the web for medical devices that appear to run on Windows operating systems, I came across the Baxa ExactaMix Compounder. One could use a compounder for parenteral nutrition. These devices do run a "Microsoft Operating System" according to Baxa. Interestingly, the product page contains a link to a Baxa-authored whitepaper titled Preventing Cyber Attacks (PDF). At first glance, I was pleased to see that Baxa actually offers guidance on this issue, but the content of the whitepaper raises alarms. This excerpt in particular is unsettling (my emphasis added):

FDA regulations require manufacturers to “Validate all changes, updates, and patches, including operating systems, before installing them to ensure the safety and effectiveness of the medical devices.”1 Baxa ExactaMix Compounders have been verified and validated only with the software that was installed by Baxa. Thus, any changes to the original, validated image, including installation of antivirus software, nullifies the validated state, may create an unsafe operating condition, and would constitute off‐label use. 

As an FDA‐regulated manufacturer, Baxa Corporation will not/cannot support nor endorse off‐label use of its compounder. Only validated systems are approved by Baxa as being safe and effective for use. Any unauthorized programs installed on a Baxa product will void the manufacturer’s warranty. ExactaMix Compounders have been validated only with the operating system and patches installed by Baxa. Installing any software not provided by Baxa, including OS updates, firewall software and anti‐virus products, on Baxa automated compounding devices may change the operating parameters and adversely affect the operation of the device, rendering it unsafe to use. 

The footnote above points to an FDA document titled Reminder from FDA: Cybersecurity for Networked Medical Devices is a Shared Responsibility, of which Baxa has adopted a very narrow interpretation that maximally reduces their responsibility for software security.  How convenient.

While the quote that Baxa pulled from the document is really there, it does not tell the whole story. Rather than taking the draconian stance on the issue of software configuration that Baxa suggests, the document also explicitly states that, "Medical device manufacturers and user facilities should work together to ensure that cybersecurity threats are addressed in a timely manner." and furthermore 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).

Other highlights from the FDA document include these two bullet points that appear to directly contradict Baxa's stance on software updates:

• Make sure that you have adequate anti-virus software and firewalls installed, properly set up and current.

• Update your operating system and medical device software. Software updates offer the latest protection against harmful activities.

In fairness to Baxa, the FDA guidance does not make it entirely clear what the company's responsibilities are in terms of validation for software updates and antivirus software, but a blanket mandate that customers must not take vital steps to protect their devices or patients seems like an irresponsible choice by a manufacturer that could put patients at risk. Rather than sharing responsibility as FDA recommends, Baxa is completely abdicating responsibility for security and forcing customers to do the same by forbidding them to install software updates.

A Fluke of Security Issues from Updating Software on Windows-Based X-Ray Testers

Imagine you'd like to test X-ray machines in a hospital, dental office, etc. for safety and calibration.  X-ray testers come into play.  So how does one maintain the software used with X-ray testers?  How do you know that you've downloaded the legitimate software? 

The TNT 12000 X-Ray Test Device from Fluke Biomedical distributes its software updates online.  Worried about the security of your hospital network while downloading software?  Concerned that installing software might violate your hospital's corporate security policies and get you in hot water with your CIO or CISO if you accidentally download malware?  No problem.  Trust the Internet.  Just download the .EXE file or the ZIP file using any shared Internet connection from an HTTP site.  No need for connection-oriented SSL security or pesky end-to-end digital signatures of integrity-protected content.  Another time saver for increased productivity.

Philips Medical Patient Monitors and Downloading Medical Device Software

Earlier this year after speaking about medical device security at a Semiconductor Research Corporation event, I got the gift of food poisoning that landed me in an ER.  I enjoyed a warm IV and a Philips Medical Intellivue patient monitor.  As I writhed in pain, I wondered how the hospital updated the medical device software.

Here's how.  Download an unsigned .EXE file from Philips Medical.

What could go wrong? Don't worry because a 2009 FDA MAUDE adverse event report on a different product explains that "Philips Medical Systems is not responsible for ... the integrity of the ... system infected with a computer virus."  The MAUDE report seems to conflict with the spirit of Philips Medical's own product security policy.  Philips Medical deserves kudos for writing a security policy document; not too many medical manufacturers can claim to have a policy on software security.  However, Philips Medical may wish to hold off on claims of having "security designed in" if the same document later says:

In many of our products, we provide you with a controlled update repository to reduce the risk of equipment outage due to unauthorized or faulty anti-virus signature updates.

Many?  Many is a euphemism for we're sorry that we cannot quantify our cybersecurity preparedness.  There is a diffusion of responsibility between hospitals and manufacturers that leads to certifiable finger pointing over security of medical devices.  It has already been almost a decade since Philips discussed the problem of medical device security.  Let's hope that achieving reasonable medical device security doesn't take as long as it took physicians to accept the advice of Semmelweis et al. on the importance of hand washing.  That was 1847.  And hand washing is still a problem.

FDA Recalls Attributed to Software Failures

Today FDA released its FY2011 OSEL Annual Report.  Of relevance to medical device software, Figure 5 on page 22 charts the impact of software on medical device recalls.  The figure indicates that last year, about 24% of FDA recalls of medical devices were attributable to software failures. The report also proposes an analogue to "flight data recording" to get better introspection into adverse events on medical devices (page 39).

Secure Software Updates for Medical Devices?

[In April 2010, I wrote the following incomplete draft post about software updates for medical devices after the automatic anti-virus snafu in hospitals.  More than two years later, I figure it's time to release this paragraph warts and all.]

Software updates are hard to write well. One example is the McAfee update that reportedly caused thousands of computers to get stuck repeatedly rebooting. I am often asked why it's hard to automatically securely update software on a medical device. I think the example from McAfee is illustrative: what does a person do when a software update goes awry? For a desktop computer, one can call tech support and grab a cup of coffee until the computer is repaired. With a medical device, there is much less room for error and the consequences of downtime (or erroneous operation) potentially higher. Software updates are hard to get right for personal computing, and software updates for medical devices have less wiggle room for error.

Click Here to Download Your AVEA Ventilator Software Update. Trust Me.

[Updates contributed from readers appear at the bottom of this blog post.]

Summary: The web server distributing the software updates for a ventilator (a medical device) itself needs some help with software updates. According to Google, the web server was infected with 48 viruses and 2 scripting exploits. 20 pages resulted in malicious software being downloaded and installed without user consent. 

The risks should be obvious. This is an update for a medical device, and yet one must download it in a manner as if software sepsis is no big deal. Health care professionals might as well stop their washing hands while they're at it.

Hospital IT staff:  How much do you trust the Internet for updating medical device software? A number of researchers in software upgrades bemoan the general state of the art for secure software updates.  Worse, the cryptographic technology at the core of commercial software update mechanisms is broken and being actively exploited by the Flame virus.

Well, if you work for a hospital, the Flame virus is probably the least of your worries.  You just want to keep your HIT systems and software-controlled medical devices working.  Vendors routinely install software updates for medical devices from the Internet or USB keys.  I've seen medical sales engineers download pacemaker-related software from the Internet.

Today I tried to download a software update for CareFusion AVEA Ventilators.  What I found may disturb hospital IT staff.  Here's a screenshot.  When I clicked on the highlighted link for "AVEA Ventilator software update," a second dialog box popped up, "Warning: Visiting this site may harm your computer."

What's this second dialog box?  It's a feature in the web browser that uses the Google Safe Browsing service.  For this particular web server that provides the software update for a ventilator, Google had the following data for www.viasyshealthcare.com:

What happened when Google visited this site?Of the 347 pages we tested on the site over the past 90 days, 20 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2012-06-08, and the last time suspicious content was found on this site was on 2012-06-03.
Malicious software includes 48 trojan(s), 2 scripting exploit(s).
Malicious software is hosted on 3 domain(s), including nikjju.com/, lilupophilupop.com/, koklik.com/.
This site was hosted on 1 network(s) including AS26651 (CAREFUSION).

Wonderful.  I am downloading ventilator software from a web server known to have 48 trojans and 2 scripting exploits.  Hurray for science and technology.  Clicking on the CAREFUSION link provides further assuring data:

What happened when Google visited sites hosted on this network?
Of the 3 site(s) we tested on this network over the past 90 days, 2 site(s), including, for example, viasyshealthcare.com/, sensormedics.com/, served content that resulted in malicious software being downloaded and installed without user consent.
The last time Google tested a site on this network was on 2012-06-08, and the last time suspicious content was found was on 2012-06-06.

On the same site, I found another product that discusses its software update mechanism for Cortical Stimulator Control Units.  The company advises its customers to "Click Run" when the "File Download Security Warning" dialog box appears.  The instructions appear to refer to a CD rather than an Internet download, but I wonder how many technicians take a short cut by downloading an update via the Internet.  That Internet is so darn convenient.

I find it difficult to establish trust in the safety of software affilatied with reports of "malicious software being downloaded and installed without user consent."

What's the way forward?  That's a longer discussion.  Let me update you over drinks.  For starters, go read the Google papers on web malware [Trends in Circumventing Web-Malware Detection and All Your iFRAMEs Point to Us].  Here's to a better and more secure software update infrastructure.  Cheers.

---

Going to the doctor and worrying about cybersecurity

[Editor's note: Jeremy Epstein with our colleagues at the Freedom to Tinker blog is our Secure-Medicine.org guest blogger this week.  Below we syndicate his recent posting about "Going to the doctor and worrying about cybersecurity."  Jeremy is a Senior Computer Scientist at SRI International. ]

For most people, going to the doctor means thinking about co-pays and when they’ll feel better. For me though, it means thinking about those plus the cyber security of the computer systems being used by the medical professionals.

I’ve spent more time than usual visiting doctors recently. I broke my hand – sure I’ll tell you how.  It was a hit-and-run accident with a woodchuck. I was riding my bike, the woodchuck ran in front of me, I ran over him, and he fled into the woods, leaving me lying on the ground moaning in pain.  Okay now that we got that out of the way…

So the emergency room doctor ordered a CT scan (to check for a concussion and the presence of a brain) and various x-rays.  I thought  about the computer controls while in the CT scanner, but what was really interesting was when the hospital emergency room digitized  the results and gave them me on a CD to provide to the orthopedist.

Before going to the orthopedist, they had me fill out a bunch of forms online. As I provided the detailed medical information, I wondered how secure the web interface is, and whether someone could attack the medical record system through the patient input interface.

When I got to the orthopedist’s office a few days later, I gave the receptionist the CD, which she promptly read into the medical records computer and returned to me. It occurred to me that the risk taken in reading a CD  or other media from an unknown source is pretty substantial, something we’ve known in the security world for  decades but has not filtered well into other fields.  On the other hand, every time I’m on a conference program committee I open PDFs from people I may never have heard of, so it’s not as if I’m immune from this risk myself.

When I got home, I read the CD on my Mac laptop, and discovered that it has an autorun.INF file to start the application that reads the x-ray data files. I don’t know whether the doctor’s office disables AutoRun on their computers; undoubtedly some doctors do and others don’t.

And even if the doctors’ computers have disabled AutoRun and don’t use the software on the CD to view the test results, how secure are they against data-driven attacks, such as we saw a number of years ago against JPEG files in browsers?

So given this experience, how would I use the information if I were a bad guy?  Patient-provided removable media are a part of the attack surface that may not have been considered.  If the security model assumes that the media is coming from a trustworthy source, there needs to be a way to validate that trust.  Relying on a imprint on the media is not much of a protection. Creating a CD with a legitimate looking imprint from a hospital isn’t hard; and if I didn’t know what an imprint looked like, I would make one up and put address in a state or country far enough away that it’s unlikely it ever would’ve been seen before by the doctors office staff. Next, the attacker needs to make an appointment with a doctor who is inclined to read data off a CD. In addition to orthopedists, that probably includes many other specialties such as oncologists and cardiologists given an appropriate explanation of what the data is. Finally, the attacker needs to create appropriate malware. But that’s easier than a web attack against a medical application, since they’re going to run whatever program is put on the disk, and there’s no need to find new vulnerabilities.

But that begs the question, why would someone bother? I’m not really sure, but blackmail, identity theft, or just kicks from knowing that you could seem like possible motivations. Then again, I doubt many of us could have predicted the varied motivations that exist for malware on the web today.

I (obviously) didn’t infect my doctor’s computers with malware, however tempting the thought may be, especially after I got the bill. But the lesson learned for me was that attack surfaces show up in the most unanticipated places.

[Postscript: Thanks to David J for pointing out several typos which have been corrected. The side effect of being a novice at using speech-to-text, thanks to the above-cited broken hand!]

[Editor's note: See FTT for Jeremy's original post and comments.]

Cybersecurity Incident Response and Coordination Center for the Healthcare Industry from HiTrust

The HiTrust initiative for "Cybersecurity Incident Response and Coordination Center for the Healthcare Industry" seems to be off to a rough start.   Maybe they should contact Diginotar for help.  Hat tip to Shawn Merdinger.

NIST explores economic incentives for medical device cybersecurity

The NIST Information Security and Privacy Advisory Board recently held a panel on Economic Incentives for Medical Device Cybersecurity.

Discussion summary: The lack of meaningful data on medical device cybersecurity leads to cybersecurity unpreparedness. Today, though, there is an economic disincentive for reporting of vulnerabilities and incidents. For instance, a hospital would incur liability by reporting a problem. The economic factors self-reinforce a cycle of not reporting cybersecurity problems, which increases the false impression of preparedness from lack of reported incidents. The lack of reported incidents is more likely a result of lack of incentives for reporting and a lack of effective reporting mechanisms designed to collect cybersecurity threat indicators from the clinical setting.

• Discussion questions and panelist biographies
• Full NIST ISPAB agenda
• 90-minute audio recording of the panel discussion

Panelists:

• Brian Fitzgerald
  Deputy Director, Division of Electrical and Software Engineering, FDA CDRH OSEL
• Kevin Fu
  Associate Professor, Computer Science, UMass Amherst (moderator)
• Louis Jacques
  Director, Coverage and Analysis Group, Centers for Medicare and Medicaid Services
• James Keller
  Vice President, Health Technology Evaluation and Safety, ECRI Institute
• George Mills
  Director, Department of Engineering, The Joint Commission
• Erich P. Murrell
  Lt. Col., CISO, Medical Devices, Office of the Air Force Surgeon General

Past ISPAB meetings with panels on medical device cybersecurity:

• March 2011
• July 2011

ACM Workshop on Medical Communication Systems

The ACM Workshop on Medical Communication Systems (MedCOMM) seeks short research papers. Research communities such as communications, networking, sensor networks, cyberphysical systems, human-computer interaction, security, and wireless are highly relevant. This workshop is co-located with ACM SIGCOMM in Helsinki, Finland.

From the CFP:

We solicit submissions on topics including, but not limited to, the following:

• Safe and effective network architectures and protocols for highly interoperable wireless medical devices

• Applications of cognitive radio to maximize spectrum utilization and spectrum sharing on unlicensed bands

• Data integrity and reliability issues in allocated or unlicensed spectrum

• Mobile phones as medical sensor gateways

• Ultra-low power communications

• Deployment of open medical communication systems

• Communications and computer networks designed for validation, formal verification, or hazard analysis

• Usability issues, security/privacy issues, regulatory/policy issues

• Industrial experiences, provider experiences, regulator experiences

As a workshop, the focus is on position papers and early-stage works. The submission deadline is March 23rd. Please consider submitting.

The full CFP with all of the relevant deadline information is available here.