Select Page

Tyler Curry

Hello, everyone, and thank you for joining us today. My name is Tyler Curry, I’m a Cyber Threat Intelligence Analyst at Health-ISAC. I will be your moderator for today’s webinar, presented by Irdeto. Irdeto is one of our trusted Navigator participants at Health-ISAC.

Today’s Navigator webinar comes to you in a form of a discussion exploring concepts pertaining to security by design, software bill of materials, and Pen testing, amongst the host of other topics related to critical device security. You can expect to hear valuable discussion topics surrounding recent attacks and what they mean for connected health cybersecurity, the importance of complexity and surrounding SBOM, key security principles under various medical device cybersecurity guidances, and steps taken today that future-proof connected medical devices.

Today’s panelists include Dr. Hans-Martin von Stockhausen, Chief Product and Solution Officer and Senior Product Manager, Cyber Security at Siemens Healthineers, Steeve Huin, Chief Marketing Officer and GM, Connected Health at Irdeto, and Chris Reed, Director of Digital Health and Product Security, as well as global regulatory policy at Medtronic. Just a few housekeeping notes to announce, all attendees have been muted for this discussion. The Webinar will be recorded and made available for future use, and please feel free to engage by posting questions to the chat section, which we will dedicate 10 to 15 minutes at the end of the webinar to address.

So without further delay, Let’s begin.

Six months into 2021 and cyber security has consistently been on the front pages in the healthcare industry. I’d like to get some first impressions from our panelists on their experiences so far, and some views on the meta-trends impacting medical device security. With that, I would like to go ahead and start that with Chris.

Chris Reed

Thanks, Tyler. Obviously the trend continues in 2021 of just, as our societies increasingly rely on technology and connected devices, the implications of security issues just continue to show their impact on all of us. I think a couple of recent examples, the solar winds issue at the end of last year and the exchange vulnerabilities, as well as the colonial pipeline in the US, just illustrate how interconnected all this is and how important it is, and really just emphasizes why in health care we need to be preparing and making sure our products and environments are resilient to attacks. So I think it just continues to illustrate that point.

Tyler Curry

Nice. Hans, what insight would you have?

Dr. Hans-Martin von Stockhausen

The most striking event for me was the attack on the Irish health system, which had a large impact, and I think there are still hospitals recovering or being on paper-based workflows and paper-based processing until they get everything back online. There was some interesting aspects to it.

First of all, of course, why the attackers gave or released the key to decrypt the data. So you never know what… Now, with the new trend of not keeping the machines ransom, but rather have the data exfiltrated first and doing something with it potentially later or for further ransoming.

The key learning, and this is an aspect we’ve seen in other such scenarios was that the customers are asking us to prove somehow that any network nodes which are not obviously infected, to somehow prove them being in a clean state, which is a bit difficult for a device which utilizes a full-fledged operating system.

Of course we do have meta protection. White-listing in this scenario is not really helpful because you would have to do some forensics in order to prove it was not infected. Pattern-based would be easier to prove, but of course pattern based meta-protection comes at a price that is not easy to pay in our scenario. So this is a challenge still, do full forensics, do an external-based scan of the system to prove the absence of any patterns, or even just reinstall it, which would be the most straightforward way, but of course, comes at a cost as well because of the effort to set up systems again afresh.

But from a customer’s perspective, I guess it’s important for them to get some kind of proof that putting that node back onto the network is reasonable and safe.

Tyler Curry

Great. And Steeve, what would you say?

Steeve Huin

In 2020, what we’ve seen is an increase of about 350 percent in cyber attacks, and I wouldn’t expect 2021 to be any better in practice.

And I would certainly second the comment on attacks on the Irish healthcare provider that security been hit quite significantly in this space. For me, perhaps the good news, if there is one, is that the policymakers are starting to actually take actions. And you’ve seen, for example, the executive order that’s been signed by Biden recently is probably a good step in the direction of addressing some of the problems.

Tyler Curry

Absolutely. That takes us into our next discussion here. I want to jump in and talk about software bill of materials, or SBOM. We’ve been hearing a lot about it lately. What are the key challenges for medical device manufacturers to build an SBOM, and how can they maintain it, making sure it’s usable for healthcare providers? To start, let’s go back to Chris on this one.

Chris Reed

Sure. Tyler, as you mentioned, we’re definitely hearing a lot about it lately. It’s really been an effort that’s years in the making, a lot of people pounding the drum for a while, like Alan Friedmen and leading the effort at NTIA to bring all the stakeholders across all industries together to figure out how to create these SBOMs. I guess before I talk about the difficulty, just SBOM in itself is really just an artifact, but it can be used in so many different use cases to help build trust and help risk management happen effectively in the ecosystem.

