 |
| Not an official logo of the AAMI Medical Device Security Working Group, but it may become a T-shirt after members catch up. |
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 operation when you’re developing a standard. It’s a very iterative 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 segue 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 risk 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 intimate 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 through 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 IEC 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 tests 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 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 model, 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 doozy. 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 hacktivists 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 TIR 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.
No comments:
Post a Comment
All comments are moderated to prevent spam, so please pardon the delay while our anti-spam team looks at incoming messages.