The Future of Cybersecurity

What will the future be for software as a medical device (SaMD) and cybersecurity? Manufacturers need to identify cybersecurity issues with their medical devices because incidents have become more frequent, severe, and impactful.

In this episode of the Global Medical Device Podcast, Etienne Nichols talks to Chris Gates, Director of Product Security at Velentium and author of Medical Device Cybersecurity for Engineers and Manufacturers.

Chris has more than 30 years of experience developing and securing medical devices for device manufacturers and collaborates with regulatory and standardization agencies to present, clarify, and systemize tools, techniques, and processes that enable the creation of secure medical devices.

LISTEN NOW:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Although the FDA understands the importance of updating cybersecurity guidance, it should tie the documents to real standards from ISO and EU MDR, rather than only referencing consensus standards for global harmonization.

• To make secure medical devices, a standard cybersecurity requirement needs to be created for manufacturers to do it the same way based on research and tools.

• During the development portion of the product life cycle, manufacturers need to identify threats. However, if there is not a workable requirement and the developer does not know what to do or not do, then nothing is done but ignored.

• Manufacturers have to look for the vulnerabilities or end-root cause of all exploits and threats during development. Vulnerabilities occur during the design, implementation, and use of third-party software components.

• Software Bill of Materials (SBOMs) need to be readable and consumable. An asset management system needs to be built in to address risk mitigation.

• When buying medical devices, health delivery organizations (HDOs) want SBOMs, support, and other cybersecurity expectations included in contracts.

• Find out what you need to do to create secure medical devices. At the very least, look at it as a competitive advantage in the industry.

Links:

Velentium

Medical Device Cybersecurity for Engineers and Manufacturers

FDA - Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions

FDA - Quality Management System Regulation (QMSR)

International Organization for Standardization (ISO)

European Union - Medical Device Regulation (EU MDR)

Protecting and Transforming Cyber Healthcare (PATCH) Act

Supply Chain - Cybersecurity and Infrastructure Security Agency (CISA)

NIST Special Publication (SP) 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations

Software Bill Of Materials - National Telecommunications and Information Administration

Software Bill of Materials - CISA

OWASP CycloneDX Software Bill of Materials (SBOM) Standard

CycloneDX Tool Center

International Open Standard (ISO/IEC 5962:2021) - Software Package Data Exchange (SPDX)

Medcrypt

Cyber BOM (SBOM) Management - Cybellum

SBOM Use Case - RKVST

The Greenlight Guru True Quality Virtual Summit

Greenlight Guru YouTube Channel

MedTech True Quality Stories Podcast

Greenlight Guru Academy

Greenlight Guru

Global Medical Device Podcast Email

Memorable quotes from chris gates:

“I want something that’s workable, something that’s harmonized.” 

“What you have to look for are the vulnerabilities or the end-root cause of all exploits and threats.” 

“We want SBOMs. We want people to talk to. In case of a breach, we want some help.” 

“Take a look at what you need to do to be a good corporate citizen and create secure medical devices. At the very least, look at it as a competitive advantage in the industry.”

Transcript

Announcer: Welcome to the Global Medical Device podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Etienne Nichols: Everyone, this is Estienne Nichols, and welcome back to the Global Medical Device podcast. Today, we're going to be talking to someone who has a ton of experience in cybersecurity. His name is Chris Gates, he's the director of product security at Velentium. He's a thought leader in really all aspects of medical device cybersecurity. He wrote the book," Cybersecurity for Medical Devices", and we'll have a link in the show notes, but a lot of takeaways from this episode. There's been a lot of recent laws, legislation, standards, templates, and rules that all apply to how medical devices are developed. We discuss how some of those could be impacting your organization. So his goal is to raise the awareness of how cybersecurity is realized in medical devices, and some of the reasons behind doing it, and some of the ways in which you can do it better. So without any further ado, we hope you enjoy this episode with Chris Gates. Hey, everyone. Welcome back. It's good to be with you again. Today with me is Chris Gates from Velentium. Am I pronouncing Velentium correctly?

Chris Gates: You are.

Etienne Nichols: Okay. Today, we're going to be talking about cybersecurity. This guy wrote the book on it, literally, and we'll have a link to that in the show notes. If you're interested in more cybersecurity, as it relates to medical devices, we will have a link to that. But before we get into that, maybe I'm getting ahead of myself. Today's episode is going to be talking about a lot of different subjects related to software as a medical device, specifically cybersecurity, potentially. But Chris, do you want to tell a little bit more about yourself, before we just jump into the topics?