SBOM in itself is really just an artifact, but it can be used in so many different use cases to help build trust and help risk management happen effectively in the ecosystem.

And that’s why the executive order that Steeve mentioned 14028, if I remember the number off the top of my head, is really established. It forced NTIA to start to push this process along and name some minimum elements of an SBOM that have to be present when you sell software to the US Federal Government. That will start to lay the groundwork that the echo will happen across all industries. I guarantee you that whatever minimums get set there will probably be what regulatory agencies like the FDA looks for at a minimum. 

So in as far as the challenges for healthcare, there definitely are a couple. First, just around SBOMs in general, the community has been working towards how to make these effective. But there are definitely problems. We have issues, like with common naming space for software products, like how do we label them the same way so that we all know we’re talking about the same product? How do you create an SBOM for something like a web app versus a mobile app versus embedded software, and have it all interoperate and use the same fields? 

So there are a lot of practical issues that the community is still working through, but I guess what I’m encouraged about is it’s clearly…  

Clearly the time has come where there’s no longer excuses, we have to start getting it done and make it happen.

And I think for medical device manufacturers, if you’re doing submissions lately, the FDA’s already been expecting this in the US. IMDRF requires it elsewhere.

I think right now there’s a lot of flexibility on what that content has but figuring out how to get it built into our life cycle so that they’re available to customers and to regulators, and that they’re accurate in that we have cycles that are continually refreshing that.

There’s still a lot of problems, both on how to generate them, as well as how to consume them effectively on the other side. So as you can tell, these are numerous issues but I’ll let my esteemed panelists weigh in too.

Tyler Curry

Nice. And Steeve, what insight would you have?

Steeve Huin

I think Chris was very spot on. I think there’s a number of challenges in terms of using a common language and making sure that it’s possible for everyone to start using it in a format and content. But at least it’s teething problems. Hopefully in the next few months, or perhaps that’s probably too optimistic, perhaps the next year or two, these are things that that we’ll tackle with. We certainly see indeed more and more guidelines that are recommending it around the world.

We also see actually customers starting to want it because they see that there’s a long-term benefit to it in terms of enabling trustability, also for themselves, so it’s only a value add for the industry.

Tyler Curry

Absolutely. And Hans?

Dr. Hans-Martin von Stockhausen

I completely agree about the value-add, and I was surprised about the existing ideas already. I read in that request for information from the NTIA that recently was presented to different use scenarios just from mere transparency to really support it, risk management, operate it on the consumer side. And I think this is where the concept still falls short if you just provide a mere list of components. Because without any design knowledge, as a consumer you may always overestimate the risk that’s presented by knowledge of the SBOM or running the SBOM.

Again, any threat repository based on vulnerabilities for the components on the inside of the SBOM, because not knowing what other controls are in place, how the A component is used in the first place, which portions of a third-party component is actually utilized in a product in your endpoint on your network, you don’t really know how severe a vulnerability is. Which means that on top of actually creating the SBOM, communicating the SBOM, maintaining it being current so it matches the actual installation on site, you always need that piece of design information. Ideally already the evaluation of any vulnerability associated with a component on the SBOM, which can only be provided by the manufacturer or some… maybe another organization knowing how that component is utilized inside of a product.

We are doing SBOMs for a while already, and I’m enthusiastic about the transparency, but I’m still… I have not yet found a global or universal solution for how to really make it useful for consumers in the risk management scenario.

Chris Reed

I’d like to get on that too, real quick, I think it’s really important. This is going to take a little while to have effective risk management from a lot of these and we’re all going to… Every stakeholder is going to have to be patient with each other as we really learn how to leverage these. But, what I love about it is …

I really do think the SBOM will get us to an objective source of at least starting the conversation from a ground truth.

So many times it’s, ‘Tell me your software is secure,’ and how do you objectively do that?

And I think what people need to be patient about, like Hans-Martin said, just because you might see a vulnerable component in there, it doesn’t mean the actual device or component is vulnerable. Steeve, go ahead, I see you…

Steeve Huin

No, I concur, and I recently read an article that was giving an interesting analogy that ultimately the SBOM could be seen as an equivalent to food and the list of ingredients that’s in there, and that allows people that are allergic to ensure that they can take the steps to stay away from it. Now, I think in this context, at least it enables care providers, for example, to… ‘Ok, there might be something. Let me isolate that device from the network and let’s check with the manufacturer if indeed there is a problem or not.’

So at least that enables taking the proactive step as opposed to being in the dark.

But I concur that it’s probably going to trigger overreaction, but perhaps in this instance that might be better than not reacting. 

Dr. Hans-Martin von Stockhausen

