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.
Kevin:                      Let me begin with just a little background here because not everybody is familiar with AAMI. AAMI is the Association for the Advancement of Medical Instrumentation. When talking with my information security colleagues I often liken AAMI to the IETF of the medical device manufacturing world. AAMI is this nonprofit organization that supports the healthcare community, has over 7000 professional members represented and they’re really the primary source of consensus standards for the medical device industry.
                                    Before we get into what AAMI is doing in the medical device space, I was hoping Wil, maybe you could just tell us a little bit about AAMI and in a jargon-free world to introduce some of our technical folks who may not be familiar with medical devices what exactly AAMI does.
Wil:                         Sure. AAMI stands for the Association for the Advancement of Medical Instrumentation. They have been around for almost I think 50 years now. Its focus has been on issues relating to patient safety with medical devices. The efforts really started around creating voluntary standards and guidance documents to help address and facilitate those issues to improve patient safety for medical devices across a wide spectrum of device safety issues from sterilization all the way through elements of software and security.
                                    AAMI’s products and services have developed and grown over time really with that core focus in mind. We have conferences and courses and events, all related to communicating the issues related to patient safety. The standards program is really where the rubber hits the road bringing the experts together, from industry manufacturers and even the end users which are the doctors as well as the biomeds, the biotech, and getting them around the table to address and create those voluntary standards. That’s part of the core of what AAMI does even 50 years later.
Kevin:                      My understanding is that AAMI is this independent body that is not an advocacy group but is more a builder of consensus. Maybe you could help us understand how that affects or what makes AAMI special.
Wil:                         You’re right. AAMI doesn’t really get involved and doesn’t really play a role in advocacy or lobbying. It’s a nonprofit organization that relies on the consensus process which is basically where you get folks to agree enough on a topic that we can move on, not that everyone completely 100% solidly is behind or believes 100% that they would do it that way if it were up to them. Consensus is one of those weird squishy things but it works and it works really well in order to create these voluntary standards, but it also takes on or takes in a lot of feedback within the consensus building process.
                                    It’s not a one and done type of process when you’re developing a standard. It’s a very intricate sequential process where the issues and elements are discussed at great length over a very long period of time, at least a minimum of a year, it can be as long as five years in order to achieve that level of consensus required to achieve and get the document approved.
Geoff:                      This is Geoff, I think one of the really useful things about this consensus process is that especially in the medical device industry where we’re heavily regulated it really provides a mechanism for the FDA to collaborate with industry in an open structure that doesn’t favor any particular manufacturer. They have to be very careful about how they communicate their intent to manufacturers. The AAMI rules at being a standards organization really creates a forum where it’s not just the product but the product actually creates these mechanisms for communication in such a way that it actually meets both the needs of the regulators as well as also the needs of the manufactures, and also, in some case the providers.
Kevin:                      This is a good Segway to Geoff and Ken on your specific duties on the AMMI Working Group on medical device security. Everybody who is listening to this is aware that medical device security is a problem and one of the problems is where do you point a manufacturer to improve the medical device security posture? Ken or Geoff, I am hoping you can give me just a brief introduction to what is the AAMI working group on medical device security. What is it doing?
Ken:                          Sure. This is Ken. We were formed about three years ago I think really in response to when the general accounting office (GAO) issued their report encouraging the FDA to improve their pre-market expectations of cyber security and medical devices and their post market surveillance. Again, as Geoff mentioned there is this collaboration between AAMI and the FDA. I think AAMI saw the opportunity there to help drive some consensus standards and discussions between industry and regulator to help evolve the thinking on that and provide some clear guidance on industry to meet the expectations of the FDA.
                                    The committee was formed in the typical AAMI process where all the various member organizations are informed of new committees that are emerging and other kinds of communication vehicles. I think our first meeting was in May of 2013. I think we had about 40 people at that first meeting and have cut across FDA participated medical device manufacturers, security researchers, hospitals, the veteran’s administration had cyber security involved in it. There is clearly a lot of interest and energy working on improving cyber security in these devices.
