Software Bill of Materials (SBOMs) & Cybersecurity in the Medical Device Industry

In this episode of the Global Medical Device Podcast, Jon Speer and Etienne Nichols talk to Ken Zalevsky, Certified CyberSecurity Leader and CEO of Vigilant Ops, about software bill of materials (SBOMs) and cybersecurity in the medical device industry.

Ken has collaborated with the FDA, U.S. Department of Homeland Security (DHS), and National Telecommunications and Information Administration (NTIA) on cybersecurity initiatives, including cyber simulation exercises, industry guidance documents, and SBOMs. Ken’s written work advises medical device manufacturers on cybersecurity best practices and coaches hospitals on handling record numbers of breaches.

Listen now:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Ken defines an SBOM as a list of software components that compose any system, application, or device. In health care, medical devices are computer-based systems with software components.

• Engineers may know all about software and security, but not with medical devices and SBOMs. Medical device manufacturers are familiar with safety and efficacy in a regulated industry and may need to overcome software challenges.

• Most medical device software teams don’t build everything that is in a medical device. Scope appropriately because third-party components may involve risk.

• Safety is not the same as security, but both should be included early in the product life cycle. Cybersecurity standards include authorization, authentication, and encryption versus safety recalls, use cases, and vulnerabilities.

• SBOMs are not evergreen documents. They need to be maintained and updated regularly to act, react, and take action.

• Health care is the primary target for hackers over other verticals and the response time in health care has always been the slowest. Today, it takes about 160 days for a healthcare organization to discover a security breach.

Links:

Medical Device Security Made Easy - InSight Platform by Vigilant Ops

SBOM - National Telecommunications and Information Administration (NTIA)

NTIA - Minimum Elements For a Software Bill of Materials

FDA - Guidance Documents (Medical Devices and Radiation-Emitting Products)

FDA - Medical Device Overview

AAMI TIR57: Principles for medical device security - Risk management

The Greenlight Guru True Quality Virtual Summit

Greenlight Guru YouTube Channel

MedTech True Quality Stories Podcast

Greenlight Guru Academy

Greenlight Guru

Memorable quotes from Ken Zalevsky:

“A detailed list of those software components is really the essence of an SBOM.”

“At the heart of it, the idea and the purpose of the SBOM is to give that transparency into software components that are utilized in medical devices.”

“Most software companies, especially medical device software teams, don’t build everything that’s in the device. They take components from other third parties and there’s risk associated with those components.”

“You can’t blame it all on the hospital because the hospital has no idea what’s running in those devices.”

“Providing that transparency, understanding what you’re deploying on your network, just is common sense.”

Transcription:

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: Hey, everyone. Welcome back. Today we're going to be talking about SBOMs, software bill of materials, and cybersecurity. We're talking with Ken Zalevsky, who is a certified cybersecurity leader from the School of Computer Science at Carnegie Mellon. He has 19 years of experience in the medical device industry. He served as a cybersecurity consultant to national and international healthcare industry stakeholders. He's worked with the FDA, the Department of Homeland Security on various cybersecurity and initiatives, as well as cyber simulation exercises and industry guidance documents. He was also featured speaker and panelists at the FDA workshop content of pre- market submissions for management of cybersecurity in medical devices in January, 2019, so he has a lot of experience. I could go on and on, but in addition to earning a certification in cybersecurity leadership from the School of Computer Science, Ken also has an undergraduate degree in applied math from Carnegie Mellon University and a graduate degree in business management and has attended the Executive Education Program at the Harvard Business School. Very qualified, very interested in the impact of software bill of materials or the SBOM on the medical device industry, so I hope you enjoy today's episode and the discussion. If you do have any thoughts, questions, feel free to email us at podcast @ greenlight. guru. com. Hey, everyone. Welcome back to the Global Medical Device podcast. This is Etienne Nichols. Co- host of the podcast today with us is Jon Speer, founder of Greenlight Guru, as well as Ken Zalevsky, who is a cybersecurity leader with 19 years of experience in the medical device industry as well as experience with the FDA. Today, we're going to be talking about the software bill of materials or SBOM, if you see it written out in the acronym. And maybe we ought to just start by talking out about this, Ken. What is software bill of materials?