Chris Gates: Sure. As you mentioned, I am the director of product security for Velentium. I've been with them for five years. I was brought into Velentium to build their cybersecurity division up, and set up our whole section of experts, so we can help our clients solve their cybersecurity problems and get their products to market faster, but still create safe systems. I, myself am a medical device engineer. I have been working and creating medical devices for 50 years, as of this year. When I first started, I was the little kid that walked in, and now I'm the old guy. I've gone the entire arc of that existence. And so for the last 15 of those years, I have pretty much been devoted 100% towards cybersecurity. I still keep my hands in a couple of things like Bluetooth, low energy and stuff, otherwise, I would go crazy as an engineer. Really my goal in all this is to be the schizophrenic engineer, developer and hacker, and how do I blend those two? And how do I make this workable in our environment, and yet add value in something that you can manage in a development activity, and still create these secure products, and deliver artifacts that will work for regulatory agencies, that will work for yourself two years later, when you want to make a change to that product? All of these things come together, not just security because it sounds good or is a box to check, but actually real workable solutions.

Etienne Nichols: That's great. So 50 years, man, my goodness. So I can't even imagine what you've seen change over the course.

Chris Gates: Oh yeah. Well, we started off life with all eight bitters, 6805s and 8051s, and stuff like that we were working with, with no throughput, no power, no memory, no nothing. And so today, I always get a kick out of when I have firmware engineers who complain about it," Oh, well, I can't do that on that Arm Cortex- M33." I just laugh, and it's like," Yeah, okay." So anyway, there's been so many changes, and then some parts of it that hasn't changed at all. How we develop firmware for instance is very similar to what we used to do. Some of the stuff has gone down in cost. I remember back developing ventilators that used Intel Series Three and Series Four blue boxes,$ 60,000 a piece. And now today we get JTAG SWD pods that are six bucks. They're almost disposable. Okay. And it's like, so that stuff has changed, but the environment itself, not as much as you would like. We should all be doing model based development by now or something like that. But we're still playing around with bits and bites and C code and Ooh, we got C plus plus. Yeah. Okay. So it's remarkable in the sense of what hasn't changed and what has changed and why, what we do, hasn't gotten more streamlined, more repetitive, more obvious.

Etienne Nichols: Well so you've seen a lot of different changes and there have been some recent changes. For example, let's just go ahead and lead into this one. The draft guidance that was released from the FDA just a few weeks ago, curious what your thoughts are, if you have thoughts on that draft guidance.

Chris Gates: So let's go back to 2014 since we're doing retrospective anyway. That was the first pre-market cybersecurity guidance. It was the FDA saying you should make your devices secure. We like unicorns. Puppies are cute. And no clear guidance of what their expectations were. This set off years of me explaining to clients, no, this is what they want because I would see 483 rejection letters, pre sub meeting minutes. All of these things were there. They're extremely pointed in what they wanted to see as artifacts to support your claim of being secure. Then in 2018, they came out with a vastly improved document. Unfortunately, they did a couple things wrong. Like the formatting was still in the 2018 format. So it was almost impossible to read, but they did call out all the things they wanted to see. Good for them. They now made it concrete. This is what we need to do to get our device to market. That's always my goal. And I was really looking forward to the next spin of this, the 2018 document. And this new one that has come out here April 7th, while twice the size, and there are some good things. Overall it is an improvement to the 2018 one. It's much more readable. There's also a lot of things in there that are going to add a tremendous amount of burden. Some of the things like the anomalies. You're supposed to take all of your anomalies, do anomaly testing forever over the entire supported life of the product ongoing. And if there's anything that can be weaponized into a vulnerability, and then are there chained vulnerabilities off of that? You suddenly realize that making your medical device is a very small effort compared to the cybersecurity effort of very low returns is going to be. Who pays for this? Who's doing this. How is this impacting my business going forward? All of these things have to be looked at. And so the other part of this is their lack of ties to real standards. And by that I mean standards that are used by countries for their countries. So you can introduce your medical device into their country. I was hoping they would try to harmonize this latest guidance with say ISO and IEC. Wouldn't it be great? Because if you're marketing a product in the United States, you're probably going to target the EU as well too. That means all the ISO, IEC standards that the MDR is referred to, which are good standards. There's no reason not to harmonize with them. And we should, we should tie it together. Instead they went the route of referencing consensus standards. Now don't get me wrong. I love a good consensus standard. I'm on the version two JSP Committee, as an example from L sector coordinating council, Greg Garcia. He does a great job. But those aren't real standards. No country says, great, you have to meet the JSP to market your product in our country. That's kind of upsetting to me. And then on top of it, they put their spin on everything. As an example, the NTIA working groups for software bill of materials definition. That is what was adopted for the critical infrastructure in the United States. There are minimum elements that are published. And what this means is that oil and gas can come together with pipelines, with medical devices and all these. And we can all work together and the tools suddenly start to appear because now it's not just poor little medical device industry, it's all of these industries. So you start getting better tools. Well, the FDA came out and said, oh yeah, well you need machine readable S bombs. Excellent. And then said, and they have to have these weird elements in it that nobody has ever defined or knows how to deal with or wouldn't provide any value. And then they left out a bunch of stuff that they needed to put in there. And I'm like, why did they do this? This is like, look, go out, find the good standards, point to them and say, yeah, do this. The views. I like the views. They're really good. Too bad they created their own and didn't go with something like the United Architecture Framework, UAF, and their views. It's like, because there's tools for that. That's the problem I have with the new one.