I guess the most prominent and the most wanted piece of information in the SBOM is the operating system, assuming that your endpoint is based on some standard operating system. So for a small device… Well, of course there might be some variant inside. But if, for example, you’re running a Windows-based endpoint with your product, then it’s important for the customer to know, the operator to know which operating system version is running at the bottom of the device. If that’s not communicated somewhere elsewhere or in parallel to the SBOM. That’s most likely the piece of information everybody is looking for. 

Tyler Curry

Absolutely, all very informative perspectives. SBOMs can definitely aid in the development of a more secure ecosystem of devices for all parties involved, for developers, buyers, and operators, so nicely put. What do medical device manufacturers need to know about the steps they should take to identify risks and mitigations from the early design stage? I’ll start with Hans first. 

Dr. Hans-Martin von Stockhausen

What we came up, or not came up, but identified as a very helpful scenario is, of course, having some kind of a secure development life cycle and integrate the necessary actions or process steps into it that allow you to identify the risk. First of all, having some kind of security requirement list that maps various standards to actual product requirements, and which should be provided to each product before or in the starting phase to evaluate whether these controls in the requirement lists are applicable to their scenario, and add it as a base to the actual functional requirements. 

And the next step, which is more specific or more individual to the product, is, of course, running a threat and risk analysis in an early phase to capture the individual risks of the scenario of running a device, and add the mitigations for those after evaluating the risks and the mitigations of their remaining risks should be added as requirements to the product to ensure that you also test them at the end. And from there, of course, start into your secure development life cycle with an architecture design guideline, including security aspects to avoid the programming or implementation errors. 

Of course, having third party component management of some sort which leads to the SBOM in the end, but be aware of additional risks that you, or additional vulnerabilities that you add to your product by making use of third-party technologies, and be sure that you keep track of the versions so that at the time of… If you’re close to release of the product, that you include the most recent or at least a version that does not contain unnecessary or known vulnerabilities to release a product without known vulnerabilities in the first place. 

Tyler Curry

Okay, and Steeve? 

Steeve Huin

Well, it’s certainly not easy. There’s many great resources out there, including the METR57, for example, that’s helping, I guess, understand what are the risks in the pre-market stage, and help basically draw a security assessment and understand what are the … what are the risks, and how should you mitigate against that. So, I think that’s the critical inception point as companies focus on designing new products. It’s certainly a good starting point, and that’s where we see a lot of pull in the market at the moment, because there’s a lot of companies that are in need for help, and that’s certainly not easy. 

Chris Reed

Maybe just sharing, I think one of the biggest lessons learns I try to share. I sit centrally and help lots of different product teams. And making sure that … you hear the term threat modeling used, but the thing I want to emphasize about that is: identifying what those key sensitive use cases are in your product, and making sure you understand those things inside out, how they should work, and then applying all the threats and make sure you’ve managed them. 

One thing I’ve seen and you can see this, and it’s really subtle in some of the FDA documentation, but I know through my experience, they’ll talk about making sure you start just by sharing use cases. So, for instance, if you’re pairing an insulin pump, that’s a sensitive use case that you should start just by detailing, here’s how it works, and here’s all the controls we’ve got. And then here’s all the threats that we’ve thought of and why we resisted those, and the controls that are in place. 

Being up front about, ‘These are the risky areas of our product, and we’ve clearly thought through this in the model,’ I think, is one of the best things that can help you with both your regulators as well as your engineering teams. 

I know sometimes when we are doing the modeling with our engineering teams, some of the assumptions they make, they realize, “Okay. I really do need to go in more detail.” And I will tell you, we found major flaws as we go into some of those detailed processes where that wouldn’t be caught by any scanning tool, and honestly would have been hard to catch on a penetration test. So it really is an invaluable process. But it is still, unfortunately, more of an art than it is a science. 

You’ve really got to pick those areas of the system that you know are riskier and make sure you give appropriate energy with that.

Tyler Curry

Absolutely. What can the health care industry learn from so many big cyber security incidents in 2021, for example, ransomware disabling the Irish Healthcare Service, which was previously mentioned, and disrupting a hospital for weeks. Steeve, what’s your insight view on that? 

Steeve Huin

Yeah. So the HSE attack is fascinating, and most of them end up being fascinating in practice. This one was based on Conti ransomware which was very sophisticated. It was designed to be protected against reverse engineering. It was designed to make it really hard for people to understand the malware itself, and that that’s, I think the most important thing to realize is that ultimately the attacks are becoming more and more sophisticated in nature. In this case, I think it’s about 700 gigabytes of patient data that ended up leaking, and the whole network was taken down as a consequence, and that’s unfortunately just the beginning. 

