The Growing Importance of Interoperability and Third-Party Component Security | Ep. 14

In this episode of The Med Device Cyber Podcast, hosts Christian Espinosa and Trevor Slattery delve into the critical topic of interoperability in medical devices and the significant cybersecurity risks it introduces. They begin by defining interoperability as the ability of a medical device to connect and exchange data with other systems within a healthcare delivery organization's (HDO) environment, such as networks, wireless connections, and other devices. The central argument is that every point of connection creates a new potential vulnerability, expanding the device's attack surface and increasing overall cybersecurity risk for both the device and the hospital network. A key concept explored is the 'second-order attack,' which Trevor Slattery explains in detail. Unlike a direct attack on a target, a second-order attack involves compromising one system to indirectly gain access to another. He provides concrete examples relevant to healthcare, such as an attacker modifying DICOM image files on a PACS server. When an interconnected medical device ingests these malicious files, it becomes compromised. This principle works in reverse as well; an insecure medical device could be used as a pivot point to attack other critical systems on the hospital network, like the Electronic Medical Records (EMR) system or even seemingly benign devices like printers, which Trevor notes are notoriously easy to hack. The conversation emphasizes that this risk is a two-way street, where the hostile nature of many hospital networks can endanger a secure device, and a vulnerable device can poison an otherwise secure network. The hosts also discuss practical considerations and solutions for both device manufacturers and HDOs to mitigate these interoperability risks. A fundamental recommendation is to implement robust data integrity and authentication checks. Every piece of data entering or leaving a medical device should be validated to ensure it is from a legitimate source and has not been tampered with, for instance, through the use of digital signatures. They also advise against reinventing the wheel by creating proprietary communication protocols. Instead, leveraging well-established, open-source, and heavily scrutinized standards like DICOM is a more secure approach, as these have been battle-tested over many years. Furthermore, the discussion touches on securing physical and logical ports, such as using whitelisting to allow only specific, authorized USB devices to connect. As healthcare moves towards greater digital transformation and data consolidation, the hosts conclude that addressing the security challenges of interoperability is not just a technical requirement but a fundamental aspect of patient safety.

