Data Protection in Medical Devices: A Deep Dive with Kevin Derr | Ep. 19

Hi, welcome to the Med Device Cyber Podcast. I am your host, Christian Espinosa, along with our co-host, Trevor Slattery. Today, we have a guest, Kevin Derr, from Neuronsphere. Kevin, would you like to tell us a little bit about what you do at Neuronsphere and maybe a little bit about your background in the medtech industry? Yeah, sure. Good morning, Christian and Trevor. I have spent the last 20-some-odd years working with data, and in the last 16 or 17 years, I have been completely focused on the medical device area. I started at Stryker, moved on from there to Auris Surgical Robotics, which got acquired by Johnson & Johnson. Then we started Neuronsphere. When we started Neuronsphere, we decided, or we were trying to give a toolkit to engineers working in the medical device industry, which they could use to develop data products. I spent the previous ten years stringing together 15, 20, 25 different SaaS companies and systems to make a data platform, and all the challenges that come with that. Then one of my architects, a gentleman named Brian Green, came to me one day and said, "Hey, I think I figured out how to make this into a product and not make it so specific to a company." Thus was born Neuronsphere. In 2020, we broke out of J&J and started Neuronsphere. The idea is to give a toolkit to engineers to help them productize their data, develop new AI/ML algorithms for their medical devices, and get them out to those medical devices, staying compliant with both cybersecurity and FDA regulations. That is what Neuronsphere is. It is a toolkit. It straddles the line between SaaS and software. We do not deploy like a typical SaaS solution. That is pretty unique to a Neuronsphere deployment. You maintain ownership of your data throughout the lifecycle of your data platform with Neuronsphere. That does a number of things from a security perspective, right? It makes things like BAAs a little bit easier because it is one vendor out of the chain of trust, right? So that is what Neuronsphere is, in its shortest description: a toolkit for engineering teams to be able to make good data products, whether it is in R or in Python or in C++. The language is not so much of a concern to Neuronsphere because Neuronsphere is about keeping your AWS infrastructure in a state of control, doing things like spinning up resources automatically when you need them. The idea is to enable engineers to be compliant without having to slow down. A Neuronsphere install takes less than two weeks, and you can be up and running and exploring your data. Awesome. I think it is interesting that a lot of people who have kind of broken out and started their own organization in medtech came from one of these larger companies like Medtronic or Stryker, like you mentioned, or J&J. Trevor, from your perspective, we look at protecting the data with something like Neuronsphere. I am not sure how familiar you are with it, Trevor. What do you see as some of the cybersecurity challenges with data and kind of managing the data throughout its lifecycle? Well, the big one, which Kevin already kind of touched upon, is if you do not maintain ownership of that data, you do not have control of where it is. If you send that into like a hosting provider or something, they might not have the same sort of controls that you would want to implement on your data protection. So, having that control over your own data is, I think, a really important point to touch on. It is really good that you guys have a solution that makes sure that you know you are not just giving the data away to someone, they handle it a different way. That is probably one of the bigger concerns that we see from our clients trying to get through the whole cybersecurity process. They are a little bit afraid of, "Oh, well, who is getting this information?" Cybersecurity is a sensitive topic. We are giving you guys a lot of sensitive information to build out these packets. Where is it going? What is the FDA doing with it? What is that static testing tool you are doing? How is that taking our source code? So data management, data protection, and IP protection are at the forefront of everyone's mind, especially when they are coming up with a new product or working for a startup. So it is good to have some controls around that to protect it. Yeah, it is interesting. If I could jump in there with a little bit of a story. All of my career, whether it was Stryker, J&J, or Auris, one of the things that I struggled with as a purchaser, right, as a director of whatever I was directing at the point, even middleware back in the day when I was directing the middleware team, you always have this conversation as a medical device company with vendors. It starts out great. They have a solution, we have a problem, you know, the solution gets fixed with their, or the problem gets fixed with their solution. Then it comes time to do your 510(k) filing, and quality gets involved with the conversation. You start doing things like actually going through the rigorous level of testing that you have to do for V&V, and you figure out that the infrastructure that you are running at this said vendor is not compliant with, you know, 13485, whatever the ISO rule is, 27001. Then you go to your vendor and you find out, "Oh, if you want those controls, you have to go to the medical grade version of this service." Then you wind up having to pay a premium. That was a pattern that repeated for me everywhere I went. One of the things that Brian and I tried to do with Neuronsphere was solve that. Our solution for that was to just give you ownership. As a customer of Neuronsphere, you own it. You run it in your infrastructure. So if you are 13485 compliant or you are 27001 compliant, and you keep your environment that compliant, you are good, right? And you have to do that as a manufacturer anyway. So so it really does simplify that portion of running a data ecosystem, running a data platform. So you are saying that it solves the challenge, like if I have HIPAA data and I put it in AWS, there is the normal AWS which costs a certain amount, but there is also the HIPAA compliant AWS which costs more, right? So you are saying it solves that challenge. Yeah. I just do not like your analogy to AWS, because the infrastructure provider is AWS. So they are that data center. It would be more akin to running some kind of distributed airflow environment, and your vendor who is running your airflow environment is not complying. Well, here you are. You buy the software. When you buy a license from Neuronsphere, you are not just licensing a space in HMD Labs, our company's cloud. No, you are buying an install of Neuronsphere that you are going to run in your AWS environment. So, there is no BAA that needs to be signed with Neuronsphere, right? Because your BAA is with AWS because they are housing your data. In my past life, I would have a BAA with every vendor that was in that chain, right? And so that is kind of what I am talking about more. It is not so much solving something with AWS. AWS has a great solution for being HIPAA compliant. Their BAA program is very easy to understand. It is very easy to implement. But it removes one piece of that complexity: being us as the vendor providing the solution on top of AWS, right? So, you know, I would not want to set a false expectation that you are not signing a BAA with AWS. You still have to do that, right? You do have to do that. But with Neuronsphere, it is in your ecosystem. It is not in the HMD or the Neuronsphere ecosystem. So, it is one step removed, and it is one piece simpler in your trust chain. So all the cybersecurity controls are up to the organization to implement versus, I guess, have them transferred over. Yeah. So, we like to say Neuronsphere is architected to be compliant. This means that we created Neuronsphere with all of ISO 27001, 13485, and SOC 2 Type 2. All of those types of controls are architected into the Neuronsphere ecosystem. That way, we try to make it as easy as possible for our customers to be compliant. But with taking ownership of your data with Neuronsphere and controlling your own fate with your data, it also means that you need to make sure that your compliance is upheld. So we can give you the tools, but our customers could still break the rules. So, if you were, right, so when it is, I think of it similarly to S3 buckets in AWS, right? The most common vulnerability in S3 is a misconfigured S3 bucket. Yeah, I know that back in the day when I worked for the DoD, the FBI and CIA had misconfigured S3 buckets where you could pull out tons of information. I am not an Amazon S3 bucket expert. Trevor probably knows more about that than I do, but is that a common thing we see, Trevor, with our clients, like misconfigured S3 buckets? Surprisingly, we do not see it a ton on the same like software as a medical device side of things. When I was doing a lot of bug bounty hunting, on the other hand, yeah, I would just look for any .gov domain, try to find their S3 buckets, and like you said, they are everywhere. I mean, it also there was some big news like eight years ago with some big data breaches that were misconfigured S3 buckets. A lot of the bigger players, the Strykers, the J&Js, invested a lot of money in systems to make sure that their teams spread across the world were implementing the controls properly. So I think in the last ten years it has probably come down significantly, but it is still the easiest hole to create in your environment is missing one setting or things like that. Honestly, I have leaned on other vendors very heavily over the last 6 to 8 years to make sure that teams do not miss things and things do not fall through the cracks. So, there are a bunch of players out there that will look at your AWS configuration and check it for you. I think part of the issue is you only need to make one mistake for someone to get in. You have to fix, you know, 200 different problems. If you fix 199 problems, you would think, "Oh, you know, that's almost perfect." But it is not perfect. If there is one problem, one little chink in the armor, someone is going to find it. There are all these like web scrapers and tools just combing over the internet five million times a day trying to look for those little tiny holes, those little misconfigurations in an S3 bucket. So, it is kind of the, you know, the good guys need to be lucky every time. And the bad guys need to be lucky once. Yeah, exactly. I was on a podcast yesterday, and we were talking about standing up an AWS instance. I have stood them up before, and within like 30 seconds, it has been scanned like a thousand times by somebody trying to break into it. It just came online, right? So I was trying to explain what the landscape is really like. There are all these attacks going on, but we cannot see them. But it would be like a hundred people running through the parking lot and checking every door to see if there is an unlocked car in the parking lot and trying to break in. It is pretty crazy the amount of attacks, non-direct attacks, that are just propagating incessantly out there. And I mean, it has been getting worse, and I think it is only going to continue, right? So the tools on both sides of the attacking equation, the defenders and the attackers, the tools are just always getting better, and there is always more out there. So, but we take an approach with Neuronsphere that the standards exist for good reasons. There has been a lot of brainpower and a lot of effort by a lot of people to get a lot of those standards in place. And so making sure that your ISO 27001, I know I keep referencing that, but it is a big one, making sure that those controls are in place and working is really all you can do. It really does give you a good sense of protection. The biggest thing is if or when there is a breach, you have hopefully all the reporting and all the tools available to both stop the breach and recover from the breach, right? And that is all you can do in the security space. It is, I kind of feel like these standards, like ISO 27001 or 27002, which I think defines the controls, I think they are like the minimum. I think people think this is all I should do: find some random standard out there and follow it. But compliance is like the bare minimum from my experience. I mean, Target was PCI DSS compliant when they had a hack. All these organizations were compliant with the appropriate body, like SOC 2, or whatever, they still were compromised. So I think it is definitely a good idea to follow a standard or a framework, but you have to go beyond that and think about your environment and how that applies to the environment, and then what the gap is as well. Wasn't that Target attack also like a fringe system? Wasn't it an HVAC system that was compromised that let them onto the network? They did come in through the HVAC system, yeah. An HVAC vendor, yep. But I think their credit card system was also vulnerable. It was not on an isolated network as my understanding. Trevor may know more about that one. I do not know. Yeah. I think the whole issue is Internet of Things are always, they are kind of on the back burner in anyone's mind for security. But those are super, super easy ways in. When I was doing a lot of internal penetration testing, nine out of ten times, my first foothold in the network was through a misconfigured printer. They left a default credential or something like that, and then you get domain credentials out of the printer, and then boom, it is game over. Their entire network is toast. And so all of these internet-connected things, HVAC systems, credit card readers, thermostats, refrigerators, TVs, how do you know what that vendor is doing for cybersecurity? If you get some cheap TV off of Amazon, great, you have a $90 flat screen TV, but it connects to the internet, and boom, that is the bad guys' foothold in. So, I think there needs to be more awareness around those fringe systems, around these weird components that are not necessarily just a computer or a server or something people always think of for traditional cybersecurity. You still need to apply it to these Internet of Things. Yeah, the other interesting aspect that we deal with in medical devices that we do not see elsewhere, well, I guess you might see it in aerospace or other big controlled systems, but it is the idea that it is not just about your data security. It is about the impact of that data on the medical device and whether or not there is an impact on the safety and effectiveness of it. So we always have to remember that the companies that are building the medical devices are weighing this equation of heightened security, adequate security versus not impacting or enhancing patient safety and effectiveness. And sometimes in the data space, those things are very separate, right? Because your data has been sucked off to some other system, and it is up in the cloud somewhere, or it is on this service team server for being able to service the devices in the field. But typically, that data is not overly sensitive. It is, you know, telemetry, it is motors, heat sensors, and things like that. But then you have mosaic data and the idea of, well, you can figure out the date and time of a procedure, and you can figure out where the procedure was done, and God forbid there is a doctor's name in that payload, and suddenly you have tripped the HIPAA, the HIPAA threshold or the GDPR threshold, right? So there is that side of the security trust chain, which is just ensuring that the data is kept safe and secure, and then there is that whole other aspect, which is making sure that whatever you are doing with that data is not impacting the safety and effectiveness because sometimes the data trips a logic check and the device behaves differently based on that data, right? That is an attack vector that I think the FDA is most concerned about, right? The FDA is more concerned about whether or not the attack vectors are going to impact patients, have an impact on patient safety and effectiveness. Right. It is less about the HIPAA side of things. The HIPAA side of things is more just regulation. Yeah, you have been in the industry for quite some time. I would like to get your perspective, Kevin, on, I know the FDA came out and really raised the bar with cybersecurity in September of 2023. Do you feel like the industry is actually progressing in cybersecurity and in data protection, the MedTech industry is actually progressing? Oh yeah, I have seen it. I have seen it. I mean, when I started at Stryker like 15, 16 years ago, compared to what I saw Stryker doing when I left Stryker 6 years ago, seven, eight years ago, in the nine years that I was at Stryker, I saw them just invest a huge amount of time, people, and money into this space. Now that being said, prior to joining the medical device industry, I was in the travel industry. I worked for the Hertz Corporation for almost a decade, where I helped them really digitize their entire business. So, when I started at Hertz, our goal was to do a million dollars of sales a month on the website. When I left nine and a half years later, we were doing millions of dollars an hour, right? So, it went from a fragment of the business to, when I left the business, it was like 40% of the sales were coming through the website, right? I learned more about being compliant with regulations than I ever thought I would have to deal with in a company like a car rental company. I thought, "Who cares about a car rental company?" And then you remember that presidents are not always presidents, right? And before they are presidents, before they are really famous, they rent cars. And car rentals have things like your social security number, especially in the past, maybe not so much today, credit card information, your home address, your driver's license number. If you travel internationally, it has your passport information. They have really sensitive information about you, and they invest huge amounts of money in security and being compliant. The first secure data center I was ever in was a travel industry data center back in like 1999, 2000, something like that. So, coming, I learned HIPAA at Hertz, right? I learned what the HIPAA rule set was, and I made the Hertz call center HIPAA compliant back in 2003 when the stuff was just getting rolled out. So yeah, I definitely feel like the industry is making big strides. I just think that they are slow. I think that is not a fault of anyone in the industry. I think that is a natural thing that happens when your primary concern is the patient's safety. Your testing, your rigor is all about ensuring that we are not going to kill the patient with our device, right? At least that is what you would like to think. I know that is the case at the big companies that I have been at. I would like to think that every medical device company in the world has that mindset at its core. So, are they improving in the security space? Absolutely. Is it taking longer than other industries? Absolutely. And I think that this is because of this history that we have of dealing with long submission timelines, right? 510(k) filings have always been six-plus month endeavors, right? It is great to see some pointed examples over the last five years of people getting things through in 90 or 120 days, right? But there is a culture in the industry of slow, steady progress and not killing our patients. Right, right. I am curious about both your takes on something as you were talking, Kevin. I agree. I think we are making slow progress, but I think the fundamental issue, if we roll back the curtain, is most medical device manufacturers will outsource their product development to a team of software developers or they have a team in-house. From my experience, and I am just curious on both of your takes, software developers do not know how to develop secure code, and they were never taught to develop secure code. So, until that changes, we are not going to get out of the cycle in my mind. So, yeah, I generally agree with a lot of what you just said. I do think that most people who learned how to write code in school and in their first jobs were taught the right ways to write code, which are structured with good comments, nice and secure. Then I think what happens is people get into their jobs, and their jobs have deadlines, and the deadlines become the important thing, and making sure that you do not miss that deadline is the important thing. And all of the other stuff that you learned in school about structuring your code and keeping it secure and making it well documented and all of those things, they become lower priority. And I think that for a long time we have operated kind of in that guise, and that has allowed, that is always going to allow for a bad actor to find a place to exploit you, right? So I do, my experience has been that while yes, I agree with the sentiment that these engineers just do not know how to write secure code, I, the schism that I have, is that it is less about them not knowing how to write good secure code, and it is just more that they have not exercised that muscle, you know, for some in a long time. Because I do find that when you like get into the nitty-gritty and start talking to them at a method level about what they did in their code and why they chose to do it this way, they will be like, "Oh yeah, well, I could have done it that way, and it would have been more secure." They do know, it is just not there. It is not their focal point. So what I have always done with my teams is I always try to make my team's focal point the secure side of the coding practice. And thus, I try to inject it into my teams as an almost as a motivation to do well, right? And then, of course, with Neuronsphere, what we did was we made it a structured framework, right? So with Neuronsphere, if you code things the Neuronsphere way, it kind of like if you adopt our way of thinking in general, by default, you will be more secure because we have architected into the system that all of the methods and everything that you are doing is structured from a secure and compliant perspective, right? But yeah, I do like, it is, I cannot tell you how many times I have sat down with an engineer and been like, "Well, why did you do it that way? Didn't you think of this vulnerability that you just opened up?" And the answer invariably is it did not dawn on me, right? Or there is one other aspect which maybe you were trying to touch on, which is the other aspect that they often fall into is there is a, I would say, I will not say universal, that is too generalized, but there is a pretty consistent opinion from engineers that I have worked with in the medical device industry that hospitals are secure, and we do not have to worry about it because it is going to be at a hospital, right? I have definitely run into that attitude with engineers, especially if they are engineers coming from like fintech, right? So, if you bring in a group to manage a system for you that is from fintech or from some other, or God forbid, from advertising, a completely non-regulated industry. Well, maybe that is an overstatement, but you get my point. Those engineers often, they are operating from a point of ignorance, right? They are coming at it from with a false expectation. That is really what it is. They have a false expectation that hospitals are secure or that doctors are secure, by in general, right? They have to be HIPAA compliant. They are dealing with your medical device data. Of course, they are going to be secure, right? But at the end of the day, the doctors, they never want to put their password into any system, right? Anybody who has worked on a medical device that is in an operatory knows that one of the biggest complaints about that medical device in the operatory is that the doctor has to sign on and tell the system who they are when they all walk into the room, right? It interrupts their workflow. And at the end of the day, it is about the patient's care to the doctor. It is not about the effectiveness or the use of that device, right? Yeah, I want to touch on something you mentioned, and then I will throw it over to Trevor. I think you touched on a couple of things, Kevin. One is some software developers simply do not know how to do secure code. But the other thing you mentioned, and I agree, is these deadlines. Because I used to work and manage a team of software developers when I was a director a long time ago, and we were developing a product, and we had like a six-month timeframe. Then the CEO came to me and said, "We sold a bunch of the products. Whatever we have done, just package up and ship it out a month from now." And I am like, "Well, we haven't done our security testing. We haven't completed all these things." He is like, "I do not care, just get it out the door." So that definitely comes into play. And then something else you mentioned, you know, it is ironic because Trevor and I call hospital networks hostile networks because we just assume they are compromised. So I am curious what your take is on what Kevin said, Trevor. I think the point about doctors having their workflow interrupted by logins is spot on, and the mitigation that doctors usually have, and I mean, anytime you go to a doctor's office or if you are in a hospital for whatever reason, sticky notes with the password stuck on the device every single time. I thought it was funny. Last time I was in and out of a hospital, I had a broken leg, so I was going back and forth for rehab all the time. And they would, you know, take all sorts of readings and measurements and all that whatnot whenever I would go in. And I would see like the X-ray machine. It had a login page, and there was the password stuck on it. The IP of the X-ray machine was stuck on it on a sticky note. It was on every single device that had some sort of computer built in. And so I think that, you know, in general, just places where a lot of people are interacting with something are going to be insecure. Human interaction is the weak link in security nine out of ten times. You look at any reports on how did a breach start, for like the MGM breach, you know, that is the famous one that everyone knows about, social engineering. It is always that human connection. And then like 3% of the time, it is a vulnerability in an application. It is very, very slow. It is like an edge device, like a VPN portal or something, or just breach credentials, social engineering. So yeah, in general, networks are not secure. I think even secure networks are not secure, and secure development is a rare skill, and it is not something we see all the time. I think I do not think we have ever had a device without any vulnerabilities. It just does not happen. There are always problems. Developers are always introducing some small mistakes, but small mistakes can stack up and build to a big thing. The FDA talks about vulnerability chaining, where you see if the combination is greater than the sum of its parts. And more often than not, it is. So there, and it goes back to the point that I was making earlier. The good guys need to get lucky every time. You need to secure every line of code, which is impossible. And the bad guys only need to find one problem to cause a bunch of damage to a device. So, it is a delicate balance, and the fact that having near-perfect security, I am never going to say perfect security, but near-perfect security is going to compromise functionality. If you have a device running on an embedded operating system, and it is performing some time-sensitive functionality, if you are putting a bunch of agents like CrowdStrike or whatever to make sure that it is safe, make sure there are no breaches, you are going to shut down that functionality. You are going to reduce its workflow. You are going to add time to that functionality. It has to be a balance. And I think that a lot of developers, a lot of manufacturers go too far and miss that balance, and they instead say, "Make it work, make it fast," and they do not think about security. One requirement for the FDA is you need to have security requirement validation verification. The amount of times that I have been working with a client, I say, "Okay, we need to prepare, you know, your security requirement V&V." They say, "Security requirements?" I go, "Oh, man. Okay. Well, let us start there." So you just, you just hit on something that I think ties right into your question before, Christian. And that is that the new FDA guidance that came out a little over a year ago, right, end of 2023. God, it is almost a year and a half at this point. That security, that new guidance, which for a person like me, I was like, "I thought that that finally was done," right? Like it was finally done. I thought that that could have been ratified three years, four years ago, right? But it is finally done. And one of the biggest things that I am seeing from that is right towards what you were just talking about, Trevor, it is moving the security conversation up in the NPDP lifecycle, right? So new product development process, NPDP, what all the medical device companies follow. There are all kinds of QM regulations. Everybody knows what NPDP is if you are engineering in the medical device space. You moved, or they moved, the FDA moved the conversation about security up in the NPDP chain. Thus, we are having conversations about how to secure, what are the security requirements, how do the security requirements impact the safety and effectiveness. We are having that conversation a lot sooner in NPDP because for the last ten years, one of my biggest frustrations has been security is the thing that we will do right before filing, right? I think it is still that. I think it is still that way. It is, but it is getting better. I am starting to see the signs, right? This guidance injected things like data flow diagrams have to be done with your initial submissions, right? All of these ideas, bringing the concept of managing your data and doing that securely earlier in the NPDP process, is going to have a great effect for us. But you are right, Christian, it is going to take time, right? To my point from before, the medical device industry is a big ship that turns slowly. It does not turn quickly. But I do see the signs of it changing, and I do see the startups that I am talking to trying to sell Neuronsphere into. I am seeing them talk about security and data so much earlier in their lifecycle than they did even three years ago, four years ago, when I started Neuronsphere, right? Our biggest struggles when we first started Neuronsphere was we would approach a small to medium-sized startup, right? So not an angel-invested startup, but like, you know, kind of getting their thing working, maybe out of benchside testing and into first in-human trials, like that size company. And invariably, what we were getting the answer on was, "Oh no, security and data is really important to us, but right now we are very much focused on the product. We are very much focused on our procedure," right? With the new FDA guidance, they have to ask those questions earlier because to get to that first-in-human study, they now need to have their data flow diagrams. They need to understand a bit about the security posture of their company and their product, right? And so I do, I like, I know I am talking circularly because I think it is all a big pattern, right? It is all a big circle that we would all like to move faster, but yeah. Awesome. Well, I know we are coming up here on time. So, Kevin, we appreciate you being a guest on our podcast. Yeah, I will throw it over to Trevor for any last words of wisdom for the listeners. Yeah, I think just, you know, keeping that in mind, like Kevin was saying, shifting it a little bit earlier in the process and just understanding the regulations before you go into it. It is exciting to build a new product, but if you mess up, it is going to be really expensive. So know what you have to do the first time, and then, you know, you are not burning through $2 million of extra VC funding that you could have used somewhere else. So know what you need to do, do it at the right time, at the right phase. And I think security should be done as close to the beginning as you can think of. Awesome. How about you, Kevin? Any parting words? I think that I hope that people hear this conversation and hear the positive side of it, right? I hope that this does not come across as too doom and gloomy. But I really do see the positive trend that is happening in the industry. I think that the FDA guidance is the centerpiece, the inflection point, if you will, of the industry really starting to change. I think it is going to take another two or three years before we really feel it throughout the engineering teams, right? But now I will give you my plug: download Neuronsphere's open-source components and start looking at the Neuronsphere way of managing your data and your data platform. And, you know, I would never make the claim that do it with Neuronsphere and you will be secure, right? Like you were saying before, Trevor, I will never say that it is completely secure. But know that using tools like Neuronsphere, you can build systems that are compliant. Try to make sure that the systems that you are implementing are architected from a compliance posture. It is a really important thing. A lot of people think that those are like fluff words, but they are really not. If the system is architected for compliance from the beginning, it will save you a tremendous amount of money to making it compliant for your submission time, right? So, yeah, that is my final thought. Perfect. Well, thanks so much everyone for tuning in, and we will see you next time.