Monday, May 2, 2016

Archimedes Circular Podcast 0x01: Co-Chairs of the AAMI Medical Device Security Working Group

Not an official logo of the AAMI Medical Device Security Working
Group, but it may become a T-shirt after members catch up.
Welcome to the inaugural Archimedes Circular Podcast. Today, Dr. Kevin Fu interviews the co-chairs of the AAMI Working Group on Medical Device Security ahead of the release of its Technical Information Report 57 to medical device manufacturers on specific security engineering methods designed to help satisfy regulatory expectations of cybersecurity in the 510(k) and PMA processes.

Ken Hoyme and Geoffrey Pascoe are co-chairs of the AAMI Medical Device Security Working group. AAMI is the Association for the Advancement of Medical Instrumentation. Founded in 1967, AAMI is a non-profit organization of 7,000 professionals for the development, management, and use of safe and effective healthcare technology. AAMI consists of over 100 technical committees and working groups that produce Standards, Recommended Practices, and Technical Information Reports for medical devices. The medical device security co-chairs are interviewed by Kevin Fu, a professor at the University of Michigan and the Archimedes Center for Medical Device Security.

For several years, the AAMI Medical Device Security Working group has been toiling away tirelessly on the Technical Information Report #57 (Principles for medical device information security risk management). Its members fondly call it TIR 57.  The document provides advice to front-line medical device engineers on how to begin integrating security engineering into the design and implementation of medical devices. The TIR 57 is based on the input and consensus vote of medical device manufacturers, health delivery organizations, security engineering experts, and faculty.

Kevin:                      Welcome to the Inaugural Archimedes Broadcast. My name is Kevin Fu. I direct the Archimedes Center for Medical Device Security. Today, we’re going to talk about consensus standards and guidance documents for manufacturers to meet FDA expectations on medical device security. Today, I am interviewing Ken Hoyme and Geoff Pascoe, the co-chairs of the Medical Device Security Working Group of AAMI, which is considered the most respected standards body in the medical devices arena. I am also joined by Wil Vargas who is the director of standards at AAMI, so welcome, Ken, Geoff and Wil.
Wil:                         Thank you.
Ken:                          Thank you. Thank you for having us.
Geoff:                      Thanks.

Saturday, April 23, 2016

Comments on Postmarket Cybersecurity Guidance: The FDA Awakens

FDA's draft postmarket guidance on cybersecurity greatly
improves beyond past approaches, but the devil is in the details
The deadline to submit comments on FDA's draft postmarket cybersecurity guidance has come and gone last week. Below is a copy of my comments to FDA.

My major recommendation pertains to language choice when describing postmarket risks so as to monitor for postmarket problems without falling victim to the streetlight effect. While network-based threats are a significant part of the problem, it's just one of many postmarket problems. There's a reason we don't write guidance on how to avoid flu by sneeze, then write a different guidance document on how to avoid flu by cough. By focusing instead on exposure to cybersecurity risk, the industry can better prepare for shifting threats whether it be by network, USB drive, telephone social engineering, or whatever fancy technology next comes out of Silicon Valley. To ensure that the postmarket guidance can remain relevant as technology and threats change, focus on overarching exposure rather than streetlight modalities.

I also advise manufacturers and HDOs to follow the NIST cybersecurity guidance for critical infrastructure.  For example, (1) enumerate cybersecurity risks because deploying technology without understanding risk is counterproductive; (2) deploy cybersecurity controls that match the specific risks; and (3) continuously measure the effectiveness of the security controls because threats, vulnerabilities, and misconfigurations can bypass a previously effective control within seconds. For instance, if you just look for threats against your core reactor, you might forget about your thermal oscillator.

My letter is downloadable here.

Sunday, January 31, 2016

White House Roundtable on Cybersecurity of Hospitals and Medical Devices

The White House convened a leadership roundtable
on the topic of cybersecurity of hospitals and
medical devices.
Last month, the White House quietly convened a group of medical device security stakeholders and domain experts to discuss the cybersecurity challenges faced by healthcare delivery organizations and medical device manufacturers. There were actually multiple meetings. Here I summarize just one that I attended in my role as a professor leading the Archimedes Center for Medical Device Security at the University of Michigan, and in my role as a member of the Computing Research Association's Computing Community Consortium (CCC) Council.

Convened by the President's Office of Science and Technology Policy (OSTP), we sat together in the elegant Diplomatic Room in the Old Executive Office Building. I was invited because of my expertise in medical device security and FDA regulatory affairs dating back to when I briefed the FDA in October 2006 on looming cybersecurity risks and when I worked in hospital IT in the early 1990s. I was probably not invited for my bread making skills.

The room was packed with people from a diverse set of backgrounds: techies, physicians, policy wonks, CISOs, lawyers, and more. I noticed that the group roughly divided into three parts, like Gaul:
  • visitors like myself who responded to questions, 
  • special assistants to the President who asked questions, and 
  • leaders from various parts of the executive branch who listened attentively.