It is absolutely critical going forward for cyber security to be considered from basically the beginning of the design phase of products going forward.

It’s anything that has connectivity needs to have careful consideration, and it bounces back to the previous question, you need to do an absolute stellar job at identifying what are your assets? What are your threats? And making sure that you actually mitigate them?

Tyler Curry

Nicely put. Chris, what would you say?

Chris Reed

Yeah, I think, again, just goes back to the complexity. I think there’s a growing… I always try to describe threats in two different planes, the target of opportunity. You got to have the basic hygiene in place to meet today’s threats, and that’s really difficult. It’s easy, it sounds easy and we can all sit and throw lots of shots across the bow of, ‘why can’t they do basic stuff?’ But when you have a health care network that has probably thousands of devices and hundreds of applications, making sure each one of those is secure enough to handle something like ransomware is a lot harder than it sounds.

But at the same time, it’s important to invest in that, and you have to be able to secure yourself against what I call just being a target of opportunity. And then again, on the medical device base, like Steeve said well, you’ve got to make sure that even if someone is targeting your system, that you’ll be able to resist those attacks. And so I think it’s really difficult when you consider the scale that some of it…

It only takes a couple of weak points, and before you know it, there’s enough trust gained that you can rip through environments.

And I think that just shows you why we need more effective ways to find and deal with the biggest risks, because the other thing we need to balance here is costs, right? Healthcare is already expensive, so we don’t have an infinite budget. We’ve got to figure out more effective ways to identify and manage those risks.

Steeve Huin

Yeah, and maybe just to bounce on this for a second. Sadly, it’s a complex problem because often times more than not, there are also people involved that are certainly not trained enough in cyber security. And it’s not always fair to expect them to be. But if you look, for example, in a completely different domain that, for example, Electronic Arts that essentially got hacked about two weeks ago, the attack occurred on the basis of somebody joining a Slack channel and say, “Hey, I lost my password. Can you resend it to me?” And the IT Department just complying. So sometimes unfortunately there’s also humans involved, and that makes it even more complex.

Tyler Curry

Absolutely. Hans, any insight?

Dr. Hans-Martin von Stockhausen

I guess just to continue on that, the human factor, the human endpoint is the largest attack surface typically in such a scenario, because I think most of the ransomware scenarios, they rather start with that click on the wrong attachment, or the attachment in the wrong email, or the link in the wrong email, adding or opening the door for the actual attack later on. And if I’m correct, then the majority portion of the attack was interactive in the first place. Of course, it helps to protect or to keep your devices updated, provide patches to the customer as a manufacturer, kind of making sure that they also consume and install them too, because otherwise they’re not in effect.

But on the other hand, it’s important to know that it’s not always a missing patch, but it’s usually, I say usually because that’s what I heard, it’s some human doing the first step. And then later on, it’s interactive in scenarios like that with a large organization being penetrated. It’s rather an interactive activity to attack and to infiltrate the whole organization.

As kind of a fun fact, luckily, it was mostly the endpoints on the domain that were infected as far as I heard, so which kept the medical devices not being able to join the domain, at least out of the infection focus, which is kind of fun because since years we’re trying to educate our product teams, “Hey, guys, you need to support active directory. You need to support domain joining.” Everybody who joined the domain in this case, in this scenario would have been prone to be, or much more exposed to the attack than if you were not joined in the domain.

Which on the other hand, also shows that having proper segmentation of your network in place helps a lot of… Well, this is not new, of course, to prevent spreading the infection to all network segments.

Steeve Huin

And it’s interesting because when you think about the human mistake that leads to these things, I think in the case of HSE with this massive amount of data that ended up being available, I think presumably what’s been missed, and it’s easy to say that, but of course, the systems might have been developed 20 years ago, in which case the paradigm and posture that were expected back then was very different than it is today. But if we looked at it today, then one of the things would be, well, every single piece of data that you store should be encrypted, so that well, worst case, if there’s a malware that happens, it might actually lock the machine down and make sure that you have backups in place, et cetera, but data should not be leaking in the first place.

Tyler Curry

Absolutely. All great points. Certainly, those tasked with protecting network infrastructure should remain vigilant, and it goes without saying that they should remain vigilant and know the organization is no exception to targeting as these threat actors appetite is for exploitations generally spared by financial gain, and they are continuously probing for opportunities to strike.

Our next discussion, in the FDA’s 2018 Draft Cyber Security Guidance, it proposed certain vital elements of an SBOM for medical devices in support of consistency and standardization. Based on comments received and additional learnings, the draft guidance is now under revision. Can you share what you’re doing to prepare for the updated draft guidance, especially as it pertains to SBOM and threat modeling? I’ll start with Chris on this one.