Kevin:                      Right, so you have a pretty broad group contributing then. These guidance documents take quite a while to produce because the thing about democracy and consensus building is it takes time. I understand that AAMI is still in the middle of this, but what should we be expecting down the road? To a medical device manufacturer who is looking at the FDA pre-market guidance and the draft post market guidance on cyber security, what elements of this guidance document is going to be most valued or what do you think they are going to be looking for?
Geoff:                      Kevin, when you say ‘guidance document’ you’re referring to AAMI in this particular case, because we refer to these things that are nonstandard as technical reports.
Kevin:                      My apologies. I am not speaking the lingo. Yes, the TIR. Tell us a little bit about the TIR 57 and how it relates to manufacturer needs to meet FDA expectations with both the pre-market and the post market guidance. Basically, what can they expect?
Ken:                          The first technical report that the committee decided to tackle we evaluated probably a dozen different directions that we could go, looked at what that other organizations were already producing out there. Our initial choice was to try to address. What ended up shortly after we focused on this, directly tied to the original guidance for pre-market notification, pre-market analysis. What we decided as a committee is since medical device manufacturers are very familiar with safety risk management as part of their quality systems and there is an international standards, standard 14971 that address the risk management process associated with patient harm and patient hazards. Most of our organizations understand the need to do this and have systems in place to assist in that.
                                    What we decided to do was to essentially frame security risk management in the context of the procedures that are defined in that 14971 document and essentially teach device manufacturers that might not have a security background how to reason about security risk management during the development of their process. That ended being up very closely aligned to how the original guidance for the pre-market information addresses manufactures to basically look at acceptability of risk and mitigate those risks that are unacceptable.
Geoff:                      Right. I was going to say I think one of the things about this familiarity with the medical device manufacturer familiarity with safety risk management, it’s a double edged sword. They understand the concept of risk management but I think they don’t really fully appreciate the significant differences between security management, safety risk management. The fact that there are similarities, there are linkages that need to occur but as a result there are significant differences.
                                    We wouldn’t want to see manufacturers saying well we do safety risk management according to 14971 and we put some security stuff in there and we’re set. I think one of the things about this that is a strength of this technical report is that it makes clear what those similarities are, what those differences are and how the two interact.
Kevin:                      For the folks who are less familiar with AAMI and even FDA guidance documents, could you try to tease out for me what is the difference between an AAMI Technical Information report (TIR) and an FDA guidance document or even a company whitepaper? How is this going to be different?
Ken:                          I think a guidance document by the FDA is recommended approaches that manufacturers should consider. They aren’t bound to it as opposed to a standard or something that’s recognized as a shell document. The FDA has flexibility in how they understand and interpret it, but it is reasonably understood by device manufacturers that when the FDA produces a guidance document that that creates an expectation for what they should do and if they ask for device approval without following the information or anything with respect to those documents, that they would expect to have a slow process with lots of questions back from the FDA during the approval.
Geoff:                      Yeah. I think that’s the key, is that technically guidance from the FDA is not enforceable. On the other hand, if you don’t follow the guidance, you create additional barriers either during approval process for regulatory submissions or even in the case of an FDA inspection. Now FDA inspectors are familiar with the guides, so if you show documentation that supports an approach that is commensurate with the guidance, they know how to follow that. If you do it in a completely different way, then it leads to additional questions and makes inspections and regulatory submissions a lot more complicated. I think as a practical matter, most manufactures try to follow the guidance whenever they can.
Kevin:                      Right, and to the effect that I am beginning to see whitepapers being circulated about recommended ways to improve medical device security, where do you think AAMI is going to distinguish itself with its TIR compared to what we’re seeing coming out of individual companies and other sources of information for general advice?
Geoff:                      I think one of the strengths of AAMI is number one their internet familiarity with medical device fields and particularly an emphasis on safety. I think that that is one of the things that distinguishes medical device security and some other types of security, some that are similar to this, perhaps in the transportation field would be one example or even ITS systems. It’s really safety and it’s the linkages between safety and security that I think really is a place where AAMI can make significant contributions as opposed to the traditional protection of confidentiality of information.
Ken:                          I agree with Geoff. That’s a key distinction. Nature abhors a vacuum. As soon as a lot of press was hit with regard to medical device security, there are a lot of organization that wanted to pile in and help. I think many of those organizations because they don’t have that intimate connection with the safety and effectiveness that regulators expect for medical devices will come at it more from a confidentiality encryption point of view. Everyone is very familiar with the various financial penalties that hospitals and health systems and insurance companies have been hit because of breech of information but medical devices are cyber-physical systems. They touch patients. They measure things off of people. They are delivering therapy to people.
                                    In that regard, the issues of integrity and availability can sometimes take precedence over confidentiality concerns particularly if you are dealing with devices that are deployed in an emergency room or in a surgery theater. Having that understanding of being able to balance and trade off the safety aspects of things and security aspects of things is I think a unique position that AAMI has because of that connection to the regulators and the health delivery organizations.