Ken: So thanks, Etienne. That's a great question, a great way to start. The software bill of materials by definition is the list of the software components that compose, really, any system or any application or device. In our case, in healthcare, we think about medical devices, computer- based systems with software components. A detailed list of those software components is really the essence of an SBOM. There are various elements to include in an SBOM and we can talk through all that. And NTIA has got some requirements that they came out with, with respect to including in various information, but at the heart of it, the idea and the purpose of the SBOM is to give that transparency into software components that are utilized in medical devices.

Jon: I don't think it was a guidance, but there was some document that was published recently. And I don't remember if it was from FDA or National Institute of Health or some organization like that. That was the first time I personally had seen the term software bill of materials and I'm like," Oh, to me, that makes a lot of sense." But I come from a background in med device that well, classic, mostly mechanical or even some electro- mechanical products where bill of materials, that's my recipe. It's all the parts, components, pieces that I need for my product. And I think one of the things that we see a lot at Greenlight Guru is the software as a med device companies. I would say they don't speak med device, they speak software. And it seems like this term might not resonate with, I'll say classic software development. What are your thoughts about that?

Ken: It's a good point. I actually just had a discussion the other day with a mechanical engineer. So it's a funny story that, he thought this whole bill of materials idea, to him, it was amazing that in the software world, we were stumbling over this compiling a list of things that go into these devices because he said," In my world where I come from, in BOMs, we've been doing those for 40 years. We know beforehand what's going into a product and we know what the BOM looks like. That's part of the very beginnings of product development and creating things," so he said that same thing. It's strange that we're all talking software bill of materials, but I think that there's a lot happening in healthcare with respect to security and what you hear about breaches and hospitals being breached and security being breached. That's all about what they call legacy devices or devices that are fielded. Those devices have profiles and components and software as part of them. And I look at a big job with the software bill of materials to help protect those devices, or at least give transparency into what's running in those fielded devices. And that's a whole different use case than engineering software bill of materials when you're maybe potentially using that in the software billing process to determine which components to put in there to begin with. So to your point, Jon, I agree. Software folks might recoil a little bit at this tracking or looking at components that they're using in the device, but in a way it's quite natural. Most software companies, especially medical device software teams, don't build everything that's in the device. They take components from other third parties and there's risk associated with those components, so knowing that ahead of time and helping you design and develop the product in a more secure way from the very beginning is what everybody always talks about, even FDA.

Etienne: So what are some of the challenges? I'm with Jon. I'm mechanical background so I think about everything down to the nuts and bolt's going to be in your bill of materials. Software, what are the specific challenges that maybe companies need to overcome? Thoughts? And when it comes to mind, actually, its... Sorry, go ahead. Must be a lag. Sorry.

Ken: Etienne, that's good. I think that speaking specifically of medical device manufacturers in the healthcare space, healthcare is a regulated industry, as we know. Medical device manufacturers have been designing and building products for many years in this regulated environment, very familiar with safety and efficacy of devices. There are processes in place. There are systems in place, regulatory requirements, to keep devices safe. And at the end of the day, that means to make it safe for patients. Security is a little bit new and it's a little bit of a newer game to most device manufacturers. And if you think about, as an engineer, a software engineer working for a device manufacturer, the way you need to think of security is a little different than the way you think of safety. The use cases are a little different. Take an example from a safety perspective. There may be some safety mechanisms, some fail safe mechanisms that need to build into the device to keep the patient safe, so if it's an injection system, not to inject too much volume of an agent or an infusion pump with a volume contrast being controlled or volume rate being controlled in some form or fashion and there's hardware and software components that make up that safety piece of it. And you're looking at intended uses of the product and looking at ways that you can mitigate potential uses outside those use cases and edge cases for patient interaction and patient safety. From a security perspective, you're starting with a blank slate. You're saying," Well, here's what I'm going to build into the system," and you look at authentication and authorization mechanisms that you put in to keep the product safe or the data safe, maybe encryption and things like that. That's all pretty standard. But if you think about the use cases of a device, now you're thinking like a bad actor might think. You need to think all the possible ways that somebody could use your system nefariously. It's almost like a greenfield or a blank slate where you sit down and think through," Wow, we didn't think of that and we didn't think of that," and" Wow, they could do this." A lot of it is missed and I think that's to be expected. Engineering teams will sit down with their workup risk assessments of the product and from a security perspective, they'll try to play out those scenarios, but a lot of it's missed because you can't think of everything, obviously. There'll be new ways and that's why the field of cybersecurity's so enticing because it's just so quick to move and folks are always out there looking for ways to get into systems and they're coming up with new ways every day and things you're not thinking of. So it's a little bit of different mindset for an engineering team and that's one of the challenges, I think, today is that sitting down and thinking through all that and laying that out in a nicely formatted scenario that you can then present a case to, say a regulatory authority like FDA, is a little bit of a challenge for a lot of teams.

