The Future of Cybersecurity

Speaker 1: 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: Hey everyone, this is Etienne 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 and we discuss how some of those could be impacting your organization. So, his goal is to raise the awareness of how cybersecurity is realized, 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 in into Velamentum 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. And I've gotten the entire arc of that existence. And so for the last 15 of those years, I have pretty much been devoted 100% towards cybersecurity. And I still keep my hands in a couple of things like Bluetooth, low energy, and stuff. Otherwise, I would go crazy as an engineer, but so, 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, I mean, we started off life with all eight bedders. 68. 05s and 80.51s, and stuff like that we were working with. But 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." So I just laugh. Yeah, you're okay. Yeah it's... So anyway, there's been so many changes, and then some parts of it that hasn't changed at all. I mean, how we develop firmware for instance is very similar to what we used to do. I mean, some of the stuff has gone down in cost. I remember back developing ventilators that used Intel Series 3, and Series 4 blue boxes.$ 60,000 a piece. And now today we get, JTAG/ SWD pods that are, six bucks. They're almost disposable. Okay? And, so that kind of stuff has changed, but the environment itself, not as much as you would like. I mean, we should all be doing model based development by now or something like that, but we're still playing around with bits and bytes, and C code, and oh we got C ++. Yeah okay. So it's remarkable in the sense of what hasn't changed, and what has changed and why, what we do, what 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 here 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 4. 83 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 you wanted and 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, and 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 what the cybersecurity effort of very low returns it's 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 I mean, if you're marketing a product in the United States, you're probably going to target the EU as well too. So 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 2 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." So, 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 SBOMs." 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." Alright?

Etienne Nichols: Mm- hmm.

Chris Gates: 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. So 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. I mean, 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 we would have reached 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 or, we've talked about on the podcast, even a draft guidance, it's a guidance, but-

Chris Gates: But is it? Okay? Okay, draft-

Etienne Nichols: Okay.

Chris Gates: Draft effectively means current expectations, okay? And I know this because again, I see warning letters, 4. 83s-

Etienne Nichols: Yeah.

Chris Gates: Crosstalk 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 approved 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 a guidance for 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 this act basically gives carte 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?

Etienne Nichols: Okay.

Chris Gates: 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 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 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. Okay? 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 set, 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 a 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. Okay? So 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 why 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 there 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 commanding 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, Logjam." 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. 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 us, to try to expose this. We, 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 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 firm, initially NTIA for four years, and under the great and wonderful Allan Friedman. The man can hurt 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 OWASP and Cyclone DX. Both great, great ways of JSON oriented files to convey 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 Slope 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 OWASP, excuse me, the OASIS Standards Group to come up with a separate document that's a JSON machine readable one, that is basically the manufacturer's position where, there's a bunch of sub states, 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 need 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: So 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, okay.

Chris Gates: Right. And the beautiful part, like Cyclone DX version 1. 4 has now incorporated Vex into the SBOM itself. So we have a 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 for IETF that is now got, the IETF is formalized 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. 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. 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. So now we're seeing things like the whole 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 including your contracts when you're buying medical device. 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 a, great concept, because it'll reduce the amount of work MDMs have to do with everybody having in 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 [ 42971 00:22;17] 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 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 it's really, I mean there... 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 a SweynTooth, 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, 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 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. You know, how do companies handle that?

Chris Gates: Well, until 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 put 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. 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. So that's really what I've got. I mean, 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 out there. Industry take advantage of this review this, especially in light of the PATCHES Act that, 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. 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, SweynTooth earlier for Bluetooth. Anything that I is Bluetooth, low energy in it. I immediately talk about why it's not a problem. I outline all the ways it can fail for SweynTooth 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, here we go. Okay, I'm not waiting around for you to ask me in another 90 day delay, that we 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. So 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. I mean, 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 sort of 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 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 those manual work.

Etienne Nichols: That makes sense.

Chris Gates: The whole area of 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 NIST 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, 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 sort of stuff of creating attestation 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, 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, and before you update that, you go through that process again. So 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 supply iron 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, I mean, we started this in 2014. Okay? You know, 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 pressures, 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, and 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 yeah, 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 I mean, obviously we've been talking about cybersecurity. We've been talking about this-

Chris Gates: What book? This book up there? This... Oh guys, look, look right here. We got...

Etienne Nichols: Medical Device Cybersecurity. I'm curious so, you have a lot of experience, but it's such a moving industry and you wrote the book. So some-

Chris Gates: So perfect lead in. Perfect lead in. So, back in 2020 myself and one of the employees here, who's a technical writer at Velamentum, great guy, Jason Smith. We decided we were going to write a book on medical device cybersecurity. We kind of figured, 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, our tech publishing out of London contacted my buddy Alex Worth, who works at Med crypt, and great guy, Alex, 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, which I like to do one focus 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 say," 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, 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 our tech 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 look 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 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, 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, 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 and 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 we're not, 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 them.

Etienne Nichols: Wow.

Chris Gates: And this would've, if it had gone come to and fruition, 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 distress tested. Do not, do not, when you go to the last stage on your manufacturing line, disable though 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. Velamentum 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 cyber security. 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. 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 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- 1, 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: They're both vehicles. They're both cryptographic in nature, but one's not a car. And It's-

Etienne Nichols: 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. You know, 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 this time.