Geoff:                      Sometimes you’ll actually see or hear people talk about the inverting of the CIA triangle. Normally, this is demonstrated with confidentiality at the top, integrity and availability at the bottom of vertices of the triangle but really from a safety standpoint it’s really the integrity and availability are more important. Sometimes you’ll see the triangle upside down. Not that confidentiality isn’t important, but integrity and availability takes a driver’s seat and shotgun.
Kevin:                      I have a couple of more technical questions for you. We’ll see how many we can get through in our time today, but I am curious, because the hospitals are involved in attending these working group meetings, to a medical device manufacturer who uses the TIR 57, is that going to help them to better understand what kind of procurement questions they are going to be asked in the coming future by hospitals and other healthcare providers? What is the interface here that is going to help the manufacturer to meet not only expectations of the regulator but also expectations of the purchaser?
Ken:                          I think the primary vehicle that has been used by purchasers has been the MDS2 form, which is a medical disclosure statement for a medical device security. It’s actually MDS squared. That form is a means for a device manufacturer to articulate the different security properties that are available in their device which would inform both the purchaser as well as any people in the hospital that are going to deploy a device into the hospital network, want they should expect.
                                    While TIR 57 doesn’t directly address a MDS2 form requirements, we do reference it. I would expect that a manufacturer that would use the expectation of that form as they do their security risk management during product design would have the information necessary to disclose on that form automatically by going through the process. That is as opposed to a manufacturer that doesn’t think about security and then is asked at the point when they are marketing the device, “Could you fill this form out?” and they really haven’t thought the questions when they developed the device then they certainly are  going to be in a weaker position.
Geoff:                      I would also add that there is another actual standard that plays into this communication between manufacturers and providers, and that is EIC 80001 which is also worked on by a group at AAMI which is the application of risk management for IT networks incorporating medical devices. Now, their risk management incorporates security but it also considers other types of safety risk. In one of the parts of 80001, they have actually aligned with the MDS2 categorization of the types of things to be considered in security. There is an alignment there.
                                    As Ken has pointed out, we do reference the MDS2. There is some good guidance in some of the annexes of the technical report but I think you’ll see actually much more of that from the post market point of view. We’re currently considering what our next technical report will be. It’s a definite possibility, especially considering the issuance of the most recent guidance on post market that we might tackle a technical report on post market as one of our next work items, but that hasn’t been decided yet.
