Cybersecurity Labeling and MedTech Transparency

Hi, welcome back to another episode of the Med Device Cyber Podcast. Today we're going to talking about a complex, but yet simple concept. It's called labeling. Specifically, we're talking about cyber security labeling. And we're going to hit some of the main points about labeling. What is it... is... some of the common misconceptions, how a manufacturer should be doing labeling. We'll also hit at the MDS2, which is a common form people have questions about. So, that's the objective of today's podcast. I'm your host Christian Espinosa. I'm coming to you from Florida today, I got stuck here for a couple days, uh, so I've got a portable setup and I've got Trevor here. I don't know where Trevor is today, actually, where are you today Trevor? You got like these... those weird wooden background things. Trevor: Yeah, I'm uh, in Arizona for today. Off to California tomorrow. Christian: All right. Awesome. Cool, so... in... as far as a definition of labeling goes, what would you... or how would you describe labeling, Trevor? Trevor: So, labeling is the information that a manufacturer or a MedTech innovator needs to portray to users and patients. Uh, this is essentially going to be under the cyber security context, what risk are they taking on by using the product? And how can they work to mitigate that risk? And then just as well generally, any information about the product from a cybersecurity or software perspective that would be helpful for users to know. Christian: So this is in the act of transparency... because the FDA is pretty big on transparency. So we're trying to like make the risk transparent to somebody purchasing one of these medical devices. Is that a fair... Trevor: Exactly. We're looking at, you know, you're gonna wanna know if you're buying a car if it tends to be in a lot of accidents because there are a lot of broken parts. You want to know if you're buying a phone. Like do you remember when the Samsung phones were exploding for a while? Christian: Yes. I think it was just the iPhone versions though, what wasn't it or something? Trevor: No, the Samsung Note something, the batteries would puff up and explode. Oh. So you'd want to know if you're buying a phone with one of those batteries. I... there might have been other phones but anyways. So you want to be aware of what's going on in the product that you buy. Uh, this is just an effort to try to portray that risk and it's also a way to keep manufacturers accountable. So if they have to disclose any risk present in the system, they're obviously going to want that risk to be minimal otherwise they're likely not going to be purchased due to the fact that they impose a very high risk to the user or to the patient. So it's that twofold area of making sure that users and customers are well informed and they know what's going on in their product and keeping manufacturers accountable and making sure that they do their best to disclose minimal risk since they shouldn't have very much risk. Christian: So it's really to help the consumer of the medical device, which is typically a healthcare delivery organization, make an informed decision. If they're comparing two different products and they have a specific risk appetite, they have a little more transparency into the risk associated from a cyber security lens with either device. Trevor: Exactly. Um, good cyber security labeling is also going to contain instructions on best practices for use, integrating it into an existing hospital network, any optional configurations that may be security relevant and when you should use them. So good cyber security labeling is not only conveying potential problems but saying, here is a way to fix those problems. Here's how you make sure that you're setting up this product safely. So good cybersecurity labeling is going to cover all of these different areas. Christian: Yeah, and what... what... how does the MDS2 fit into that labeling? Trevor: It's a good idea to take a bit of a standardized approach when it comes to cybersecurity labeling and an MDS2 is part of that. So that stands for Manufacturer Disclosure Statement for Medical Device Security. And what that is essentially saying, it's a questionnaire. I think it's about 180 line items and it's different questions about the product. Christian: It's just a civil document basically that a manufacturer has to fill out to disclose certain, like what type of encryption you have, what type of authentication you're using. So the same concept, it's a labeling to inform a consumer of the product or the medical device, like what the risks are and what protections are there as well. Trevor: It ties closely into things like NIST certification, ISO 27001 certification and in the um, in the template for an MDS2 put out by NEMA, you can see actually which items need to be met by certain compliance standards and the actual section out of those standards. So if you're ISO 27001 compliant, you can translate that directly into your MDS2 and it'll show you which boxes you can tick with that compliance and then exactly where it comes out from. So it takes a standardized approach, which is really great to pull in other standardized approaches recommended by the FDA. Um, and so the cybersecurity labeling side of things shouldn't be a very complicated process as long as you had your quality system and your just general compliance set up beforehand. MDS2s are not the only standardized approach towards labeling. Typically what we recommend is a mix between the MDS2 and the JSP2, which is a Joint Security Plan and they have customer security documentation in there. This is something that's recommended by the FDA for use in labeling. And that JSP2, the customer security documentation goes into more on the what the user should do side. So MDS2 is facts about the product and JSP2 is how to use those facts to increase your security posture. How should you configure the product? How can you integrate it into an existing system? And that also is where we'll find that uh risk disclosure. Here's a list of any of the problems that are possible in the product. Christian: And what are some of the common misconceptions of labeling? Because I know with clients, we talk about tamper-proof seals. Um, I guess that's technically control, but it's also a label. Um, and a lot of clients, they ask specifically like, what do we do about cybersecurity labeling? They just... they have no, I guess no concept of what it really means. Um, so what... what are some of the common misconceptions or would you say common questions people ask about labeling? Trevor: I think it's a bit of a new area that people are still figuring out. So labeling for medical devices is as old as medical devices themselves. It's nothing new when we're just looking at general labeling. Anytime you even if you just buy anything, a pair of headphones, it'll come with a list of instructions for it in a couple different languages, any of the standards used, some things about electrical safety, stuff like that. So that's always been present for medical devices. I think when we're moving into the cybersecurity labeling, one of the biggest things that comes up is isn't disclosing this information going to let hackers attack us? And that's a pretty big misconception. Part of that comes from the software bill of materials being part of labeling. So you're disclosing what different components are in the product. Um, part of that comes from disclosing the potential risks in the product, part of that comes from disclosing the architecture. And while if you have an insecure product, that information can be leveraged by attackers, if you have an insecure product, they're going to attack it anyways. This goes back to that accountability that I was talking about. Part of the drive to push out all this information is the thought is that manufacturers should not have very many problems to disclose. They should be addressing security at a solid level. Christian: It's not it's... it's the opposite of uh, what do they say? Security through obscurity, right? Trevor: Yeah, exactly. It's security through transparency. Christian: Exactly. Trevor: But I'd say that's a pretty big one and then just where to start. So the FDA has a list of requirements that they want to see for labeling. And we often get a lot of questions, oh, is this going to be covered by MDS2? Is this going to be covered by our software documentation? And the answer is sometimes. So the labeling requirements from the FDA are a little bit vague, and they don't take a specifically standardized approach. That's why we hybridized the approach with the MDS2 and the JSP2 customer security documentation. In combination, that covers most of the FDA asks. There are a couple of additional things that we have to add, but for the most part, it's a very good combo. Christian: So we have the MDS2, the JSP2, which are two ways to provide that transparency in labeling. We also have a labeling document, uh like the instructions that are sent with the device. We have tamper-proof seals. And then we have the software bill of materials as well. So all those would fall technically under the umbrella of labeling. Trevor: Yep. In this context, the tamper-evident seals would be more of a control. Um, that's it's... that's something that we get a lot of back and forth with since they can also be called tamper-evident labeling. But it's more labeling as in like sticker labeling. And so when we're talking cybersecurity labeling documentation, we're talking disclosure information. Um, when we have tamper-evident labels or tamper-evident seals, that becomes part of our labeling in the context that that is a check. That's a control. Someone has to go and look get these seals every time they're going to use the product. Christian: So the labeling would be the seal would be the control. The labeling would be, you would tell the user of the product, if you notice this seal is broken, assume the device is compromised and don't no longer use it. That would be the labeling portion that ties to the control. Trevor: It's the labeling for the labeling. Christian: Yes. Cool. And I, I uh, I wasn't thinking about 'em until you talked about it, but I think I'm having a... I'm in a hotel, I have a coffee cup here, but it has a lot of labeling on it. It says careful, contents are very hot. It also says do not microwave, and then at the bottom it says this cup is made with 10% post-consumer recycled fiber. So there's actually a lot of labeling on just a paper coffee cup right here. Trevor: Yeah. I see the same thing. Looking at this can, you know, it's USDA certified, certified B corporation, whatever that means. Apparently it's gluten-free, so there you go. Christian: The can is gluten-free? Trevor: I'm assuming it is. Christian: That's a good thing. There's no wheat in there. Trevor: But even looking at, you know, on this can we see the list of ingredients, how many calories are in it, how much sugar, all of that. That is food safety labeling. So, you're providing information to the consumer of this product about what's in it. What's going on? How much sugar is it? Um, when you have, you know, alcohol it'll say should not be consumed by pregnant women, you know, there's a risk of addiction, should not be consumed while driving, things like that. Um, it's the same and then on a box of cigarettes it'll say nicotine is an addictive chemical. You should not buy these. And so that is essentially the same concept. We're informing users of risk. This even has a statement that, uh yeah, pregnant women, children or individual sensitive to caffeine should not consume this product. So that's informing you the risk of consuming caffeine. Which is a little bit of a different level of risk as opposed to using a potential dangerous medical device, but the principal remains the same. We have to inform users of any potential problems that could come up with using this product. Christian: I think the challenge is with like the ingredients of that Yerba Mate or whatever you're drinking there, uh, those are like physical things and the warning is like, you know, pretty like if you're if you're over-like stimulated by caffeine, maybe you should avoid it. I mean, those are pretty obvious. I think the challenge with cyber security is like, what do we actually need to disclose? Like, does someone need to know this device uses AES 256 encryption uh because if they're trying to make a decision and one uses triple DES or something super old, they could say okay, I don't want to use that one. Is is that the purpose really and then how how much detail do we really need to go into? It's kind of unlimited. Trevor: So the more detail the better in my opinion. I fully believe that outside of disclosing any risk this is a way for manufacturers to make sure that they are really on top of their security. Same way they have to be on top of their safety. They have to be on top of any FCC certifications or EMC certifications. So they really, really need to be on top of covering all these bases. If they are disclosing saying we're using triple DES in our system, they shouldn't get purchased by someone. That is their fault for a designing an insecure product. Christian: So it sounds like you're saying this labeling is effectively a control for a manufacturer to do things properly because if they have to disclose if they didn't do it properly, or how they actually did it, which may not be the industry accepted method. Trevor: Yeah, and they're not gonna get acquired by hospitals. They're going to run into problems down the line if they don't have this cybersecurity covered. And so what we usually want to see is, in a secure device, this labeling is never going to be an issue. You can disclose whatever you want about the information down to as much detail as you need. The labeling is never going to require you to disclose trade secrets or give up the secret sauce of the product, like giving up your source code or something. But it's going to say enough information without giving away any proprietary company secrets where someone is very well informed about every operational function of that device and any potential risk in there. And so the level of detail needs to be pretty high, and it can be a little bit... there are two different kind of groups that are going to look for this information. The first is the actual user who we're assuming doesn't know very much about cybersecurity. And so when we're talking about that level of information, we want to make sure that that user is well informed on any potential risk in common language as well as any common mitigations in common language. So, just best practices and simple terms on protecting themselves while using this device and reducing risk. We also want to have some more information for, we'll say a hospital IT administrator who's likely going to be more familiar with these technical terms. And so how are they going to integrate this into a complex network? What network controls can they put in place? Do they need to make any changes to their firewall? These two levels need to be considered depending on who's going to be using the product and the context where it's gonna be operating. And so it can be a little bit tricky to strike the balance, but like a home use product they'll just be different from a hospital product. Christian: And what are some of the biggest challenges that our clients have faced with labeling? Trevor: I would say... that level of detail can be a pretty big one and just understanding the sheer amount of information that needs to be provided to users. Labeling documents are massive. Like I said, that MDS2, I think it's around 180 items that you need to disclose to users. And then that JSP2 adds another 20 or so in very large items. So, it's a very large burden to prepare good cybersecurity labeling. This is even besides getting through the FDA process. We'll assume that the FDA isn't worrying about the labeling. That's not the case, they very much are, but we'll just pretend for a minute. Once you're trying to get acquired by a reseller or by a hospital, they're going to ask for all of these documents. They might ask for more documents than the FDA asked. Uh if you're trying to get acquired into Mayo Clinic, for example, there are a lot of requirements they have that the FDA does not. So it can go very deep as far as how much information you need to provide and I don't think a lot of manufacturers are fully prepared for exactly how much information is involved there. Christian: Yeah, and one of the questions that came up with one of our clients, it was a very complex system with like multiple subsystems. Some of the subsystems had different levels of encryption that were less secure than let's say AES 256. So they were wondering like, how do we label or disclose this? And my thought is, we should disclose the weakest link and say, we actually have a subsystem that uses triple DES, as an example. Otherwise, you're you're not being transparent because if if we have one subsystem that's AES 256, but the rest are triple DES, you you should be disclosing the triple DES aspect of it. Trevor: Right. And I think it does depend on what you're doing for your information as well. If this is something like an electronic health record system and you're using triple DES, that is a fundamentally insecure product. I don't even think you should be disclosing that, you should be redesigning your device. If we're transferring non-essential information, it's just machine data, there's no real risk if it's compromised, then it's likely not actually going to be that big of a deal even if you have it set up that way. So, this should all be contextualized and in that big device with multiple subsystems, what is the specific subsystem doing? So, is it handling PHI? Is it handling PII? Or is it just dealing with non-essential information? Those are all things that we need to consider when we're saying what's the actual risk here? Cause in general, yeah you shouldn't use Triple DES, you shouldn't use MD5. But if you're using it for like a CRC, a cyclical redundancy check to just verify that the content of something hasn't been modified. It's likely not going to be that big of a deal. Christian: And that's a good point about the... the what you're talking about, it the context of the use case. Because we've had clients that are sending data, there's no sensitive data across the internet. And by default, people think, oh, that needs to be via PKI and digital certificates and they, you know, people automatically assume everything needs to be encrypted, everything needs to be, you know, digitally signed, everything needs to go to a certain degree. So when you're disclosing that you don't do that and the consumer is uninformed, they might view that as a red flag. Trevor: Definitely. Yeah, and that's... Christian: So what's, what do you... what do you recommend about how to disclose that in a way where the consumer isn't turned off because, you know, we don't do digital certificates and something as an example. Trevor: Well, it's a little bit of a tricky balance. At a certain point, disclosing that you have that problem, you're going to have... if you have that problem, you have to disclose it. At a certain point, the problem is going to be too severe. And so, let's say... digital certificates are a great example. If you are not... Christian: It's actually a problem if you don't need to encrypt the data. Trevor: If you don't need to encrypt the data, then it's not something that you need to disclose because it's not a problem. If it is a problem, it's something you need to disclose. And so that's where you'd want to... Christian: Okay, so let me go back because I want to I want to just hone in on this. So on that MDS2 form, you're saying I, if something is not technically a risk because the data is not sensitive, we do not need to encrypt it but we choose to encrypt it with something that's older technology, we do not have to disclose that. Trevor: It's going to... what's the impact? Christian: It's not a great area. Trevor: So if you say that there's no risk if the data is unencrypted, what's the risk if the data is encrypted poorly? Christian: We've had this exact discussion with clients. Trevor: We've had this exact discussion and at a certain point, you know, it's better to... if you've feel that the data does not need to be encrypted, at a certain point it's better to leave it unencrypted. Christian: Then to do it poorly because it opens up a line of questioning. Trevor: It opens up a line of questioning. Why are you using Triple DES? You know, you shouldn't be using that for the past 25 years. So, why do you have it in your system? It opens up these questions. Um, I think the situations where you can use really bad encryption is just with like hash checking. So verifying data integrity, that's a great use case to use weak encryption because weak encryption is usually fast encryption. So you can check integrity very, very quickly. When you're using it under that context, it doesn't matter. You're just getting a hash out of the data. It does not matter that that is poor encryption and someone could try to decrypt it. What you're looking for is just getting that hash, verifying it, and then moving on. So, even though it's weak encryption, you're using it in a secure context where there is no risk introduced. Um, I guess the same would apply if you're poorly encrypting data, but at a certain point if you think, you know, like I said, if you think it's secure unencrypted, why encrypted poorly at all? Christian: Yeah. And that's where from our experience we help edge, get the clients, our clients on the best way to do the labeling. Like you said, if or to even make decisions, like if you don't need to encrypt this and why encrypt it poorly? Exactly. which I remember was a specific scenario we had. Cool. And then what else uh, should a manufacturer know about labeling? Trevor: So, I think as far as the cybersecurity side of things go, there's just... there's a very large amount of information. And the main point that is really important is just understand your audience. And so, even when we're looking at, part of a JSP2 customer security documentation form is an architecture view of the product. What's that global system view? Which is something that we're also preparing for the FDA. And so how deep does it need to go for the FDA versus the customers are going to be different questions. But really make sure that you have the right level of detail for the customers. Make sure that you're taking all the boxes. Um, I think a next point which I sort of alluded to earlier is understand where this device is going to go. The requirements if you're selling direct to consumers for labeling are likely going to be pretty thin. You might not even be asked for your labeling most of the time. You should still provide it no matter what, but... Christian: Like if a patient is buying your device directly, is what you're saying, versus it being deployed in a clinic or a hospital? Trevor: Correct, yes. And even going down to which hospital is it. Uh St. Jude's has different acquisition policies from Mayo Clinic. Mayo Clinic has different acquisition policies from, you know, like any other different hospital. Like a private hospital is going to have its own thing, public hospitals, government hospitals are going to have their own procedures. So understand where this product is going and cater to what they're going to expect. Christian: Yeah, that makes sense. It's all kind of understanding how you're going to commercialize your product. Yeah. As well and who your target market is. Trevor: And that whole thing branches out from the regulatory concerns. This is their private practices and this is based on their internal supplier quality agreements. And so, you know, getting past the regulations is one conversation with the labeling, it's not as strict as often the hospitals are going to be. Christian: Yeah, and that's a good point. It's like the FDA's the compliance aspect from cyber security in my perspective is like the minimum you should do. Uh because the healthcare delivery organization, the HDO may have stronger requirements than the FDA does. So you might as well consider going the extra little bit if your ultimate consumer that's going to purchase your product is asking for more than just compliance from the FDA. Trevor: Yeah, exactly, and it makes sense. The FDA is not taking on the burden of liability for this product. The hospital is taking on that burden of liability. So if they take in an insecure device, if they have an X-ray machine that can be hacked. And then that X-ray machine gets hacked and they get ransomware because of it. That is the hospital at liability, that is the hospital at fault. They have to deal with the ramification of ransomware. And it's a shared responsibility between the manufacturer and the hospital, but it's not a shared responsibility between the manufacturer and the FDA. So the hospitals are going to be extremely, extremely careful on what they're getting in. Of course, the FDA wants to make sure that you're establishing a good baseline for security and FDA requirements for labeling are very good, very strong, but hospitals are often going to be stronger. Christian: Yeah, that makes sense that it's about time hospitals are doing something to prevent all these data breaches. Yeah. Uh cause hospital networks are notoriously insecure. Trevor: Oh, they're, you know. Christian: I used to say unsecure by the way, but I looked it up. You told me once that unsecure was not a word. I think you're right. So that's why we use insecure with cyber security, but it just seems weird to me. Trevor: Yeah. I guess. insecure, unsecure. Christian: Well. Trevor: Either way, whichever one is correct, hospitals are it. Christian: Right. Cool. Uh, well we're coming up on time here. So what are like a couple key takeaways would you say about labeling that like the top three that someone should know? Trevor: I think top three. Number one, know what information you're going to have to provide. There's a lot of it. Get familiar with an MDS2. Get familiar with JSP2 customer security documentation. Um, there's a lot that goes into it and if you don't have the artifacts prepared, it's going to be hard to fill it out and take a very long time. Um, number two is use it as a method to keep yourself accountable. It's very detailed. All these documents are very precise. They cover a lot of security controls. And the reason for that is they want to make sure that everything is secure. If you are going through the labeling and it's a breeze, you don't have any problems, you're not marking no on any controls, that means you probably have a pretty secure device. And number three, know your audience. Know who you're selling to and tailor that documentation towards them. There's going to be a different level of detail for the end user as opposed to an IT admin. There're going to be different requirements for a hospital for direct to consumer. So, there are a couple layers to that one, but yeah, I think those are the three main points for labeling. Christian: I think that's a good top three. And number one, I think it's a challenge. Uh, the probably the biggest challenge from my experience, maybe that's why you made it number one. A lot of the manufacturers simply don't know what type of encryption the developer used or what type of authentication mechanism they chose. So it's hard to fill out the form where they don't have the information. So they have to... like you said, it holds them accountable where they have to actually figure out what they did to fill out the form properly. Trevor: And that even branches pass cybersecurity, that branches into how good is your software documentation? Are your engineers preparing quality documents to feed into your QMS? And if not, then you need to have a stern talking to with your engineers telling them to start writing their documentation. Even though every... Christian: A stern talking to, is that how it works? Trevor: Every engineer hates it more than anything. It is like pulling teeth to get engineers to write documents. I mean, every one in cyber security hates it too. Pen testers want to do the testing, they don't want to write the report even though the client only cares about the report. So, Christian: Well why why is that though? Cuz if I'm an engineer and I design a bridge, I better have freaking documentation. Trevor: You better, but I don't think you want to sit there and write 600 pages describing how the bridge is built. Christian: Well that's how I have to... if I design something, I usually design it on paper before I start coding. I know that's that's just the way I would do things, but I know some people start coding and later try to retroactively come up with the documentation which is maybe part of the challenge or the problem. Trevor: Yeah and I think the whole trend of vibe coding where you just start coding and see where it takes you is not productive. Christian: Vibe coding? Trevor: Yeah that's what they're calling it. Christian: Is like... it's like when you start writing a book and you just like whatever comes to mind, you just start typing it out. Trevor: Exactly. You just start writing code and then you have your AI fix it later, which is uh leading to some documentation deficits for sure and what we've seen. Christian: Well you can have the AI do the documentation for you, I guess. Trevor: There you go. Christian: You know I didn't know Vibe coding was a thing. I do listen to... maybe that's why like when I'm trying to work and be more efficient, I listen to like these coding vibes. Uh like this like ambient coding music and maybe that's why they designed that. So it's like you could just start coding. I I'm not coding but I I do listen to that music. Trevor: There we go. Christian: It's supposed to help. But-But-Binaural beats helped me the most if I'm trying to focus and be smarter. I listen to binaural beats. You ever tried that? Trevor: I don't think so. No. Christian: No. They're supposed to operate at certain frequencies which make your brain work better or make you chill out or make you more energized, etc. Trevor: I'll have to give that a try. I've uh, I always sleep with a noise machine, so I've pavlov'd myself. If I hear white noise, I just fall asleep immediately. Could be the middle of the day. I'm out. And so that's us- my usual relaxation. Throw on white noise, I fall asleep wherever I am. Christian: Yeah, I have a habit of turning the fan on for the white noise when I sleep as well. Probably not good because where if I hear that on the airplane, that humming noise, it's hard to stay awake. So yeah, I get it. Cool. Um Any last minute words of wisdom before we wrap up here? Trevor: Just know your audience. I think that know your information, know your audience. Those are the two big points that you really need to focus on when you're doing your documentation and if you don't know where to start, then look for an expert on this side of things. It's difficult to make sure you have all your boxes ticked and so it can always help to get a little bit of outside consulting and outside help on this side of things. Christian: For sure. All right, awesome. Well, thanks everyone for tuning in. Be sure and check out the binaural beats as well. Might improve your productivity. And uh, reach out to Blue Goat Cyber if you have any questions about cybersecurity labeling or need help with your 510(k) or PMA submission. We hope to see you on our next episode. Take it easy.