Etienne: Wow. That makes sense. So it's almost as if you have two different situations going on the risk, the device to the patient itself, but then also how the device could be tampered with and so forth and used, like you said, nefariously. Are there any examples of the FDA recalls or things like that specific to cybersecurity? It's an interesting thought.

Ken: It is and really interesting. FDA's been recalling product for safety reasons forever, for a lot of years, and that's real important to all of us. But from a cybersecurity perspective, it wasn't until around 2015 that FDA made this unprecedented move into that space. It was a specific infusion pump that was found to have vulnerabilities associated with it. And FDA eventually warned hospitals, an unprecedented move, warned hospitals to switch and not use that pump, essentially recalling that pump. And the company that manufactured that pump, I guess, was taken aback a little bit. A lot of their product was pulled out of networks and pulled out of hospitals. And it was really quite a bold move from FDA's perspective to actually go that far and say," We don't feel it's safe for patients to use this because of cybersecurity." First time that happened.

Etienne: Interesting. So I guess my question about that is what did the FDA look for? What was their, I guess, evidence? I suppose that would be adverse event reporting or any thoughts there?

Ken: That's interesting. So FDA says that the vulnerability and they even say this today, that vulnerability information about components utilized in devices can come from all different sources. I think in the case of that pump, it was independent research that had found this vulnerability. And so FDA takes in these sources of vulnerability information from all over. So I don't think any patients were harmed from this potential exploit and I don't even know that the exploit was actually ever taken advantage of by any bad actors, but I think they were able to get the pumps off network quickly enough. But going forward from that, FDA has gained more experience in working with information sharing organizations and pulling in independent researchers and understanding vulnerabilities. And so I think that their normal process now, and probably was then too, as they worked with the manufacturer to get the vulnerability corrected or to at least give them warning as much warning as they can prior to it being publicly exposed.

Etienne: So do you have these situations that could occur, maybe even remotely tied to safety, which it sounds like it would be. Cybersecurity venture's going to lead to a safety concern, I would assume. So that being said, what are some best practices that you've seen, maybe even pitfalls depending on which direction you want to come at this from, the best practices or things that you've seen that I'm doing incorrectly?

Ken: Right. Well, I think from the perspective of a manufacturer, best practices, FDA will say this, too. Cybersecurity should not be a bolt on to a device. So you shouldn't be thinking about cybersecurity, the security of the device, when you've gotten through development, when you've gotten to the point where you're doing testing or even beyond that. It should be baked in from the very beginning and in the design and development phases of your product life cycle. So going back to what we touched on a little bit earlier, device manufacturers, as they begin to think design with new product in mind, or maybe updates to product that currently exists, thinking design and development of those products, they should be thinking about security and what that means. What's the exposure? Not all devices are created equal in terms of their exploitability or even their proximity to the patient. So depending on that, the risk factors for the product may be higher or lower and build in the appropriate cybersecurity for that device. And that requires a good understanding of that device, the potential impact of that device on patient safety at the end of the day. And then you don't want to build in overly secure so you think about how clinicians need to interact with your product. So there's a little bit of a trade off there, but it's making as secure as possible for the environment that it's going to be deployed in with the best controls possible and have that opportunity to work through. And then from a use case perspective, work through the intended use of the product potential nefarious uses and create those use cases and look for ways to mitigate or mitigation techniques for those. That's a great way to start, I would say

