Trevor Slattery Answers Tough Medical Device Cyber Questions | Ep. 51

In this episode of the Med Device Cyber Podcast, host Christian Espinosa, founder and CEO of Blue Goat Cyber, switches formats to put his CTO, Trevor Slattery, in the "hot seat." The episode is a rapid-fire Q&A session designed to test Trevor's knowledge and provide listeners with quick, clear definitions of essential concepts, standards, and acronyms in the world of medical device cybersecurity. Christian quizzes Trevor on a wide range of topics, starting with foundational regulatory standards and moving into more technical testing methodologies and security concepts. The core of the discussion revolves around the key standards that govern medical device development and security. Trevor begins by explaining IEC 62304, which dictates the software development lifecycle and safety classifications for medical devices. He then contrasts this with ISO 14971, clarifying that its focus is primarily on patient safety risk management, not cybersecurity directly. Building on this, Trevor defines AAMI TIR57 as the standard that adapts the risk management principles of ISO 14971 specifically for cybersecurity risks, and notes that AAMI TIR97 addresses post-market security activities. The conversation also touches on ISO/IEC 81001-5-1, which provides guidance on implementing a Secure Product Development Framework (SPDF) across the entire Total Product Life Cycle (TPLC), from design to decommissioning. Beyond regulatory frameworks, the Q&A delves into practical security terminology and practices. Trevor defines different testing approaches, distinguishing between black-box penetration testing (simulating an attacker with no prior knowledge) and white-box testing (where the tester has full access to source code and architecture). He also explains fuzz testing, a dynamic testing method that involves sending a massive amount of malformed data to a device to uncover vulnerabilities. Other key terms defined include SBOM (Software Bill of Materials), an essential inventory of all software components in a device, and SOUP (Software of Unknown Provenance), which refers to any code without a clear, documented origin. The episode serves as a valuable glossary for professionals in the MedTech space, demystifying the complex language of cybersecurity compliance and practice.