White House Chief Data Scientist DJ Patil chaired the meeting. White House Cybersecurity Czar Michael Daniel asked many questions. There were a large number of federal representatives from 
  • various HHS agencies (FDA, CMS, OCR, ONC) plus the HHS CISO,
  • the U.S. Digital Service, 
  • DOD, 
  • DHS, 
  • FBI, 
  • NIH, 
  • the National Security Council, and 
  • a guy from the Secret Service who offered just his first name.
One notable techie in the room was Mina Hsiang, a fellow engineer from MIT who served in the tech surge team to rescue

We talked about the NIST cybersecurity framework, collaboration across agencies and industry, regulatory matters to incentivize better cybersecurity, information sharing so that hospitals and manufacturers need not be in the dark about threats, incident and vulnerability response, leadership, and medical devices in general.

Prof. Kevin Fu and Dr. David Klonoff
Michael Daniel expressed concern that the Internet was becoming a liability, but also that security problems can slow innovation. He pointed out that the median number of days to detect an intrusion has improved to an embarrassing 209 days across all industries. So what happens during those 209 days as the intrusion spreads its tentacles thru a hospital? He also expressed hope that computer scientists can find a way to decouple and better layer security into operating systems (sounds right up the alley for an SOSP paper). Multiple speakers brought up the topic of Medicare/Medicaid reimbursement policies, and how it ought to use the power of the purse to incentivize purchasing of more secure, safe, and effective products. Separately reached for comment, a representative from CMS explained that they do routinely realign their reimbursement policies, especially when FDA uses new guidance (ahem, cue the new FDA pre-market and post-market guidance). A CMS representative explained that it's not uncommon to set policies more strict than FDA requirements by pointing to industry standards (cue AAMI TIR 57 on medical device security).

It's the Simple Stuff, Stupid

I spoke about cybersecurity problems at hospitals and medical device manufacturers, why the problems exist in the first place, and how stakeholders are genuinely working on the problems. The good news is that many (but not all) manufacturers and hospitals genuinely want to find a way to mitigate cybersecurity risks. In contrast to sensationalist media reports, I emphasized that the greatest near-term risks are dirt simple: the delivery of patient care is disrupted when medical devices get compromised by garden variety, decade-old malware by accident. These devices are no longer safe and effective, and often require downtime to clean up the cybermess. My longer manifesto on this subject appears in the National Academy of Engineering Winter 2015 newsletter and as part of a workshop at the Institute of Medicine.

The feds had many questions about NIST guidance documents on cybersecurity, and the invited guests from industry heaped praise on NIST for documents that actually get used in practice. Footnote: NIST is about to celebrate the grand opening of its new National Cybersecurity Center of Excellence (NCCoE). I've been asked to spread the word about their recently posted call on tools to protect the security of medical devices.

One of the more interesting conversations involved culture shock. When I spoke about the security problems that hospitals face and the sometimes adversarial relationship between IT and biomedical groups, the counsels from the American Hospital Association nodded, smiled, and sighed in agreement. They know what I am talking about: the IT security people that lock down computers to the point that clinicians can't get their job done, or the clinician who accidentally infects a cathlab with virus transferred by a USB stick from a Yahoo account on a nursing workstation. Having worked in a community hospital installing computers in patient rooms, back offices such as medical records, and administrative areas such as the CEO's office, I had first hand experience observing effective and ineffective ways of deploying technology in clinical areas. IT security people: thou shalt not interrupt clinical workflow! Period!

For the academics

I'd like to encourage my fellow computer science faculty to get out of their dingy offices and educate leaders in government. Conference and journal publications are not the end point of research, but rather the beginning of impact on society at large. For faculty who might participate in future White House roundtables, here's a bit of advice. Come prepared with a single request, not a long annoying list, of how the government can help help rather than get in the way. My request was simple: use the force. That is, use the convening force of the government to bring stakeholders together. I asked them to convene medical device manufacturer CEOs, Boards of Directors, and hospital executives to ask how they are meaningfully addressing medical device security risks.

Final thoughts

The higher ranking people in federal government are just beginning to wrestle with the problem of medical device security. It's clear that the government isn't going to sit idly as hospitals continue to get infected with cybersecurity problems (three hospitals hit last week [1, 2, 3]) and manufacturers continue to produce difficult to secure devices (remote buffer overflows in drug infusion pumps last week). At the end of the day, hands were shook, business cards were exchanged, speaking invitations were offered, and other passive tense events. 

The government is a meta-organization, and you should not expect them to directly solve your problems. They will not do your homework for you, and they won't debug your software for you. But they will set expectations and desired outcomes, and they will take action against medical device companies that prefer to bury cybersecurity problems. Expect to hear about the outcomes of these types of ongoing meetings at the 4th Annual Archimedes Workshop on Medical Device Security at the University of Michigan. Ok, all for now!

Kevin Fu is Associate Professor of EECS at the University of Michigan and Chief Scientist of Virta Labs, Inc.