Presentation: Cybersecurity for Networked Medical Devices Containing Off- the-Shelf (OTS) Software
John F. Murray Jr.
Software Compliance Expert
US Food and Drug Administration
- A cybersecurity vulnerability exists whenever the software provides the opportunity for unauthorized access to the network or the medical device.
- Vulnerabilities in cybersecurity may represent a risk to the safe and effective operation
- Failure to properly address these vulnerabilities could result in an adverse effect on public health
- This guidance outlines general principles that the FDA considers to be applicable to software maintenance actions required to address cybersecurity vulnerabilities
- The QS regulation, 21 CFR Part 820, applies to software maintenance actions.
- FDA has issued several guidance documents on software, including:
Which medical devices are covered by this guidance?
- Medical devices that incorporate off-the-shelf (OTS) software
- Medical Devices that can be connected to a private intranet or the public Internet
- This information also may be useful to network administrators in health care organizations and information technology vendors.
Who is responsible for ensuring the safety and effectiveness of medical devices?
- The device manufacturer bears the responsibility for the continued safe and effective performance of their medical device,
- The device manufacturer does not bear responsibility for the Hospital Network
What should the user do?
- FDA recommends that purchasers and users of medical devices contact the medical device manufacturer
- The user should not attempt to make changes without seeking the device manufacturer’s advice and recommendations
- Have a approved plan to address cybersecurity patches that includes a risk management and assurance system
Is FDA premarket review required prior to implementation of a software patch?
- Usually not
- FDA review is necessary when a change or modification could significantly affect the safety or effectiveness of the medical device
- refer to our guidance entitled, "Deciding When to Submit a 510(k) for a Change to an Existing Device."
- It is possible, but unlikely, that a software patch will need a new 510(k) submission.
Should software changes made to address cybersecurity be validated?
- All software design changes should be validated including
- Computer software changes to address cybersecurity vulnerabilities,
- Software changes intended to address cybersecurity vulnerabilities, analysis, inspection, and testing should be adequate and clinical validation should not be necessary.
- All software design changes should be validated including
What else should I do to ensure cybersecurity for networked medical devices?
- Maintain formal business relationships with your OTS software vendors and medical device manufacturers to ensure timely receipt of information concerning quality problems and recommended corrective and preventive actions
- Develop a maintenance system to assure that cybersecurity maintenance actions do not impact device operation.
- While it is customary for the medical device manufacturer to perform these software maintenance activities, there may be situations in which it is appropriate for the user facility, OTS vendor, or a third party to be involved.
Transcript for "Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software"
With that I’ll go ahead and get started. I will introduce each speaker before they present. Our first speaker is John Murray. John is a software and electronics records compliance expert for the Office of Compliance in the Center for Devices and Radiological Health at FDA. John is the primary advisor to the Director of the Office of Compliance, in the areas of software validation, software policy, software classification and electronic record compliance.
John joined FDA in March of ’94. Previously, John was a Qualified Reactor Operator with the U.S. Navy Submarine Fleet, a Computer Field Engineer with Telex Computer Products, and Electronics and Software Engineer with the General Dynamics Corporation and a Systems Engineer at Technology Management and Analysis. With that, I’ll turn it over to John Murray. John?
J. Murray: Good afternoon everyone, this is John Murray here. I want to talk about the guidance document that we published in January of 2005. But most importantly, I want to put out the word that we’re really at the beginning of this journey. The issue of cybersecurity and the issue of the use of off-the-shelf software and the integration of proprietary products with third party products is kind of a long-term issue or long-term problem that’s going to require a lot of work by a lot of folks.
I really envision this problem as being owned by four different parties. The first party is the Food & Drug Administration. The second party would be the medical device manufacturer. The third party is what I refer to as the IT users (Information Technology User Group) which are mostly hospitals and doctor’s offices. The fourth party is what is referred to as the Independent IT Providers, the Information Technology Providers, like the IBMs, the Microsoft’s, the Cisco’s of the world and things like that.
What we’re trying to do here, is we’re trying to get all the parties together, so that we can talk about issue, because many times it’s not clear who owns responsibility for the problem. What each party should be doing. What we’re trying to minimize is all the finger pointing that has been going on for the last year and a half or two years. So the idea is to put together these events and get some folks to the table, so that we can actually start putting our points of view out and we can come to some kind of resolution.
There’s another event that we’ve scheduled for May 26th. It’s going to be sponsored by AdvaMed, here in Washington DC; it’s a one day workshop. If you go to the AdvaMed Web site, you can get some information on how to register for that. Currently for that event we have a guest speaker from Microsoft, from IBM and from Cisco appearing. So it should be a great opportunity to get all four of these groups together in the same room and actually discuss this issue.
I’m moving on to slide number two. The question is what is the issue? Well the cybersecurity vulnerability exists whenever the software provides the opportunity for unauthorized access. This is problematic, because once the doors are open, some unknown force or unknown hacker or virus can penetrate the inner workings of a medical device and this represents a risk to the safe and effective operation of these devices. Medical device manufactures spend a large amount of time and money and effort in making safe devices, and cybersecurity represents a hole in that.
The failure to properly address these vulnerabilities could result in an adverse effect on public health. It’s unclear at this point what that risk could be, and I will point out to-date, in our entire database, we only have two reports of incidents related to a cybersecurity threat or cybersecurity vulnerability. But I want to make it clear that FDAs issue in this is the safety of medical devices. We fully recognize that there are other issues that are around like compliance with HIPAA, from Sarbanes-Oxley issues, but we’re mainly focused on the safety of medical devices.
Slide three, please. Over the last two years we’ve received a lot of phone calls from device manufacturers, from hospitals, even from Microsoft itself, and there seemed to be a lot of confusion about what FDA laws and regulations actually applied. So when we sat down at the table, we decided that we should write a guidance document to reinforce what the regulation says.
Our current position is that this is not a new policy or a new regulation; this is merely pointing out or providing a roadmap to the elements in the regulation or in the policy that currently applied to cybersecurity. So this guidance outlines general principles that FDA considers to be applicable to the situation. Of course the quality system regulation applies to software maintenance actions, which a cybersecurity update or patch is on software maintenance activity.
We’d further like to point out that existing FDA guidance documents, there are three of them listed at the bottom of slide number three, if you go look at the material in those guidance documents or software, you will clearly see that the maintenance and the validation of cybersecurity patches, would easily fit within the instructions and guidance in those documents.
Slide number four, please. The next most common question that comes up is which medical devices are covered by this guidance document? Clearly the medical device that incorporates the use of off-the-shelf software, which is where most of these cybersecurity vulnerabilities occur, this guidance applies to. These devices are devices connected to private Intranet or public Internet connections. In other words, there has to be an opportunity for a risk to exist.
We also believe that the information that’s in this guidance document could be helpful to the user, to the hospitals themselves, by understanding and having an appreciation for the regulatory process and the validation process that we go through on a regular basis. Hopefully they can help us understand this problem a little better and actually provide a solution in a quicker fashion.
Slide number five. I often hear the question, who is responsible for insuring the safety and effectiveness of medical devices? Clearly under the food and drug law, the device manufacturer bears the ultimate responsibility for the continued safe and effective performance of their medical device. However, the device manufacturer does not always bear the responsibility for the hospital network.
This line can become very blurred at times, because just about every hospital I take a look at, for every situation the engineering configuration is different, the type of equipment is different, the equipment provided by device manufacturers are different. Some device manufacturers actually provide networks and some do not. So this line is very, very blurred and it’s going to require an effort on both sides of this problem to actually solve that.
I do want to point out that from and FDA perspective, we have no regulatory concern for compliance with HIPAA. Although we think it’s important, from a personal point of view, we don’t have a regulation that requires us to ensure that medical device manufacturers are HIPAA compliant.
Slide number six, please. We get questions all the time about what we think the user should be doing. The number one thing is that we need the purchasers and the users to be in a continual contact with medical device manufacturers. A lot of folks just buy these products and it’s an event that occurs once every two or three years. We’ve discovered in this integrated environment, with the use of products from multiple sources that that’s no longer sufficient. We require some kind of continuous contact or continuous relationship between the users and the device manufacturers.
We also believe you should have some kind of continuous contact with the off-the-shelf software provider. I got an opportunity in February, to go out to Microsoft and speak for their computer security officer’s conference. I discovered that they’re actually setting up a system, and they call it an early warning system, where you as a device manufacturer or a user can get signed up in a program that allows you to sign a non-disclosure agreement with Microsoft and they will give you up-to-date, early information about upcoming threats. So this occurs, maybe two or three weeks, before the actual patch arrives on the scene.
The problem we’ve had in the past is that this patch would be popping out the end of the tunnel and when that patch arrives, that gives a flag to the hackers and the virus makers of the world. So this could give us a running start on the problem. I suggest that you could contact Microsoft, and if you send me an e-mail, I can probably put you directly in contact with the people running that program there. The second piece of guidance or information that we’d like to put out is that we don’t believe that users should attempt to make changes without seeking device manufacturer’s advice and recommendations.
Now to me, this is merely common sense. When I look at the back of my television, I clearly see a sign that says, “To be serviced by qualified personnel, only.” We believe that the device manufacturers know best about the safety packages and the criteria from which the devices were built. We don’t suggest that users go about making changes without some interaction or some guidance from their manufacturer.
We also suggest that in each hospital, each user facility, where you’re actually involved in devices that are networked, and you have hospital networks, I think everyone does, it would be a really great idea to have some kind of proof plan in place that actually addressed the risk management and the assurance system that you’re going to use to address this problem. I know that hospitals do a really great job at this with everything else. They have controls in place, they have procedures in place and they go about their business in a daily base, but for some reason, we as a society have adopted a new philosophy when it comes to patching our software.
I’m not sure where that comes from, but my recommendation is if you apply your current biomedical engineering practices and thought processes and risk management process to this problem, you’ll have some great success. The way to do that is by addressing the problem in the way you’d address any other update or change to your system, by having a plan, a standard SOPs, standard training and things like that.
The one thing you should absolutely not do is turn on the automatic download feature of any software product of a hospital network or a hospital medical device. That could be disastrous. You don’t really want Microsoft or IBM or Cisco controlling the configuration of your hospital network, without you having some kind of prior knowledge.
Slide number seven, please. Another question that always comes up is; I’ve gotten calls from users and they’ve said they’ve call the device manufacturer and the device manufacturer says, “I can’t do anything, I have to get FDA approval.” So we went back and examined this question and the answer is that pre-market review of a software patch or a cybersecurity update, usually does not require and FDA pre-market approval.
There is a guidance document under bullet three there, and it’s available on our Web site, about when to submit a new 510 (k) or a new pre-market submission. The rules are basically still the same for cybersecurity patches, as they are for other changes. One is if it does not change the intended use of a device, there’s no requirement for pre-market submission. Two is that it doesn’t introduce any new elements of risk.
Our opinion is that we can’t think of a case where a cybersecurity patch would represent a change of intended use or the introduction of new risk. In fact we believe that this is a decrease of risk. Although we don’t absolutely say 100% of the time that this could be true. We really believe that it’s unlikely that a software patch for cybersecurity would require pre-market approval.
Slide number eight, please. This is the million dollar question. Can software change made to address cybersecurity be validated? The answer is yes. Any change made to any medical device, requires some kind of validation or some kind of assurance that it works correctly. All software design changes, which are cybersecurity patches, a software design change under the regulation, requires validation.
The key to this is it doesn’t say 100% validation. It doesn’t say to go back in time and redo all of the validation and all the assurance activities you’ve done to that point. You have to do what is necessary. The way to address what is necessary is by analyzing the problem, understanding your networks and understanding your devices. In other words, do your engineering homework. Then you’ll be in a better position to make valid decisions about what kind of assurances or validation you need to put in place, to address these cybersecurity changes. It’s very, very important.
We say in our guidance document that we believe that analysis inspection and some form of testing should be adequate and clinical validation should never to necessary for a cybersecurity patch. I think the key thing here is that you have to do your homework, you have to have an ongoing program and you have to understand your domain to be able to make good decisions. It doesn’t make much sense to just put these patches on a system, in an automatic mode or in any mode, without some kind of assurance activity.
You should always keep in mind, and I think Scott, who is a speaker today, said, “Well you can always disconnect a device from a network, you need to get work.” That’s kind of an extreme case, but you know, that’s pretty true. If you feel some kind of threat from the network and you need to use the device, you should have some kind of alternative plan in your facility, to use this equipment.
I really hate it when I go into a store and I can’t buy anything, because their cash registers are down, and nobody knows how to fill out a paper slip. So it’s kind of the same situation. We have to be prepared. We can’t always accept the benefits of this technology without recognizing that there’s some risk that we need to take on.
I’m on to slide number nine. We were asked a question about what other things we should be doing to ensure that these medical devices remain safe. We recommend a formal business relationship between the off-the-shelf software vendors and the medical device manufacturers. The reality of it is that we haven’t done a very good job of this in the past. But we’re not going to go around and blame the past and point fingers. The idea is, “Hey, we could have done a better job.” So in the future, when you write an RFP (Request for Proposal, Request for Quote,) you need to put this kind of information in there.
Of course it’s going to cost money, nothing in the world is free. But the continued use of this technology, we need to address the risk, as well as the benefits of using these. So you need to maintain some formal business relationship. My suggestion is that even if you know that the vendor can’t provide it right away, you do want to put it in there, and then you can change the RFP/RFQ later.
When the FDA comes along and starts asking you questions about what you’ve done about these things and you have no documentation or what I call breadcrumbs, you’re going to be in a non-defensible situation. What you want to do is keep track of these things and keep trying to get these technologies in these things. You need to develop a maintenance system, to provide this assurance, just like you provide assurance for other biomedical engineering activity in your hospital.
Our recommendation is that each device manufacturer, with his product line or his product, has some kind of maintenance plan. This could be in the user manual or it could be under the contract. It’s not quite clear how this should be conveyed, that’s kind of a business-to-business issue. But the idea is that once you have this in place, you have a better understanding of who’s responsible for what. The idea is that the device manufacturer provides the engineering leadership. He may delegate some of that authority or some of that activity to the hospital, and that would be a very good thing.
Before I conclude, I don’t have a slide for this, but the other question I’m always asked is does the FDA regulations prohibit a user from updating his own medical device? The answer to that question is no. I get phone calls all the times, from users, and they’re being pressured by their administrative staff or their executive staff, to put this patch on. They want to defend themselves by putting the FDA flag up, saying, “Well the FDA says that I can’t do this.” Well there’s no regulation that prohibits a user from modifying a medical device.
However, when you do so, you open up a whole new category of risk. It’s really unclear, under the law, as to who would actually be responsible for the safety and effects of that device. This is one of those areas that need to get worked out, and hopefully we can have more discussion about that in the future.
I think that’s all I have to say today. I’m not sure who is next, but it’s been a pleasure to speak to you, and I hope that I’ve added some insight and value to the subject for you. Thank you very much.