Kevin:                      Okay, great. One more technical question. I’m curious in the TIR 57---medical device manufacturers have very well honed processes for verification, validation and testing. What kinds of things should manufacturers expect to be unusual or maybe different from normal business in terms of testing when it comes to the security principles discussed by the TIR?
Geoff:                      I think in the case of verification from the standpoint of let’s take the example of outside security, essentially when we develop a device, we develop a set of requirements that both are functional and nonfunctional. Then the verification step is to actually verify that the product design and built in manufacture actually meets those requirements. Now, security is a certain nonfunctional property that requires I think some other types of testing. In the case when you look particularly at functional requirements, the universe of things that you’ve said the device must do is finite. You can enumerate what those functional requirements are. You can design tasks based on particular use cases that are tied to those functional requirements.
                                    In the area of security, I think the more challenging thing here is that you are actually saying that the device should not do certain things. Of course the universe of things that any product should do or should not do is essentially infinite, so we can’t enumerate all of the things that a product shouldn’t do in a very fixed sort of way. That creates certain challenges to security testing that we don’t see in a normal verification step. There should be some exploratory types of security testing, penetration testing, obviously there are going to be functional requirements tied to security. Those are obviously to be verified using the typical techniques, but then applying certain tools to actually do vulnerability scanning, fuzz testers and those sorts of things.
                                    Really, I think the way of thinking about this is that when you do risk management according to for example TIR 57 you’re actually creating a model of the security risk of the device. In my view, what security testing does is, it’s essentially performing an experiment that allows you to verify that your model is correct. You may find things during testing that you have not considered in your risk mode, your risk management or your risk assessment of the device, and you’ll have to adjust it. You may determine that you have considered risk but your estimation of the likelihood of that risk or the level of vulnerability or the threat or the exploit-ability is higher than you anticipated.
                                    It’s just as in science; we create models and we actually do tests, we do experiments to determine whether our models actually fit reality. From my point of view, that is the place of security testing within the framework of risk management.
Ken:                          There is one other area that goes into the post-market side of things that is somewhat different for device manufacturers as they enter the cyber security realm. It has been very traditional for safety risk for manufacturers that are expected by the regulators to have a post market device surveillance and they often rely on complaints. If a device breaks, somebody is going to call in or contact their service rep and so they have a reasonably good vehicle to collect information about how devices are failing.
                                    In the cyber security realm, it could be that there is vulnerabilities in their devices because they’ve perhaps used third party software. They have built it on top of a commercial operating system or they have used openSSL libraries that hardly gets discovered in. The whole process of being aware of what might be a vulnerability in your product goes beyond waiting for end users to phone in with a complaint about device failure.
                                    Many cyber security failures aren’t necessarily going to be noticeable by the user, so that whole process of how manufactures need to think about configuring their monitoring systems and doing diligence on newly discovered vulnerabilities is a brave new world for medical device manufactures.
Kevin:                      Great. I’d like to relay at least an account a little story in the context of your work in this working group on medical device security. Let’s take a look at last month. Last month, January 2016, it was a dozy. Over a period of just one week in January, FDA had released its draft guidance document on post market management of cyber security. As you know, more than 500 people registered for that FDA cyber security workshop. It was sold out. People had to be turned away.
                                    The surprising thing to me was that week when everybody was nestled at FDA, three hospitals confirmed various cyber security attacks ranging from ransomware that had encrypted the system demanding a ransom to get the data back and even a computer virus that has been confirmed to have interrupted clinical workflow and admission systems, including one pathology department of a large hospital that resorted to blood manual processing of their blood and urine samples because of a virus infecting, as you might expect, ancient Windows XP systems.
                                    With these three compromises including one in Flint where allegedly some activists were causing disruptions to service, with all that happening, an infusion pump company received a second ICS cert alert for what is known as a remotely exploitable buffer overflow in a drug infusion pump. That really surprised me, that this all happened in a period of one week. What I am wondering is imagine a world when the TIR 57 comes out, how is that going to help edge us away from to me it seems like really low-hanging fruit of such weak infrastructure in our healthcare system. What should we expect to see change?