Chris Reed

Sure. Well, again, as I mentioned earlier, if you’ve been doing submissions, you’ve already been creating SBOMs, so a lot of our work internally is focused on the efficiency we’re doing that and the different use cases, even that we would use internally to help us monitor across our whole product portfolio when we have vulnerabilities and such.

The other thing I would highlight there, I think that really in the FDA 2018 Draft Guidance, they didn’t really specify specific elements as much as the scope, like, “Hey, we mean firmware and hardware too…” They even called it CBOM back then, and they’ve been clear they’re going to go away from that term, but I think that’s where the executive order NTIA minimum elements are going to be interesting. They released the components that they’re planning on requiring, and I would expect that systems will have to be able to generate at least those, although I think there’s going to be a lot of open discussion on exactly what those mean, but it’s a pretty small number, but you can already hear the complexity in this, supplier name, component name, those should hopefully be fairly easy, although component name, as I mentioned, naming gets interesting.

Cryptographic hash, this one, I know there were a lot of comments that went back to NTIA, like, “What’s that mean if it’s a library or something?” I’m just trying to illustrate quickly, there’s going to be a lot of growing pains as we really try to put this to test. They have a category, “any other unique identifier.”

Well, if everyone uses different unique Identifiers, that’s not going to be really helpful, and then relationships with dependencies and they ask questions about depth as well. So we’re working through all those and how to consistently generate those across products and again consume those centrally so we can manage and monitor it. That’s really where our focus has been inside our company.

Tyler Curry

Nice. And Hans?

Dr. Hans-Martin von Stockhausen

Apart from the SBOM, which I think was the biggest announcement or a major point, as you mentioned, Chris, I do remember there was a lot of ask for more documentation on the design side, but also on the TRA side. So describing the residual risk. Our work was concentrating back then on being able to express the TRA result towards regulators or towards the public, because typically the threat and risk analysis is a confidential document on our end. This is nothing that you really share with the public, but trying to find a way to extract the important aspects without having to unfold the full design information to make it understandable.

There was one activity we were pursuing, and which becomes now more… Well, hopefully the final version will arrive soon at the ISAC meeting, the spring summit, Suzanne Schwartz was talking about end of 2021, so that’s still a draft. Let’s see what the timeline for the final version is going to be and to prepare to also share this type of information on the regulatory side.

Tyler Curry

Absolutely. And Steeve?

Steeve Huin

Well, not being a medical device manufacturer here, that’s a bit of an odd question for me to answer, but I’d say from our perspective, what we’re doing is providing technologies that enable, ultimately, building and tracking the SBOM, and that’s what our focus is, to make it easy, because, again, it’s a hard problem and it’s one that needs to be not only created at the point of release of the device, but also maintained over time as devices actually get maintained. So that’s what our focus is on our end.

Tyler Curry

Absolutely. That certainly speaks to how dynamic things can be especially when addressing matters related to supporting medical devices and illustrates the ongoing and necessary pursuit for a consistency of standardization. Earlier we talked about the pre-market steps for the device security. When you look at post-market requirements, what can MDMs do to systematically approach continuous security patch delivery and be transparent in their vulnerability handling? I’ll start with Hans on this one.

Dr. Hans-Martin von Stockhausen

Well, continuous patch delivery requires both the organization being prepared and basic support on the product side so that products are able to or our endpoints are able to consume updates. So this is definitely a design requirement that should be on that requirements list for the generic security requirements list. But it’s important that there’s more.

The logistics about being able to perform or to continuously provide security patches is not to be underestimated.

Of course, you need to have some kind of repository where you know about the… Ideally you have something like a central list of the third-party components in use that need to be monitored, of course, have some store the relation, respectively, in which product, which component, or which technology is used. You need to monitor emerging information, vulnerability information about it to make the distinction between controlled, or them being controlled or uncontrolled, which then impacts your speed of delivery of the patch, because control patches can be released at your speed, at your pace, which is individual to the device and applicable to a device. The uncontrolled ones, of course, have more urgency with the 30- or 60-day timeline attached to it. 

And on top of that, you, of course, need to have some kind of delivery mechanism for your patches being at a website from which it can be downloaded, if customers can apply them themselves, or some kind of remote mechanism to push, ideally to push patches to devices in a WSUS fashion that we know from Microsoft. And I guess all these add some complexity to an organization and to be ready to perform that continuously. Then, of course, there’s a matter of frequency, because if you ask the IT Department they go for “Yep, I want to have it on Patch Thursday,” while the clinicians rather want to push it out as far as possible, like, “Yeah, it’s urgent, but we need to run these 24/7 operations on the device. So why don’t you come next week or next month with the update?” 