Etienne Nichols: Yeah. Well the FDA is, or so I go back to QMSR when I think about what the reasoning and the motivation for the QMSR was to harmonize more with a global standard or global harmonization of different standards as far as that goes. It sounds like that's not happening in the software world or the cybersecurity world.

Chris Gates: It is not happening in the cybersecurity world. And I was hoping this would, we would reach a level of maturity where we would start to migrate in that direction. That was really my hope for this.

Etienne Nichols: Now it sounds like you're a voice in the industry. Is there hope that this draft could potentially be turned around? We've talked about it on the podcast, even a draft guidance, it's a guidance, but.

Chris Gates: Ah, but is it? Okay? Okay.

Etienne Nichols: Okay.

Chris Gates: Draft effectively means current expectations. Okay. And I know this because again, I see warning letters 483s, many minutes and guidance means requirements, and they go, well. And in fact, the first part of this document, they go through several paragraphs that explain, it's not really that. It's only if you just want to get your product to market in the United States that you have to meet these. So it's not a requirement. How is that not a requirement? But even more than that, and that's always been that way by the way. I remember Don Witters of the FDA, who's retired like two years ago from the FDA, good guy, did RF coexistence guidance. And it was like a guidance for like 10 years. Did not spend a lot of money testing, because we did. We did all the tests because you had to meet these bars for RF coexistence. So it's not just cybersecurity. It's everything that's viewed that way. So all of that being said, however, there are now the Patches Act in the Senate and the House and these act basically gives cart blanche to HHS and thus the FDA for what they need to see and when they need to see it and how they need to see it for cybersecurity and medical devices. So this whole thing of this is just a guidance is going away. Okay. And it is going to be a requirement. So if you look at Patches Act on top of this latest guidance, and I was looking forward to the Patches Act by the way, yet another guidance I was very much in favor of. I wanted some teeth, as Suzanne Schwartz said. I think that's good. It clarifies that they're in lead position and they're going to hold your feet to the fire to make secure medical devices. Totally in favor. But I want something that's workable. Something that's harmonized, something that they just didn't sit around in a room and say, Hey, this sounds good. Let's do this. No. How about stuff that a lot of industry groups have are already looked at for years and come together with. So we're all doing it the same way. The tools are available and we can all talk the same language.

Etienne Nichols: So how do you propose that? I guess my curiosity is we have... the industry's big. How do you get that many people in the same room working on the same standard to make that happen?

Chris Gates: It's real simple. Okay. We're not that big. There's what, some 10, 000 registered medical device developers? Yeah. You go to an electronic supplier and say, Hey I need my a hundred thousand chips for this year and they're going to laugh. Okay. You're nothing. We think we're big because we're in a small pond. But now you look at something like oil and gas, pipelines, nuclear power generation, on and on. Okay. Those, you put all of those 16 industries that make up the critical infrastructure together. That is a big pond. Okay. And that gets respect. So what you want to do is exactly what the executive order did last year, which was put them all into the same area and say, these are going to have to live up to cybersecurity standards. That means now tools can start to be created. Standards can be put in place and adopted and really said, okay, these are workable. And these are the things we're going to use. And we're all going to speak this same language and the same way of doing it, going about it. Love it. That economies of scale, you can hire people across disciplines. You can get people that are trained in this. It all works out for the better in the end. So what we don't need is yet another I'm going to go off and create my own way of doing this.

Etienne Nichols: Yeah, no, that makes sense. So I guess if we take a step back from trying to heal the industry at an industry level scale, let's talk about specifically the draft guidance. You mentioned the anomaly testing. So a company that now is working on their software medical device and they have this guidance. What do you recommend? Or what are your suggestions? As they're looking through this trying to follow the requirements, guidance or no guidance, that debate beside the point, what are your thoughts on how a company should go about doing these things?

Chris Gates: Well, and there really are good standards. When you're developing, and since you specifically call that out, the total product life cycle is much larger. But let's just talk about the development portion of that. What you're looking for are not threats. Okay. If I told you, oh, protect this device against ransomware. What do you as a developer do or not do to make that happen? Right. And the answer is that you don't know. So as a developer, who's got 5, 000 lines of code to write that day, what is he going to do? He's going to ignore it.

Etienne Nichols: Ah.

Chris Gates: Okay. That isn't a workable requirement. Instead, what you have to look for are the vulnerabilities. Vulnerabilities are end root cause of all exploits and threats. So if I said there were 34 different ways ransomware infects a system, would you know I'm telling you the truth? I'm lying by the way.

