Cybersecurity Labeling and MedTech Transparency | Ep. 25

Hi, welcome back to another episode of the Med Device Cyber Podcast. Today we're talking about a complex yet simple concept: labeling. Specifically, we're discussing cybersecurity labeling. We're going to hit on some of the main points about what labeling is, common misconceptions, and how a manufacturer should approach labeling. We'll also touch upon the MDS2, which is a common form people ask questions about. So, that's the objective of today's podcast. I'm your host, Christian Espinosa, coming to you from Florida today. I got stuck here for a couple of days, 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've got those weird wooden background things. Yeah, I'm in Arizona for today, off to California tomorrow. All right, awesome, cool. So, as far as a definition of labeling goes, what would you, or how would you describe labeling, Trevor? So, labeling is the information that a manufacturer or a MedTech innovator needs to portray to users and patients. This is essentially, under the cybersecurity 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. So, this is in the act of transparency because the FDA is pretty big on transparency. So, we're trying to make the risk transparent to somebody purchasing one of these medical devices. Is that a fair statement? Okay. We're looking at, you know, you're going to want to 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, you remember when the Samsung phones were exploding for a while? Yes. You'd want to know if you were buying, I think it was just the iPhone versions though, wasn't it or something? No, it was the Samsung Note something. The batteries would puff up and explode, and so you'd want to know if you were buying a phone with one of those batteries. 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. This is just an effort to try to portray that risk. 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 two-fold 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. 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 cybersecurity lens with either device. Exactly. Good cybersecurity 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 cybersecurity 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. Yeah, and how does the MDS2 fit into that labeling? 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 document basically that a manufacturer has to fill out to disclose certain things, 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. It ties closely into things like NIST certification, ISO 27001 certification. And 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. And so the cybersecurity labeling side of things shouldn't be a very complicated process as long as you have your quality system and your just general compliance setup beforehand. MDS2s aren't 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 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 risk disclosure. Here's a list of any of the problems that are possible in the product. And what are some of the common misconceptions of labeling? Because I know with clients we talk about tamper-proof seals. I guess that's technically a control, but it's also a label. And a lot of clients, they ask specifically like, what do we do about cybersecurity labeling? They just have no, I guess, no concept of what it really means. So, what are some of the common misconceptions, or would you say common questions people ask about labeling? 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 of 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. 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. It's not, it's the opposite of, what do they say, security through obscurity, right? Yeah. Exactly, it's security through transparency. Exactly. 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 hybridize 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. So, we have the MDS2 and the JSP2, which are two ways of providing that transparency and labeling. We also have a labeling document, 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. Yep. In this context, the tamper evidence seals would be more of a control. 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. When we have tamper-evident labels or tamper-evidence 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 at these seals every time they're going to use the product. 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 no longer use it. That would be the labeling portion that ties to the control. It's the labeling for the labeling. Yes. Cool. And I, I wasn't thinking about it until you talked about it, but I think I'm having, 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 on the bottom it says, this cup is made with 10% post-consumer recycled fiber. There's actually a lot of labeling on just a paper coffee cup right here. It's interesting. 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. But that's just another example. Or the can is gluten-free, I'm assuming it is. That's a good thing. There's no wheat. Yeah. 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. 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. 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, yeah, pregnant women, children, or individuals sensitive to caffeine should not consume this product. So that's informing you of the risk of consuming caffeine, which is a little bit of a different level of risk as opposed to using a potentially dangerous medical device, but the principle remains the same. We have to inform users of any potential problems that could come up with using this product. I think the challenge with, like the ingredients of that Yerba Mate or whatever you're drinking there, those are like physical things, and the warning is like, you know, pretty like if you're over-stimulated by caffeine, maybe you should avoid it. I mean, those are pretty obvious. I think the challenge with cybersecurity is like, what do we actually need to disclose? Like, does someone need to know this device uses AES 256 encryption? Because if they're trying to make a decision and one uses Triple DES or something super old, they can say, okay, I don't want to use that one. Is this, is that the purpose really, and then how much detail do we really need to go into? It's kind of unlimited. 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 of 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 designing an insecure product. 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? Yeah. And they're not going to 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 going 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 kinds 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 in 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 going to be operating. And so, it can be a little bit tricky to strike the balance, but like a home-use product will just be different from a hospital product. And what are some of the biggest challenges that our clients have faced with labeling? 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 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 asks. If you're trying to get acquired into a 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. Yeah. 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 not being transparent because if we have one subsystem that's AES 256, but the rest are Triple DES, you should be disclosing the Triple DES aspect of it, 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 because 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 cyclic 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. And that's a good point about what you're talking about, 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. Definitely. Yeah. And that's... So what... 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? Well, 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, is it actually a problem? If you don't need to encrypt the data, 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 talk to... Okay. Oh, let me go back because I want, 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. What's the impact? A gray area. So if you say that there's no risk if the data is unencrypted, what's the risk if the data is encrypted poorly? We've had this exact discussion with clients. We've had this exact discussion. And at a certain point, you know, it's better to, if you feel that the data does not need to be encrypted, at a certain point, it's better to leave it unencrypted than to do it poorly because it opens up a line of questioning. 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. 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. 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 encrypt it poorly at all? Yeah. And that's where from our experience we help educate 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, then why encrypt it poorly? Exactly. Which I remember was a specific scenario we had. Cool. And then what else should a manufacturer know about labeling? So I think as far as the cybersecurity side of things go, there's just 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 ticking all the boxes. 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 if a patient is buying your device directly is what you're saying versus it being deployed in a clinic or a hospital? Correct. Yes. And even going down to which hospital is it? 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. Yeah, that makes sense. That's all kind of understanding how you're going to commercialize your product as well and who your target market is. 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. Yeah, that's a good point. It's like the FDA's the compliance aspect from cybersecurity, in my perspective, is like the minimum you should do, 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. 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 ramifications 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. Yeah, that makes sense. It's about time hospitals are doing something to prevent all these data breaches. Yeah, because hospital networks are notoriously insecure. Oh, they're, you know, I don't know, 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 cybersecurity, but it just seems weird to me. Yeah, I guess insecure, unsecure. Well, either way, whichever one is correct, hospitals are it, right? Cool. 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? 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. 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. 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 an end-user as opposed to an IT admin. There are going to be different requirements for a hospital for direct to consumer. So there are a couple of layers to that one. But yeah, I think those are the three main points for labeling. I think that's a good top three. And number one, I think is a challenge. 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 when 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. And that even branches past cybersecurity. That branches into how good is your software documentation? Are your engineers preparing quality documents to feed into your QM? And if not, then you need to have a stern talking to with your engineers, telling them to start writing their documentation. Even though, talking to, is that how it works? Every engineer hates it more than anything. It is like pulling teeth to get engineers to write documents. I mean, everyone in cybersecurity 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, yeah. Why? Why is that though? Because if I'm an engineer, I design a bridge, I better have freaking documentation. You better, but I don't think you want to sit there and write 600 pages describing how the bridge is built. Well, that's how I have to if I'm going to design something, I usually design it on paper before I start coding. I know 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. Yeah. And I think the whole trend of vibe coding where you just start coding and see where it takes you, is vibe coding? Yeah, that's what they're calling it. It's like, it's like when you start writing a book and you just, like, whatever comes to mind, you just start typing it out. Exactly. You just start writing code and then you have your AI fix it later, which is leading to some documentation deficits for sure and what we've seen. Well, you can have the AI do the documentation for you, I guess. There you go. There you go. 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, like this ambient coding music and maybe that's why they designed that. So it's like you could just start coding. I'm not coding, but I do listen to music. There you go. It's supposed to help. Binaural beats help me the most. If I'm trying to focus and be smarter, I listen to binaural beats. You ever tried that? I don't think so. No. 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. I'll have to give that a try. I've always sleep with a noise machine. So, I've Pavlov'd myself. If I hear white noise, I just fall asleep immediately. Could be middle of the day, I'm out. And so, that's usually my relaxation. Throw on white noise, I fall asleep wherever I am. Yeah, I have a habit of turning the fan on for the white noise when I sleep as well. Probably not good because if I hear that on the airplane, that humming noise, it's hard to stay awake. So, yeah, I get it. Cool. Any last-minute words of wisdom before we wrap up here? 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 of 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 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 reach out to Blue Go Cyber if you have any questions about cybersecurity labeling or need help with your 510k or PMA submission. We hope to see you on our next episode. Take it easy.