Fault Injection is a podcast from Synopsys that digs into software quality and security issues. This week, hosts Robert Vamosi, CISSP and Security Strategist at Synopsys, and Chris Clark, Principal Security Engineer at Synopsys, go into detail about a new report from Synopsys and the Ponemon Institute on medical device security.
You can always join the discussion by sending us an email at firstname.lastname@example.org.
Fault Injection, Episode .001: “Paging Dr. McCoy”
Or, read the transcript for Fault Injection, Episode .001: “Paging Dr. McCoy” below:
Chris Clark: Hello. This is Chris Clark, again from Synopsys.
Robert Vamosi: I’m Robert Vamosi, CISSP and Security Strategist at Synopsys.
Chris: Welcome to the second episode of “Fault Injection.” Today, we’re going to talk about something interesting. In our last podcast, we talked about supply chain. This is going to be the first in a couple of different series related to the supply chain and processes around that for different industries.
The first I want to talk about is going to be medical.
Robert: Medical? What does that necessarily mean when we talk about the cyber supply chain for the medical industry? There’s primarily two different pieces to it.
Chris: Arguably, three.
Chris: When we look at medical device manufacturers, we have…
Robert: And then the consumers.
Chris: The consumers and then healthcare delivery organizations who are using these devices in the industry and how do they use them to provide patient care.
Robert: We’ll focus today a little more on the medical device providers and then also the health delivery organizations, the HDOs.
Chris: HDOs. This is what, you as a consumer, typically are going to be familiar with. This is going to be the hospitals, the doctor’s offices, and the organizations that provide you with the healthcare to ensure that you’re healthy.
Robert: Which is interesting when you’re in this field a little bit. You start to see that they are consumers of the medical device technology. You have these people over here building the devices and are being consumed by the HDOs which then, you as the consumer, actually go and visit and use those services.
There’s two different users, two different end‑users. We’re going to not talk so much about the consumer side of things and focus more on the higher end which is the medical device manufacturers and the HDOs.
Chris: HDOs. I got a quick question for you.
Chris: When you go to the doctor, you usually go there for a check‑up, right?
Chris: You are either there sick, you want a check‑up, you want to clean bill health. Do you ever think about those medical devices that they’re using on you?
Robert: Actually, I do because I have a security background and so I’m like, “Why are you still using Windows Vista? Why are you still using…” Anyway, I’m a little different. Usually, the health provider just stares at me and they’re like, “I need to run this test.” They don’t think beyond that.
Chris: No, they really don’t. This is one of the things we want to bring to light. There is this back end supply chain that’s so critical to these devices as they go through the early development phases all the way through manufacturing delivered to these HDOs.
It’s a substantially long cycle. When we look at the regulatory requirements and everything else that goes around that, it could be years before a product from its initial phase of development makes it to the healthcare delivery organization.
Robert: The healthcare delivery organization has multiple vendors that they’re receiving products from. Oftentimes, they need it stat, in a particular place, and they don’t necessarily have the luxury of testing the equipment or thoroughly vetting it.
Other than the fact that it meets FDA approval, other than the fact that it’s been used in other organizations, it’s rolled out there.
What happens when something fails? What happens when something goes wrong? They deal with it in a case‑by‑case basis. We’re here to suggest that maybe you can start higher up the food chain. Maybe you can make those decisions before purchasing, before using.
Chris: And consuming those devices. From a supply chain perspective, this makes sense, because there’s a procurement process. If you’re making this procurement, this purchase of a device, security should be part of that if you’re an HDO, especially when we consider that HDO’s are critical infrastructure items from a federal perspective.
We have to have these in the event of some catastrophic event.
What does that really mean? If we take one of these devices, we break it down. We know that there’s a source code that’s been written by a manufacturer. We also know that some portion of that code has been extracted from third parties, whether it’s open source or some other provider.
As that source code starts to congeal into a product, especially over the development phase of this product when they’re looking at what are the capabilities of the product going to be, we start seeing more and more bolt-ons. Here’s a library that performs this, here’s another library that performs this.
From a manufacturing standpoint, they’re really looking at it, “How can I get that device to market in a reasonable time frame, at a reasonable cost, and provide a level of service for the endpoint, which is that healthcare delivery organization.” That brings up a lot of challenges when we start talking about that, especially from a security perspective.
Robert: Right, and not to fault the medical device industry, but they will try to open up as many ports, make the product as accessible and easy to use on the HDO side of the equation. The problem is now the HDO is exposed because from a hacker perspective, those ports are points of entry.
If they don’t shut them down, if they don’t know how to configure the device, that becomes a problem. You understand from the medical device perspective, they don’t want all the support calls. They don’t want all the hassle in setting up a new system if they can avoid that and make it an easy process to onboard this equipment into an HDO environment. A lot of this has been anecdotal.
This is conversation and you probably hear a lot of that. One of the things we did at Synopsys was we commissioned a survey with the Ponemon Institute and we asked several medical device manufacturers—actually, several hundreds—and HDO providers very specific questions around device security and software security, in particular.
This report is available. You can download it from our website and I encourage you to do so, but Chris?
Chris: There were a lot of surprising results that came out of this particular report, but one of the ones that stood out to me the most was that 45 percent of HDOs have no plan for preventing attacks.
They really don’t have a process in place for establishing a security policy that helps them deal with the potential vulnerabilities that are there, so what does that mean? That means 55 percent of the organizations can address a cybersecurity incident and handle it well.
There’s a remaining 45 percent that aren’t meeting the requirements, either mandated by regulatory requirement or by JCAHO requirements that say they must have an incident response plan. That’s pretty telling.
Robert: You just mentioned JCAHO. Can you briefly explain?
Chris: Joint Commission is one of the organizations that are out there that provide standards for hospitals. A hospital, in order to meet JCAHO certification, must meet certain standards.
They must have standard business practices. They must have policies in place to address specific types of incidents, not only from a security perspective, but also a health care delivery perspective.
They are one of the giants in the America’s markets for ensuring hospitals meet certain levels. Globally, there’s other organizations, but from our perspective, that’s who we typically work with on a regular basis.
I got a question for you.
Chris: When you go to the hospital, you think a little bit differently. You look at some of these devices. What’s the first thing that pops into your mind when you see a Windows CE embedded device?
Robert: [laughs] Why are they still using that?
Chris: Part of that reason is because that development lifecycle is so long, some of these older products are still in production and will continue to be for a number of years.
We talk about a car. Cars have limited lifespans for most people. The end of their loan, and they want to get a new vehicle or they’ve drawn it for a few years and it’s reaches maturity and they get a balance return.
From an HDO perspective, we want maximum value out of that device, so if that means that device is performing its function for 10 years…
Robert: Why replace it?
Chris: Why replace it? Exactly. Until we bring security into part of this discussion, there’s no requirement to start rotating those devices out of production, especially when we look at the manufacturers are required to provide support for the device when we’re looking at delivering healthcare, but not necessarily patching for security vulnerabilities. That’s changing, though.
Robert: It is changing. The device manufacturers are putting end‑of‑life in there, but some HDOs continue to use the device. Again, because if it’s working, why change it up?
Chris: There are aftermarket support alternatives to continue that. Why do I bring that up? Well, part of the reason I bring that up is when we look at devices that have gone into HDO organizations, part of the survey that we did found that 30 percent, on average, of HDOs don’t perform regular cybersecurity testing.
When we talk about cybersecurity and we talk about a supply chain, it’s a never‑ending process, it’s cyclical. Typically, these organizations, if they’ve done their initial security testing, it stops at that point.
Other processes for maintaining the device, training for the device for staff so that they use that device appropriately may continue. Security typically stops. I know you’ve heard some of these types of issues. Does that ring a bell for you?
Robert: It does. I wonder if you could expand from a device manufacturer’s perspective. What sort of testing might they be interested in as opposed to the HDO, which is going to have a totally different perspective?
Chris: Well, HDO has limitations. They don’t have source code.
Robert: Usually, usually. Sometimes, they do bake their own but…
Chris: The glue that integrates different components within an organization, very much so.
That will fall under some of the types of testing that a manufacturer might perform. When we’re looking from the HDO perspective, again, they typically don’t have that source code, so they’re a little bit more limited, but there are things that they can do.
There are sources that they can subscribe to provide them with attack information related to medical devices. They can perform composition analysis testing so that they can get an idea what are the known vulnerabilities baked into this product.
What has that risk transfer been to that organization? How can they mitigate that risk transfer? There are some capabilities that are available to them and really, what it boils down to is understanding knowledge.
This is going to be an ongoing thing that we talked about different verticals in this series. Knowledge is power and if they understand what their risk is because they understand what the known vulnerabilities are, they can be much more proactive, and certainly reactive.
Robert: I just want to add to that mix that having pen testing, having red teams, having services that provide them with the knowledge on an annual basis. You may be good today but how are you a year from now?
PCI, which is over in the finance and retail space requires annual testing and certification, so how do you prove that as an HDO? Need to add that into the mix, I would imagine.
Robert: Some HDOs have been much more progressive.
For example, Mayo Clinic. We’ve worked with Mayo Clinic many a time. That’s an excellent organization. They’ve really established a solid cyber security plan, not only for implementing medical devices, but for that long‑term management of those medical devices.
They’re very happy to share information. They’ve gone through a lot of work to ensure that whatever product they’re bringing into their environment, they’ve worked with the manufacturer to mitigate potential risk and they’re always looking for other organizations to participate in the work that they’re doing.
As an audience member, reach out to them, talk with those folks because they’re doing an amazing job.
Robert: What recommendations might we offer the audience on this? If they’re interested in doing more, how can they do that?
Chris: One of the things that organizations need to do is participate at a community level with regards to cyber security. They need to talk to other hospitals, other organizations, or one, is first off, establish a cybersecurity internally.
Robert: A team.
Chris: A team, a cybersecurity program. Usually, this is a function of IT, but security is not just IT. It needs to be an overall process that reaches throughout the organization. It needs to start at the top and work its way down.
Robert: It needs to have executive level visibility in order to accomplish its mission, but it can be a team of individuals. We call them software security group individuals, and then, oftentimes, there’s satellites of those that operate in conjunction with the security group.
The security group has probably the most visibility with the higher level executives to accomplish its goals.
Chris: Sure, most understanding. There is a class of organization, HDOs that writes their own software. We’ve talked about that. I call that glue. Having worked in a hospital system for a number of years as CIO, we wrote software all the time.
For those organizations, they need to be especially focused on what their supply chain looks like from a cyber perspective and what their internal security practices are.
Because when we look at product that’s been out on the market for a while, it tends to be a little bit more robust because it has been hacked on for a while. If I’m writing my own code, I’m not a security expert, I am opening the door for potential breaches.
For those organizations, they really need to look at having not only pen testing. That should be something that’s coming towards the end of their release cycle. They should look at establishing a secure development lifecycle, which is the very same thing that medical manufacturers are doing.
It’s also incumbent upon them to be more proactive in the types of tools that they use so that when they release code, it’s more robust and that they’re also utilizing other types of tools to test these products before they go to market.
Robert: Additionally, the procurement. If you’re going to be purchasing software that you got from somebody else, you can ask them to attest that it’s been certified or it’s been validated through various testing. You can make the decision whether the risk is agreeable with you or you want to pass on this product and move to another. You have a bake‑off.
Chris: Very much so. Especially, the market has a lot of competition today in the medical space. There’s very few areas where there’s only one provider. There’s almost always three to five providers.
Those bake‑offs, where not only is the procurement or cost process part of the decision making metrics, security should be one of those metrics as well.
Just as on the side, Synopsys does provide a template for procurement language and I know you’re very familiar with that. You want to talk about that for a moment?
Robert: Yeah, it’s an interactive PDF form. You can fill in your requirements, your needs, and you can offer it up to the vendor. That way, the vendor can provide you back the information that you need to make a secure decision in purchasing their product.
On the other hand, as a vendor, you will want to go through some of that testing so that when you’re asked to produce this material, you do have the test results to show that your product has been certified, or at least is aware of its own vulnerabilities. I think that’s a key thing, is just being able to acknowledge.
I’ve heard people that procure say that they will choose the product that has vulnerabilities because at least they’re disclosing them. They don’t have to have a clean bill of health, but at least you’re disclosing and you’re self‑aware that your product has these things.
Oftentimes, these are ones that can be mitigated and dealt with, whereas the other one that comes forward and says, “We don’t have any certifications, we don’t have any testing data to show you,” it’s an unknown black box. You don’t know what you’re getting.
Chris: You bring up two interesting points. One, before I forget, the procurement language is based off of industry standards. This isn’t information that we just put together because we thought this makes sense. There’s industry standards that are out there driving these types of requirements.
Again, knowledge is power. If you know what the standards are, and you know our procurement language looks like, you can be much more effective. We also brought up something that I think is interesting. You mentioned organizations are actually acknowledged that they have vulnerabilities. Why do you think that’s important?
Robert: Again, self‑aware. They’re trying, which is a huge step over everybody else. Just trying to fix the problems is great. You don’t have to solve them all today, but you’re on that journey, you’re on that pathway to getting to secure software.
Chris: You as an HDO, if you have that information, you can take mitigating steps. A lot of times if you don’t know about it, you may get surprised by that. When you go back to the vendor, and the vendor says, “Oh, here’s a patch for that,” it’s too late.
As we’ve seen with the number of the ransomware attacks and other cyber events that have taken place, the manufacturers name is not the one that’s typically in the news.
Robert: It’s the brand.
Chris: It’s that end point. It’s that last end point brand that takes the hit for that. You want to work with those types of organizations that are willing to disclose that information, and communicate with you, and have a back and forth on how you address these particular challenges.
Robert: We’ll continue that discussion in subsequent episodes of this podcast. The next one in particular, we’re going to be looking at a report that we did ourselves on software composition analysis.
Not every piece of software is composed in the same way. It has pieces that come from other parties and that self‑knowledge is important there, very important. You want to make sure you’re using the latest and greatest code libraries.
We’ll talk about that in our very next episode. As always, there are opportunities for you to provide feedback whether it would be the email address, or comments below. We love to hear your thoughts, and we’d love to incorporate that into future episodes, and we might even invite you on as a guest.
Chris: Very excited about that. Thank you all for joining us and looking forward to seeing you on our next episode.