Etienne Nichols: Yeah, no clue.

Chris Gates: Right. Exactly. So really what you're looking for are those pseudo 34 or however many they are, vulnerabilities that are in your system. This could be things such as, I designed this incorrectly and I'm not doing authentication on this communications connection. I didn't implement it correctly and I'm not looking at my buffer overflow. I'm using unsafe intrinsic functions to move key material around that's used for authentication or integrity. So you have during development, three different places where you create vulnerabilities during design. The aforementioned, I'm moving PHI over this. I'm doing command and control without authentication or authorization or integrity checking. Those are design choices you make up front. I hard coded a password. My favorite example of you just don't care.

Etienne Nichols: Hard coding a password. Okay.

Chris Gates: Yeah. Whenever you see that, it's not like, oh, I feel sorry that you missed some zero day vulnerability. It's like, no, you clearly just don't care. Okay. So those are all design vulnerabilities. Implementation vulnerabilities are like that. You coded it incorrectly. You did it in a way that the coding was insecure. And then lastly, the third places where you create vulnerabilities are in your use of third party software components. You inherit these things and you're a Java programmer and you say, Hey, I want to do logging. So I'm going to go out and get the industry leading logging library, logging for Jay. And guess what? You just inherited some vulnerabilities. You also inherited 294 sub transitive dependencies that you don't even know exist, but it needs for it to function.

Etienne Nichols: Yeah.

Chris Gates: So in this day and age where your supply chain is intentionally being attacked and if people are intentionally putting bad code, these aren't just weaknesses now, they're intentionally being inserted into these repos and you got 294 of them. You suddenly start to realize human beings can't do this. Okay. It can't be. This all has to be machine readable. This all has to be automatic. We have to use tools to do this for, to try to expose this. Whether we're developers, whether we're the consumers of these products, you are literally looking at tens, if not hundreds of thousands of components that have to be looked at. Obviously not a human problem.

Etienne Nichols: So the software bill of material portion of that, does that feed into that machine readability? And so one of the questions that I have too about SBOM for example is, is there a standardized way of putting that SBOM together and is it going to be something that a machine is going to read that and be able to do something automatically with it? Or is it still just for humans to look at? What are your thoughts on the SBOM as that pertains to that?

Chris Gates: So by way of credits for this, I have been on the software bill of materials working group from initially NTIA for four years and under the great and wonderful Alan Friedman. The man can herd cats like nobody else. So, and we were a bunch of highly opinionated experts defining what this was. And I thought this was going to be relatively straightforward, because like everybody, I had my blinders on.

Etienne Nichols: Sure.

Chris Gates: And then as you got all the other experts in the room, you started to realize this is a very big topic. So we explored and fluffed out all the edge conditions of this. We took standards that were already in existence, usually for license tracking of software, made twists and modifications into them. And we have representatives from these groups, Kate Stewart, from Linux Foundation with SPDX format, Steven Spirit from AOSP and Cyclone DX, both great, great ways of JSOM oriented files to covey these, to be generated by machines during development, to be monitored by those developers going forward by tools like Med Crypt's Heimdall and Cerebellum, all these good tools that are out there for doing this all completely automatically bringing this to your attention. The place where we early on discovered there was a problem is you've got a product and here's your ventilator and I'm using open SSL on it. Oh, it's 1. 1. F. It's the one that's susceptible to heart bleed. Okay. That's one part of it that deals with... There's about six lines of code that deals with certificates in there. That's where you have this memory leak. Well maybe I'm just using it to generate random numbers. So your software built material says to that in consumer, oh, that ventilator is at risk because it has this vulnerable version. Maybe the way you built the code with conditional compiles, that code isn't even in there, but it's the right version. So we realized early on, we needed yet another way of conveying this to be useful without getting tons of false positives. And that was what we called the Vex. Horrible name, by the way. We all universally agreed we hated it, and yet we all called it this. The vulnerability exposure machine readable document. And we worked with the Oasis standards group to come up with a separate document, that's JSON machine readable one, that is basically the manufacturer's position where there's a bunch of substrates, but the primary states are, it's an investigation, you're affected or you're not affected. If you're not affected, it's pretty primal. And if you are affected, it could be under it. Maybe based upon a setting for instance. If you set this setting configuration item, then you would be affected by, but it has some subcategories as well. This allows you to come back and have that position of the developer inform you to even greater degree, whether or not the device that's in your institution is at risk or not. And that's the goal of this whole thing is to really inform people automatically, Hey, you've got to go worry about this device. This device you need to disconnect, you to apply the patches, you need to contact the manufacturer. You need to feed it to a wood chipper. Whatever it is, that's the whole thing. And sending out text messages and emails and notices. No, there's just too much. You're overwhelming human capability.

