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.

Amphion Forum discusses medical device security in Minneapolis on November 3

Join MDSC co-director Dr. Kevin Fu and several other experts on medical device security at the Amphion Forum in Minneapolis on November 3. Request an invitation and then take a morning break from MDM to learn about the emerging security risks of software-based medical devices.

It's not too surprising that medical devices have security risks. The bigger question is how to find effective and balanced ways to reduce security risks in a landscape where threats can emerge without warning. Dr. Fu explains that if a medical device company wishes to attract hackers to devices, the company should follow this simple, four-step program:

1. Increase software complexity so that testing becomes an ineffective technique for risk management. Make extensive use of pointers and non-type-safe programming languages.
2. Add unprotected radio communication so that previous physical barriers no longer keep out the bad. Special overconfidence points are awarded for using "proprietary techniques" to "secure" a radio/wireless link.
3. Trust the Internet for clinical decision making; add decades of Internet security holes and web browser vulnerabilities to your trusted computing base.
4. Be complacent. Assume that absence of a security problem today means there never will be.

Software race conditions in intravascular radiation delivery systems

There are very few MAUDE reports that cite "race conditions" in medical device software as a cause of malfunction, patient harm, or death. But to a computer scientist, this 2002 MAUDE report on a radiation delivery device sounds like it's describing a classic race condition:

The root cause for the appearance of the partial treatment button is the result of a software anomaly combined with the user not following the ifu. The time window necessary for this anomaly to occur (after completion of the treatment and prior to the treatment summary screen being displayed) is small (approximately 1 second),...

The phrase "race condition" does appear occasionally in MAUDE. Here's a sample excerpt.

Engineering investigation determined that after the table top is tilted to 88 degees, releasing and engaging the angulation knob very quickly when the table is near its extension limit creates a software race condition that allows the table to continue its motion towards the floor.

Another wireless infusion pump announced

Another wireless infusion pump has been announced. Wireless has the potential to revolutionize medicine, but what about the challenging security and privacy risks of wireless? I wonder how well the software system adheres to the classic open design principle for security engineering. What kind of cryptographic protocols are in place for secure updates of drug libraries? If SSL is used, how does the manufacturer revoke certificates when a CA is compromised? Does the device rely on proprietary techniques or sound security engineering? These are important types of questions to ponder when taking a previously non-wireless medical device and then exposing the device to the wild west of wireless. Meanwhile, it's still a vexing problem to protect a Facebook account from wireless compromise let alone a medical device.

According to this public database entry, this pump was cleared through the 510(k) process and deemed substantially equivalent to a predicate device. The database entry does not indicate whether the predicate device was wireless.