Ken:                          Hopefully along with the tier coming out will be a significant amount of communication both at conferences and workshops about what is in this and potentially even education processes that we can have available to try to teach manufacturers. I think a month like last month helps continue to communicate to device manufacturers that may be dragging their feet that this is actually a real problem and they do need to address it. I think some of it, as you say, is poor cyber security hygiene.
                                    I think some is poor choice of systems. I think a lot of manufactures and I think even purchasers of equipment are drawn to low prices and low prices can be achieved when you build on top of commercial operating systems, but building on top of something that you know is going to lose support well before end of use of the device is not really a wise decision by the manufacturer. Hopefully we’ll see better choices of underlying platform technologies and better awareness that they need to be able maintain these devices.
Geoff:                      I think the technical report is not obviously the complete answer. There is a number of other things that Ken particularly alluded to. For example, the alignment of the product road-maps or the third party components that you build into your devices with a very long life-cycles of typical medical devices is a critical part, so actually doing some cyber security planning in terms of life cycle alignment is going to be really important. I think in general what you’ll see from the technical report is that the devices will generally be more secure out of the box.
                                    Obvious sorts of defects will decrease and as they gain expertise with doing security risk management and assessment, they’ll systematize the way they actually look at the security of the device and hopefully most of these types of issues with regard to really, really poor security will be caught during the initial analysis phase. If they do it right there is a post market component to that also, which is, as new data comes in about the security of the device whether it is through complaints or cyber security incidents, we expect those security risk assessments to be updated.
                                    Initially there will be more security outside of the box an as time goes on, we expect the risk assessments to be updated and the devices to be more secure in an ongoing basis throughout their lifecycle. That is my hope at least.
Ken:                          Kevin, I wanted to jump in one implication of the question when you mentioned the occurrence of ransomware. I have provided this as advice in other situations. If a medical device, an actual classified medical device is taken over by ransomware, the only appropriate solution is for them to repave the software on that back to an original state. I think it would be unreasonable to expect that if you paid ransom on a medical device that the attacker will return the device to an adulterated state. You really can’t trust the state of the software after such an attack has happened. The manufacturer, your biomed company should come in and set it back to some initial controlled state
Kevin:                      All right, so it can be set up for the next infection.
Geoff:                      Yeah, because the thing is, again, the integrity of the device is really paramount and whenever it is compromised, really you have to have confidence that the device is in the state that was intended by the manufacturer. It also makes it really important that manufacturers also have a good baseline of the devices before they deploy them because you want to know what actually happened. When the device is adulterated you’d like to apply some tooling to determine how the system changed. That should be input into; how was it changed and by what mechanism might it have been change and how can we prevent this in the future and then of course, it really needs to go back to its installed state.
Kevin:                      Well, we’re rounding out this Archimedes Circular now at about pie-cubed minutes so we’re just about out of time. I did want to take any, if you have any final thoughts you’d like to share with the Archimedes audience on AAMI, the TIR 57 or any other thoughts on medical device security?
Ken:                          Sure. I think it’s been a fascinating process to see the growing realization amongst a larger and larger community that there is really a need for this. I think there was, when the AAMI committee was formed, I think there was a certain amount of resistance and skepticism, how is this going to impact me. I think as time goes on we’re seeing greater and greater awareness amongst both the users and the manufacturers. People are looking for the tools and methods about how to do it, so hopefully we’ll be providing something useful to the community in that regard.
Geoff:                      I agree with that. I would add also that we certainly want people to look at the technical report and at least try to apply some of those lessons there. Also, I’d just like to extend an open call to those involved in cyber security and medical device development to participate in our AAMI device security work-group. I think the more expertise we get in the work-group, I think the better the work product. It’ll be best for manufacturers, and most importantly, best for patients.
Kevin:                      Well, thank you. Thanks Ken, Geoff and Wil for speaking on the program. You’ve been listening to the Archimedes Circular on medical device security as part of the Archimedes Center for Medical Device Security. We’ll see you next time. Thank you very much.
Ken:                          Thank you, Kevin.
Wil:                         You’re welcome. Thank you, Kevin

Geoff:                      Thanks, Kevin.

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 healthcare.gov.

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.