Etienne Nichols: That Vex program that you're talking about, that's something that the hospital themselves would be using on software that is being used inside. Yeah.

Chris Gates: Right. And the beautiful part like Cyclone DX version 1.4 has now incorporated Vex into the SBOM itself. So we have distribution systems like Archivist that's out there right now that you can go out and either behind a password credentials or not, you can make it open source as well. You put out your SBOM, your device can self- identify using something like the mud standard from IETF that is now got the IETF is formalized a way of including point to an SBOM. So you could go out and say, Hey ventilator, tell me, where can I get your SBOM? And it would go, okay, over the manufacturer's usage description protocol, would give you a URL that you would then go over to Archivist, pull this SBOM up that would be for the version that's in this ventilator, and you could see the software build materials and the Vex information encoded inside of that one place. All completely JSON machine readable, consumable. And now, the piece that is missing. All of that's in place, we've got really robust tools for that.

Etienne Nichols: Yeah.

Chris Gates: The piece that's missing is that asset management system in the health delivery organizations. The HDOs, those that do have asset management systems, don't have this capability. We need that built in. So this thing says, okay, we've got a thousand ventilators here and those floor number 11 in this building, okay, need to be upgraded. Okay. And that's literally the level of involvement. That's workable by a human being. That's a way these end institutions can really protect themselves. And the interesting thing about this is this relationship between medical device manufacturers, MDMs health delivery organizations, HDOs, is how they work together. The MDM creates these devices, throws them over the wall basically to its customers and says, here you go. And they're on the front lines. Who's going to take the abuse if they get attacked? It's going to be them. Especially with things like ransomware. It may take down your whole organization.

Etienne Nichols: Yeah.

Chris Gates: So now we're seeing things like the health sector coordinating council come up with model contract language for cybersecurity, which is a way for all of the HDOs out there to use fixed sets. There's 45 different clauses to include in your contracts when you're buying medical device.

Etienne Nichols: Hmm.

Chris Gates: And it says, these are our expectations contractually enforced for us to be supported by you over the life of this device.

Etienne Nichols: I see. Okay.

Chris Gates: We want SBOMs. We want people to talk to. We want in case of a breach, we want some help that we can have people come in here. We want to see a periodic cadence of updates. These were things that they spent 18 months building up. It's great concept because it'll reduce the amount of work MDMs have to do with everybody having their own one off level of doing it. It'll be a more standardized approach and it'll improve the security posture of HDOs.

Etienne Nichols: That makes sense. So really they took that risk based approach similar to 14971 beginning with the end user in mind. And part of the reason I even bring that up is some of the people I talk to about software bill of materials, like why do I need a bill of materials? Why are you telling me how to do this? But it's really for the end user.

Chris Gates: Well, that's the main one. Yeah. And first off we have a huge problem with MDMs. We talk about HDOs like it's this monolithic thing. The HDOs run the gamut. You have one extreme, Mayo Clinic, who does everything right. They have pin testers. They're very thorough about their security. And then at the other side, there is a hospital that will remain unnamed that's in Ohio that the guy who mows their lawn is the guy who sets up their network.

Etienne Nichols: Okay.

Chris Gates: Okay. And there's everybody in between. So a lot of what we're doing here now is not for the Mayo Clinics. It's for the everything in between. How do we do this in a way that's cost effective? How do we... Things like these asset management tools. The lawnmower guy, maybe he can't even afford the asset management tool, but a few notches up those HDOs can and should to avoid the huge risk and speak to what their risk appetite is. They don't want a device that's going to take down their entire network and cause them tens of millions of dollars in loss. So there's that. That is the primary market, primary audience we're into. But you know who's next? The manufacturers themself. So you're a big manufacturer. You've got potentially thousands, if not tens of thousands of legacy medical devices that are still out there being used, have not reached into support yet. You're on the hook for them. Something comes up and you've got the BLE family of vulnerabilities here a few years ago, a lot of companies spent a lot of time with engineers going back through going all of these devices, what semiconductor manufacturer was this? What version of the stack were we using? Are we susceptible to this? Where if you use some of the tools that are now commercially available, like I mentioned, Heimdall, this tells you instantly as a manufacturer. You go, oh, here's your product lines. Here's the ones that are affected that are using that same version and you go, oh, okay. Even got linkages out to JRO. So I go, yeah, just punch this into JRO and the developers now have to pay attention to it. Okay. So there's stuff like that it saves the manufacturer huge amounts of time, creates a better product, and it's actually cheaper.

Etienne Nichols: Very cool. That's good to know that there are things out there that you can definitely do things like that. The draft guidance though. So you kind of answered that question that I asked about how companies should do this. I think you gave a great overview of how companies should approach cybersecurity. How now, I guess when you have a draft guidance that comes out with like, your opinion might be that there are things that maybe they may miss the mark on. How do companies handle that?