Etienne: I heard a few different things in there, so I'm just repeat back and you tell me where I missed. So it almost sounds like you really need to weave it in early, number one, to your risk management process. So cybersecurity, that's going to be right there alongside all of the other risks that are associated with the device than it sounds like, and then the usability as well. So I guess I'm trying to think, the specific things associated with software, obviously cybersecurity is solely associated with software, but what are the additional challenges that other medical device people may not be thinking about, I guess, as they approach this?

Ken: Well, another huge challenge is, and unlike again, this goes back to how is a software bill of materials different? Let's start cybersecurity level and say cybersecurity is just a totally new animal, if you will, to the device manufacturer, especially software engineering teams. And then you delve into, from a cybersecurity perspective, let's look at the tools that we can use to make our products more secure. And SBOM is by no means a silver bullet, but it is a security document that will help device manufacturers and users deploy devices more safely and more securely. So if you look at an SBOM as," Okay, now this is going to be integrated as part and parcel of our development process through engineering, through product development," what are some of the things we need to think about with respect to this SBOM that are somewhat different than the way we've thought in the past about documentation we've created for product? And the one huge difference is a software bill of materials is an evergreen document. It's continuously changing because there're vulnerabilities that are being continuously introduced on a daily, hourly basis. And if you've got components in your product that are being utilized in any form or function, you need to worry about the risk profile of those components because at any point in time, all of those components are on a different trajectory or different life cycle. And if you look at the security life cycle of those components, at any point in time, your device is either more or less secure based on the security of those components. So it's like this aggregate roll up of risk that you're undertaking when you start to install components in your platform or your system, but you've got to continuously monitor that. So unlike patient safety, where you can say," I put these controls in place to guard usage against patients being harmed by my product," you can't stop when you finish that document. You need to continue and monitor. And that's where a lot of, I think, manufacturers, at least that I've seen, get a little bit tripped up because they're a little less used to that continuous updating and monitoring of product documentation than they have been in the past.

Jon: We at Greenlight, obviously, we make software. Software, as a service, help companies with their quality systems and design controls on a number of other workflows. The data and the information that our customers, medical device companies, manage and maintain within Greenlight is obviously proprietary, confidential, and that sort of thing. So we've taken those precautions on our end to protect the product, the software, from a cybersecurity perspective. It's expensive. It takes a skillset that may not be inherent within a traditional software development team. What advice, what approaches would you recommend to a software development team that they know more or less what cybersecurity is, they know that they have to address that in some way, shape, or form in their product, but they don't have that skill set. How should they approach that?

Ken: Yeah, Jon. That's a good point. And that was one of the things that we discovered right away, going into this space. There is a lack of skillset with respect to cybersecurity because A, it's really new, compared to a lot of the other stuff the engineers have been doing for years and B, it's outside the wheelhouse of a software development team, really, in a lot of cases when comes to device manufacturing. So one of the things we recommend is scope appropriately, especially with device manufacturers that are just starting out down this path. And maybe they've got, especially the startups and the softwares medical device organizations that don't have a lot of resources, scope appropriately. If you've got one product, that's great. You've already scoped, but if you've got multiple products in your cache, take a product that you feel has the maybe highest potential for risk or highest security profile, and start looking at cybersecurity with respect to that product. And a good exercise is to get the subject matter experts or the engineers or the product folks that are familiar with inner workings of the product together and lay out first architectural diagrams. That's really helpful. Just say," Here are the ins and outs. Here are the data flows in this device. Here's what I can see from a very high level hardware, software perspective." And just look at it and get engineers. That's where they're comfortable. They're comfortable on that architectural side, understanding the software piece of it and look at it from that perspective and then start to think about it easily from a security perspective. If there were any ways to infiltrate the product or pull data from the product, what would those ways be? I'm not using, say, authenticated passwords or I'm not requiring strong passwords on my device. Is that a weakness? Do I need to worry about that from a security perspective? And start with simple questions like that and really scope, and then as you grow into it and understand it a little bit more, you can start to scale. There are a lot of good resources out there and a lot of training that folks can do. There's online training that folks can do to bring them up speed on cybersecurity essentials. And I would recommend some of that too, for resources that aren't well versed in the topic, but then there's also consulting organizations that will work with you and come in and shore up your processes and understand how your product life cycle is implemented and give you suggestions that way. It's a little bit of an uphill battle because we're in a little bit of a tough climate from a hiring perspective. It's an employees' market at this point and so it makes it even tougher, but it's not going anywhere. You're not going to be able to say," Well, we checked the box on cybersecurity." You're going to need to implement this and so you really need to think ahead and look for ways to do that.