Christian: Hi, welcome back to the Med Device Cyber podcast. I'm your host, Christian Espinosa. I'm here with our co-host, Trevor Slattery. Christian: And today, we're talking about an important topic, interoperability and some of these cybersecurity risk associated with interoperability. Any medical device is going to be deployed on a healthcare delivery organization environment, and it often has to interoperate... Uh, it's a it's a challenging word. Um, be interoperable with other systems on that environment. And any time you connect one device to another one, uh, you've across a network or wirelessly or Bluetooth, that that introduces more cybersecurity risk. Christian: So we're going to go over that today and some of the considerations a manufacturer should consider as well as a healthcare delivery organization, an HDO, should consider. Christian: So how, how you doing today, Trevor? Trevor: Not too bad. It's uh, turning into a full-on blizzard outside. I can't see the house in front of me anymore, but uh... Christian: I don't think it's really a blizzard in Flagstaff. Trevor: No, it's supposed to get a foot and a half of snow this morning. Christian: Well, I think the last podcast you were complaining about not enough snow because you couldn't go to, you bought that annual ski pass or something. Trevor: I know, and as soon as it starts snowing, I'm leaving tonight for, like, a week and a half, so now I don't get to enjoy the snow. Christian: Oh, no. Sounds like a first, first world problem to me. Trevor: Yep. Christian: Awesome. Christian: Well, uh, let's uh, dive right into it. So, what do you think are the main risks associated with interoperable medical devices? Trevor: I think there, it can depend on the device. I would say a blanket problem that can be present in a lot of devices. So, a lot of like newer penetration testers won't be as experienced with this concept, and a lot of cybersecurity professionals may not even be very familiar with it. And that's the concept of a second-order attack. Trevor: And what we're really saying when we say a second-order attack is you exploit a vulnerability in one system that compromises another system. So, you don't directly see the impact, but you're feeding in bad input or bad data into somewhere else, and then that triggers a problem. Christian: So let me back up a second to make sure our audience understands what you're saying with a concrete example. So I, I think you're saying if I can exploit a, a PACS system, for instance, that has DICOM files on there and modify the DICOM files so those are ingested by a medical device, then we could infect that device with these infected DICOM files. Is that right? Trevor: Exactly. Or like if I was able to somehow compromise this mouse and I made it send different Bluetooth signals instead of just operating the mouse like normal, it controlled input to do certain bad things on my computer. While I technically hacked into the mouse, I compromised my computer. So that would be another example of a second-order attack. Trevor: And I think that can be a pretty big and prolific problem with medical devices. And the main reason being that even if the device itself is secure, so there isn't a problem that you can necessarily exploit in the device itself, a lot of components in a hospital might not be secure. And a lot of components, you know, it may not even be at the front of someone's mind for security. Trevor: Like a printer, for example. I know every, every penetration tester has their war stories about hacking into printers in hospital networks. Christian: We love talking about these printers. Trevor: It's, I'm serious. Every time I've been on a hospital penetration test, it's been my first way in is through a printer. And so if you have a medical device with a problem, you can potentially exploit that problem in a second component, like a printer, like an EMR system, like a workstation. And so I think that's a big concern with interoperability. But I know that there can be a couple of other areas that that covers as well. It's a little bit of a broad topic. So, I'd be interested to hear what some of the, what some of your thoughts would be on the topic. Christian: Well, I think it's a two-way street what you're describing, right? Uh, you said a second-order attack... from the perspective somebody attacks a printer, and then they leverage that to attack the medical device, or somebody attacks the EMR and that attacks the medical device. But it's also the other way around, right? Somebody can attack the medical device and then that could attack the EMR or the PACS system or any other system on the hospital environment. So it goes both directions, right? Trevor: Yeah, exactly. Christian: Is there such thing as a third, a third-order attack? Trevor: You know, I'm sure there is. Um, it gets down to the complexity of a system. Once you get to a third stop, you can get pretty far removed from the first device that you're attacking. Like I would think, you know, technically a third stop would be going from my mouse like to my router or something that's really far detached. There's no connection there, but there is, you know, some transitive component that you can jump through. So, I'm sure it is possible. I'm sure it's very difficult to pull off, but it would be a pretty edge case scenario. Christian: Yeah, I know when I did DOD stuff, uh, we always, well, not we, but the enemy, I guess, would go from like one country to another country, to another country, to another country. You know, so maybe go from Russia to a system in Korea that you've a compromised, to a system in Malta, to a system in Finland, and then to the U.S. So it, it's hard to trace back that attack back to the source because it's being bounced through all these systems you've compromised. Uh, so it does definitely cover the tracks in that scenario. So that would be, I guess, more of a third order or fifth order or something like that. Trevor: Yeah, tunneling through all these compromised systems. Christian: Yeah, yeah, exactly. Um. Christian: So, interoperability, do you feel like we're, I, increasing the number of devices that are interoperable from a medical device perspective? Trevor: I think we are. So much, so much in a hospital environment or just in a healthcare organization is connected now. Everything hooks up to the internet in some way or there's some connection between two components. So there's a hub for data transfer in one way or another. Everything plugs into an EMR system. And I think that's a great thing. Um, of course, it introduces challenges from a security perspective, but from an operational perspective, it lets everyone have very easy access to information. It lets data transfers happen near instantly now where before it took a long time having to deal with faxes and passing around physical paper documents. So data transfer is extremely fast, data transfer can go very wide, very far, very just spread out. It can cover a lot of ground really quickly, and I think that's really helpful, especially in healthcare, where stuff can be super, super time-sensitive. Trevor: Uh, now, of course, this introduces a lot of security risks, especially in like large connected networks. Um, anytime you're introducing a new component to that network, it's connected to dozens of other, if not hundreds or thousands of other components. And so if there's a problem in one of them, that can often lead to a problem in a lot of them, which is why we really need to be careful with securing devices, looking at that interoperability component. Christian: Yeah, I feel like in healthcare, we're kind of at the infancy stage of interoperability. 'Cause I, I know like if I go to the doctor, I still have to fill out freaking like, you know, photocopy pieces of paper you can barely read like what they're asking for, right? And then somebody takes it and types it in the computer, you know, and then it goes somewhere, but it's like, it's still a very antiquated system, I think. And when I was in, uh, a few weeks ago, I was in MedTech World in Dubai, and there's this big push for digital transformation because a lot of people are saying, we have all this data about, you know, a patient, but it's not consolidated anywhere. Some of it's over here, some of it's over here, some of it's over here. And without it being consolidated, you can't use tools like AI to really do some analysis or try to predict someone's condition later on because all the data is isolated. So I believe there's going to be a even bigger push for interoperability so we can have this data more readily available, which is going to introduce more risk to a medical device, to a hospital environment, to a clinic, uh, and I, I don't know, I think it's going to be very challenging to make this secure. What are your thoughts? Trevor: I definitely agree. Um, and one thing that comes to mind when you're talking about like a single source of truth for this information is there's also a single point of failure. So, if you have that single source of truth and someone's able to compromise it, then they're able to access so much information for so many people. So, it's a little bit of a double-edged sword. I think that from a healthcare perspective, from a functionality perspective, it would be fantastic. We'd be able to do things so much faster, you wouldn't have to try to track down information from different hospitals and different doctors. But from a security perspective, it becomes a little bit of a nightmare. Um, you know, we always talk about how inherently insecure healthcare networks are. Hospital networks, all things like that. Christian: We call it hostile networks. Trevor: Hostile networks. One of my scariest and favorite statistics is at any given moment, there are around 2,000 EMR systems exposed to the open internet with no password on it. So you can just go and look at people's... Christian: Where do you find that? Like a Shodan or something? Trevor: Yeah, on Shodan. Christian: Okay. Trevor: Yeah. 2,000 with no passwords. Christian: So, I don't wonder everyone's medical records have been stolen. Trevor: Exactly, it's easy. You just, you can just quite literally Google it and see them. And so, it's a pretty scary thing. I think that while interoperability is in its infancy, so is just security awareness. And I think, unfortunately, interoperability is accelerating a little faster than security awareness, and so it's being done in a dangerous way in a lot of times. Christian: You know, it's an interesting point because EMRs, uh, electronic medical record systems have security controls, but what it boils down to is the person setting this thing up, doing it correctly. You know, have they turned on the right settings and turned off the wrong settings? And the the answer, according to these 2,000 you said are exposed, is obviously no. Trevor: Yeah. And another problem with it is some of these were set up, you know, 15, 20 years ago and just never touched. And obviously, you know, security has evolved a lot in the past 15 or 20 years. Security is one of those fields where even in the past year, it's changed massively. So, leaving something unprotected for that long is just asking for problems. Uh, the hacker skills are evolving just as quickly as the defensive skills are evolving. And so if we aren't keeping up on the defense side, then the hackers are naturally going to win. Christian: Yeah, what's, I think you mentioned it the other day, it's a challenge for the good guys, per se, because we have to get a hundred things right, and if we just miss one, that's the way the attacker can get in. So the advantage is always to their side, right? Trevor: Yeah, they need to get lucky one time. We look at, one of my favorite examples to always go over is the MGM hack. That was something everyone heard about, was top of the news for a long time. All their systems were pretty good, pretty secure. Casinos definitely take security very seriously. Um, I recently was actually able to meet with the VP of operations at MGM out in Macau, and we were talking about security features in casinos. They make these things very, very hard to compromise. Christian: I think they're way more secure than healthcare and finance. Trevor: I think they're more secure than banks and, like, government, healthcare, everything. Casinos are a well-oiled machine. Christian: Then why did MGM get hacked? Trevor: It was one point of failure. One person, it was like a, I think it was a help desk rep or, it was a social engineering attack. And so one person gave up their credentials to a phishing attack over a phone call, and that's all it took. They were able to just run through the network as soon as they had those credentials. So, it's another point of, there were 10,000 security considerations going on in those casinos. They got 9,990 of them right, and the attackers found, you know, one of those 10 problems left, and they were able to just run through the network, take over everything, and shut down basically the entire city of Las Vegas for a while there. Christian: Did they have multi-factor authentication enabled? Trevor: They did, but I think it was a bad configuration through um, oh I can't remember what the provider was. I remember it was a provider with a known problem where you could bypass it if you had certain controls or if you did it, I don't remember the details of it, but they did have multi-factor authentication enabled. Not all multi-factor authentication works properly all the time. Christian: Of course. Christian: With with the interoperability, if I am a device manufacturer, what are some of the things um, I can do or consider to make sure my device is securely interoperable. Trevor: I think the first point, and this is probably the most important one, is checking anything that comes into the device. And we'll get to the other side of that here in a second, but any data that is moved from a secondary location to the device needs to be checked and validated. Uh, data authentication is one of the primary security controls that the FDA calls out. Authentication is normally thought of as identifying yourself as a user or like an entity identifying itself, but it can also be verifying the source and integrity of information as it comes into a product. Christian: So this is like data integrity with like a digital signature or something? Trevor: Yeah, a digital signature. Um, I know the FDA sort of leans away from cyclic redundancy checks, which are essentially just like hashing a bit of information to make sure... Christian: Yeah, those came out like the 1960s or something. Trevor: It's super old. There are other ways to do this now. But we just need to verify that data coming in is what we expected it to be. On the other side of that, you know, while that's going to protect the device, we need to protect what the device is connected to. We have to protect the EMR system. Uh, if you look up vulnerabilities in DICOM servers, you'll see hundreds of pages pop up from security researchers publishing articles on how they hacked into popular EMR systems. So, on the inverse, we need to check anything leaving the device. It may be the case that the device let you put in a bunch of bad data, doesn't do anything to the device, and then when you pass it into the EMR, it crashes the whole system. So, anything entering, anything leaving needs to be verified as accurate and secure data. Trevor: I think that's the primary concern for any data flows. And then, of course, it can get down to the specifics. If you have a USB port, there are all these controls. If you have an Ethernet port, there are all these controls. But just the general rule is data integrity. Christian: Yeah, and I was talking to someone a couple days ago, and they were saying like the future of healthcare, which goes back to your previous point, about a centralized source of truth is going to be on the blockchain. Christian: And what are your thoughts about that? Trevor: I don't know about that. I don't think that it would be a bad idea, exactly. I just think if blockchain technology was really going to take off, it would have done it by now. And so I feel like there is a use case for it. Um, it's, it's pretty secure. It's very hard to forge an action, which gets down to, when we're looking at medical device threats, that brings up threat modeling, um, like repudiation, proving that an action was taken by a legitimate source, that does fix that problem. And so I don't think it would be a bad idea, but I don't think that the implementation would be very widespread because if it would, if it was going to be widespread, we would have seen it by now. There are all sorts of talks about how we can use the blockchain for, you know, obviously cryptocurrency, uh, for voting, for... Christian: Health care for, yeah. Real estate. Trevor: Real estate, all this stuff, but none of it ever happens. So I don't, maybe, maybe I'm wrong. Maybe, maybe it's still just taken off, but I don't think it's going to happen. Christian: Yeah, I guess that's a good point because if the healthcare systems, I think worldwide, are so analog still, getting all the way to blockchain implementations, uh, pretty far off if it if it will even happen. Trevor: Yeah. And blockchain's not a new thing, it's been around for a long time. So I feel like it's had time to grow and mature. Like AI is a great example. AI is still a pretty new thing or I guess modern, really effective AI. Um, and that has taken off. I mean, that's in every industry, it grew like wildfire. Everyone uses AI, it's in every system, every industry, every product now. And so that's an example of a technology that comes out where people go, "Oh, this is really cool, let's use this everywhere." And I just don't think that happened with blockchain and I feel like the window's passed. Christian: Yeah, I, I tend to agree with that. It's kind of like the Betamax. Uh, it was a great thing but nobody adopted it so we still ended up with VHS for the the old school, you know. Christian: Cool. So, interoperability, we're, we're talking about connecting to another system. And you alluded to Bluetooth earlier. So if we're looking at interoperability from a regulatory affairs or regulatory authority perspective, are we looking at everything? Like if I have a medical device with Bluetooth that then connects to a mobile application, uh, so we've got the mobile application, we've got the Bluetooth, but then that mobile application might send something to the cloud via an API. So, are we looking at every single, like, connection point, like including the Bluetooth, the means of the interoperability, the communication channel? Trevor: So it's a little bit of a blurred line exactly what meets the definition for interoperability requirements. Um, the FDA guidance and eSTAR say different things for what meets the definition for interoperability requirements. We like to stay a little bit on the safe side and if we're in doubt, we believe it's an interoperable device. But when we're looking at something like that, so we'll take that example, there's a mobile app, Bluetooth connection to something, and then that passes it to a cloud server. That cloud server is part of the system. That mobile app is part of the system. That device is part of the system. So this, the connections aren't necessarily interoperable since it's part of an enclosed system. Trevor: Now that mobile app is sitting on a mobile phone. That is an interoperable component. You don't control that phone. The connection to the API has to go through the hospital network through a router out to the cloud. That router is not something under your control. That hospital network is not something under your control. So I think it's a matter of what do you own and what do you not? What do you know you can secure and what can you control? 'Cause that's the main concern with interoperability. You don't know what you don't know. You don't know what's going to connect to this. You don't know what's in a standard hospital network. Trevor: So if you're able to control something, then it's going to fall a little bit out of scope. I would say we can use the mouse and computer example. Uh this mouse is, it comes with my laptop and it connects automatically to the laptop. It doesn't connect to other laptops. This is part, in my mind, of the enclosed eco system of my laptop. The microphone that I'm using, I got third-party. The camera I'm using, I got third-party. These are connecting into the laptop, so these are interoperable components. So it's a matter of just what can a manufacturer really change? What can a manufacturer be responsible for? Christian: Okay, let me let me back up a second what you said because I think it's an important distinction. Christian: If I have a medical device, uh, a system that has a physical device, a Bluetooth connection to a mobile app, and a mobile app that sends data to the cloud, those components are part of the system. So it's, like you're alluding to, it's, um, it's not really interoperable with anything else, or interoperating within the system, but it's not from an interoperability perspective, you know, interoperating with with anything else, right? It's more like the the components of the system are talking with each other. But from an interoperability perspective, we're looking at this system, the umbrella of the system that falls under the definition of the medical device, it has to be talking with some other component outside of the system, right? Trevor: Exactly. So, what, well with that example, we'll say that the device with the Bluetooth connection to the mobile app, um, whatever it does, it's an ultrasound probe. If the manufacturer is creating that ultrasound probe, it is only going to connect to that mobile phone, to that app. All the proper Bluetooth controls are in place. It's using Bluetooth authentication. It has to connect to that app only. Nothing else is going to work. That the manufacturer controls. They're able to make any changes they want, they can shut out other devices. If they're doing Bluetooth authentication properly, it's only going to work with that device. So that's not something that you really have to worry about. You have to secure the connection between the two, obviously, but it's the same as securing the connection for parts inside of the ultrasound probe. You have to make sure everything is secure in the system. Trevor: Now, if it's a bring-your-own-device situation, you bring your own ultrasound probe and you connect it to the mobile app, and it will connect to any ultrasound probe, that's an interoperability consideration. You're using someone else's component in your system. So you have to make sure you don't know what's going on with that component. You don't know if it's safe or secure. You don't even know if it's an approved device. And so, you have to make sure whatever is leaving or entering that component is safe. Any data has to be checked before it can leave that component into the mobile app. Cuz what if there's something dangerous coming in that can compromise that phone or leave all the way going to that, you know, third order attack of compromising the cloud server? So, it's just a, it's an important distinction to make when you're mapping out what are you doing with a device, what components are you building into it and what components are expected to be user-provided. Christian: Would a solution for that be that the manufacturer provides their own mobile platform? Trevor: That would be one solution. I think that it's something that we've seen before to just not have to worry about all this stuff. It's a lot of work to make sure that you can properly and safely interact with the system. Um, who knows what users are going to bring for their own devices? They might bring, you know, some weird Android phone from 2008 that barely works and say, well, it's worked on everything else. So, you can add a layer of control by doing that. Now, having said that, that can be expensive. It can be a lot more time consuming. You have to collect a lot of these phones and sell a lot of phones with the product and that takes time, that takes money, buying all this phone all these phones might not be something that the manufacturer wants to do. So it's one way to do it and the other way is just really drilling into the core security concerns for whatever the device is. For a mobile app, there are a lot of low hanging fruit vulnerabilities that penetration testers and hackers pick up on all the time. Bad Android configurations, uh hard coded credentials, exposed secrets, letting it run on an insecure version of Android. There are a lot of problems that can just be easily introduced. Trevor: Now, I think that, and this is a little, I hear a lot of people go back and forth on this opinion. I think that phones are inherently secure. The Android operating system is so sandboxed from any functionality. If there is a compromise of an app, if the if you download malware onto your phone, you have to let it access functionality. It'll ask you, can I access the file system? Can I access your camera? And... Christian: Yeah, most people just, just say accept all. Trevor: Yeah, they just have, sure, sure, sure, sure. Yeah, whatever, you want to access my bank account? Why not? But if you're not doing that, if you're thinking about why does this app need to access my bank account? That doesn't make much sense. The Android operating system is inherently very secure. It sandbox you out of damaging stuff. So I think that as long as that's properly set up, and that goes into like permissions for Android, what should the app be able to access, what should it not be able to access? That's another very easy, low-hanging fruit thing to cross over. You really don't have to worry as much as you'd think, just making sure that you're implementing good basic controls, general cyber hygiene for your product. And you don't have to go as far as providing your own phone. You can if you want, and you have more layers of control there. But if you're taking care of the app the first time around, you can put it on anything and it'll be okay. Christian: Yeah, so it sounds like from interoperability perspective, the the normal cyber security things to apply, the normal control, like to make sure you're, you know, all your ports are secure, your Ethernet port is secure, your USB port is secure. But then the additional component is to check the data as it's coming into your device to make sure it has integrity, and to check it when it leaves the device. Is there anything else that would be like a major thing of consideration for interoperability? Trevor: I think restricting who has access to interoperability. Um, USB ports are probably the trickiest one to get right because USB has so much functionality. Uh, you can add files to it, you can plug it into a camera, you can use it for data transfer, you can update devices with it, you can use it for video capture. You can do a lot with a USB port, it has really wide functionality and attackers know that too. So USB is a very easy way to compromise a system. Now, you can put a physical lock onto it and you need a key to open up the USB port. If you're doing that, you're restricting the access to who, you're not even letting most people get around the interoperability. You're really, really stripping it down to only people who need that key and have that key. And that's just one example. You can get a key for Ethernet, key for HDMI, you can just disable it and require admin credentials to re-enable it. There's a lot that you can do to really restrict access to who can interact with the interable components. And I think that's good. It just reduces the odds of like, you know, someone finding a thumb drive in the parking lot on their way into work and they go, "Huh, wonder what this is." And they just plug it into some device. It seems silly and it seems crazy, but that stuff happens all the time. That's social engineering and red teaming tactics 101. Leave thumb drives out and people will just plug them into random things. Christian: Yeah, from a medical device perspective, in your USB example, would you we want to white list what types of devices are allowed to be plugged into our medical device? Trevor: Yeah, definitely. So, depending on what you intend that USB port for, let's say it's used for updates, then it's likely that you're only going to want certain removable media to interact with it. Um, so you couldn't plug in like a a wireless adapter or something like that. It just wouldn't even recognize it. Regardless if there's a cover or not, if you actually remove the cover and plugged in, it wouldn't even recognize that device. Trevor: Exactly. We've had um, clients in the past before going to the level of detail where only a certain brand and a certain model of keyboard or mouse is used. If they want to have that functionality of a keyboard and mouse, which can open up vulnerabilities in a system for sure, but sometimes that added functionality is important. So they say only this brand, this exact model is allowed. We don't tell anyone what that model is, and we only give it to service technicians. And so then if you plug any other mouse or keyboard, it'll just reject it until you get the right one and then you can interact with the system. So, there's a lot that you can do to secure these systems. It's not a blanket solution and it's not something that manufacturers should shy away from because of security problems. There's a lot that you can do to make sure that interoperable components are safe. Christian: Now, what about if we have the scenario where I have something in the cloud, let's say it's a software as a medical device toMD uh and it it's receiving data from the healthcare provider, it does some analysis with AI and then sends it back uh and it's on AWS. Do we have to consider interoperability from like this instance on AWS with maybe an S3 bucket? Like what are some of the interoperability concerns with that if any? Trevor: There are definitely some concerns around like a cloud host provider. AWS does a pretty good job at inherent security, but it still has to be configured right. Uh, it, you know, at a certain point you're going, you can keep expanding out into layers. You say, well, we need to secure AWS. Well, we need to secure what goes into AWS. So we need to secure the development environment. Well, we need to secure those work stations that developers are working on. Well, they're working from home, so we need to secure their home network. You can keep going out for all these different layers. But with the AWS example, there are right configurations and there are wrong configurations. S3 buckets are, you know, very popular method for storage, and they're misconfigured all the time to leave information out in the open. So, there again, it's a situation of just general cyber hygiene. Get rid of the low hanging fruit. Make sure you're dotting your eyes and crossing your tees on security for these common platforms. AWS security guides are out there. It's simple to implement as long as you're doing it right the first time around. So, yeah, there are definitely concerns there. If you misconfigure it, you can expose a lot of risk in that system. Christian: Awesome. Uh I want to dive into one example here. I I know we had just a while back with a uh prospect and then we'll wrap up because we're almost up on time, like we had a prospect and you you know more about this than I do that instead of using a standard, uh, protocol, I believe it was DICOM, they decided to write their own DICOM protocol. Uh, and that that, to me, like breaks all the interoperability consideration rules. So I'm just curious like your take on that scenario. Trevor: I think that a lot of times proprietary protocols can be a great thing. Um, but there's no point in reinventing the wheel. There's the DICOM toolkit, which is an open source library for DICOM transfer, upload, uh, supports encryption, it has built-in security controls and it works really well. Nine out of 10 times, everyone uses the exact same DICOM library. So, given that it is a pretty secure component, there aren't any known vulnerabilities in the latest release. It's actively supported, and it's used by millions of products. I don't see a ton of value in creating something like that from scratch when there's already a great solution out there. If you want, sure, go for it. You need to make sure that you're covering all the security points. You may introduce levels of risk into the device by doing this. The DICOM toolkit is a very heavily researched toolkit. If there are problems, they're going to get identified and problems have been identified in it and they've been fixed every time. So, I think that it's not the best use of time in general. If you need a proprietary protocol for a certain interaction between components or proprietary data transfer, that's totally fine. We see that all the time. Manufacturers need to make proprietary protocols often if they're dealing with novel technologies. But I think an example like DICOM is it's just not the best use of that effort. There are there are better things to focus on. Christian: Yeah, I I I agree. I I generally think uh writing your proprietary protocol if there's already one that exists, doesn't make a lot of sense because the one that's already out there, like this could be Ethernet as example, uh has been tested, battle tested over the years and the in years and years, and there's plenty of data on it, and there's plenty of security updates. Uh but if you write your own, it hasn't really been tested. So it's like it's super risky I think, unless it's within a system that's controller self-contained which would not be interoperable. Trevor: Yeah. Even still though, I don't see much point in you're reinventing the wheel. There's already a perfectly good solution. And using DICOM toolkit, it's free. It's an open source tool. You can just put it in your project and you're good to go. So, there's no money constraint around it. There's no time constraint, super easy to integrate. I don't get why someone would want to do that from scratch when there's already a perfectly good solution out there. Of course, there, you know, if you're interacting with you're developing your own EMR. It's taking in very specific requirements. You might have to build around those requirements. That's understandable. But when manufacturers are creating a device that is just expected to operate with a normal DICOM server like Orthan, one of the popular ones that is super wide spread. There's not much point in trying to create something special for it. There are already a lot of resources that work very well to interact with those uh DICOM servers. Christian: Yeah. Christian: Awesome. Well, we're up on time here. Uh I like to always ask for any last, last um, parting words of wisdom. You have any Trevor? Trevor: Yep, data integrity. Always check what's coming in, always check what's going out. This is super important for medical devices, but it's important for any connected system. Um, an IT network, a healthcare network, a phone, whatever whatever data is being moved around, you have to make sure that it's safe data. Christian: That's a fundamental cyber security control, right? Even with a a forum on a website, we want to do input validation to make sure it's the data is in the right format. So this is not something new, but it's something a lot of people don't think about from an interoperability perspective. Trevor: Yeah, exactly. I think, uh, it's funny when you're in the weeds of an industry, you overestimate what people are familiar with. And so you say, you know, you live and breathe cyber security for so long, you go, "Oh yeah, the CIA triad, confidentiality, integrity, availability. That's common knowledge." But it's not. You know, people don't know that's a core cyber security control and people just aren't familiar with cyber security, but yeah, it is very important. Christian: For sure. Christian: Awesome. Well, I hope everyone enjoyed this episode and be sure to tune in for the next one. Thank you.