Tyler Curry

Absolutely. Steeve, any insight here? 

Steeve Huin

Sure. First of all, again, it’s not an easy problem, so I think people should realize that if you’re having challenges there, you definitely not alone, because we did a survey couple of months back, only to realize that less than 20 percent of all the people that we surveyed in the medical companies felt that they were confident with essentially the processes, and that they were feeling that they could easily meet the cyber security requirement. It’s a real challenge for the entire industry, specifically, in this instance I think there’s guidelines and guidances that are available out there, like the TR97, for example. That’s a pretty good one to give insight into what kind of activities you want to follow for connected health, or software, for example. 

The SBOM is, I guess it’s the theme of the day, but it’s certainly a good starting point, right? Because then you at least have a basic understanding of what is your exposure, you’re able to monitor your abilities associated with each piece of software that’s out there, and you’re able to make the assessment as there are things discovered, whether you need to make any changes to ensure patient safety so that’s probably what I would give us. 

Tyler Curry

Absolutely, and Chris? 

Chris Reed

Yes, maybe I agree with much of what’s been shared. A couple of things I would maybe highlight here is, I think the importance of a regular life cycle in products, and I think the key point I’d make there is that will look different for different types of products. So, for instance, Medtronic, we do pacemakers and implanted products. We’re probably not going to have a Patch Tuesday, I don’t think our patients would want that. I don’t think our clinicians would want that. But at the same time, there needs to be a sustainable life cycle of when things are released, and kind of going back to the… We also need to be really disciplined on rating those vulnerabilities, so even the 30- and 60-day comments that were made earlier that came out in the FDA post-market guidance, it’s interesting how that gets misunderstood a lot. That was for uncontrolled vulnerabilities, where there’s safety implications. And again, even there it was a carrot, not a stick. And please don’t hear me wrong. I’m a big fan of timely patching, but I think the FDA rightfully recognized that it’s a complex ecosystem. That being said, I don’t think manufacturers should hide behind it’s complicated. So we don’t have regular cycles and things like that. 

I think the most important part is to think through the sustainable practice, both on the manufacturer side, but also on the healthcare side.

Because, again, even if you release monthly patches on some piece of equipment, it doesn’t mean that, you know, they don’t usually use a centralized inventory system like you do for desktops to push up patches to medical devices. So we really need to think about both sides having a sustainable process. 

And when we do make the exception to say something is uncontrolled, ideally, we’ve filtered down the noise so that it’s very clear, “Hey, we really do need to react because there really is an issue here. It’s all hands on deck.”  

Sometimes I think we have a lot of noise, and it’s hard to sort through the noise from when we really have a legitimate issue, so just a couple of thoughts as I’m hearing the discussion, but it’s definitely a difficult problem, and definitely every manufacturer needs to be able to support delivery. And at the same time, on the healthcare side, we need to be thinking through the implications of the support demands there as well. 

Tyler Curry

Absolutely. And definitely want to get into this next discussion topic. And I see we have some questions coming in. We want to provide some time for our audience to chime in. But before we get into the pending questions, two-part question, actually, the cyber attack on Colonial Pipeline, the largest fuel pipeline in US impacted the energy sector. As connected medical devices become the target of similar attacks, what steps can health care organizations take to protect themselves? I’ll start with Steeve on this one. 

Steeve Huin

Okay. Well, I think if you reflect on what we’ve said there’s basically it has been tremendous issues and that’s across all industries at this point. So there’s evidence, and certainly no reason to believe that the healthcare industry would be spared from a cyber security attack perspective. There’s ample evidence of otherwise. So I think what’s really critical is perhaps to drill in on what Chris just said, which is you need to consider the cyber security throughout the entire life cycle of the product, and that starts with as you’re looking at designing your product, you understand, what are the threats? What are your assets? 

Then it’s making sure that you employ the right technology to fit for purpose, to secure your assets, to mitigate some of the risks that you’ve identified. It’s validating it, it’s not just about trusting. 

There needs to be a point where software is then checked, that there’s penetration testing, whether that’s through white box or a black box kind of perspective, and perhaps both are unnecessary, I don’t know. But there is a need for third party, and I don’t necessarily mean external necessary, but certainly independent teams to be looking at things, and then once it’s out there, it’s really understanding and monitoring what’s going on and being able to respond to it. So it’s through the entire life cycle of the product, and it’s a big ask, but one that is unfortunately needed at this point. 

Tyler Curry

Absolutely. Chris, any insight here? 

Chris Reed