Chris Gates: Well, till July 7th, you have a comment period. At the FDA, I've seen comments ignored. I've seen comments taken seriously and applied. Who knows how this is going to work. But, this is your time to speak, industry. Time to push back, look at what they put out there. Walk through that relatively large 49 page document line by line. There are some things in there that start to get your attention. Like we're going to be doing ongoing testing against all of our legacy products for their supported life. And that includes things like anomaly testing, which is, or is a magnitude more than vulnerabilities. Right. And chaining of those. Okay. Which means permutations. So all of a sudden you start to realize that, oh yeah, it took us nine months to develop this medical device. We're going to be spending five years testing it here. Oh, okay. And it's like, there's a lot of burden that's going into this. And some of that, like that anomaly part of it, really needs to be pushed back on. Non- adherence to standards, as I mentioned, I really wish they would just stick to the standards and not try to get creative because they're doing themself and everybody a disservice. That's really what I've got. I've got 61 items that I'm pushing back on that will be submitting into the system and anything from grammar to major issues like the software build materials that they came up with their own method. So there's a lot of that there. Industry take advantage of this, review this, especially in light of the Patches Act that make these, would make these mandatory if it passes. We want something workable and we want something that really gives us value.

Etienne Nichols: I guess the idea right now, if this did go through and not think about the Patches Act, prior to that, you could make arguments, I suppose, against some of that testing. Is that accurate?

Chris Gates: Yes you can. Not very successfully.

Etienne Nichols: Right? That's the other side. Might win a battle, but lose a war.

Chris Gates: And at the very least you're going to be spending many, many more months getting your pre- market approval.

Etienne Nichols: Yeah.

Chris Gates: My goal with what we do and all my clients is that I try to streamline the process to make it so obvious we did the right things for security, that they go through and don't even have a question. I mentioned earlier for Bluetooth. Anything that has Bluetooth low energy in it, I immediately talk about why it's not a problem. I outline all the ways it can fail and other known vulnerabilities and just call it out because it's like, Nope, I'm just going to clarify this up front. We did it right.

Etienne Nichols: Yeah.

Chris Gates: Here we go. Okay. I'm not waiting around for you to ask me in another 90 day delay that'll be throw into this whole thing. We just want to streamline it and get it out the door. And it's like, we did it right. That's really what I look for in any of these type of guidance is how workable is it for our industry? What is the value it brings? What is the huge amount of work that brings no value? Let's minimize that. And so, yeah. I was a little disappointed in the guidance. It is a step up, but it could have been better.

Etienne Nichols: Yeah. Well, so the other thing, so we talked a little bit about development. I used that word and you mentioned product lifecycle when we were talking about how to approach cybersecurity. So in light of these different items that you've brought up, what about a company that does have that legacy software out there, or those legacy products that utilize software? Do you have any recommendations or suggest on how they could be better?

Chris Gates: Yeah. Get ahead of it. What you don't want is some disclosure that happens seems like every week of some third party software component that then you're wondering, am I affected by it? Get ahead of it and start creating software bill of materials for these legacy products that you can put into a management tool and have it do it for you. That way you are not scrambling at a time to try to quickly address this. You're ahead of the game time wise. And you have this in there, but you can create these software bill of materials for the legacy at a low priority background task with your people to build this library up and keep it going. And then as you introduce new products, of course, with those you'll have pre- created software bill of materials. Get those into place, let these tools do the work for you. End of the day, you'll have a better product. You'll have better relationships with your customers and it'll be cheaper than doing all this manual work.

Etienne Nichols: That makes sense.

Chris Gates: The whole area is supply chain, by the way.

Etienne Nichols: Yeah.

Chris Gates: It's an umbrella term. It's like threat modeling. There's a lot of different things that you can mean by that. Okay. Supply chain we always think of as our vendor. Yes. One step up. Yes. And certainly things like CISA and mist even, it has a very heavyweight 200 and some odd page guidance on how to do that. But it's still good. Just big. Of how to deal with your vendors. That's only one out of like 12 to 15 different vulnerabilities that can occur. And there's a lot of different things. So in supply chain, we're very much following the Josh Cor man crawl, walk, run model of implementation. We are very much at that crawl stage. So we want to go out, look at those vendors, qualify our vendors, bring in the code, keep our code in our own repo. Use the code that we've qualified to be in there. Those are simple, easy to use. We have tools for them in place. We know we can do them all crawling. The rest of all those vulnerabilities are only now starting to be looked at for how do we do this? How do we incorporate this into tools? How do we make this work? The Linux foundation in Toto and GitLab is now doing some of that stuff of creating ATEST station. As you check things in and out of your repo, including your CI system, all of this looks at who touched this, why did they touch it? What was affected from a cryptographic standpoint? So all very cool stuff, but that's like tomorrow, that's not quite today. It's getting close, but not quite today. But what you can do is look at things like that. CISA, vendor qualification questions, and literally incorporate that into your acquisition model of, I want to go out and use this. How do I know what it is? Where is it coming from? Don't dynamically pull from it. Do whatever testing, do whatever qualification is needed. Keep it in your own repo. Before you update that, you go through that process again. So a lot to be done over there, a lot of growth.