Etienne: So the SBOM itself, there's additional things that maybe a traditional manufacturer might not have to think about. There's a lot of additional things there, but you almost talked about what post- market surveillance or additional scope to your post- market surveillance. So that, tying into the regulation, I'm curious what are maybe some expectations of regulators that you've seen, reading between the lines with the guidance documents and so forth? What are some thoughts there?

Ken: So you probably know the FDA came out with our pre- market guidance at the end of 2018, so October, 2018, and I was actually involved in a lot of that upfront. I visited FDA and I sat on a panel to discuss the pre- market guidance way back when and the expectations around FDA's regulatory guidance on device manufacturers. And one of the things that also... Let me just conclude that for a second, say that the final version of that guidance is still pending. FDA is looking to release that and a lot of folks are saying it's going to happen this year. But interestingly enough, FDA also asked for legislative authority to enforce the requirements of that guidance document, which is also a first. And there was a bill that was recently introduced in the house of representatives called the Burgess Bill that is asking for that legislative authority for FDA to enforce pre- market guidance, which includes the SBOM. So long story short, you don't have to read too far between the lines to understand the requirement is there and it will be there from an SBOM perspective, so FDA, the very least expects SBOM from device manufacturers. When you go to your point, Etienne, about the devices that are fielded already, legacy devices or devices that are already running in healthcare delivery organizations, the expectation has been there since 2016. Either the post- market surveillance and post- market guidance has already been there. The device manufacturers would be responsible to communicate vulnerabilities to their customers in specific periods of time. And that's based on assignment of risk and calculating in a rough way, the criticality of those vulnerabilities, and then giving timeframes for response based on the criticality. So there are already regulations in place that, say, if there are vulnerabilities in field of devices, you need to respond and here's what you need to do. More regulations are coming, more pre- market devices, so you won't be able to get a device through the 510( K) process, for example, without SBOM documentation. And then manufacturers need to continuously update this, so as devices age in within hospital systems, there needs to be communication between the manufacturer and the end user as to where vulnerabilities potentially exist in that system. So all kinds of impact and all kinds of expectations, a lot of it above the board and a lot of it, as you said, between the lines.

Etienne: Is that feedback loop something that you would build into your SBOM, almost another component of your software or just curious what some of the best practices are around that.

Ken: Yeah. So what we've seen is the continuous integration, continuous development, or CICD pipeline that you see in a lot of agile software development outfits will bake the feedback from the field. And this has been feedback all the way going back to post- market surveillance that has nothing to do with security, but from a safety perspective, or even just from a bug fix perspective. They bake that right into the development process so the customer input is fed directly into development and take action on those items and cybersecurity should be no different. Those patient safety issues that come in from the field, there should be a process for those already and cybersecurity, the security issues can follow that same process. The issues that may occur and probably will occur in device manufacturers is a lot of those frontline folks that are handling that input or customer feedback are not prepared or not equipped to understand the difference between patient safety and security. So they may not know if you get into the tactical piece of it, where and how critical they need to communicate these vulnerability issues to the team. So I've seen in situations where there are certain amounts of time that are allowed to lapse between customer feedback and making that feedback loop available, actually getting back to the development team and taking action. If a vulnerability is critical and severe, that timeframe may not work. You may need to get that information in more quickly. Folks may need to take action on it. For example, I could tell you in 2017, you guys probably remember the WannaCry incident that hit healthcare really was impacted by the WannaCry vulnerability and the normal chains of communication broke down. A lot of healthcare organizations reached out to manufacturers and were not able to get responses quickly enough or as quickly as they needed them. Some cases, manufacturers were able to respond quickly, but the normal channels didn't hold up, so there's got to be a better way to triage the issues coming in from the field so that you know how to act and react to them.