Yeah, I’m thinking back to the question specifically how health care organizations can help protect themselves. As I mentioned earlier, just the scale and the diversity that a lot of devices, that a lot of healthcare organizations are dealing with is not a small problem. I have a lot of… I have dealt with the… Not in a healthcare work, but I’ve had to defend manufacturing networks and corporate networks before, so I can empathize with the severity of the problem. I think it really gets down to the basic, it’s not easy, but at the same time, it’s inventory, it’s that you’ve assessed your inventory against where your biggest risks are, that you’re getting resources prioritized there, which goes back a lot to things like the NIST CSF, and then making sure when you’ve got serious risk that you’re escalating those to management to make decisions. 

And it doesn’t mean that every risk you escalate is going to get resourced, but I think that’s what the NIT CSF is supposed to do is help escalate and get resources on the problems that are the biggest. I 
It’s that discipline, and it’s not all glory that work but it’s super important to do. And I think that’s even in the Colonial Pipeline, a lot of that, their vulnerability was probably evidence from just a lack of some of that, unfortunately, some of the basics of making sure that process was working effectively. 

Tyler Curry

Absolutely, and Hans? 

Dr. Hans-Martin von Stockhausen

On top of what Steeve and Chris said, I just want to add that term shared responsibility, which should be mentioned here to the shared responsibility for medical device security as a point by the FDA back then. And I think it’s important that we do have devices offering the necessary security controls from the MDM side, but at the same time also to ensure that the operators, the HDOs (Health Delivery Organization) have the necessary resources to build an infrastructure that works well together with those controls to reach an overall acceptable level of security, and this can only work, this can only be reached if both sides are playing together or adding the necessary ingredients from their end, because a completely secure device will not work, a medical device with all the security in it or mostly will not be a good clinical use. 

On the other hand, an only secure or a completely secure environment cannot be reached by the HDO. So the truth is somewhere in between to balance the usage of controls in the device, but also of security in the infrastructure. 

Steeve Huin

Perhaps it’s worth adding one more thing from a perspective, I think Chris was very spot on. If you think of the healthcare providers, they may have a network with thousands of medical devices with a varying degree of cyber security capabilities, some that were 20 years old for sure would not even have the basics in place. Perhaps one of the important advises listed for the health care providers is to think about it as, do the best you can for what’s already in your network, because the reality is it will not be possible to upgrade the cyber security technologies in a 20-year-old X-ray machine, for example. 

So use basic IT technologies like firewalls and perhaps other network based technology for basic security, and where possible anti-virus, anti-malware and things like that. But then what is, I think, critical and is really the tipping point for the future, is make sure that you select devices for the future. So as you start procuring your devices, that you focus your efforts on those that have the right cyber security technologies and ultimately processes that are there to support the future is perhaps the important distinction between past and future. 

Tyler Curry

Absolutely. And that’s promising for the second time here. We certainly want to get to some of our Q&As by our audience, we do have some questions pending here. I do see one here was in reference to Chris, your talking points in reference to the need for threat modeling, and Steeve and Hans, feel free to chime in as well. Basically, what is your suggestion when product teams are heavily under-resourced and focused mostly on velocity on releasing new versions of the products? How can the product team leverage threat modeling better rather than just check-boxing? 

Chris Reed

Yeah, that’s a great question, and I’ll give some ideas here. It’s definitely something I have thought through before. And to be honest with you, it’s different depending on the circumstances. I think the biggest thing I can encourage there is engaging the teams to get alignment on where the riskiest areas are. And the other tip that I would share there is, I found a lot of success at times where, again, there is pressure for releases, but I mentioned this earlier and this isn’t about getting people in trouble or pointing fingers, but sometimes the development teams just need the okay to spend time on things

And so it’s okay to escalate issues and let their management make a decision, and then they have to live with that decision and make sure it gets documented and things like that. And I have personally found that when I’ve highlighted a high-risk area of a system and asked for more time and they’ve said, “Yeah, but we don’t have time to do that,” but I’ve escalated it, I’ve been lucky in that every time, it’s always come back down to, “Here’s… Okay, you can take an extra couple of weeks to get this done.” I’ve had pretty high success in that. 

At the same time, I would say I’ve been on the trail end of other projects where they didn’t do that, and we’re spending just as much time on the back end dealing with questions we can’t answer well, sometimes from our customers or regulatory friends because we didn’t put the work in. And so a lot of times it’s saving, I think it’s framing that well and getting escalated if you need to, as well as making sure you’re looking at the whole “Where’s time going to be spent?” 

It’s a lot cheaper up front than it is later in the process. But you also can’t play that card all the time.

Your teams have to trust that when you’re trying to escalate a specific area that needs to work, that you get them aligned, and they trust that that’s where a good investment would be. So it’s not an easy question to answer. So, again, I empathize with that. Steeve?