Etienne Nichols: CISA. So tell me that one more time and I'll try to put maybe a link in the show notes.

Chris Gates: C- I- S- A.

Etienne Nichols: Okay.

Chris Gates: I will send you a link to it if you're interested.

Etienne Nichols: Yeah, that'd be great because we do get some questions about supplier management for software. And really, if you just zoom out just in general, software's a medical device versus a physical device. Sometimes people ask, well, does that mean the DMR is obsolete for software or supplier management? Is that required for software? What are your thoughts on those things?

Chris Gates: Not obsolete at all. If anything, get it more robust, polish it up, make it more streamlined, get rid of the index cards. The traveler should not be in this. This should all be digital. You want this stuff so you can scan through there and come up with these answers in seconds, not many, many person hours of work to come up with the answers you need. So no, definitely not. You want to make this and stop resisting. This is the part that really... we started this in 2014. Okay. I get it. 2015, people were still going, I don't know what I have to do with my medical. It's, come on. It's 2022. Time to stop being the ostrich. Pull your head out of the sand, take a look at what you need to do to be a good corporate citizen and create secure medical devices. At the very least, look at it as a competitive advantage in the industry. Those who do this are going to be selling more products. It's just that simple. Those who advertise it and talk about it. It's going to be a competitive advantage going forward. So there will still be some institutions that are only going to buy for costs. That's the beginning and ending of the whole thing, but more and more pressure is even being put on them. And even from their business perspective, that may be Penny wise pound foolish in the sense that yeah, we got this super cheap thing, but everything's attacking it. And it was a pivot point in the rest of our organization. We lost weeks of time and we had to close down and millions and millions of dollars. So look at that and say, who's giving me a better product at the end of the day. Okay. They're five bucks more, but look at all this proof they can show us that we've done a good job for cybersecurity and are going to work with us. So that's the differential that we see doing in the industry. If you don't do it for ethical reasons, do for your bottom line.

Etienne Nichols: Yeah. And do you want to talk about your book for a moment? Because obviously we've been talking about cybersecurity. We've been talking about this...

Chris Gates: This book? Right there? This? Oh gosh, look, look. Right here. We got.

Etienne Nichols: "Medical Devices Cybersecurity". I'm curious though. You have a lot of experience, but it's such a moving industry and you wrote the book.

Chris Gates: Perfect lead up. Perfect lead up. So back in 2020, myself and one of the employees here, who's a technical writer at Velentium, great guy, Jason Smith. We decided we were going to write a book on medical device cybersecurity. We figured, eh, it'll probably be a vanity press. We'll go pay somebody to print these. Right? So we started this up, we got the outline. We did the table of content first and start to burn down from the top down. And about this time, Artech Publishing out of London contacted my buddy Axel Worth, who works at MedCrypt and great guy, Axel, another senior security person in the industry like myself, knows it all. And they contacted him and said, Hey, a few years back for Amy, you wrote a book on cybersecurity for hospitals. Would you like to do one focused toward the manufacturers. And he said, yeah, but hang on. Can I bring on other people? Oh sure. So he came to me and he says, Chris, would you like to write a book? And I says, oh, here's the outline for it actually. We were on a Zoom meeting and I pulled it up and showed it to him. It's like, and it's like, we've already started on this. And we had a blast writing it. And we knew when we were wrote it that three to five years out, a lot of it's going to be obsolete. And so the book went out and won two different cybersecurity book of the year awards in 2021. And it's been one of Artech Publishing's biggest books they've ever sold. It was on the bestseller list for Amazon for a while for technical books.

Etienne Nichols: Wow.

Chris Gates: I love it when I bring on a client and they hold up the book and there's post- it notes sticking out.

Etienne Nichols: Yes.

Chris Gates: They are the best to work with. This is what I love because you've already brought them up way higher than they were before reading this. And you can now say, I don't need to talk to you as a child. I can now talk about the advanced things and where we need to go. It makes the engagement so much easier. Love it. So all of that's gone on and here the other day, our tech came back and said, you guys said, that's going to be obsolete. Yeah. You want to do second edition?

Etienne Nichols: All right.

Chris Gates: So there's a second edition coming. That will be out there. And we have to, when you write this because of all the latencies, you have to shoot out a little farther and figure out where things are going and, or at least leave them for the last part of the book to be written. So we are updating it. We're spinning it. Things that have changed. We're leaving in original content that's still very valid and we're going forward with that. We're also going to be bringing in more expert industry. We've already had a good set of industry advisors that wrote content for us as well. We'll have more of those. So yeah, we're happy about that. I'm glad to make a difference in my industry. That's my goal.

