Medical Devices MUST Be Secure

The FDA states that MDMs (Medical Device Manufacturers) can always update a medical device to strengthen cybersecurity, and the FDA typically doesn’t need to review the update. You should provide instructions to the team responsible for updating your device, implement a secure update procedure with public/private key structure, and build in fail safe code so the device is not in operation when you update.

Yes, in one way, but I think Robert made a great point that there's just a wide range of things that need to be implemented. A password can prevent somebody getting to it, but they can buy one of your devices and start working on it outside of a hospital environment, or steal it, or whatever. So you can't count on your users and put the onus on them to say, "You have to keep our product secure." You have to build security into your devices. I think Robert did a great job talking about the procedure for updating products and maintaining security in the environment where the product is deployed.

That's a great question, Rich. And the fact is that the FDA does not do specific testing for any kind of malware infection or cybersecurity. They're issuing constantly evolving recommendations, but there's no specific testing, and they state explicitly that it's the responsibility of the medical device manufacturer.

I would say that, for truly best-in-class security, you actually need a combination of both hardware and software. Hardware brings some of the things that we've discussed, such as anti-tamper capabilities into the mix. Software starts to give you logical source of attacks. So, if you think of the anti-tampering as a physical countermeasure, when you combine both hardware and software together, you get the best of both when it comes to logical and physical attack vectors, as far as what you can protect against. The other thing to consider, though, of course, is the nature of the information you're trying to protect. So, you may need different functionalities from a hardware or a software perspective, depending on what protection profiles you're targeting with your device.

Robert: Yeah. And I'll just step in. I mean, just to extend that, that's why I spent time on my part of the presentation talking about taking advantage of the hardware. There are many things that the hardware is capable of doing or capable of helping with the software, but the software needs to be there to take advantage of all of that, you know. And it's only with the two working in concert that the device can actually become more secure.

In cases where you're not sure where to start, or what level of security is necessary for your application, we get this question often of, you know, "I'm not a security expert. How do I get started?" The easiest thing to do, of course, is to find the standard that's most applicable for what your device class is, and use that as a starting point. And ultimately, if you're not sure even what standard to start with, NIST is always a good place to start, for example, National Institute of Standards and Technology. They have a cybersecurity framework that they've actually published, and that can be used as a guide for novices as well as veterans alike in the security arena. So, that would be one place that I would definitely recommend to at least start taking a look at if you're not familiar with security, or if you're new to security.

And then, some of these other standards that have been discussed throughout the webinar as well. So, for example, Bob had mentioned FIPS. It's another NIST standard, if you will, that we see a lot of people targeting or looking to design towards. The other thing that you can do is you can also consult with partners who are experts in security, such as the people that are on the call today, myself, Robert, and Bob. Or, if you have your own in-house expertise, of course, utilize that as well.

Well, I can do the one-word answer for that, which is nothing. You know, the techniques that I think all three of us talked about today aren't really specific to the medical market at all. They are more general things to think about if you're doing autonomous drive, right? The security requirements and techniques are essentially the same.

The difference really is in emphasis, you know. If I'm doing a consumer device, and my consumer device gets compromised, and personal data gets transmitted to the bad guys, or a web application, or whatever, that's embarrassing, and it's costly. But the laws are entirely different.

The scrutiny done by regulators is entirely different. Most other industries look at security as basically what happens when the barn door gets open and the horses have all escaped. Whereas the medical regulators are really trying to make sure that you lock the barn door before the horses escape. And that's where all of that emphasis is. It's not just you, and then how do you deal with it after it happens. It is the regulators saying, "Hey, how are you going to prevent this from happening?" And so, even though it would be right to consider all of these things up front for any kind of device, the medical industry requires it.

Patrick: Robert, one more thing that I would add to that as well. I often get the comparison, people saying security is a little bit like insurance. And it is. But when you talk about the medical industry, in particular, I would say, yes, it's like insurance, and the liability is a lot higher as well in medical applications.

Well, like I said in my presentation, nothing's perfect. But the kinds of steps that we've all talked about in our individual presentations really do help. If it is difficult or impossible for a hacker to get a device so that they can probe it and figure out its weaknesses, or the device becomes somehow invalidated when that happens, then it makes it a lot more difficult for them to figure out how to attack the device.

If your software is developed using preventative techniques, and is using high-quality security best practices, then even if they get access to the device, it will be much more difficult for them to inject, say, malware into the device, which is where the ransomware and other attacks on the hospital network come from. And so, at least you can protect the device to the greatest extent possible, and then you hope that the other providers of the hospital network are doing the same, and therefore, the hospital network will at least be more secure.

Rich: And I know you said it makes it more difficult, but not impossible.

Robert: Yeah, it goes all the way back to, you know, the armed guards and the concrete-encased device.

Sure. We get that from our customers, too. And the challenge is the trade-off in time. I mean, the things that Siemens has implemented, and Digi has implemented, and Infineon had implemented and/or will make available to our customers, can all be done using open source software. But it's a huge amount of work, and time, and essentially you're on your own, collecting your own tools, your own pieces, and integrating them on top of the open source hardware. And you have to get it right! So, it's a lot of time, and then you have the issue of certification, going through the different global certifications and showing what you've done, when, again, you just won't have any support from your vendors for that. So, I guess the shorter answer is, yes, it's possible, but really, extremely difficult.

It is important to design detection features into a connected device. This can include logging attack attempts and examining the logs for unexpected activity on a device. It is also possible to detect network activity to unexpected IP addresses or activity by a device. If a device fails or begins to malfunction, you should remove it from the network and test for malware or code that does not belong on the device. There are companies and labs that can test devices for the presence of malware.