Etienne: Yeah, that's interesting. And bringing up those specific examples is really poignant to, I guess, put the weight on this matter. It seems obvious that this is something that's tied to risk management should be integrated into your entire process. Have you seen any adoption issues with companies or how to overcome those adoption issues?

Ken: Most manufacturers that I work with or I've talked to agree, so the story's different than it was five years ago. We started talking about cybersecurity five years ago and it wasn't as tightly coupled or as looked at as tightly coupled to the risk management process as it is today. So I think the argument, if you will, is getting easier. Folks are starting to understand we need to build this into risk management. There's all kinds of documentation that's subsequently being made available to help folks do that. So TIR57 and AAMI document has been out for some years that does some mapping of risk management processes today and how you can bake security into that. There's a cybersecurity risk framework that was put out by NIST, The National Institute of Standards Technology, that helped manufacturers do that crosswalk between safety and security, so you can see there are resources that you can use and manufacturers really are starting to embrace that a little bit more. They're starting to understand it's just the part and parcel of our risk management process. It should be no different than the way we're managing risk today. And, as I said, I think that's becoming more of the common reaction to it now than it was just a few years ago.

Etienne: Jon, did you have any thoughts on that? I saw you nodding. I didn't know.

Jon: Just nodding in agreement. You mentioned the infusion pump example earlier, Ken, and I heard a story once about, I think it was an insulin pump, where a person figured out how to hack the code and was posting that on the internet and that sort of thing. Your product that has software, heck, your product that's mechanical, actually, Etienne and I were just talking with another gentleman on a different podcast and he was talking about a catheter that back in the day, a doctor, if they didn't like the shape of it, they would have steam going in the background and they would shape the catheter to curve they wanted with steam. So that was the mechanical version, I guess, of a cybersecurity thread, if you will. I might have stretched that analogy a little bit too far, but I think it's important. Obviously, software is here to stay. Technology is constantly, even catheter products, probably one day, in fact, there's probably catheter products out there today that incorporate software in some way, shape, or form. It's just something we have to be aware of. To me, my quality background, I like to think about the inputs, the outputs, maybe even a little bit of a SWOT analysis. There's lots of different tools you can think about. How can this product be attacked? You don't want to assume that it will, but you have to in order to do your job and due diligence, I think.