Steeve Huin

Yeah. It probably will feel self-served, but it’s certainly not coming from there. But I think this is where it’s important to recognize that it’s possible to also leverage experts in the industry as well. And so the fact that the teams are flat out and may not even have the competence is okay. I think the primary focus for a medical device company remains to build the most amazing medical devices that actually provides the care. That’s okay. It’s just that if you don’t have the competency, or you don’t have enough resources, simply leverage somebody that you can trust can support you in that.

Dr. Hans-Martin von Stockhausen

I’d like to add, in the long run, it may help to have a template or think upfront about the threat scenario in the first place, because most likely a manufacturer will not produce or create products which are completely unalike, but may be rather similar like. For example, at Healthineers, we do have all these imaging machines, CT, MRI, MI, X-ray, so they live in a fairly similar scenario. Of course, they have different characteristics, but presumably they are all connected to the radiology network or run somewhere in the radiology scenario. So the number of threats, the original threats are rather the same. So there is a potential of reuse within TRAs in the first place, but not to the specific threat being identified or risk being identified. But at least you can describe, or it makes sense to describe the intended operation environment, and derive the threats in a more generic way and then apply them to the individual upcoming product.

This is much quicker than starting with a blank sheet each time and then trying to think anew of, “What was that threat?” So the suggestion is to make use of the experience from the past.

Chris Reed

If I could too combine a couple of these thoughts. I’m trying to give practical tips because I’ve been in the trenches before. It’s not fun, but being involved in the release planning process, and making sure there’s gates either through process or you’ve fought to get them in there, and even planning for, to Steeve’s point, “Hey, we want to bring a pen tester in at this point in the project,” and making sure that’s agreed to upfront and that it’s a gate that has to be passed, because then it’s designed into the workflow.

And so I was talking about escalating in the past, but it’s just as important to make sure that work is in the plan to start with. And it’s not fun to do because they’re trying to figure out how to manage cost and get things out fast. But if you win those the right discussions there, and get the right things into the product or into the plan, it just becomes a lot easier. So I just wanted to give that little practical tip as well.

Tyler Curry

Absolutely. It looks like we have one more question left here. So if we could all combine on this one is, are different approaches to right-sizing cybersecurity priorities and considerations taken for devices that are stand alone with ports or that are connected to other medical devices, yet not to hospital networks, for example SBOMs, threat modeling, threat and vulnerability assessments, well  listing and so on?

Steeve Huin

I’m not 100 percent sure that I got the question, but I think the answer lies into somehow some of what we’ve said, which is first thing you need to focus on is understanding the threats, because then you can actually right size all the rest of the threat. Once you understand this is what I need to protect, this is what I need to prepare for, then you can focus your efforts. So that’s the area that I think is most important in the entire cycle.

Dr. Hans-Martin von Stockhausen

Yeah, I agree to that. That’s what I meant with the list of some generic requirements based on standards where you will definitely hardening is on that list, so security hardening for a device. And if you find out that you do have a completely standalone product which is not networked at all, and I guess many of these requirements reduce to zero are not applicable, and it’s still a matter of having, encrypting the data or limiting physical access of some sort to the device to protect it from malware.

But as soon as it is connected, or assumed to be connected, then of course, it may become a pivot point, so you would have to do a lot more to not only protect the device, but rather also to protect the environment.

Chris Reed

And I might just… I know we’re about out of time, but just to add on, I view that as a way to prioritize the healthcare network inventory as well. I think I’ve heard the saying, “if you’ve seen one hospital, you’ve seen one hospital.” Your priorities, unfortunately, are going to be different in every healthcare organization because you have different assets, and it is difficult. But I think coming up with the way you tier things. I know maybe you scan for the top 10 vulnerabilities and make sure that’s not on any of the devices. So there’s a number of ways you could go about that, but you absolutely need to do that. Because, again, there’s no way you can have the resources to make sure every device that’s plugged in is 100 percent secure. So it really becomes essential of having a good strategy based on your environment, how to tier those and make sure you’re putting the right effort and the right tier. So hopefully that is helpful. It could be using SBOMs and things like that, but it’s definitely coming up with those tiers, and in your environment, what would drive those tiers.

Tyler Curry

Great, great. Well, we are… Sorry. I believe we are at the end of our time today. I would like to thank our attendees for their time, and esteemed panelists for participating in today’s discussion, and I certainly hope that everyone enjoys the remainder of their day.

Chris Reed

Great, thanks, everyone.

Steeve Huin

Thank you, everybody.

Dr. Hans-Martin von Stockhausen

Thank you. Bye-bye.

Steeve Huin

Bye.