Christian: Hi, welcome back to another episode of The Med Device Cyber Podcast. Today we're going to switch it up a little bit and I'm going to put Trevor in the hot seat and do a rapid fire to see if he actually is the brain box as he's been called before. So we'll put him to the test. Christian: Uh I'm your host, Christian Espinosa, the Founder and CEO of Blue Goat Cyber. I'm here with Trevor who is the brain box and the CTO of our company. He's coming from NorCal, California. So I'm not sure if he's gained intelligence or lost intelligence from moving from Arizona to California, but we'll, I guess we'll figure it out. Trevor: I've definitely lost some having to go to the DMV here like 40 times. Christian: 40 times. Trevor: It felt like it. I think it was actually about five times, which is five too many. The San Francisco DMV is a dark place. Christian: Yeah, I don't like going to DMVs at all. I heard there was, there's like private places though you can pay a little bit extra to avoid the DMV. Trevor: I couldn't find one near here, but I would always do that in Arizona. There was a, the Footwork in Cottonwood. Christian: Yeah, all right. So we're gonna play, uh, rapid fire. So Trevor is a super smart with medical device cybersecurity, so I'm gonna ask him some questions and see how he does answering. And these are questions that a lot of you probably think about periodically, maybe not, but you're probably wondering like what IEC 62304 is, and all this other stuff. So we'll get Trevor's answer and if he goofs it up too much, which I don't expect him to, then I'll fill in the gaps. Trevor: IEC 62304 talks about safety classifications and secure development lifecycle practices within medical devices. So, it's a good framework for understanding what controls would be applicable based on scaling device risk. Uh, uses the European classification class A, B, and C, and talks about some of the specific implementations that may be applicable for a high-risk Class C device, may not be as applicable for a low-risk Class A device, and then general best practices with software lifecycles within medical devices. Christian: Perfect. So if I am a medical device manufacturer and I'm trying to decide what sort of outsourced software development vendor or company I should choose, I should choose one that follows IEC 62304, correct? Trevor: Yep, exactly. Christian: Awesome. Let's stick with the standards and we'll jump into one, uh, ISO 14971. What is that? Trevor: ISO 14971 is titled Risk Management in Medical Devices and it focuses mostly on how safety risk is handled within medical products. Obviously, safety is the paramount concern within medical systems. It wants to outline a clearly repeatable process for conducting a risk assessment and having a risk management process. So, what acts as the input into the risk assessment, what is that procedure for successfully triaging it, moving into pre- and post-production activities and risk controls after the fact. But it is notably gated largely to these safety considerations. So there are other standards that are more applicable and more appropriate for handling other types of risks in product. Christian: All right. So to sum it up ISO 14971 talks about patient safety and risk in terms of patient safety. It has nothing to do with cybersecurity. Uh, it's mainly about patient safety, correct? Trevor: Correct. The framework for it can be modified for cybersecurity and I might even be getting ahead of you on one of these questions here. Christian: Well I was gonna get, I was gonna go to that. I might as well since we're talking about ISO 14971. So let's talk about, are you tell me what AAMI TIR57 is and then tie it back to ISO 14971? Trevor: So AAMI TIR57 is security risk management within medical devices. Uh, it is very, very heavily based off of ISO 14971 and both of them actually talk about the risk management flow and they look practically identical between the two standards. AAMI TIR57 explicitly calls out ISO 14971 as the inspiration for how this standard was created, and it also talks about the intersection points where the two can overlap. Trevor: So when we're conducting a risk assessment, we identify a problem. We say, "Oh, we think this is a security vulnerability, we're conducting our risk assessment against it." Turns out there's actually some safety impacts here. So AAMI TIR57 talks about when we feed these vulnerabilities out from the security risk management framework into your ISO 14971 safety risk management framework as the intersection and blend of safety and security. Christian: Perfect. Since we're talking about AAMI TIR57, let's go ahead and jump to AAMI TIR97 because they're both related to medical device cybersecurity. So, what is that one? Trevor: 97 is gearing towards postmarket activities. They're both getting blended with AAMI SW96, which is meant to take a little bit more of a modern approach to AAMI TIR57. Um, but that one is a little bit more gated towards the initial premarket activities. So when we're conducting risk assessments, there are obviously going to be some shifting and varying factors moving into the postmarket phase, and we have to understand that these might be a little bit different, new criteria may evolve and identifying how some of those distinctions may be in place. Christian: So what about 81001-5-1? Trevor: 81001-5-1. So that is a joint standard between IEC and ISO that talks about, it's a little bit similar to IEC 62304, but is more talking about the overall device lifecycle as opposed to explicitly being around development controls and lifecycles. So a little bit of a similar perspective, but there is some distinction there. What we're talking about is a secure total product lifecycle. So, as you always say, design to decommissioning all the way through, how are addressing security risks and how are we ensuring that we're building safe products and safe processes within the medical space. It's also unofficially kind of trying to be a little bit of an international standardized and harmonized approach. Uh, unfortunately, regulators don't always like to get along, so there's been a little bit of slow progress on that. Christian: Yes. All right. So what is a SPDF? Trevor: SPDF is a secure product development framework. So that effectively means the processes and procedures that engineers and quality teams use when building out a device, building out the quality documentation around it. There should be strictly adhered to processes, strictly well-documented processes. Um, that's gonna, the process side of things will be a little bit more on the quality team side of things, and the engineering team must adhere to these and implement any of the development pipelines with that security in mind that help build out that security posture. Christian: For sure. We'll return to develop a product in a secure manner. Also, some people like to call it dev sec ops. It's kind of the same concept. Trevor: DevSecOps is gonna be a little bit different since that is the actual development operation. That would be more thought of as like the infrastructure and the processes around that infrastructure. So like a DevOps pipeline will be all of the checks and balances and code review cycles and static testing cycles that go through from when an engineer is writing new changes to the code, pushing it into version control, what checks happen before it goes into version control, what checks happen once it is in there through, like, an engineering manager. It's a very similar approach. The secure product development framework will go outside of that into the policies around it as well. Christian: Fair enough. What about TPLC? Trevor: That is the total product life cycle. So end to end from design to decommissioning, how are we addressing security through these initial design phases, avoiding any costly pitfalls that may introduce significant risk into the system, talking about early threat modeling before you even have a product. Once you have it out on the field, how are you ensuring that you aren't leaving risky devices out there? How are you managing updates through field devices, how are you decommissioning them when you're done, scrubbing them of any potential PHI, removing them from the, I guess, removing them from the public use. Um, so pretty much everything start to finish within the product. Christian: Design to disposal I like to say. Perfect. All right, what about fuzz testing? Trevor: Fuzz testing is spiking an input field or a connection with a massive amount of data, sometimes legitimate data, typically illegitimate data to see how the application responds. So an example could be you have a username field on a web application, you try putting in one A and then two A's and then you go all the way up to a million A's to see if there is a certain length that will cause the application to crash. That would be an example of fuzz testing. Christian: I heard the term fuzz testing came from like in your belly button you have a shirt on, you pull the fuzz out and that's where fuzz testing came from. Is that true? Trevor: I have no idea. Christian: All right, I stumped you on one of them. That wasn't really a fair question, that's more of a historical, I don't know. There's probably a couple different theories about where fuzz testing came from. What about black versus white box penetration testing? Trevor: So black box penetration testing is when you're coming in with minimal information about a product. It can be thought of as a very realistic type of testing. So, let's say if an attacker just took my phone, they don't have the password to my phone, they don't have any information about what's on the phone, none of the apps that are inside of it, they just see the phone. White box testing is when you have pretty much unlimited information about the product. So this would be any architectures about it. Uh, you have complete understanding of the architecture within the phone. You have my password to log into the phone, the password of any applications I have on this phone, the source code for the operating system and for any software or firmware running on the phone itself. It's pretty much a just open box, complete understanding perspective of testing. It's a lot more comprehensive, but generally somewhat unrealistic as attackers usually won't have that level of access. Christian: Fair enough. What is DICOM? Trevor: DICOM is an imaging format for medical images. It's a very old format. I believe the specification has been around since the 80s, late 80s, early 90s. And it is a standardized approach for data transfer and data storage in electronic imaging systems, so like a PACS system or electronic health records. It is a very flexible image format. So as opposed to just say PNG which is just a static image, you can store multiple layers of imaging, you can store information or context about the patient, notes from the healthcare delivery organization around this specific practice. And then that is often times tied in with a DICOM server or a PACS server which is a file store effectively meant to store and query these files. Christian: Good answer. The FDA finalized a guidance in June 2025 for premarket submissions and they defined what a cyber device is. Can you articulate that for us? Trevor: A cyber device needs software that is validated or installed on a product in some way or another, software, firmware, compiled code, really anything code based. There needs to be a network interfacing capability. So when they say network interfacing capability, this can be a very broad definition. It does not mean just you can connect to Wi-Fi. It means you may have Bluetooth, you may have NFC, the same NFC that is used for credit card taps. Uh you may have a USB connection. So it's a very wide umbrella there. And that the software can be exposed to some sort of cybersecurity risk. This last point is a little bit of a s-sticking point since it's very hard to prove that software could not be exposed to risk. I know one of our senior testers for his master's thesis was doing a project to prove that four lines of code were 100% secure with no vulnerabilities and it was something crazy like 50 pages of proof to do so. So... Christian: I think most things we test have a little bit more than four lines of code, don't they? Trevor: Yeah, maybe by a factor of about 10,000 times that. So proving that 40,000 lines of code is obviously going to be a little bit harder than four lines of code. So, generally, we avoid too much focus around the third bullet point and instead focus around the software and then that network connectivity aspect. Christian: What neighborhood do you live in in San Francisco? Trevor: In Pacific Heights. Christian: Is that different than Telegraph Hill or something? Are they close to each other? Trevor: Yes. I was in Telegraph Hill last night. It's about a 45-minute walk from here. Christian: Okay. So why are there parrots where you live? Trevor: There are a lot of parrots that are released because people would have them as captive pets and they join flocks of wild parrots. Um, there are, there's, I can't remember the exact name of the parrots, but they have little scarlet caps on them and they wake me up at 5:00 in the morning every single day. They're super loud. But often times it is just people releasing wild parrots and eventually parrot colony started to form in San Francisco. There are just under 400 parrots living wild in San Francisco. Telegraph Hill is the main area that they live but I'm across from Lafayette Park and a lot of the parrots live up in the trees in Lafayette Park as well. Christian: Well, I was talking to someone in Singapore last week and they swear that what happened is some parrots got out of the zoo, like a flock of them and they just started mass reproducing. And that's where all the parrots came from. Trevor: I had not heard that story. Uh, it could be. I've always just heard that they were captive parrots that got released by their owners. Christian: That's a lot of captive- that's a lot of captive parrots. I was, I I just flew through San Francisco airport. I always fly through that airport and the walk from one terminal to another one, I think two to three, a hall, the whole walk you see like this painting, not painting but the walls are covered with the parrots and like a little bit of history about the parrots. Trevor: I've got a little pin that I usually wear whenever I'm wear at conferences, which is one of the, it's a miniature version of one of the parrots, and um, always works as a great conversation starter. Why are you wearing a parrot when your company is Blue Goat? Christian: Well, most people would assume you're like a parrothead and like Jimmy Buffet. Trevor: I guess so, yeah. Christian: What are the main ways attackers get into medical devices? Trevor: So attackers are typically going to look for the lowest hanging fruit or the fastest thing that they can get into with as little effort and research as possible. As a reminder on what happens with hackers and why they do this, it is for money. It is treated as a business. The faster you can do something for the maximum reward, the more likely they are... Christian: The bigger the ROI, yeah. Trevor: Exactly. If you can hack into this one company in 15 minutes and the other one takes 15 days, you're probably going to pick the first one, even if there's, you know, a higher ransom on the second one. So that's the perspective of these criminals. When they're looking at what is the most realistic attack vector for a medical device, it's going to be most realistic through a network-connected device that gets attacked by non-targeted ransomware. So a prolific ransomware spreading through a network, it will latch on to anything that it can get into, especially the way that this is typically deployed is through complete domain compromise and then proliferation through the network. Though if this medical device is to act as the starting point for such an attack, generally you would expect it to be an active directory or network connected medical device that you can see other products from. Christian: What is an SBOM? Trevor: An SBOM is a software bill of materials. That is a list of all of the software components that make up a medical device. One common misconception about it is it is not just third-party software components. So it should include your controlled software as well as part of that bill of materials. Pretty much it's just a register of all the code that you have in your product. Christian: So if it's not if it's includes your own code, how come manufacturers have to make the SBOM public to anyone that is going to purchase their product? Trevor: So the SBOM does not contain the code itself. It just says what the code is. So when you have, say you have a library or you're using Windows 11 in your product. You may have Windows 11 within that SBOM. It'll say the vendor is Microsoft, the product is Windows, the version is 11, and it will have a hash of or a hash being essentially just you encrypt the full bit of code so that you have an identifying value from it. Does not contain any of the information from the code. It's just a unique identifier where you can map it back to the code and see that it is the same value. And that is the information that will be provided. There are a couple of other details that go into SBOM minimum elements, but those are the main points that are covered. So you're saying this is the product, this is who makes it, this is the version of the product, but you are not providing the source code. So, similarly, if you are integrating your own source code into an SBOM, there's no risk of say a competitor uncovering that or an attacker finding it, since they would just see that you have, you know, the Acme device made by Acme Corporation and it's on version 2.0. That's all the information that would be captured. Christian: Related to SBOM, what is a, or what is SOUP? S-O-U-P? Not like Campbell's soup but like related to the SBOM. Trevor: Good clarification. I was going to go down that other path. But soup in this context is software of unknown provenance or unknown pedigree. They're kind of used interchangeably. And it is effectively any software where you're not exactly able to pin down exactly the origin of it, what it is doing to 100% extent. Interestingly, this can be your own software as well. If you have very poorly or very, or absent documentation for code that was written or maybe a previous engineer that had worked at the company wrote some code, has left, there's no documentation, people know it works, but nobody knows why. That is technically considered software of unknown pedigree. So it is effectively any code that you're integrating into your system where you can't exactly pin down the origin of it. Christian: Perfect. I just noticed I, I have a glass here that says Blue Goat Cyber. Where did the, the name Blue Goat Cyber come from? Trevor: The name Blue Goat Cyber came from you going mountaineering and climbing in high mountains. I'm assuming Pacific Northwest where there are goats absolutely everywhere. You get up to the top of the mountains and you'll see the goats climbing higher than anyone else and then that contrast of the goats against the blue sky and also the image of integrity and commitment to excellence that blue often represents. Christian: True, and goats are always trying to get to the next level. Trevor: They are. Christian: I think I've done all my, uh, questions here. You can throw a few softball questions at me and then we'll wrap up. Trevor: How would you best describe the difference between static application security testing and dynamic application security testing? Christian: I would say static application is you're looking at the code, like line by line or using a tool and the code is not running, it's static. You're just looking at the code, using a tool or you might manually be looking at the code. Dynamic, the code is actually running, so you're interacting with it and testing it as the code is running. Trevor: Yep, exactly. What standard dictates how quality systems should be developed for medical companies? Christian: I forgot to ask you this one. ISO 13485. Trevor: What standard dictates how general quality system should be built? Christian: Uh-oh. ISO 9001. Trevor: Yes. Correct. Christian: You're trying to stump me, I said those are softballs. Trevor: Well, hey, you did it. Christian: Cool. A-all right, awesome. Any, uh, departing words here before we wrap up? Trevor: Well, now I have to go figure out exactly where the parrots in San Francisco came from. Christian: All right, awesome. Uh, one other question, Trevor. How many countries have you been to? Trevor: Oh, I don't know. Um, 30 something, I think. Christian: Okay. Quite a few. Awesome. Trevor: Quite a few. I've been all over Asia, through most of Southern Europe, um, all over North, Central America. I've not been to Africa though, and so there's still a lot of countries on the list. Christian: Yeah, I have a lot on my list too. I, I think I've been to about 82 countries or so right now. Trevor: Well you got me beat by a lot then. Christian: Yeah. Well, I'm a little bit older than you, so I got a few more years. And I'm traveling like every, every week now. So I'm getting a new country in here pretty soon. Malta, I've never been to Malta. So that's a new one. Um, everything else this year I've been to before. Trevor: Well there you go. Christian: Awesome. Well thanks everyone for tuning in. I hope you found some value in this episode. It's a quick kind of rundown of all the terms you may hear in Medical Device Cyber Security. I know we went through a lot of standards and some people like to say it's kind of robot talk, but in MedTech, uh, we do talk about all these standards and in cybersecurity we talk about these standards as well, especially the intersection of medical device devices and cybersecurity. So I hope to see you on the next episode and I hope you found value in this one. So, adios and talk to you later on.