Ken: Yeah, right on, Jon. I agree with 100%. It's here to say. There's no putting the genie back in the bottle or however you want to say it. Cybersecurity is an issue and we're talking about healthcare here. And a big impediment or one of the big impediments, let me say, to the adoption of digital solutions is can you secure them? You guys remember 10 years ago, you'd pick up a Gartner Report and they'd tell you how many billions of devices are going to be connected to the internet of things in 2023 or whatever it is, and that's still the case. Refrigerators and everything's connected. To your example, Jon, we were talking about, well, connected devices in a hospital. How many are there? On average, there's 10 to 15 connected devices per hospital bed and it's probably more than that now, but everything's connected. Thermometers are connected. They're all sharing data and the purpose of that is admirable. You want to share patient data to help with patient diagnostics and to help with patient cure and patient safety and all those things that you want to do as a healthcare practitioner. But if your devices aren't secure, you're opening up this huge gap and this huge opportunity for folks to do nefarious things with your devices. And so as device manufacturers, you just really need to be aware of that and need to be aware from the very beginning stages that when you give your product over to a customer and they put it on the network, it should be as secure as you can make it so that you won't find or if they do, you have the opportunity to respond and keep those bad actors at bay, in some sense. You're never going to eliminate. And that's one issue that we... Etienne, you ran up the challenge discussion, which is a lot of folks in the beginning, and I think this is also changing somewhat, but in the very beginning of cybersecurity in the medical device space, and especially in healthcare, a lot of organizations on the MDM side had a really difficult time partitioning out some budget or to make resources available to tackle the problem because the first question was, can you eliminate this security thread in our product? So if I throw money at this, will it go away? And the answer to that is no, no matter what we do. And so you had to get over that first hurdle, which was, I can build in the best program to implement cybersecurity within our product and I still can't guarantee you at the end of the day that we're going to put it out there and it's not going to get hacked. So that was a put off at the beginning and folks were leery to invest tons of money into what they thought was," Well, we can't protect ourselves anyway." And so this whole cyber insurance industry took hold and people were buying insurance and trying to protect themselves that way, business associate agreements, where hospitals were trying to make manufacturers take responsibility legally, all kinds of things sprung up in the place of good security practice, but it's changing now. Folks are starting to realize this has to be part of it. And I see more device manufacturers opening up budgets and making this a real big part of their strategy.

Etienne: Yeah. I love that, your point. You can't just throw money at a problem. I hope it goes away. You have to put a lot of thought into it. So if I go back to the SBOM, what the SBOM is, it's a document outlining everything related to it. And when we're talking about cybersecurity and those risks, those are being handled in your risk management activities. The SBOM, is that bubbling those to the surface to show what has been implemented or what's the specific document and how it handles and assists in that cybersecurity? Maybe you can help me out. Probably a dumb question, but...

Ken: No, it's a great question. And I can tell you, I'm going to help you out in the sense that, if we go back to the essence of the document or the essence that we're trying to get at, really, is transparency into deployed systems. And I say systems because it could be really anything that's running in any industry, but going back to healthcare, we'll say transparency in medical devices. And what that means is, prior to having component level access or understanding components that are inside the device, hospitals really were deploying and still are deploying black boxes to their network, so you think about that. You get a medical device from a manufacturer and you have no idea what's running on it. And if you look at the stat, they're pretty staggering. Healthcare is the biggest target, the primary target. It's been continued to be the primary target for hackers over other verticals. And the response time in healthcare has always been the slowest. A couple years ago it was 329 days for a healthcare organization to figure out that they even had a breach and it's getting better now. I think it's in the 160 range, but it's still pretty long. But you can't blame it all on the hospitals because the hospital has no idea what's running in those devices, so if you went to the hospital and said," There's vulnerability in windows 10.1," I'll just make it up, they would be hard pressed to tell you how many devices they have that are running that operating system. And so the SBOM started off as the idea to provide that transparency, really, to the end user or the consumer of the product so that they can understand the risk profile of what they're actually deploying on their network. Which makes a ton of sense, which when you talk to folks and device manufacturers, even in the beginning, years ago when I would talk to folks about SBOM, they all bought into the idea that really makes a lot of sense. Providing that transparency, understanding what you're deploying on your network just is common sense. I've heard NTIA refer to it as the analogous to the list of ingredients on food. You need to know what's in there and that's how it started. And device manufacturers then pushed back a little bit in the beginning, but are now embracing it as a good idea. So that's the real purpose of the SBOM, is really to provide that transparency. And if you look at the work that's being done today with NTIA and now SISA has picked up some of that, you look at they're really digging in now to, we're past the idea that SBOM's a good idea and something to be shared. Now we're trying to figure out how to share it. What are the best mechanisms? How is it most efficient to get that SBOM to folks? What does it need to include? What format should it be? Should it be machine readable? Yes. All kinds of issues like that, so I think we've gone past how can SBOM help and now we're figuring out what's the best adoption plan.

Jon: No, maybe we're thinking the same thing, but with that in mind, that sounds like an awesome challenge. Awesome cool, maybe, but awesome, massive challenge, especially if we were to draw a line in the sand and move forward and say," From this day forward," that's one thing, but what did you say that the standard ICU has, what, 11?