Etienne Nichols: That is super cool. Well, we'll put a link in the show notes so everybody will be able to read it. And then maybe we can have a follow up episode later after everybody's gotten the book and read it and look it over again.

Chris Gates: Hey. And don't think I'm getting rich on it. Believe me. First you've written as a technical book. You make no money on it at all.

Etienne Nichols: I've talked to authors before. The margins are so small and the numbers, they sound big to us, but oh man.

Chris Gates: I'm just glad the impact it makes. That's what makes me happy.

Etienne Nichols: That's huge. That's, that's so huge. And I'm really glad you're looking at those guidance and providing guidance to those who are writing the guidance as well so that's exciting.

Chris Gates: Try to.

Etienne Nichols: Yeah. Any other recommendations or thoughts you just want to share with other medical device manufacturers out there before we shut it down?

Chris Gates: Oh, things like the myths of the go on in this industry.

Etienne Nichols: Please. Yeah.

Chris Gates: I'm putting my medical device in a medical institution. It's their responsibility to make it secure. No. Nobody's ever going to attack my medical device because we're nice people and why would they do that? Go take a look at some of the recent disclosures of chat messages between malware writers, where they basically knew they were targeting some 400 HDOs and they basically said F- em.

Etienne Nichols: Wow.

Chris Gates: And this would've, if it had come to fruition, it would have really endangered a lot of lives. They don't care. Okay. Don't go out there and say, Hey, I'm going to leave my USB port completely open. Because I will attack it. If you leave your USB open, it's completely vulnerable. No matter what else you do. Don't leave enabled manufacturing functionality. During the manufacturing process, I need to calibrate this. I need to stress test it. Do not. Do not. When you go to the last stage on your manufacturing line, disable that functionality permanently, I'm not saying contract. And in fact I'm actually trying to work myself out of a job. Contract, third party security experts. I don't want you to, I want you to have your security experts in house. And since we're very short supply, get them trained. Velentium offers training for your people, other training organizations and universities as well too. Some of which we stood up training programs in those universities actually. Like University of Colorado, Boulder, we've got a good program going on there and several others. So these are the things. Get them trained. Bring that in house. Okay. Make this part of just another ism that you include in your development. Used to be we never considered human factors, right?

Etienne Nichols: Yeah.

Chris Gates: And now we realize we do and we incorporate it. And it's just another thing we do. Same with cybersecurity. Don't make this some sort of standout thing that you have to go get a high price security expert to do this. Get this in- house. Get the people trained so they know how to do this. This is the kind of thing. This is the goal I have from my industry is that I can walk into any manufacturer here within five years, talk to their engineers and they're going to answer intelligently cybersecurity questions. I've seen so, so much as well as the FDA has seen so much that at the end of the day it appears to be intentional obfuscation. And I think 90% of it is just ignorance of what to use. The FDA asking what kind of encryption and how big of an encryption key are you using for this data stream? And they come back and go SHA one, which is the rough equivalent saying, what car do you drive to work? And you go, Boeing 747.

Etienne Nichols: Yeah. Oh no.

Chris Gates: It's like, they're both vehicles. They're both cryptographic in nature, but one's not a car.

Etienne Nichols: And what a great example.

Chris Gates: So yeah, this is the kind of stuff. And it's, you have to believe that at the FDA the people are just sitting there slapping their forehead going... And by the way, that particular example I saw, did not get approved at pre- market approval. And they shouldn't because they asked those questions. And that's when I got involved after the fact. And it's like, now let's go back and explain to them exactly what we're doing. Let's fix all the problems and then show them that we fixed them all. That's what you need to do. Just be logical about it, go through it and do it in an intelligent way.

Etienne Nichols: That's cool. I love that you're educating the entire industry. That's going to be great. That's a huge impact.

Chris Gates: It's a heck of a goal, huh?

Etienne Nichols: Yeah. Big goals. That's awesome. Makes life worthwhile. All right. Well thank you so much. I appreciate it, Chris. Hopefully we can have you on again in the future possibly. Maybe when the draft is no longer draft, we'll talk more about that at some point potentially, but those of you've been listening, thank for listing. You've been listening to the Global Medical Device podcast. If you are interested in learning more about Greenlight Guru, as we are powered by Greenlight Guru, head over to www.greenlight.guru and check the show notes. We should have several links there for you to further research on what Chris is talking about. Thank you. And we will see all next time.

Would you like to participate in an AMA (Ask Me Anything) session with this speaker? Head over to community.greenlight.guru and use the access code TrueQuality2022 to see what AMA’s are coming up.

ABOUT THE GLOBAL MEDICAL DEVICE PODCAST:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.