Ken: Yeah. About 10 to 15 network connected devices per bay.

Jon: That's crazy. And what percentage, I don't know if this is a guess or what, but I'm guessing the percentage of those products that actually has an SBOM is probably in the single digit percent.

Ken: Very low.

Jon: Very low.

Ken: At this point, very low. And so you're right. This whole legacy device, I say the term legacy with a little bit of a hesitation because folks interpret that differently so maybe I should just say fielded device, so device that already exists in the field is probably a better way to say it. And there's this whole fielded device issue. You think about the millions of devices that have been deployed already. What do you do about those? How do you protect those? And it's a little different issue. So the engineering team, let's take a real use case from, say, a device manufacturer that would be puzzling over this. A device that's been fielded for 20 years and there are devices out there that lasts that long and hospitals use them for the life of the device. And so there could be 20- year- old software running on these devices and maybe the device manufacturer has moved on to new products, hopefully, and maybe they don't even have the build environment that existed when they created that product to begin with. How do they create an SBOM for that legacy device that's 20 years old? Do they need to re- create that entire engineering environment? Can they even get components that they used on the original device? It's a challenge. It's a tricky proposition, but there are ways to do it and they just need a little bit more time to come to fruition, but we'll get there, but legacy device is going to be a challenge for at least a few years.

Etienne: Yeah. That makes sense. I appreciate you explaining that. That made a lot of sense when you started talking about the transparency of medical devices. I think that's admirable and I'm excited to see how that improves things. If we go back to what you were talking about from a moment ago, the standardization of that SBOM, are some of those things in that draft guidance that could potentially be published this year? Are we getting close to knowing all of those things?

Ken: Yeah. Great question. NTIA has published a minimum elements document that exists today so folks can find that. Just go out and look for SBOM minimum elements NTIA and you can easily find the minimum elements published there. It's what you would expect. It's what's the software component, who's the manufacturer, what's the version, a little bit more information about it, to be able to identify it, say, unique identifier and things like that, but nothing that you wouldn't expect in terms of what you'd want to track with respect to the SBOM. And then there are all kinds of other opportunities from a device manufacturer perspective to start thinking a little bit ahead. If you think about your risk process and where you want to build it in, device manufacturers differ up and down their pipeline in terms of how they build software. There's this little bit of integration issue. So understanding the elements of the SBOM, understanding what goes into it's one thing, the formatting the SBOM, something else, but then where along the pipeline does it make sense as a manufacturer to build it? And it's going to differ by manufacturer depending on how they build the process. Some that have dispersed teams that collect code in a repository and combine it may build the SBOM there. Others may build it further upstream. It just depends, but there are guidance documents that tell you what should be in it and, roughly speaking, the format of the document when you create it.

Etienne: Okay. We'll link to that in the show notes the NTIA SBOM minimum elements as well as the draft guidance, potentially published guidance. That's great. Excellent. It almost feels like there's two conversations going on, to a certain degree, in this world. You have cybersecurity and how to tackle that in and of itself and then how do you present that information to the end user? That's another world in itself. It's interesting. I don't know that it's unique to the medical device world, but sometimes things get a little bit difficult to understand. For example, you mentioned device identification. You can build out your product, but you still have to have that UDI and that blows a lot of people's minds, just wrapping their head around how to present those things and I assume this could potentially have the same implications, but no, this is great. I enjoyed the conversation. Jon, did you have anything to add before we get some last thoughts from Ken?

Jon: No, I think this is a good point to put a wrapper on this conversation.

Etienne: Yeah. Ken, any last words for our listeners?

Ken: Well, thank you for having me, first of all. I really appreciate it. And I would say in summary, SBOM is here to stay. Like you talked about, cybersecurity is here to stay. My advice to manufacturers is to start to think about it, start to integrate it into their processes. Don't try to bite off too much to start with. Scope wisely and scale as you go.

Etienne: Awesome. Well, for those of you who are listening, get your SBOMs ready. You've been listening to the Global Medical Device podcast and we will see you next time.

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.