Biohacking Village - How Independent Security Researchers work with Medical Device Manufacturers
Erickson, Kyle
Schmitt, Vee
Tshuva, Natali
Morgan, Peter
Hear some of the top Security Researchers share their trials and tribulations with Medical Device Manufacturers. Topics will include: How they have succeeded in their interactions with larger organizations and what they are working on next. The success stories and failures of working with Medical Device Manufacturers. How working with diverse backgrounds and being open to researchers has helped one company mature its cybersecurity program. What is a proactive security approach and how can it help anticipate failure? How can we tackle the legacy device problem? Explore new ways the community can bring innovative solutions to Medical Device Security.
 All right, well, welcome folks. It's my pleasure and honor to introduce some great friends of mine. They are all hackers and we have our moderator today. I'll do a brief introduction for him. But first and foremost, welcome to the biohacking panel. How independent security researchers vis-a-vis hackers work with MDMs or that notorious medical device manufacturer. This is the bad, the ugly and the great. Also affectionately known as bug. My name is the red dragon 1949. You know me as the volunteer coordinator. But more importantly, I'd like to introduce you to the panelists first and foremost ladies first. We have Veronica or B Schmidt yesterday was her birthday. So happy birthday V. She is a former federal law enforcement in South Africa. She has done forensic investigations. She is a cardiac implant patient three times and she's doing some great forensic work for one of the MDMs that will be showcased here at the biohacking village Medtronic. Second, we have Miss Natalie Schuva. She is the CEO for sternum out of Tel Aviv Israel. She comes to us from the unit 8200 of the Israeli Defense Force. She can do things remotely with a mobile phone and the applications that are fascinating and yet scary at the same time. So welcome Natalie. And then last but not least, we have Mr. Peter Morgan out of San Diego, California. Mr. Morgan is quite how shall we say effective at basically taking a medical device down to its very fundamental binary level and doing things with it that would surprise you not only from a software and a firmware level, but certainly from a vulnerability exposure. He has notable common vulnerabilities and exposures to his name associated with some metronic devices. So welcome Peter. And then last but not least our moderator, Mr. Kyle Erickson. He's the director for product security engineering with the cardiac rhythm heart failure business division at Medtronic out of Minneapolis, Minnesota. He has extensive breach and incident response experience with one of the largest healthcare organizations here in the Minnesota area as well as globally. So he has faced some of these individuals on the panel that he's going to be moderating. So welcome Mr. Erickson. I will turn it over to you. Thank you Red Dragon for those great introductions. I have the luxury to be here on the panel with Pete, Natalie and Vee. And I'm really excited to dig into their story and learn how they've been working with medical device manufacturers, what medical device manufacturers can do better and what we're working on to improve in the industry. So I want to start out with an origin story. And I'm going to start with Natalie. Natalie, what makes you a hacker and how did you really get involved in the security movement around medical devices? Yeah. Well, I actually don't refer to myself as a hacker, but I can tell you basically my story. I grew up with four big brothers and started my undergraduate degree at the age of 14, computer science. It wasn't just weird because I was 14. It was also weird because nobody in my family ever went to college or something like that. So I was like the black sheep in the family. And once I graduated, then I just started my period in the Israeli unit A200, one of the elite technological units there. And this is where I got exposed to cybersecurity, low level development and research and exploitation in general. We did some significant things in the unit, handled the most advanced techniques and technology. And after the period of time there, I wanted to keep using cybersecurity to create impact. So during my time in Cerebrite, I did a lot of vulnerability research and exploitation, mainly on Linux, Kerala and Android platforms. And I didn't consider it as being a hacker, but mainly to provide evidence to stop pedophiles and human trafficking and stuff like that because using the vulnerabilities and exploitation we were able to extract forensics and basically evidence from the mobile devices, including encrypted ones. So for me, it was the passion and the impact that such tools can create. And the medical device was actually not a coincidence. I was always dreaming and thinking about becoming a doctor. So when I finished my master's in computer science, I figured that this is like my last opportunity to go into the medical industry. I thought about starting medical school, but with the knowledge I had in cybersecurity, I met with a few friends and entrepreneurs and one of them is my partner, Boaz, and we started thinking about medical devices and cybersecurity. And when I saw that remote care and remote monitoring could have such a tremendous effect on our lives and they were not properly secure, this was something that attracted me tremendously because I figured that creating the right security to these devices could really improve patient's lives and improve quality of care and treatment. And I saw how the knowledge that we have from the cybersecurity industry could leverage this kind of technology. And this is what actually attracted me to Co-Front's tunnel. That's excellent. Obviously, you may not call yourself a hacker, but you have the tactics, techniques, and capabilities. So, V, I'd like to go to you. And obviously, we know you have a unique story. You're not only a hacker, a researcher, a goon, but you have a implanted medical device and refer to yourself as a cyborg. So why don't you just give us a little bit more about your background and how you've been getting more and more involved with medical device manufacturers in the industry? Yeah, so I wasn't a very good hacker when I was a child and I basically got court changing records at school because I felt everyone should have a good year. Unfortunately, that led me down a path that my parents weren't very proud of. But going back at the age of 18, I joined the Special Investigation Unit, which is a law enforcement agency that deals with cross-border human trafficking, child pornography. Some really nasty things. We actually made use of celibate, so I'm very familiar with what Nati's referring to. And let me tell you, if you want to get a physical image of those things that they develop, are key. But at 19, I also had about approximately two weeks left to live when I got my device implanted. And I know the quality of life that it gave me. But since then, I was obsessed with what my device does. For the pure fact that I believed in the same trust but verify, but I could never verify what was keeping me alive. And that was the biggest, greatest frustration. I reached out to you guys about three years ago and I was met with the ugly part of Metronics, sadly. I got met with the legal team. And I felt that the conversation wasn't going very well. I remember these words and Toro that used to work with you, knows this well. I said to them, well, if you want to bring your lawyers to the table, I can do the same and then we can have a conversation. But that's where it ended. And Inwood's Biohack Village three years ago, Nina being forever the master planner put me on the path for gold. But then I came to severe loggerheads last year because he could not confirm to me that he was from Metronics. And though I knew he was and we went at it and we had our conversation and fast forward a couple of months. I'm now finding my feet within Metronics and doing research into early detection because I didn't want to focus on the problem. I want to find the problem and then solve it. So it's not just about whether the device can be hacked. We all know everything can be hacked, but it's actually about having some tangible evidence to deal with to early detection to mitigate it. For me, literally close to my heart is the embedded implanted devices that are often misunderstood, forgotten about. And these are the things that are connected to people, flesh and bones. And I just decided to take this on and put my story out there and say, you know, these things are cool, but they also scary. But that doesn't mean we need to go in the internet. It just means we need to do more to make it safer. Absolutely. And we're glad that we can make some inroads there. I know it's been a journey to say the least. Pete, you've had a similar journey. I'd love to just kind of hear your origin story and what got you interested in medical device security. And not only do you have vulnerability discovery on your side, you've also looked at solutions and improving the problem. So give us your background. Sure. So I started out as a kid learning how to hack video games and change them before the advent of client mutual authentication. And that really got me hooked. And as I grew up learning about software development, networking, reverse engineering, exploitation, going forward into things like software to find a radio and actually understanding RF better. It was kind of like I picked up these skills along the way. And as I was able to escalate in the career path and get better jobs, I finally got into a spot where I was able to affect what direction our team was going. And previously, I'd spent some time at a hedge fund kind of protecting a billionaire, making sure their billionaire is still worth billions. And there wasn't a ton of job satisfaction out of that other than the interest of how that works. And I got a project at doing a small medical device in a consulting relationship. And it was really neat because the problem set was really interesting from the requirements that how these devices operate, the conditions they have to operate in, the battery life, processing power, all this kind of stuff gives really interesting constraints. But also when you make improvements to something like that, it has a direct impact on people's lives. And it was a lot more interesting to work on those types of problems. That's when I kind of started just doing some research on some of the metronic gear and was able to publish some vulnerabilities after maybe an ugly or bad initial interaction that then turned quite positive. And then one of the things I'm most proud of, I think, is having the patients to work through that process with metronic. And then end up in a productive working relationship where now I do get to work on solutions and help with fixing things, not just identifying issues, sending a vulnerability report and walking away. So that's been really rewarding. Absolutely. And we thank all three of you. We've all been influential in the journey here as MDMs have progressed and adapted and understood that there's a problem, but also looked to solutions. So Natalie, I want to come back to you. I have a specific question and just it's more around military grade technology and techniques. How do you think that can really help secure medical devices and the infrastructure and hospital systems that they reside in? Yeah. Well, I think many times in the history, we saw that the military developed one of the cutting edge technologies in many areas in the industry. And as part of it, I think that security techniques are also well developed within the military. And when you talk about military grade security, I think this is what we want for medical devices, right? Because you don't want your security camera be protected the same way as your pacemaker. I think medical devices do require some higher extent of security and deeper level of security. And I think what we see in the military is wide range of attack scenarios and attack techniques and exploitation techniques. And you realize that for me, at least securing medical devices just by doing vulnerability patching or penetration testing or avoiding hard-coded password, it was not enough because I know and I'm familiar with how you can bypass those things pretty easily. And I think that taking some of the knowledge and basically military grade techniques can help you understand the kind of holistic and comprehensive security that these devices deserve. And one of the things that I think was significant in our way of thinking is that even if you secure the MDM's code or doing some vulnerability research or pen testing, it's not enough because those devices contain third-party code as well. And Ripple 20 is a great example, right? We see a TCPIP library affected millions of devices, power grids, medical devices, and most solutions today just can't handle third-party vulnerabilities. You can't really protect against vulnerabilities that are within code that you didn't develop and you don't have the source code to. And I mentioned in it because that in the military, we handle the lot with binary code and with embedded systems and with the ability to reverse engineer other people's code. And actually, we are leveraging these kind of techniques in our philosophy to embed protections and security into these closed-source components because in my view, the MDM has to be responsible for the security of the device regardless of the components within the device. So we have to give controls to the MDMs to secure these third parties. And I think these binary-level capabilities are well-established in the military and can be used to holistically secure medical devices, and this is what we try to do. Excellent. I just want to say, Natalie, as a patient and as someone that's been shouting about this stuff very loudly, it's like you're serenading my ears at the moment. I'm all for what you are saying. It is solely the MDM's responsibility. They have to take ownership and responsibility of the take-play ball. Right? As a patient. I agree with you, but on the other hand, I must say it's not an easy task, right? Because the MDM, it's very difficult to secure third parties and there is no way to avoid implementing third parties within your device. So until someone wouldn't take the responsibility to create such controls for MDMs and to create the security products that they can use to basically protect their devices, we really can't blame them. But we do need to ask them to use the cutting-edge tools to secure their devices, and this is indeed something that I believe in. Yeah, to embedding the security culture and how we look at devices, right? But Metronik is a good example from those learning from lessons learned, right? They've come from a place where they were in a really bad position to where they are now, which is never an easy thing taking that ownership and responsibility, saying, hey, we need to do more. We need help. We can't do it on our own. I often say it takes a stronger person to say, hey, I now need help and go to people that can help them versus having the persona of I know everything, we are a big manufacturer, we can do it on our own. Which I've seen so many times. Completely agree with you. That's great. I want to pull on that thread a little bit, V, and just talk a little bit more about your patient-hacker relationship and how being a patient maybe changes your perspective on device security and how the more you've learned about how devices are built and a little bit more under the hood, how that's also changed your perspective. Can you talk a little bit about that? Yeah, sure. So that brings back a memory of mine. I think it was two years ago, February. I was actually in ICU where I had some issues. I had some device issues and I had to be resuscitated. But I was lying in an ICU connected to 15 different kinds of machines doing infusion, monitoring. I had a specific external monitor monitoring my pacemaker at that time. And I was offered guest Wi-Fi, obviously, because hospitals want us to feel safe and connected to the world. And soon realizing that these systems weren't segmented and that I could potentially may have or may not have access to the central station that had my vitals on it. But just realizing from a perspective of a patient how interconnected these systems are. And the more that I watch and just observe the world or even attending talks, I realize that the word medical device is exclusively used for anything in healthcare and hospital and anything that a manufacturer makes, whether it's a Windows 10 machine or versus a complex embedded system. And I think until we start understanding each system is unique, I say language, linguistics or when you have someone that you're observing, you try and observe them and learn what they are, how they talk, all those kind of things. But we don't do that with devices. And I think I appreciate what Peter does and what Natty does is reverse engineer things to understand how they work, not only at a firmware level, but at a file system level, at a binary level. And as a patient, I wanted to know what keeps me alive. I wanted to know what libraries were used, what hardware was used. And I did that through OSINT. I literally Googled manuals and for manuals, I've permitted to get more information because the manufacturer wasn't disclosing it to me even as a patient. But I wanted to know that I can trust my device because I've seen that these devices almost understood and implemented in a way where we build bridges or walls around our networks. But we're so soft in the middle, but we never considered them malicious insider, which is a big thing because I've realized that the threat from hospitals might come from within, especially with everything with COVID-19 becoming borderless. I don't know where the border stops or the perimeter starts and stops anymore. So I think it's just we need to take the time to understand the devices, learn their language, and understand their constraints because they're all different. I always say beautifully broken, wonderfully flawed, meaning we can have the most secure and perfect device. There might still be a flaw and it still might be broken, but that doesn't take away from the beautiful synergy that goes into these devices. I geeked out because I spoke to one of the engineers and learned what my functions on my pacemaker and ICD does. And let's just say it was like the moment we sat back and said, this is such a simple, complicated device. But I trust it. It's the weirdest thing, but I geeked out knowing that the maps behind it is so wonderful that in a nanosecond it raises my heart rate up. So I'm actually getting emotional. Excuse me, but yeah, it's a good thing when you realize that you can trust what's in you. I can trust that it's going to do what it needs to do. I must mention just regarding one thing you said about getting the hardware specifications the self-cursifications being exposed to how the device has been built. There are also downsides into publishing this information, meaning bad actors having this information very accessible, having them being able to see what kind of third parties and start looking for vulnerabilities or understand the specs and extract the fee very easily. You want to make it as hard as possible. So I do think that we need to keep some sort of balance between what information we put public and what information we maybe expose just under certain terms. So understand you as a patient wanting to know as much as you can about your implantable device, but imagine that bad actors could have access to this information as well. So just to clarify, the reason that I said I own Synthesis was before I spoke to them and then I realized that I could get all the information. That's when I went to the MDM, right? So I'm also that certain things shouldn't be on the internet. And this is one of the first things I raised with them. So when I met as a patient, I went to them, I was concerned. I was petrified because I managed to get technical manuals from technical manuals jump to hardware manuals, which led me to more information than I certainly wanted to find in an OSINT exercise. So yeah, that's what happened. And that's when the legal team slapped down on me and like, where did you get this information? On the website? Yeah, we had the same experience where they asked, where did you get the devices? And we're like eBay. We know about that. Yeah. But I think that underscores the point of, I mean, I could understand the request to have a balance, but the minute that comes out, you can't take it back away. And I would caution the idea that hardware designers, software designers that rely on the concept of anonymity and hiding specifications of the device may make worse decisions predicated on the idea that no one's going to know what the hardware is or what the, you know, what radio chip they used, that kind of thing, right? That's an exercise in time. And when you think about the lifetime of these devices, I just caution that concept because once that comes out, we can't take it back away. Yeah, I mean. Go ahead, V. Sorry. So, so Peter, I think you and I, I mean, I didn't have to go by my device. I just got it expanded, right? And I got the doctor. I'm like, hey, hey, hey, I would like my device, please. Can I, can I keep it? And they gave it to me. I mean, your story of course is way cooler. I mean, I didn't have to. Yeah, I was talking a little bit more about that. Talk a little bit more about that story. So I'm a little bit of an empathic person. So like awkward situations tend to land strongly on me, I guess you might say. And amidst doing some of the work I've done, I'd taken apart and reversed the majority of the home monitor device, but I needed to see live communications to understand what so the implications of that work. So I tried to get my hands on some implantables and I think it was like between 30 and 40 morgues and corners offices I called trying to get my hands on before basically anyone that did cremation, right, because they removed the devices before cremation. And it was some really, really awkward conversations. I got yelled at a few times pretty, pretty aggressively, understandably so. They didn't see what I was trying to do. But yeah, that was a little bit awkward. Yeah, you should seriously try going to a cardiologist office and they Google to you and they've seen one of your talks and you get specifically watched doing everything. Yeah, that's a different patient perspective. I am officially banned from all major hospitals in my hometown from having a laptop or even getting Wi-Fi access. I think they've gone tired of me saying, hey, we should fix this, right? Or me spending time fixing it for them and saying, hey, I fixed this for you. Here's the credentials go for a while. It's just that whole culture of when you say to someone, but we can fix this for you. It's not an insult. It's genuinely people or researchers wanting to make things better. And perhaps not having the social, I don't sometimes have the social cues like you would say people like I can totally imagine having those conversations with coroners. I think I wanted to be a fly on the wall for that. So as a medical device manufacturer, I think I'm internalizing two takeaways. Over-reliant security by obscurity, but also make sure you keep operation security in mind and you're not just posting manuals and details that can be found through open source intelligence gathering. So two takeaways right there. So I want to switch gears and go to you, Pete. We talked a lot about your vulnerability discovery. Obviously, we hinted at a few of the CVs and things that you brought to Medtronic. But how do you see the testing landscape changing for devices? And what should medical device manufacturers do on their own to learn from what researchers have done in the testing space? A great question. Well, I think the testing is going to have to follow the path of development. And one of the major things I see is very important for the medical device community right now is there's a lot of devices that have update functionality, but there's a very, very small percentage of actually use it. And I think there's an opportunity right now to fix that problem before it gets out of hand. Secure update is one of those problems that if you don't design that in early on, you can kind of lose control of what it is you're trying to work with. It's a perfectly right target for attackers, especially when it comes to low-power, questionably connected embedded devices. So I would stress, like as far as something to develop on, work on secure update and get that working immediately so it can be used. The more confidence you have in that part of the tech stack, the more able you're going to be to respond to things like security incidents or updates because of some binary or open-source package that comes in. And that kind of, I think, will drive a lot more of the modifications to testing that's going to happen. As these devices, we've seen a trend now for devices that use homegrown protocols and bespoke like radio communication systems to communicate, largely shifting over to using things like Bluetooth and something that's a lot more standardized that also tends to work with a smartphone. And as that happens, we're seeing a shift into a lot more open-source library usage in these products. Because that particular thing is a problem near and dear to my heart, we're working on a tool to basically audit the open-source ecosystem and mine for malware, mine for backdoors. The vulnerability space, I think, is kind of, well, people are looking at that pretty aggressively right now. But no one's approaching it from the concept of who are the authors of these packages and how they work together. This is going to land very important on the medical device manufacturer. When you think about, I spent a little bit of time in the defense sector myself, and when you think about how nation-states approach problems, there's a tactical and a long-term strategic goal to some of these things. And compromising the GitHub credentials of a developer that writes a package that's three levels upstream from something that goes into a medical device is a great way to lay in weight for access into an entire fleet of these things. And again, you think about that kind of problem without a good secure update mechanism, and now you have something that is irreversible. So I see this as the trend of development changes with medical devices. The testing requirements are going to change as well. I would love to see a universe where when a device is designed, there's audit. We have automated testing through like fuzzing of the protocol. We have knowledge of different aspects of this that we can bolster and use things like computers to help us and have that built into the design such that when before release, there's all these different tiers that have happened aside from just someone manually reviewing source code. That is still a strong improvement over requiring people to buy these devices or call corners offices and take them apart, dump firmware, reverse engineer it and try to find bugs. The more people we can get involved with this at a productive level, I think is going to be more valuable too. And that's I think a large challenge of the medical device manufacturer. How do you adjust the signal-to-noise ratio such that you're getting competent quality people that really want to help without wading through the deluge of things that may happen if you just bug about me, I would say. Yeah, I think there's like a diverse approach to this. I think in a prior life, you were at a boutique shop and we've used all different types of testing companies. We've internalized some of this, but even finding those niche boutique shops or those individuals I can really get at certain elements have really helped us I know. If I may jump in, as a person who researched many platforms that are highly secured, highly being researched, highly being fuzzed and pentested, including Linux kernel and iPhone devices, I can tell you that it's impossible to put a device out there without vulnerabilities. And once it's out there and you have enough researchers, some of them will find the vulnerabilities. And if we'll take a look at long-term strategy and take a look at what the traditional IT world has gone through, we have endpoint security and we have network security. And the endpoint security is something sitting on the device in real time, capable of preventing and detecting attacks, regardless if the device is vulnerable, regardless what type of attack it is, and regardless of, you know, a secure design or where the vulnerability is. Is it in the OTA or improper input validation, etc. So for me, if you ask about what's the right approach, the right approach would be sustainable. Meaning I think secure design is cool. I think penetration testing is cool, but it will never be sufficient. You will never have 100% vulnerability free device, especially when you use third party code. So I don't know how much static analysis or vulnerability assessment tools you use, but they are not very good at finding vulnerabilities in binary code. They don't. And source code is not the only thing that goes into your device, not to mention hardware components that have software within them. So your Wi-Fi module or Bluetooth module, it contains vulnerabilities as well. You have vulnerabilities on the chip level. So in my view and in my opinion, only something that's operating in real time, capable of verifying the integrity of the device, capable of preventing damage, data theft, or basically preventing attacks, or on the other end, also monitor the device. Meaning you need to be alerted if something bad happens or maybe happens. This is the approach that I believe in more because I think this is why endpoint security has been so strong for many years now in the traditional IT space. And I think this is where IoT and IOMT should go to. And obviously there are challenges in installing something on those devices. They are low resource, they are real time operating systems, they are diversified, they are extremely different from traditional cell devices or pieces. But this is where innovation comes to the picture. I think we can solve this problem. I even think that we have solved part of the problem for sure. But I don't think that this challenge should keep us from putting something on the device to protect it. We should just do a breakthrough in how we see endpoint for IoT devices. Yeah, so I totally agree with what everyone is saying. Something dawned on me the other day. If we look at the longevity of medical devices, for example, could be a decade. So if you look at just some of the statistics, 600,000 medical devices implanted yearly in the US, well, those will last 10 years. So if you start adding the numbers up, you're dealing with an ocean of legacy devices that at one point in their lifetime will be vulnerable. And it's not technology that you can rip out of your body or some people only can have that monitor depending on what device you are talking about. But those things are built to last for a long time. So any solution will have to be a multidisciplinary approach, eating it from all sides, but need to grow with the device. Need to be updatable, need to be changeable, and basically grow with the times when the device is really caught. I'm glad you brought that up, V. So I'm interested and I'll go back around the panel and start with Pete. How do we approach this legacy device problem? I think V already teased out the updateability and forecasting of the lifecycle. But we have a lot of legacy debt right now that we're dealing with. So what are some ways that we can work through that? Pete, I'll start with you. That's a super challenging problem. I think there has to be some preparation for worst case scenario and worst case scenario being think about the attack surface. If that case is disabling radio connectivity on some of these things, working with some of the medical device manufacturers come to learn, this isn't a software change for a website that can be pushed into the CICD pipeline and show up in 10 minutes. This takes legal and regulatory guidance and preparation and submission to the FDA. That can take a long time. My suggestion is prepare for those scenarios now. Get ready for how do we do this if we have to? Because the reality of ex-planting devices from hundreds of thousands or millions of people is completely untenable. So how do you get... I realize that maybe there's going to be an inherent trade-off and quality of care provided. That's probably a situation you get to only as a worst case scenario. These devices keep people alive and that we want to keep enabling that because as Vee mentioned, these are things that some people wouldn't be here without those things. We don't want to instill the wrong level of fear, but planning for those scenarios now so that if those need to be enacted, I think is one of the only things you can do for the legacy devices that don't have an update mechanism. If they do, setting up the testing for this now and being ready for it, it's an inevitability. It's a when, not if. I think what we are doing together with Metronic, I think Metronic is a true pioneer in this support to legacy devices as what we are doing together, installing protection into five years old device, I think is five years old, enhancing the security in field, getting visibility, getting protection into really old medical device using the OTA. I think it's a true innovative play and I think that I truly support this kind of acts and I think that I have a lot of respect to Metronic in being pioneering doing such a thing. I think we can learn from it. I think we can provide enhancements to existing device flits. Of course, with the right controls and the right MDM to take it to the next level and to move forward. It's a good example of what we are doing together and I hope that we could pave the way. Absolutely. Baby steps in the journey, but exciting stuff. I know you have an opinion on this. I always have. You're good. You're on mute. Back on mute V. Oh, goodness. I'm having audio issues today. It's like the audio day over how old. My feelings on this is we can't even start facing the legacy problems until we stop making stupid decisions and choices going forward. We have to now nip this in the bird and say, going forward, we're going to do better. I haven't looked into lots of the things I've Googled it. I have read up on it. I'm very excited about what you guys are doing with Metronic. That certainly is a step in the right direction, but visibility is key. Pete and I have had discussions. It was like, we don't know if the ICD or pacemaker has been attacked. Do you even have the data to know that that's happened? We want to deal with legacy. We need to start getting visibility moving forward because otherwise we're adding this amount of, another year goes past. Now we have another group of legacy devices that's going to haunt us for 10 years. Get a drive going forward and then start dealing, finding solutions for those devices that you don't have visibility on. Find ways to get eyes on your products and your data because where you have a blind spot is most likely we're going to be attacked. It's not like a nation state actor is going to say, you know what, I have owned your product. Right? Researchers have the courtesy to come, you know, to have a discussion. Very bad people looking to do bad, bad things aren't going to have that discussion with you. You're not going to know they're there. You need one patient to have your device and they get attacked and they ultimately pay with their lives. I can tell you, you're going to have a string of patients wanting to explore on their devices, which is why something I don't want to have happen. It scares me because I look at where I was at 19, where I am now at 33 celebrating my birthday, having two kids, having a master's. Thanks to a device, it kept me living. Right? Otherwise it would be dead. It was as easy and as plain as that. It added years to my life I was not supposed to have. Take that technology away and as a human race, we go backwards. So patients need MDMs. Whether people in the security want to see them as an adversary, there are people like me that rely on them to develop the technology to keep us alive. Right? It's important to understand that it's a love-hate relationship. We're not all going to do it right, but if we can have the conversations and we can fight it out and we can find the solutions that are super cool and super techy and super new, we should try them. Right? What I think Sternum is doing, what Pete's doing, is hitting the same problem from a different side. I'm concentrating more on how do we detect and log these things? How do I investigate it? Mark and I have eyes on the prize sooner. That's my passion point. But we're all effectively covering this from a different side, which is good because all sides are vulnerable and all sides are needed. I think you're bringing it all together. How can we get better visibility? And Natalie talked a little bit about this, but I'd like you to go into more detail. What are your thoughts around proactive controls in the post-market, which is the term we just use for detection, logging, monitoring? I know we've thrown surveillance out there, but to be more in line with the community, it's incident response. It's logging detection, that capability. So how do you see proactive controls fitting into that model? Yeah. It's a great question. I think I want to learn from other industries, which already developed into these directions. So you don't see devices today within enterprise or in cloud infrastructures that are not monitored actively, that do not pop up alerts when something suspicious is happening. And I see the medical space behaving the exact same way. I think with solutions, I won't mention ours, but I think there are many solutions that can do that, provide monitoring and visibility into the device itself. And then I think that this kind of information and incident response should go into two main personas. One is the product security in the MDM. Monitoring is distributed device fleets, understanding if somebody is researching this device, selling the device on eBay, maybe trying to hack into the device, stealing information. This kind of things can be visible with the right controls. And of course, there is a technological challenge of supporting all devices, all code base, which didn't come with visibility inside without logging, without monitoring, but that can be fixed. It can be installed post market, and it's even easier to install it pre-market. The other persona is the hospital, the clinic. Those devices that if they come with built-in protection and monitoring, they can be the eyes of the hospital for a beginning of an attack attempt. Imagine an attack attempt just a month ago, there was a ransomware attack on hospital starting for a remote patient monitor. So the hacker penetrates to the internal network through the vulnerable IoT device. So imagine this device transmits information. Imagine this device is capable of detecting the attack attempt and even preventing it. Not only you prevented the attack, the hospital, that moment become aware that he is under attack and can act accordingly to secure other devices, maybe un-patch devices. So you don't have to have all the environment protected, but as you have more devices that are transmitting, visible, protected, you have more visibility into your entire enterprise or hospital and can respond accordingly. So I think both personas benefit from this kind of visibility. And I think moving forward, we can use these kind of tools to embed security and visibility. And I'm making a difference between the two because the kind of solution that I see in mind is first a deterministic solution to prevent attacks in real time, prevent the damage because in medical devices, there is no time to waste. A successful attack could lead to a little resorts and you don't have enough time to detect the attack and respond in a week or two weeks. Because in enterprise, it takes six months to respond to a security incident. You don't have this kind of time in medical devices, so you have to block the attack in real time. The other aspect is really to become aware. And to become aware means to get alerted when something is behaving differently or suspiciously or if there were a prevented attack attempt. And once you are aware that this kind of attack happened, let's say, in the US and you have devices that you can't update in another country with the same vulnerability because you know what the vulnerability at this point, because you have visibility into it, you are capable of providing fast response to alert your patients, to alert the hospital, to update the devices with a patch. So I think it's essential thing that we need to embed into the medical space. And we are on it. I love doing that because I think we're starting our journey to improve our visibility, improve our prevention in near real time, improve our detection capabilities. But we've thought into the future and how we need to better partner with healthcare delivery organizations, hospital systems, and provide some of that information to the example you gave about the ransomware outbreak. And having dealt with brands and one of myself in a past life, obviously time is of the essence. And that's something that we'd love to be able to help out with as an MDM in the future using these techniques and tools that we're talking about today. So V, I want to switch gears a little bit. We're talking about all different types of aspects of security controls and capabilities to give back. But you have a unique forensics background. How does that make you approach device security differently than say the traditional vulnerability disclosure scenarios? Yeah, so I think forensics is this unique focus on scientific processes. I think that's the one thing that was hammered into my head is we need to follow a scientific process. So you need to look at it from every aspect. But I was doing forensics for eight years straight, solely focusing on that and realizing that I wasn't quite understanding all sides of it. So I always say, we have a saying in forensics, we find the truth. So we reconstruct what happened. So I decided to actually start retrieving. So to learning how to attack. And then I learned how to defend. And then I learned how to investigate. And taking that, I decided to start applying that that type of mindset of taking a multidisciplinary view to things to saying, OK, well, I want to know if we're being attacked. I'm kind of tired of having it told to me that we don't have any data that supports any attack. And now knowing that we don't have the data actually available. So to have more visibility, we can start seeing whether devices are actually currently being attacked. Because we don't know, I spoke to multiple coroners around the world through law enforcement agency contacts. And the question I said to them, if you have a cardiac patient that has an implantable, right, they've passed away. That doesn't necessarily mean that it's suspicious circumstances. But do you do get a program, pull the data, look for the time of death, look of any strange activity surrounding the device itself? And I realized that, yeah, the devices get sent back to the manufacturer that does basically a memory review to see that everything is like it should be. But people forget that programmers can be compromised and something can happen from a programmer to a device. And we don't leverage the information that we have. So the important thing for me is we have no ability at the moment, unless a researcher comes to an NPM or someone makes a grand gesture that they've had to device, unless it causes chaos or becomes public. Somehow, we don't know. And that makes me uneasy as a forensics person. Because forensics, we want to know. We want to know the bits and bytes of how something functions. Men the local principles, a big thing that I live my life by. So everything that comes into connection with each other leaves a trace evidence. I want to know what it is. But if we don't have visibility, right, it's there, but we don't have the capabilities to make it visual. So I want to learn more of what we have, what we need, and what we need to do to kick ass to get there. So that's my approach to what I'm doing with Metronik is I'm assessing what you have. What we need and willing ass to get there. And I'm seeing it come together with the various aspects of you guys have brought together, you know, covering it from different angles. And the forensics in me is like saying, we can apply forensics in development. You know, we can apply for instance, extreme market, post market. It doesn't necessarily mean it's an investigation, but it's creating the evidence that we need for the future. It's creating the data now for when we do need it. I'm always drawn to the example of Microsoft and how they used other data sets to detect a large Windows vulnerability. And I think really was mining data in Windows event reporting. And I know that a big piece of what we're thinking about is we have a lot of remote monitoring information. We know what is above the line and what's below the line. And we're trying to develop, you know, that anomaly detection there. And it can't only be done, right, with that type of detection. That's one leg in the stool. But as we look at on device agents, as we look at other ways that we can pick this up with our fleet distribution infrastructure, I think that really has to come together to get this full picture. And all of you have hit on that element. And I think it's not to discount testing or threat modeling, all of that has to happen as well. But we really want to emphasize this prevention in real time and then this detection of the current devices and fleet that are legacy and are out there live today. And what can we learn from that? And I just, I really think that's important. And all of you have been bringing a different element of that to this discussion. And it's, it's helping us, I think, learn as a medical device manufacturer how to handle this situation. Yeah, I'm always sorry. I'm sorry. We should I always say data doesn't lie, right? It always said, there's a saying that follow the money or follow the evidence. But we have so much data, we're just not mining it. We're not learning. I think it's one of your members Sasha that said, we know, we need to learn to listen. Right. So we need to learn what the data is telling us. And I think that's the big thing. We have all this data, but we're not listening to it. And once we start intuitively tuning in and understanding the data, those numbers don't lie. Then actually, I think an MDM can only really do straight analysis. Because if you don't know what you have, how do you know what to protect? Because then you're always on the back foot. Right. You need to get ahead of the problem. You need to know where you're most vulnerable at. You shouldn't wait for that to become public knowledge. So I want to shift gears one more time here. Here the concept of zero trust in medical devices. And I've talked to, I believe each of you are on the same topic. How do you think that can be, that concept can be applied from an MDM perspective or from a medical device perspective? And I'll throw that out to the group whoever wants to latch onto that one can start us off. Okay, I'll roll with it. I was waiting for you. I know you got to be like, go ahead. I love zero trust. It makes me excited because for once we turn insecurity on it and saying, we're not going to trust but verify. That's not going to be, which is not going to trust. Because the nice thing about zero trust is you can actually understand devices. But the ideal thing is now we don't have a perimeter. We harden everything. We probe a device and if it meets the specific standards, that device is allowed to have access to the minimum it needs access to. Right? It's like a patient monitor that doesn't have to be on the wifi and doesn't have to link to the accounting system or the patient records. We have this thing trying to make everything accessible but too accessible. We take it to the extremes. We either make it too secure and unusable or we go to the other way. But zero trust has really big plus points for me because now we can attend to device manufacturers independently. We're not going to have the same controls across the board because everyone builds their devices different. You can understand the device and apply the appropriate rules, privilege and access. I think this is a really good solution as we move to a perimeterless remote monitoring and medical service. I had my first video consultation today which is something very strange but yet it felt normal. The perimeter has just been broken. COVID-19 came in, swept Kalske off its feet and we are facing new territory. We're having to build while trying to catch up. This virus has crippled health care and I think security should never put such a strain on health care that could cripple it more. We should be making it safer and easier to use. That's our responsibility as security people in this field. It's the responsibility of the MDM. Zero trust is the ability to do K-TED security based on a device, not necessarily the same rule for everyone. I'm very excited about it. I agree with you and I have a slightly different interpretation of zero trust in the concept of medical devices. For me, zero trust basically means we talked earlier about third parties and we talked about embedding communication models within the code and communicating with the patient's mobile app and the patient's maybe home router, each medical device with its communication. I think zero trust should really mean that we can't trust any of those. We can't trust any of the third party open source, closed source embedded. We can't even trust the operating system that a medical device use, whether it's commercial one, Linux based. We should be expecting vulnerabilities throughout the entire supply chain. The code, the hardware, the software within the hardware and of course we can't trust that the patient didn't install a malicious application on his mobile. The last thing we want to trust is the human being not making mistakes. For me, the concept of zero trust basically means that the kind of security that we choose to implement should take all of this under consideration and to make sure that we keep the integrity of maybe not the entire device, maybe it's impossible, but essentially the critical operation of the device should remain secure regardless of all the things that I mentioned. Like if we talk about insulin pumps, so you want the functionality of injecting insulin will be the most protected functionality of the device. Same goes for personal health information on the device itself. For me, zero trust basically means taking this into consideration when designing a security solution. Exactly, I like what Natalie said. I think it's the difference in design. I talk about this all the time, every time someone will listen. I look at it as a concept of, I think a great example is like cars. When the systems were built to allow a computing interface in a car, they weren't connected to anything. They designed according to that. They scaffolded this over years. Then all of a sudden someone came along and tacked on internet connections and Bluetooth and Wi-Fi. What you should do is go back and redesign everything to consider that new approach. The zero trust concept to me means we think about it from the initial idea stage of defending it in every place it can be. It's an analogy to what Natalie and V were saying about no one operational environment is any more or less secure than any other one because they're all the same. Everything to consider that takes concerted effort from the start, from the very, very start. I think approaching the problem from that way is another one of those shifts that we have to consider from legacy devices into what is going to be the new normal for this. Everyone's going to have to get there. The quicker a manufacturer of any kind of product you can start considering that, the easier their life is going to be in the long run. I must add just one thing about that because I think we are repeating a lot of thought. Think about it in advance. You have to design it. I must mention the other side. Security has always been the last part to be incorporated into things. Everybody would like to go to market faster. Everybody likes to just build their devices, build their technology. Nobody likes to think about security. I'm saying it's okay. I don't want to say you have to think about it in advance. You don't. History teaches that nobody thinks about everything in advance and it's okay. Security comes last always. So for me as someone who is looking for solutions and not just looking to emphasize the problem, I'm looking for solutions that can be developed and installed even if you didn't think about security. I have to say, again, it's the best thing to think about it in advance. But I'm just saying it's okay if you didn't. Nobody holds you responsible. I will hold you responsible only if you didn't try to fix it later on. I have to disagree there. I want to kick an Indian's ass and say, what the hell are you thinking? Oh, let me think. You're right. That's what happened there. It depends. It depends. If you have hard-coded paths for like one, two, three, four, then this is the place where you can think. What the hell were you thinking? But I'm just saying, the more advanced stuff, it's harder to think about. Yeah, so it's a two-fold problem. We dealing with legacy. I call it the legacy because that's what it's written in, that joke for the evening. The problem is we have to stop developing legacy problems. So we need to address it ahead of time. But okay, we have to face the fact that previously we didn't address it ahead of time and there's nothing you can do. Can't pull these things back. Can't tell me you're going to cut me open, take my device back, give me a new one. I'm not going to let that happen. So we have to deal with that. It's a two-fold problem. We have to be realistic. I think you are completely correct, but realistically looking ahead, I don't think we're going to be thinking about it in advance in the years to come because new problems will appear. And like in the 50 years prior to where we stand today, companies didn't think about it in advance. So we can teach that. We can say that. But to be realistic, I don't think it's going to happen. People will only handle the problem once it bites them in the ass, basically. You know, it's human, right? I can't disagree with you because history often repeats itself. I think what's interesting is recovering it like a triangle from different sides, which is very interesting. I'm concerned with we have these devices that are diversified. How do we include this on a healthcare network? Right? NACI's product literally deals with legacy devices and new devices. And the solution covers it from a different angle. So it's just like diversified opinion that's doing the same thing, but each in a different way. And this is why I think researching is important because we all think differently. So it's having, yeah, it's a big problem. It's massive. I think we're, yeah, I agree with what you're saying. We're all kind of coming at it from a little bit of a different perspective. And I do agree, Natalie, that like there's going to be new attacks we haven't thought of today that come out in the next year, three years, five years. But we're talking about medical devices today. And I think we absolutely have to require better work on the design. We got here because of the evolutionary walk of how medical device manufacturers built businesses to help patients and computers came part of that and here we are. How we go forward though can be changed. And I think the idea that we'd be accepting to someone not working hard at that right now is dangerous. I agree that we need to have things on the other side to prepare for the inevitable, the new things that come out that we haven't thought of the next thing that shakes the industry so to speak. And we want to be resilient to that. I completely agree. But in one case when I was looking at a medical device, I then started reverse engineering in e-bike. And the e-bike was orders of magnitude better because the e-bike wanted to prevent someone from bypassing the speed controller and going too fast in the bike that it wasn't regulated for. And they did a tremendous, they did an incredible job for that. But seeing the stark contrast between those two, the difference there was they designed it to be that way. And I know I harp on that a lot, but I think that's an important point. I think we can all agree that there's some fundamentals that we need to align with. I think this is why we want this diverse experience background, opinions, because it helps us grow in the industry. And we have time for one quick final question here, and I'll go around the panel and start out with you, Pete. How can researchers, smaller shops, those attending the biohacking village, get more involved with device makers? The way I did was eBay and calling. I think there would be a lot that could be drastically improved. If there's a way to get your hands on research devices to start learning this space, one of the challenges I think newer people to working in medical device research are going to run into is becoming aware of the monstrosity that is an MDM. And something like when you find a bug and you suggest a fix for it, the reality is its scale of making that happen. So on one hand, I would say it would be wonderful if MDMs would start exposing programs for researchers to apply to and be selected to start working on this stuff. And on the other hand, I think there would be a great spot for education on the MDM side to show what is it we're going to do. We need to do a hypothetical patch to this hypothetical device. What does that actually look like? The legal ramifications, the regulatory ramifications, because without that information, a lot of security researchers I think will be frustrated at the timeline it takes because they don't have any sort of understanding of what's really happening, especially coming from a place of the hacker ones and the bug crowds where that's a pretty smooth process when you're looking at web properties. And it's a very, very different industry. It's a very different threat model. It's a very different process. You have to go through and I think there's an education opportunity for that. Natalie, I know you've had your journey with medical device manufacturers. Same question to you. How do you think that researchers in smaller shops can get more involved in making a difference? So I completely agree with Peter and I think that bug bounties programs and exposing the inner processes that's happening within medical device development, which is extremely different from traditional development with different regulations and different constraints could help getting more engaged. I think assigning a person or a unit responsible for that is also super important in some of the medical devices. You just don't know who's the right person to approach. It's not the CISO. The CISO is not concerned about medical device security. It's concerned about the network. So I think getting this better approach is good. Transparency is good. Basically saying, hey, we want you involved. We're okay with it. We're not going to send you some terrifying legal documents if you find something. This can be helpful. And I think the research community maybe thinking about it in a different direction can also help educate. Meaning I think that what we sometimes do, we go to medical devices. We do some exploitation workshops. We explain what vulnerability means, how to exploit vulnerabilities, how to write code with security in mind to avoid vulnerabilities. We had this experience with Metronik as well. It was amazing. It was super satisfying for us. And I believe that it was also interesting for medical advice engineers and software developers to suddenly see the other side of the code and the other side of what can be done with the code and how devices are being exploited can also raise awareness and can also help them understand what the researchers are doing and why they're doing that. And this could really be like open mind and open hearted conversation which we had. And I think is a great example. It's not very common. I mean, device manufacturers, OEMs, some of them do not respond well when researchers approach them with vulnerabilities. And I think positioning yourself as an MDM saying we respect that, we would work with you is amazing and it's the right approach. Last but not least, V, you get the final word. Oh, awesome. I'm going to do a call out to all my fellow biohackers, my friends, my goons, my family. The biggest thing I've learned that the constraints we're dealing with vulnerabilities from an MDM's perspective is when you do a proof of concept, approach this like a report, approach it like scientifically, give us much information, as much code as you can for the MDM. They need to verify what you have said. And if your document doesn't consist of information that is comprehensive and easy to follow, they are going to have to reverse engineer things themselves. And then the 30 days that you expect to get back from them, it's going to take them 60 to 90 days just to figure out whether it's applicable to their product. So if you come with a problem, come with a solution. Let's not just focus on what we've broken. Let's try and fix it. So my challenge to all my hacker friends are, let's not just try to break things. Let's try and solve things. For me, the term hackers, obviously sometimes associated with cyber criminal. And for me, it's a passion point because hacking is what I do. I'm not a criminal. I try and figure out what's wrong so that I can fix it using alternate ways and means of thinking. That's what a hacker does. That is what a hacker is for me. But we're also scientists and in science, we need to be thorough. We need to do the project better. And for an MDM, it won't be such hard asses. We're trying to help. I promise you, we're not your enemy. Just be a little bit nicer. I have a conversation. Buy someone a coffee. If you see someone at Biohack Village, I promise you, I haven't had a hacker that bites unless asked to bite. We don't like having teeth. We like having tech conversations. And we like geeking out with you. But it comes from both ways. We both need to open our hearts and open our minds and realize we're working towards the same ideal and working against each other is not going to get us there any sooner. And from a patient's like, keep on doing the research. Make this stuff better. Because I think either part, you need to each other. It's a trifecta. It's the medical manufacturer. It's the researcher and it's the FDA or the regulatory body, depending on where you're from. Those are the things that are going to make the future better. And those are basic engineering practices. A triangle is the strongest thing you can enforce something with. So let's enforce this with teamwork. That's all I have to say. V out. With that, I want to thank the panel. Drop the mic. Pete, Natalie, V, we're good to go. Have a good DefCon Biohacking Village, everyone. Thank you. Thank you very much. Cheers.
 All right, well, welcome folks.  It's my pleasure and honor to introduce some great friends of mine.  They are all hackers and we have our moderator today.  I'll do a brief introduction for him.  But first and foremost, welcome to the biohacking panel.  How independent security researchers vis-a-vis hackers work with MDMs or that notorious medical  device manufacturer.  This is the bad, the ugly and the great.  Also affectionately known as bug.  My name is the red dragon 1949.  You know me as the volunteer coordinator.  But more importantly, I'd like to introduce you to the panelists first and foremost ladies  first.  We have Veronica or B Schmidt yesterday was her birthday.  So happy birthday V. She is a former federal law enforcement in South Africa.  She has done forensic investigations.  She is a cardiac implant patient three times and she's doing some great forensic work  for one of the MDMs that will be showcased here at the biohacking village Medtronic.  Second, we have Miss Natalie Schuva.  She is the CEO for sternum out of Tel Aviv Israel.  She comes to us from the unit 8200 of the Israeli Defense Force.  She can do things remotely with a mobile phone and the applications that are fascinating  and yet scary at the same time.  So welcome Natalie.  And then last but not least, we have Mr. Peter Morgan out of San Diego, California.  Mr. Morgan is quite how shall we say effective at basically taking a medical device down  to its very fundamental binary level and doing things with it that would surprise you not  only from a software and a firmware level, but certainly from a vulnerability exposure.  He has notable common vulnerabilities and exposures to his name associated with some  metronic devices.  So welcome Peter.  And then last but not least our moderator, Mr. Kyle Erickson.  He's the director for product security engineering with the cardiac rhythm heart failure business  division at Medtronic out of Minneapolis, Minnesota.  He has extensive breach and incident response experience with one of the largest healthcare  organizations here in the Minnesota area as well as globally.  So he has faced some of these individuals on the panel that he's going to be moderating.  So welcome Mr. Erickson.  I will turn it over to you.  Thank you Red Dragon for those great introductions.  I have the luxury to be here on the panel with Pete, Natalie and Vee.  And I'm really excited to dig into their story and learn how they've been working with medical  device manufacturers, what medical device manufacturers can do better and what we're  working on to improve in the industry.  So I want to start out with an origin story.  And I'm going to start with Natalie.  Natalie, what makes you a hacker and how did you really get involved in the security movement  around medical devices?  Yeah.  Well, I actually don't refer to myself as a hacker, but I can tell you basically my story.  I grew up with four big brothers and started my undergraduate degree at the age of 14,  computer science.  It wasn't just weird because I was 14.  It was also weird because nobody in my family ever went to college or something like that.  So I was like the black sheep in the family.  And once I graduated, then I just started my period in the Israeli unit A200, one of  the elite technological units there.  And this is where I got exposed to cybersecurity, low level development and research and exploitation  in general.  We did some significant things in the unit, handled the most advanced techniques and technology.  And after the period of time there, I wanted to keep using cybersecurity to create impact.  So during my time in Cerebrite, I did a lot of vulnerability research and exploitation,  mainly on Linux, Kerala and Android platforms.  And I didn't consider it as being a hacker, but mainly to provide evidence to stop pedophiles  and human trafficking and stuff like that because using the vulnerabilities and exploitation  we were able to extract forensics and basically evidence from the mobile devices, including  encrypted ones.  So for me, it was the passion and the impact that such tools can create.  And the medical device was actually not a coincidence.  I was always dreaming and thinking about becoming a doctor.  So when I finished my master's in computer science, I figured that this is like my last  opportunity to go into the medical industry.  I thought about starting medical school, but with the knowledge I had in cybersecurity,  I met with a few friends and entrepreneurs and one of them is my partner, Boaz, and we  started thinking about medical devices and cybersecurity.  And when I saw that remote care and remote monitoring could have such a tremendous effect  on our lives and they were not properly secure, this was something that attracted me tremendously  because I figured that creating the right security to these devices could really improve  patient's lives and improve quality of care and treatment.  And I saw how the knowledge that we have from the cybersecurity industry could leverage  this kind of technology.  And this is what actually attracted me to Co-Front's tunnel.  That's excellent.  Obviously, you may not call yourself a hacker, but you have the tactics, techniques, and  capabilities.  So, V, I'd like to go to you.  And obviously, we know you have a unique story.  You're not only a hacker, a researcher, a goon, but you have a implanted medical device and  refer to yourself as a cyborg.  So why don't you just give us a little bit more about your background and how you've  been getting more and more involved with medical device manufacturers in the industry?  Yeah, so I wasn't a very good hacker when I was a child and I basically got court changing  records at school because I felt everyone should have a good year.  Unfortunately, that led me down a path that my parents weren't very proud of.  But going back at the age of 18, I joined the Special Investigation Unit, which is a  law enforcement agency that deals with cross-border human trafficking, child pornography.  Some really nasty things.  We actually made use of celibate, so I'm very familiar with what Nati's referring to.  And let me tell you, if you want to get a physical image of those things that they develop,  are key.  But at 19, I also had about approximately two weeks left to live when I got my device  implanted.  And I know the quality of life that it gave me.  But since then, I was obsessed with what my device does.  For the pure fact that I believed in the same trust but verify, but I could never verify  what was keeping me alive.  And that was the biggest, greatest frustration.  I reached out to you guys about three years ago and I was met with the ugly part of Metronics,  sadly.  I got met with the legal team.  And I felt that the conversation wasn't going very well.  I remember these words and Toro that used to work with you, knows this well.  I said to them, well, if you want to bring your lawyers to the table, I can do the same  and then we can have a conversation.  But that's where it ended.  And Inwood's Biohack Village three years ago, Nina being forever the master planner put  me on the path for gold.  But then I came to severe loggerheads last year because he could not confirm to me that  he was from Metronics.  And though I knew he was and we went at it and we had our conversation and fast forward  a couple of months.  I'm now finding my feet within Metronics and doing research into early detection because  I didn't want to focus on the problem.  I want to find the problem and then solve it.  So it's not just about whether the device can be hacked.  We all know everything can be hacked, but it's actually about having some tangible evidence  to deal with to early detection to mitigate it.  For me, literally close to my heart is the embedded implanted devices that are often  misunderstood, forgotten about.  And these are the things that are connected to people, flesh and bones.  And I just decided to take this on and put my story out there and say, you know, these  things are cool, but they also scary.  But that doesn't mean we need to go in the internet.  It just means we need to do more to make it safer.  Absolutely.  And we're glad that we can make some inroads there.  I know it's been a journey to say the least.  Pete, you've had a similar journey.  I'd love to just kind of hear your origin story and what got you interested in medical  device security.  And not only do you have vulnerability discovery on your side, you've also looked at solutions  and improving the problem.  So give us your background.  Sure.  So I started out as a kid learning how to hack video games and change them before the  advent of client mutual authentication.  And that really got me hooked.  And as I grew up learning about software development, networking, reverse engineering,  exploitation, going forward into things like software to find a radio and actually understanding  RF better.  It was kind of like I picked up these skills along the way.  And as I was able to escalate in the career path and get better jobs, I finally got into  a spot where I was able to affect what direction our team was going.  And previously, I'd spent some time at a hedge fund kind of protecting a billionaire, making  sure their billionaire is still worth billions.  And there wasn't a ton of job satisfaction out of that other than the interest of how  that works.  And I got a project at doing a small medical device in a consulting relationship.  And it was really neat because the problem set was really interesting from the requirements  that how these devices operate, the conditions they have to operate in, the battery life,  processing power, all this kind of stuff gives really interesting constraints.  But also when you make improvements to something like that, it has a direct impact on people's  lives.  And it was a lot more interesting to work on those types of problems.  That's when I kind of started just doing some research on some of the metronic gear and  was able to publish some vulnerabilities after maybe an ugly or bad initial interaction that  then turned quite positive.  And then one of the things I'm most proud of, I think, is having the patients to work  through that process with metronic.  And then end up in a productive working relationship where now I do get to work on solutions and  help with fixing things, not just identifying issues, sending a vulnerability report and  walking away.  So that's been really rewarding.  Absolutely.  And we thank all three of you.  We've all been influential in the journey here as MDMs have progressed and adapted and  understood that there's a problem, but also looked to solutions.  So Natalie, I want to come back to you.  I have a specific question and just it's more around military grade technology and techniques.  How do you think that can really help secure medical devices and the infrastructure and  hospital systems that they reside in?  Yeah.  Well, I think many times in the history, we saw that the military developed one of the  cutting edge technologies in many areas in the industry.  And as part of it, I think that security techniques are also well developed within the military.  And when you talk about military grade security, I think this is what we want for medical devices,  right?  Because you don't want your security camera be protected the same way as your pacemaker.  I think medical devices do require some higher extent of security and deeper level of security.  And I think what we see in the military is wide range of attack scenarios and attack  techniques and exploitation techniques.  And you realize that for me, at least securing medical devices just by doing vulnerability  patching or penetration testing or avoiding hard-coded password, it was not enough because  I know and I'm familiar with how you can bypass those things pretty easily.  And I think that taking some of the knowledge and basically military grade techniques can  help you understand the kind of holistic and comprehensive security that these devices  deserve.  And one of the things that I think was significant in our way of thinking is that even if you  secure the MDM's code or doing some vulnerability research or pen testing, it's not enough because  those devices contain third-party code as well.  And Ripple 20 is a great example, right?  We see a TCPIP library affected millions of devices, power grids, medical devices, and  most solutions today just can't handle third-party vulnerabilities.  You can't really protect against vulnerabilities that are within code that you didn't develop  and you don't have the source code to.  And I mentioned in it because that in the military, we handle the lot with binary code  and with embedded systems and with the ability to reverse engineer other people's code.  And actually, we are leveraging these kind of techniques in our philosophy to embed protections  and security into these closed-source components because in my view, the MDM has to be responsible  for the security of the device regardless of the components within the device.  So we have to give controls to the MDMs to secure these third parties.  And I think these binary-level capabilities are well-established in the military and can  be used to holistically secure medical devices, and this is what we try to do.  Excellent.  I just want to say, Natalie, as a patient and as someone that's been shouting about  this stuff very loudly, it's like you're serenading my ears at the moment.  I'm all for what you are saying.  It is solely the MDM's responsibility.  They have to take ownership and responsibility of the take-play ball.  Right?  As a patient.  I agree with you, but on the other hand, I must say it's not an easy task, right?  Because the MDM, it's very difficult to secure third parties and there is no way to avoid  implementing third parties within your device.  So until someone wouldn't take the responsibility to create such controls for MDMs and to create  the security products that they can use to basically protect their devices, we really  can't blame them.  But we do need to ask them to use the cutting-edge tools to secure their devices, and this is  indeed something that I believe in.  Yeah, to embedding the security culture and how we look at devices, right?  But Metronik is a good example from those learning from lessons learned, right?  They've come from a place where they were in a really bad position to where they are  now, which is never an easy thing taking that ownership and responsibility, saying, hey,  we need to do more.  We need help.  We can't do it on our own.  I often say it takes a stronger person to say, hey, I now need help and go to people  that can help them versus having the persona of I know everything, we are a big manufacturer,  we can do it on our own.  Which I've seen so many times.  Completely agree with you.  That's great.  I want to pull on that thread a little bit, V, and just talk a little bit more about your  patient-hacker relationship and how being a patient maybe changes your perspective on  device security and how the more you've learned about how devices are built and a little bit  more under the hood, how that's also changed your perspective.  Can you talk a little bit about that?  Yeah, sure.  So that brings back a memory of mine.  I think it was two years ago, February.  I was actually in ICU where I had some issues.  I had some device issues and I had to be resuscitated.  But I was lying in an ICU connected to 15 different kinds of machines doing infusion,  monitoring.  I had a specific external monitor monitoring my pacemaker at that time.  And I was offered guest Wi-Fi, obviously, because hospitals want us to feel safe and  connected to the world.  And soon realizing that these systems weren't segmented and that I could potentially may  have or may not have access to the central station that had my vitals on it.  But just realizing from a perspective of a patient how interconnected these systems are.  And the more that I watch and just observe the world or even attending talks, I realize  that the word medical device is exclusively used for anything in healthcare and hospital  and anything that a manufacturer makes, whether it's a Windows 10 machine or versus a complex  embedded system.  And I think until we start understanding each system is unique, I say language, linguistics  or when you have someone that you're observing, you try and observe them and learn what they  are, how they talk, all those kind of things.  But we don't do that with devices.  And I think I appreciate what Peter does and what Natty does is reverse engineer things  to understand how they work, not only at a firmware level, but at a file system level,  at a binary level.  And as a patient, I wanted to know what keeps me alive.  I wanted to know what libraries were used, what hardware was used.  And I did that through OSINT.  I literally Googled manuals and for manuals, I've permitted to get more information because  the manufacturer wasn't disclosing it to me even as a patient.  But I wanted to know that I can trust my device because I've seen that these devices almost  understood and implemented in a way where we build bridges or walls around our networks.  But we're so soft in the middle, but we never considered them malicious insider, which is  a big thing because I've realized that the threat from hospitals might come from within,  especially with everything with COVID-19 becoming borderless.  I don't know where the border stops or the perimeter starts and stops anymore.  So I think it's just we need to take the time to understand the devices, learn their language,  and understand their constraints because they're all different.  I always say beautifully broken, wonderfully flawed, meaning we can have the most secure  and perfect device.  There might still be a flaw and it still might be broken, but that doesn't take away from  the beautiful synergy that goes into these devices.  I geeked out because I spoke to one of the engineers and learned what my functions on  my pacemaker and ICD does.  And let's just say it was like the moment we sat back and said, this is such a simple,  complicated device.  But I trust it.  It's the weirdest thing, but I geeked out knowing that the maps behind it is so wonderful  that in a nanosecond it raises my heart rate up.  So I'm actually getting emotional.  Excuse me, but yeah, it's a good thing when you realize that you can trust what's in  you.  I can trust that it's going to do what it needs to do.  I must mention just regarding one thing you said about getting the hardware specifications  the self-cursifications being exposed to how the device has been built.  There are also downsides into publishing this information, meaning bad actors having this  information very accessible, having them being able to see what kind of third parties and  start looking for vulnerabilities or understand the specs and extract the fee very easily.  You want to make it as hard as possible.  So I do think that we need to keep some sort of balance between what information we put  public and what information we maybe expose just under certain terms.  So understand you as a patient wanting to know as much as you can about your implantable  device, but imagine that bad actors could have access to this information as well.  So just to clarify, the reason that I said I own Synthesis was before I spoke to them  and then I realized that I could get all the information.  That's when I went to the MDM, right?  So I'm also that certain things shouldn't be on the internet.  And this is one of the first things I raised with them.  So when I met as a patient, I went to them, I was concerned.  I was petrified because I managed to get technical manuals from technical manuals jump to hardware  manuals, which led me to more information than I certainly wanted to find in an OSINT  exercise.  So yeah, that's what happened.  And that's when the legal team slapped down on me and like, where did you get this information?  On the website?  Yeah, we had the same experience where they asked, where did you get the devices?  And we're like eBay.  We know about that.  Yeah.  But I think that underscores the point of, I mean, I could understand the request to  have a balance, but the minute that comes out, you can't take it back away.  And I would caution the idea that hardware designers, software designers that rely on  the concept of anonymity and hiding specifications of the device may make worse decisions predicated  on the idea that no one's going to know what the hardware is or what the, you know, what  radio chip they used, that kind of thing, right?  That's an exercise in time.  And when you think about the lifetime of these devices, I just caution that concept because  once that comes out, we can't take it back away.  Yeah, I mean.  Go ahead, V.  Sorry.  So, so Peter, I think you and I, I mean, I didn't have to go by my device.  I just got it expanded, right?  And I got the doctor.  I'm like, hey, hey, hey, I would like my device, please.  Can I, can I keep it?  And they gave it to me.  I mean, your story of course is way cooler.  I mean, I didn't have to.  Yeah, I was talking a little bit more about that.  Talk a little bit more about that story.  So I'm a little bit of an empathic person.  So like awkward situations tend to land strongly on me, I guess you might say.  And amidst doing some of the work I've done, I'd taken apart and reversed the majority  of the home monitor device, but I needed to see live communications to understand what  so the implications of that work.  So I tried to get my hands on some implantables and I think it was like between 30 and 40  morgues and corners offices I called trying to get my hands on before basically anyone  that did cremation, right, because they removed the devices before cremation.  And it was some really, really awkward conversations.  I got yelled at a few times pretty, pretty aggressively, understandably so.  They didn't see what I was trying to do.  But yeah, that was a little bit awkward.  Yeah, you should seriously try going to a cardiologist office and they Google to you  and they've seen one of your talks and you get specifically watched doing everything.  Yeah, that's a different patient perspective.  I am officially banned from all major hospitals in my hometown from having a laptop or even  getting Wi-Fi access.  I think they've gone tired of me saying, hey, we should fix this, right?  Or me spending time fixing it for them and saying, hey, I fixed this for you.  Here's the credentials go for a while.  It's just that whole culture of when you say to someone, but we can fix this for you.  It's not an insult.  It's genuinely people or researchers wanting to make things better.  And perhaps not having the social, I don't sometimes have the social cues like you would  say people like I can totally imagine having those conversations with coroners.  I think I wanted to be a fly on the wall for that.  So as a medical device manufacturer, I think I'm internalizing two takeaways.  Over-reliant security by obscurity, but also make sure you keep operation security in mind  and you're not just posting manuals and details that can be found through open source intelligence  gathering.  So two takeaways right there.  So I want to switch gears and go to you, Pete.  We talked a lot about your vulnerability discovery.  Obviously, we hinted at a few of the CVs and things that you brought to Medtronic.  But how do you see the testing landscape changing for devices?  And what should medical device manufacturers do on their own to learn from what researchers  have done in the testing space?  A great question.  Well, I think the testing is going to have to follow the path of development.  And one of the major things I see is very important for the medical device community right now  is there's a lot of devices that have update functionality, but there's a very, very small  percentage of actually use it.  And I think there's an opportunity right now to fix that problem before it gets out of  hand.  Secure update is one of those problems that if you don't design that in early on, you  can kind of lose control of what it is you're trying to work with.  It's a perfectly right target for attackers, especially when it comes to low-power, questionably  connected embedded devices.  So I would stress, like as far as something to develop on, work on secure update and get  that working immediately so it can be used.  The more confidence you have in that part of the tech stack, the more able you're going  to be to respond to things like security incidents or updates because of some binary or open-source  package that comes in.  And that kind of, I think, will drive a lot more of the modifications to testing that's  going to happen.  As these devices, we've seen a trend now for devices that use homegrown protocols and bespoke  like radio communication systems to communicate, largely shifting over to using things like  Bluetooth and something that's a lot more standardized that also tends to work with a  smartphone.  And as that happens, we're seeing a shift into a lot more open-source library usage in  these products.  Because that particular thing is a problem near and dear to my heart, we're working on  a tool to basically audit the open-source ecosystem and mine for malware, mine for backdoors.  The vulnerability space, I think, is kind of, well, people are looking at that pretty  aggressively right now.  But no one's approaching it from the concept of who are the authors of these packages and  how they work together.  This is going to land very important on the medical device manufacturer.  When you think about, I spent a little bit of time in the defense sector myself, and when  you think about how nation-states approach problems, there's a tactical and a long-term  strategic goal to some of these things.  And compromising the GitHub credentials of a developer that writes a package that's three  levels upstream from something that goes into a medical device is a great way to lay in  weight for access into an entire fleet of these things.  And again, you think about that kind of problem without a good secure update mechanism, and  now you have something that is irreversible.  So I see this as the trend of development changes with medical devices.  The testing requirements are going to change as well.  I would love to see a universe where when a device is designed, there's audit.  We have automated testing through like fuzzing of the protocol.  We have knowledge of different aspects of this that we can bolster and use things like  computers to help us and have that built into the design such that when before release,  there's all these different tiers that have happened aside from just someone manually  reviewing source code.  That is still a strong improvement over requiring people to buy these devices or call corners  offices and take them apart, dump firmware, reverse engineer it and try to find bugs.  The more people we can get involved with this at a productive level, I think is going to  be more valuable too.  And that's I think a large challenge of the medical device manufacturer.  How do you adjust the signal-to-noise ratio such that you're getting competent quality  people that really want to help without wading through the deluge of things that may happen  if you just bug about me, I would say.  Yeah, I think there's like a diverse approach to this.  I think in a prior life, you were at a boutique shop and we've used all different types of  testing companies.  We've internalized some of this, but even finding those niche boutique shops or those  individuals I can really get at certain elements have really helped us I know.  If I may jump in, as a person who researched many platforms that are highly secured, highly  being researched, highly being fuzzed and pentested, including Linux kernel and iPhone  devices, I can tell you that it's impossible to put a device out there without vulnerabilities.  And once it's out there and you have enough researchers, some of them will find the vulnerabilities.  And if we'll take a look at long-term strategy and take a look at what the traditional IT  world has gone through, we have endpoint security and we have network security.  And the endpoint security is something sitting on the device in real time, capable of preventing  and detecting attacks, regardless if the device is vulnerable, regardless what type of attack  it is, and regardless of, you know, a secure design or where the vulnerability is.  Is it in the OTA or improper input validation, etc.  So for me, if you ask about what's the right approach, the right approach would be sustainable.  Meaning I think secure design is cool.  I think penetration testing is cool, but it will never be sufficient.  You will never have 100% vulnerability free device, especially when you use third party  code.  So I don't know how much static analysis or vulnerability assessment tools you use, but  they are not very good at finding vulnerabilities in binary code.  They don't.  And source code is not the only thing that goes into your device, not to mention hardware  components that have software within them.  So your Wi-Fi module or Bluetooth module, it contains vulnerabilities as well.  You have vulnerabilities on the chip level.  So in my view and in my opinion, only something that's operating in real time, capable of  verifying the integrity of the device, capable of preventing damage, data theft, or basically  preventing attacks, or on the other end, also monitor the device.  Meaning you need to be alerted if something bad happens or maybe happens.  This is the approach that I believe in more because I think this is why endpoint security  has been so strong for many years now in the traditional IT space.  And I think this is where IoT and IOMT should go to.  And obviously there are challenges in installing something on those devices.  They are low resource, they are real time operating systems, they are diversified, they  are extremely different from traditional cell devices or pieces.  But this is where innovation comes to the picture.  I think we can solve this problem.  I even think that we have solved part of the problem for sure.  But I don't think that this challenge should keep us from putting something on the device  to protect it.  We should just do a breakthrough in how we see endpoint for IoT devices.  Yeah, so I totally agree with what everyone is saying.  Something dawned on me the other day.  If we look at the longevity of medical devices, for example, could be a decade.  So if you look at just some of the statistics, 600,000 medical devices implanted yearly in  the US, well, those will last 10 years.  So if you start adding the numbers up, you're dealing with an ocean of legacy devices that  at one point in their lifetime will be vulnerable.  And it's not technology that you can rip out of your body or some people only can have  that monitor depending on what device you are talking about.  But those things are built to last for a long time.  So any solution will have to be a multidisciplinary approach, eating it from all sides, but need  to grow with the device.  Need to be updatable, need to be changeable, and basically grow with the times when the  device is really caught.  I'm glad you brought that up, V. So I'm interested and I'll go back around the panel and start  with Pete.  How do we approach this legacy device problem?  I think V already teased out the updateability and forecasting of the lifecycle.  But we have a lot of legacy debt right now that we're dealing with.  So what are some ways that we can work through that?  Pete, I'll start with you.  That's a super challenging problem.  I think there has to be some preparation for worst case scenario and worst case scenario  being think about the attack surface.  If that case is disabling radio connectivity on some of these things, working with some  of the medical device manufacturers come to learn, this isn't a software change for a  website that can be pushed into the CICD pipeline and show up in 10 minutes.  This takes legal and regulatory guidance and preparation and submission to the FDA.  That can take a long time.  My suggestion is prepare for those scenarios now.  Get ready for how do we do this if we have to?  Because the reality of ex-planting devices from hundreds of thousands or millions of  people is completely untenable.  So how do you get... I realize that maybe there's going to be an inherent trade-off  and quality of care provided.  That's probably a situation you get to only as a worst case scenario.  These devices keep people alive and that we want to keep enabling that because as Vee  mentioned, these are things that some people wouldn't be here without those things.  We don't want to instill the wrong level of fear, but planning for those scenarios now  so that if those need to be enacted, I think is one of the only things you can do for the  legacy devices that don't have an update mechanism.  If they do, setting up the testing for this now and being ready for it, it's an inevitability.  It's a when, not if.  I think what we are doing together with Metronic, I think Metronic is a true pioneer in this  support to legacy devices as what we are doing together, installing protection into five  years old device, I think is five years old, enhancing the security in field, getting visibility,  getting protection into really old medical device using the OTA.  I think it's a true innovative play and I think that I truly support this kind of acts  and I think that I have a lot of respect to Metronic in being pioneering doing such a  thing.  I think we can learn from it.  I think we can provide enhancements to existing device flits.  Of course, with the right controls and the right MDM to take it to the next level and  to move forward.  It's a good example of what we are doing together and I hope that we could pave the way.  Absolutely.  Baby steps in the journey, but exciting stuff.  I know you have an opinion on this.  I always have.  You're good.  You're on mute.  Back on mute V.  Oh, goodness.  I'm having audio issues today.  It's like the audio day over how old.  My feelings on this is we can't even start facing the legacy problems until we stop making  stupid decisions and choices going forward.  We have to now nip this in the bird and say, going forward, we're going to do better.  I haven't looked into lots of the things I've Googled it.  I have read up on it.  I'm very excited about what you guys are doing with Metronic.  That certainly is a step in the right direction, but visibility is key.  Pete and I have had discussions.  It was like, we don't know if the ICD or pacemaker has been attacked.  Do you even have the data to know that that's happened?  We want to deal with legacy.  We need to start getting visibility moving forward because otherwise we're adding this  amount of, another year goes past.  Now we have another group of legacy devices that's going to haunt us for 10 years.  Get a drive going forward and then start dealing, finding solutions for those devices  that you don't have visibility on.  Find ways to get eyes on your products and your data because where you have a blind spot  is most likely we're going to be attacked.  It's not like a nation state actor is going to say, you know what, I have owned your product.  Right?  Researchers have the courtesy to come, you know, to have a discussion.  Very bad people looking to do bad, bad things aren't going to have that discussion with  you.  You're not going to know they're there.  You need one patient to have your device and they get attacked and they ultimately pay  with their lives.  I can tell you, you're going to have a string of patients wanting to explore on their devices,  which is why something I don't want to have happen.  It scares me because I look at where I was at 19, where I am now at 33 celebrating my  birthday, having two kids, having a master's.  Thanks to a device, it kept me living.  Right?  Otherwise it would be dead.  It was as easy and as plain as that.  It added years to my life I was not supposed to have.  Take that technology away and as a human race, we go backwards.  So patients need MDMs.  Whether people in the security want to see them as an adversary, there are people like  me that rely on them to develop the technology to keep us alive.  Right?  It's important to understand that it's a love-hate relationship.  We're not all going to do it right, but if we can have the conversations and we can fight  it out and we can find the solutions that are super cool and super techy and super  new, we should try them.  Right?  What I think Sternum is doing, what Pete's doing, is hitting the same problem from a different  side.  I'm concentrating more on how do we detect and log these things?  How do I investigate it?  Mark and I have eyes on the prize sooner.  That's my passion point.  But we're all effectively covering this from a different side, which is good because all  sides are vulnerable and all sides are needed.  I think you're bringing it all together.  How can we get better visibility?  And Natalie talked a little bit about this, but I'd like you to go into more detail.  What are your thoughts around proactive controls in the post-market, which is the term we just  use for detection, logging, monitoring?  I know we've thrown surveillance out there, but to be more in line with the community,  it's incident response.  It's logging detection, that capability.  So how do you see proactive controls fitting into that model?  Yeah.  It's a great question.  I think I want to learn from other industries, which already developed into these directions.  So you don't see devices today within enterprise or in cloud infrastructures that are not monitored  actively, that do not pop up alerts when something suspicious is happening.  And I see the medical space behaving the exact same way.  I think with solutions, I won't mention ours, but I think there are many solutions that  can do that, provide monitoring and visibility into the device itself.  And then I think that this kind of information and incident response should go into two main  personas.  One is the product security in the MDM.  Monitoring is distributed device fleets, understanding if somebody is researching this device, selling  the device on eBay, maybe trying to hack into the device, stealing information.  This kind of things can be visible with the right controls.  And of course, there is a technological challenge of supporting all devices, all code base,  which didn't come with visibility inside without logging, without monitoring, but that can be  fixed.  It can be installed post market, and it's even easier to install it pre-market.  The other persona is the hospital, the clinic.  Those devices that if they come with built-in protection and monitoring, they can be the  eyes of the hospital for a beginning of an attack attempt.  Imagine an attack attempt just a month ago, there was a ransomware attack on hospital  starting for a remote patient monitor.  So the hacker penetrates to the internal network through the vulnerable IoT device.  So imagine this device transmits information.  Imagine this device is capable of detecting the attack attempt and even preventing it.  Not only you prevented the attack, the hospital, that moment become aware that he is under  attack and can act accordingly to secure other devices, maybe un-patch devices.  So you don't have to have all the environment protected, but as you have more devices that  are transmitting, visible, protected, you have more visibility into your entire enterprise  or hospital and can respond accordingly.  So I think both personas benefit from this kind of visibility.  And I think moving forward, we can use these kind of tools to embed security and visibility.  And I'm making a difference between the two because the kind of solution that I see in  mind is first a deterministic solution to prevent attacks in real time, prevent the  damage because in medical devices, there is no time to waste.  A successful attack could lead to a little resorts and you don't have enough time to  detect the attack and respond in a week or two weeks.  Because in enterprise, it takes six months to respond to a security incident.  You don't have this kind of time in medical devices, so you have to block the attack in  real time.  The other aspect is really to become aware.  And to become aware means to get alerted when something is behaving differently or suspiciously  or if there were a prevented attack attempt.  And once you are aware that this kind of attack happened, let's say, in the US and you have  devices that you can't update in another country with the same vulnerability because you know  what the vulnerability at this point, because you have visibility into it, you are capable  of providing fast response to alert your patients, to alert the hospital, to update the devices  with a patch.  So I think it's essential thing that we need to embed into the medical space.  And we are on it.  I love doing that because I think we're starting our journey to improve our visibility, improve  our prevention in near real time, improve our detection capabilities.  But we've thought into the future and how we need to better partner with healthcare delivery  organizations, hospital systems, and provide some of that information to the example you  gave about the ransomware outbreak.  And having dealt with brands and one of myself in a past life, obviously time is of the essence.  And that's something that we'd love to be able to help out with as an MDM in the future  using these techniques and tools that we're talking about today.  So V, I want to switch gears a little bit.  We're talking about all different types of aspects of security controls and capabilities  to give back.  But you have a unique forensics background.  How does that make you approach device security differently than say the traditional vulnerability  disclosure scenarios?  Yeah, so I think forensics is this unique focus on scientific processes.  I think that's the one thing that was hammered into my head is we need to follow a scientific  process.  So you need to look at it from every aspect.  But I was doing forensics for eight years straight, solely focusing on that and realizing  that I wasn't quite understanding all sides of it.  So I always say, we have a saying in forensics, we find the truth.  So we reconstruct what happened.  So I decided to actually start retrieving.  So to learning how to attack.  And then I learned how to defend.  And then I learned how to investigate.  And taking that, I decided to start applying that that type of mindset of taking a multidisciplinary  view to things to saying, OK, well, I want to know if we're being attacked.  I'm kind of tired of having it told to me that we don't have any data that supports any  attack.  And now knowing that we don't have the data actually available.  So to have more visibility, we can start seeing whether devices are actually currently  being attacked.  Because we don't know, I spoke to multiple coroners around the world through law enforcement  agency contacts.  And the question I said to them, if you have a cardiac patient that has an implantable,  right, they've passed away.  That doesn't necessarily mean that it's suspicious circumstances.  But do you do get a program, pull the data, look for the time of death, look of any strange  activity surrounding the device itself?  And I realized that, yeah, the devices get sent back to the manufacturer that does basically  a memory review to see that everything is like it should be.  But people forget that programmers can be compromised and something can happen from  a programmer to a device.  And we don't leverage the information that we have.  So the important thing for me is we have no ability at the moment, unless a researcher  comes to an NPM or someone makes a grand gesture that they've had to device, unless it causes  chaos or becomes public.  Somehow, we don't know.  And that makes me uneasy as a forensics person.  Because forensics, we want to know.  We want to know the bits and bytes of how something functions.  Men the local principles, a big thing that I live my life by.  So everything that comes into connection with each other leaves a trace evidence.  I want to know what it is.  But if we don't have visibility, right, it's there, but we don't have the capabilities  to make it visual.  So I want to learn more of what we have, what we need, and what we need to do to kick ass  to get there.  So that's my approach to what I'm doing with Metronik is I'm assessing what you have.  What we need and willing ass to get there.  And I'm seeing it come together with the various aspects of you guys have brought together,  you know, covering it from different angles.  And the forensics in me is like saying, we can apply forensics in development.  You know, we can apply for instance, extreme market, post market.  It doesn't necessarily mean it's an investigation, but it's creating the evidence that we need  for the future.  It's creating the data now for when we do need it.  I'm always drawn to the example of Microsoft and how they used other data sets to detect  a large Windows vulnerability.  And I think really was mining data in Windows event reporting.  And I know that a big piece of what we're thinking about is we have a lot of remote monitoring  information.  We know what is above the line and what's below the line.  And we're trying to develop, you know, that anomaly detection there.  And it can't only be done, right, with that type of detection.  That's one leg in the stool.  But as we look at on device agents, as we look at other ways that we can pick this up  with our fleet distribution infrastructure, I think that really has to come together to  get this full picture.  And all of you have hit on that element.  And I think it's not to discount testing or threat modeling, all of that has to happen  as well.  But we really want to emphasize this prevention in real time and then this detection of the  current devices and fleet that are legacy and are out there live today.  And what can we learn from that?  And I just, I really think that's important.  And all of you have been bringing a different element of that to this discussion.  And it's, it's helping us, I think, learn as a medical device manufacturer how to handle  this situation.  Yeah, I'm always sorry.  I'm sorry.  We should I always say data doesn't lie, right?  It always said, there's a saying that follow the money or follow the evidence.  But we have so much data, we're just not mining it.  We're not learning.  I think it's one of your members Sasha that said, we know, we need to learn to listen.  Right.  So we need to learn what the data is telling us.  And I think that's the big thing.  We have all this data, but we're not listening to it.  And once we start intuitively tuning in and understanding the data, those numbers don't  lie.  Then actually, I think an MDM can only really do straight analysis.  Because if you don't know what you have, how do you know what to protect?  Because then you're always on the back foot.  Right.  You need to get ahead of the problem.  You need to know where you're most vulnerable at.  You shouldn't wait for that to become public knowledge.  So I want to shift gears one more time here.  Here the concept of zero trust in medical devices.  And I've talked to, I believe each of you are on the same topic.  How do you think that can be, that concept can be applied from an MDM perspective or  from a medical device perspective?  And I'll throw that out to the group whoever wants to latch onto that one can start us off.  Okay, I'll roll with it.  I was waiting for you.  I know you got to be like, go ahead.  I love zero trust.  It makes me excited because for once we turn insecurity on it and saying, we're not going  to trust but verify.  That's not going to be, which is not going to trust.  Because the nice thing about zero trust is you can actually understand devices.  But the ideal thing is now we don't have a perimeter.  We harden everything.  We probe a device and if it meets the specific standards, that device is allowed to have access  to the minimum it needs access to.  Right?  It's like a patient monitor that doesn't have to be on the wifi and doesn't have to  link to the accounting system or the patient records.  We have this thing trying to make everything accessible but too accessible.  We take it to the extremes.  We either make it too secure and unusable or we go to the other way.  But zero trust has really big plus points for me because now we can attend to device manufacturers  independently.  We're not going to have the same controls across the board because everyone builds their  devices different.  You can understand the device and apply the appropriate rules, privilege and access.  I think this is a really good solution as we move to a perimeterless remote monitoring  and medical service.  I had my first video consultation today which is something very strange but yet it felt  normal.  The perimeter has just been broken.  COVID-19 came in, swept Kalske off its feet and we are facing new territory.  We're having to build while trying to catch up.  This virus has crippled health care and I think security should never put such a strain  on health care that could cripple it more.  We should be making it safer and easier to use.  That's our responsibility as security people in this field.  It's the responsibility of the MDM.  Zero trust is the ability to do K-TED security based on a device, not necessarily the same  rule for everyone.  I'm very excited about it.  I agree with you and I have a slightly different interpretation of zero trust in the concept  of medical devices.  For me, zero trust basically means we talked earlier about third parties and we talked  about embedding communication models within the code and communicating with the patient's  mobile app and the patient's maybe home router, each medical device with its communication.  I think zero trust should really mean that we can't trust any of those.  We can't trust any of the third party open source, closed source embedded.  We can't even trust the operating system that a medical device use, whether it's commercial  one, Linux based.  We should be expecting vulnerabilities throughout the entire supply chain.  The code, the hardware, the software within the hardware and of course we can't trust  that the patient didn't install a malicious application on his mobile.  The last thing we want to trust is the human being not making mistakes.  For me, the concept of zero trust basically means that the kind of security that we choose  to implement should take all of this under consideration and to make sure that we keep  the integrity of maybe not the entire device, maybe it's impossible, but essentially the  critical operation of the device should remain secure regardless of all the things that I  mentioned.  Like if we talk about insulin pumps, so you want the functionality of injecting insulin  will be the most protected functionality of the device.  Same goes for personal health information on the device itself.  For me, zero trust basically means taking this into consideration when designing a security  solution.  Exactly, I like what Natalie said.  I think it's the difference in design.  I talk about this all the time, every time someone will listen.  I look at it as a concept of, I think a great example is like cars.  When the systems were built to allow a computing interface in a car, they weren't connected  to anything.  They designed according to that.  They scaffolded this over years.  Then all of a sudden someone came along and tacked on internet connections and Bluetooth  and Wi-Fi.  What you should do is go back and redesign everything to consider that new approach.  The zero trust concept to me means we think about it from the initial idea stage of defending  it in every place it can be.  It's an analogy to what Natalie and V were saying about no one operational environment  is any more or less secure than any other one because they're all the same.  Everything to consider that takes concerted effort from the start, from the very, very  start.  I think approaching the problem from that way is another one of those shifts that we  have to consider from legacy devices into what is going to be the new normal for this.  Everyone's going to have to get there.  The quicker a manufacturer of any kind of product you can start considering that, the  easier their life is going to be in the long run.  I must add just one thing about that because I think we are repeating a lot of thought.  Think about it in advance.  You have to design it.  I must mention the other side.  Security has always been the last part to be incorporated into things.  Everybody would like to go to market faster.  Everybody likes to just build their devices, build their technology.  Nobody likes to think about security.  I'm saying it's okay.  I don't want to say you have to think about it in advance.  You don't.  History teaches that nobody thinks about everything in advance and it's okay.  Security comes last always.  So for me as someone who is looking for solutions and not just looking to emphasize the problem,  I'm looking for solutions that can be developed and installed even if you didn't think about  security.  I have to say, again, it's the best thing to think about it in advance.  But I'm just saying it's okay if you didn't.  Nobody holds you responsible.  I will hold you responsible only if you didn't try to fix it later on.  I have to disagree there.  I want to kick an Indian's ass and say, what the hell are you thinking?  Oh, let me think.  You're right.  That's what happened there.  It depends.  It depends.  If you have hard-coded paths for like one, two, three, four, then this is the place where  you can think.  What the hell were you thinking?  But I'm just saying, the more advanced stuff, it's harder to think about.  Yeah, so it's a two-fold problem.  We dealing with legacy.  I call it the legacy because that's what it's written in, that joke for the evening.  The problem is we have to stop developing legacy problems.  So we need to address it ahead of time.  But okay, we have to face the fact that previously we didn't address it ahead of time and there's  nothing you can do.  Can't pull these things back.  Can't tell me you're going to cut me open, take my device back, give me a new one.  I'm not going to let that happen.  So we have to deal with that.  It's a two-fold problem.  We have to be realistic.  I think you are completely correct, but realistically looking ahead, I don't think we're going to  be thinking about it in advance in the years to come because new problems will appear.  And like in the 50 years prior to where we stand today, companies didn't think about  it in advance.  So we can teach that.  We can say that.  But to be realistic, I don't think it's going to happen.  People will only handle the problem once it bites them in the ass, basically.  You know, it's human, right?  I can't disagree with you because history often repeats itself.  I think what's interesting is recovering it like a triangle from different sides, which  is very interesting.  I'm concerned with we have these devices that are diversified.  How do we include this on a healthcare network?  Right?  NACI's product literally deals with legacy devices and new devices.  And the solution covers it from a different angle.  So it's just like diversified opinion that's doing the same thing, but each in a different  way.  And this is why I think researching is important because we all think differently.  So it's having, yeah, it's a big problem.  It's massive.  I think we're, yeah, I agree with what you're saying.  We're all kind of coming at it from a little bit of a different perspective.  And I do agree, Natalie, that like there's going to be new attacks we haven't thought  of today that come out in the next year, three years, five years.  But we're talking about medical devices today.  And I think we absolutely have to require better work on the design.  We got here because of the evolutionary walk of how medical device manufacturers built  businesses to help patients and computers came part of that and here we are.  How we go forward though can be changed.  And I think the idea that we'd be accepting to someone not working hard at that right  now is dangerous.  I agree that we need to have things on the other side to prepare for the inevitable,  the new things that come out that we haven't thought of the next thing that shakes the  industry so to speak.  And we want to be resilient to that.  I completely agree.  But in one case when I was looking at a medical device, I then started reverse engineering  in e-bike.  And the e-bike was orders of magnitude better because the e-bike wanted to prevent someone  from bypassing the speed controller and going too fast in the bike that it wasn't regulated  for.  And they did a tremendous, they did an incredible job for that.  But seeing the stark contrast between those two, the difference there was they designed  it to be that way.  And I know I harp on that a lot, but I think that's an important point.  I think we can all agree that there's some fundamentals that we need to align with.  I think this is why we want this diverse experience background, opinions, because it helps us  grow in the industry.  And we have time for one quick final question here, and I'll go around the panel and start  out with you, Pete.  How can researchers, smaller shops, those attending the biohacking village, get more  involved with device makers?  The way I did was eBay and calling.  I think there would be a lot that could be drastically improved.  If there's a way to get your hands on research devices to start learning this space, one  of the challenges I think newer people to working in medical device research are going  to run into is becoming aware of the monstrosity that is an MDM.  And something like when you find a bug and you suggest a fix for it, the reality is its  scale of making that happen.  So on one hand, I would say it would be wonderful if MDMs would start exposing programs for  researchers to apply to and be selected to start working on this stuff.  And on the other hand, I think there would be a great spot for education on the MDM side  to show what is it we're going to do.  We need to do a hypothetical patch to this hypothetical device.  What does that actually look like?  The legal ramifications, the regulatory ramifications, because without that information, a lot of  security researchers I think will be frustrated at the timeline it takes because they don't  have any sort of understanding of what's really happening, especially coming from a  place of the hacker ones and the bug crowds where that's a pretty smooth process when  you're looking at web properties.  And it's a very, very different industry.  It's a very different threat model.  It's a very different process.  You have to go through and I think there's an education opportunity for that.  Natalie, I know you've had your journey with medical device manufacturers.  Same question to you.  How do you think that researchers in smaller shops can get more involved in making a difference?  So I completely agree with Peter and I think that bug bounties programs and exposing the  inner processes that's happening within medical device development, which is extremely different  from traditional development with different regulations and different constraints could  help getting more engaged.  I think assigning a person or a unit responsible for that is also super important in some of  the medical devices.  You just don't know who's the right person to approach.  It's not the CISO.  The CISO is not concerned about medical device security.  It's concerned about the network.  So I think getting this better approach is good.  Transparency is good.  Basically saying, hey, we want you involved.  We're okay with it.  We're not going to send you some terrifying legal documents if you find something.  This can be helpful.  And I think the research community maybe thinking about it in a different direction can also  help educate.  Meaning I think that what we sometimes do, we go to medical devices.  We do some exploitation workshops.  We explain what vulnerability means, how to exploit vulnerabilities, how to write code  with security in mind to avoid vulnerabilities.  We had this experience with Metronik as well.  It was amazing.  It was super satisfying for us.  And I believe that it was also interesting for medical advice engineers and software developers  to suddenly see the other side of the code and the other side of what can be done with  the code and how devices are being exploited can also raise awareness and can also help  them understand what the researchers are doing and why they're doing that.  And this could really be like open mind and open hearted conversation which we had.  And I think is a great example.  It's not very common.  I mean, device manufacturers, OEMs, some of them do not respond well when researchers  approach them with vulnerabilities.  And I think positioning yourself as an MDM saying we respect that, we would work with  you is amazing and it's the right approach.  Last but not least, V, you get the final word.  Oh, awesome.  I'm going to do a call out to all my fellow biohackers, my friends, my goons, my family.  The biggest thing I've learned that the constraints we're dealing with vulnerabilities from an  MDM's perspective is when you do a proof of concept, approach this like a report, approach  it like scientifically, give us much information, as much code as you can for the MDM.  They need to verify what you have said.  And if your document doesn't consist of information that is comprehensive and easy to follow, they  are going to have to reverse engineer things themselves.  And then the 30 days that you expect to get back from them, it's going to take them 60  to 90 days just to figure out whether it's applicable to their product.  So if you come with a problem, come with a solution.  Let's not just focus on what we've broken.  Let's try and fix it.  So my challenge to all my hacker friends are, let's not just try to break things.  Let's try and solve things.  For me, the term hackers, obviously sometimes associated with cyber criminal.  And for me, it's a passion point because hacking is what I do.  I'm not a criminal.  I try and figure out what's wrong so that I can fix it using alternate ways and means  of thinking.  That's what a hacker does.  That is what a hacker is for me.  But we're also scientists and in science, we need to be thorough.  We need to do the project better.  And for an MDM, it won't be such hard asses.  We're trying to help.  I promise you, we're not your enemy.  Just be a little bit nicer.  I have a conversation.  Buy someone a coffee.  If you see someone at Biohack Village, I promise you, I haven't had a hacker that bites unless  asked to bite.  We don't like having teeth.  We like having tech conversations.  And we like geeking out with you.  But it comes from both ways.  We both need to open our hearts and open our minds and realize we're working towards the  same ideal and working against each other is not going to get us there any sooner.  And from a patient's like, keep on doing the research.  Make this stuff better.  Because I think either part, you need to each other.  It's a trifecta.  It's the medical manufacturer.  It's the researcher and it's the FDA or the regulatory body, depending on where you're  from.  Those are the things that are going to make the future better.  And those are basic engineering practices.  A triangle is the strongest thing you can enforce something with.  So let's enforce this with teamwork.  That's all I have to say.  V out.  With that, I want to thank the panel.  Drop the mic.  Pete, Natalie, V, we're good to go.  Have a good DefCon Biohacking Village, everyone.  Thank you.  Thank you very much.  Cheers.
DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_0_47.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_48_107.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_108_167.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_168_239.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_240_299.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_300_755.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_756_815.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_816_995.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_996_1691.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_1692_2015.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_2016_2135.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_2136_3419.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_3420_12515.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_12516_13031.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_13032_28187.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_28188_33299.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_33300_34907.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_34908_35459.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_35460_36335.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_36336_36599.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_36600_36923.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_36924_42899.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_42900_52043.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_52044_53243.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_53244_55643.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_55644_55967.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_55968_56027.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_56028_60551.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_60552_60599.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_60600_62363.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_62364_64523.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_64524_66455.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_66456_66647.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_66648_81599.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_81600_83963.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_83964_84011.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_84012_85439.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_85440_91607.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_91608_91907.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_91908_92219.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_92220_93575.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_93576_93623.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_93624_95663.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_95664_95771.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_95772_96551.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_96552_97211.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_97212_99431.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_99432_102107.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_102108_102179.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_102180_102239.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_102240_103463.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_103464_104711.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_104712_104783.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_104784_105635.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_105636_105683.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_105684_106667.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_106668_106727.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_106728_108119.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_108120_108467.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_108468_109799.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_109800_110123.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_110124_110891.png DEF_CON_Safe_Mode_Biohacking_Village_-_Panel_-_How_nDXS19Dpa0A_110892_114254.png
All right, well, welcome folks. It's my pleasure and honor to introduce some great friends of mine. They are all hackers and we have our moderator today. I'll do a brief introduction for him. But first and foremost, welcome to the biohacking panel. How independent security researchers vis-a-vis hackers work with MDMs or that notorious medical device manufacturer. This is the bad, the ugly and the great. Also affectionately known as bug. My name is the red dragon 1949. You know me as the volunteer coordinator. But more importantly, I'd like to introduce you to the panelists first and foremost ladies first. We have Veronica or B Schmidt yesterday was her birthday. So happy birthday V. She is a former federal law enforcement in South Africa. She has done forensic investigations. She is a cardiac implant patient three times and she's doing some great forensic work for one of the MDMs that will be showcased here at the biohacking village Medtronic. Second, we have Miss Natalie Schuva. She is the CEO for sternum out of Tel Aviv Israel. She comes to us from the unit 8200 of the Israeli Defense Force. She can do things remotely with a mobile phone and the applications that are fascinating and yet scary at the same time. So welcome Natalie. And then last but not least, we have Mr. Peter Morgan out of San Diego, California. Mr. Morgan is quite how shall we say effective at basically taking a medical device down to its very fundamental binary level and doing things with it that would surprise you not only from a software and a firmware level, but certainly from a vulnerability exposure. He has notable common vulnerabilities and exposures to his name associated with some metronic devices. So welcome Peter. And then last but not least our moderator, Mr. Kyle Erickson. He's the director for product security engineering with the cardiac rhythm heart failure business division at Medtronic out of Minneapolis, Minnesota. He has extensive breach and incident response experience with one of the largest healthcare organizations here in the Minnesota area as well as globally. So he has faced some of these individuals on the panel that he's going to be moderating. So welcome Mr. Erickson. I will turn it over to you. Thank you Red Dragon for those great introductions. I have the luxury to be here on the panel with Pete, Natalie and Vee. And I'm really excited to dig into their story and learn how they've been working with medical device manufacturers, what medical device manufacturers can do better and what we're working on to improve in the industry. So I want to start out with an origin story. And I'm going to start with Natalie. Natalie, what makes you a hacker and how did you really get involved in the security movement around medical devices? Yeah. Well, I actually don't refer to myself as a hacker, but I can tell you basically my story. I grew up with four big brothers and started my undergraduate degree at the age of 14, computer science. It wasn't just weird because I was 14. It was also weird because nobody in my family ever went to college or something like that. So I was like the black sheep in the family. And once I graduated, then I just started my period in the Israeli unit A200, one of the elite technological units there. And this is where I got exposed to cybersecurity, low level development and research and exploitation in general. We did some significant things in the unit, handled the most advanced techniques and technology. And after the period of time there, I wanted to keep using cybersecurity to create impact. So during my time in Cerebrite, I did a lot of vulnerability research and exploitation, mainly on Linux, Kerala and Android platforms. And I didn't consider it as being a hacker, but mainly to provide evidence to stop pedophiles and human trafficking and stuff like that because using the vulnerabilities and exploitation we were able to extract forensics and basically evidence from the mobile devices, including encrypted ones. So for me, it was the passion and the impact that such tools can create. And the medical device was actually not a coincidence. I was always dreaming and thinking about becoming a doctor. So when I finished my master's in computer science, I figured that this is like my last opportunity to go into the medical industry. I thought about starting medical school, but with the knowledge I had in cybersecurity, I met with a few friends and entrepreneurs and one of them is my partner, Boaz, and we started thinking about medical devices and cybersecurity. And when I saw that remote care and remote monitoring could have such a tremendous effect on our lives and they were not properly secure, this was something that attracted me tremendously because I figured that creating the right security to these devices could really improve patient's lives and improve quality of care and treatment. And I saw how the knowledge that we have from the cybersecurity industry could leverage this kind of technology. And this is what actually attracted me to Co-Front's tunnel. That's excellent. Obviously, you may not call yourself a hacker, but you have the tactics, techniques, and capabilities. So, V, I'd like to go to you. And obviously, we know you have a unique story. You're not only a hacker, a researcher, a goon, but you have a implanted medical device and refer to yourself as a cyborg. So why don't you just give us a little bit more about your background and how you've been getting more and more involved with medical device manufacturers in the industry? Yeah, so I wasn't a very good hacker when I was a child and I basically got court changing records at school because I felt everyone should have a good year. Unfortunately, that led me down a path that my parents weren't very proud of. But going back at the age of 18, I joined the Special Investigation Unit, which is a law enforcement agency that deals with cross-border human trafficking, child pornography. Some really nasty things. We actually made use of celibate, so I'm very familiar with what Nati's referring to. And let me tell you, if you want to get a physical image of those things that they develop, are key. But at 19, I also had about approximately two weeks left to live when I got my device implanted. And I know the quality of life that it gave me. But since then, I was obsessed with what my device does. For the pure fact that I believed in the same trust but verify, but I could never verify what was keeping me alive. And that was the biggest, greatest frustration. I reached out to you guys about three years ago and I was met with the ugly part of Metronics, sadly. I got met with the legal team. And I felt that the conversation wasn't going very well. I remember these words and Toro that used to work with you, knows this well. I said to them, well, if you want to bring your lawyers to the table, I can do the same and then we can have a conversation. But that's where it ended. And Inwood's Biohack Village three years ago, Nina being forever the master planner put me on the path for gold. But then I came to severe loggerheads last year because he could not confirm to me that he was from Metronics. And though I knew he was and we went at it and we had our conversation and fast forward a couple of months. I'm now finding my feet within Metronics and doing research into early detection because I didn't want to focus on the problem. I want to find the problem and then solve it. So it's not just about whether the device can be hacked. We all know everything can be hacked, but it's actually about having some tangible evidence to deal with to early detection to mitigate it. For me, literally close to my heart is the embedded implanted devices that are often misunderstood, forgotten about. And these are the things that are connected to people, flesh and bones. And I just decided to take this on and put my story out there and say, you know, these things are cool, but they also scary. But that doesn't mean we need to go in the internet. It just means we need to do more to make it safer. Absolutely. And we're glad that we can make some inroads there. I know it's been a journey to say the least. Pete, you've had a similar journey. I'd love to just kind of hear your origin story and what got you interested in medical device security. And not only do you have vulnerability discovery on your side, you've also looked at solutions and improving the problem. So give us your background. Sure. So I started out as a kid learning how to hack video games and change them before the advent of client mutual authentication. And that really got me hooked. And as I grew up learning about software development, networking, reverse engineering, exploitation, going forward into things like software to find a radio and actually understanding RF better. It was kind of like I picked up these skills along the way. And as I was able to escalate in the career path and get better jobs, I finally got into a spot where I was able to affect what direction our team was going. And previously, I'd spent some time at a hedge fund kind of protecting a billionaire, making sure their billionaire is still worth billions. And there wasn't a ton of job satisfaction out of that other than the interest of how that works. And I got a project at doing a small medical device in a consulting relationship. And it was really neat because the problem set was really interesting from the requirements that how these devices operate, the conditions they have to operate in, the battery life, processing power, all this kind of stuff gives really interesting constraints. But also when you make improvements to something like that, it has a direct impact on people's lives. And it was a lot more interesting to work on those types of problems. That's when I kind of started just doing some research on some of the metronic gear and was able to publish some vulnerabilities after maybe an ugly or bad initial interaction that then turned quite positive. And then one of the things I'm most proud of, I think, is having the patients to work through that process with metronic. And then end up in a productive working relationship where now I do get to work on solutions and help with fixing things, not just identifying issues, sending a vulnerability report and walking away. So that's been really rewarding. Absolutely. And we thank all three of you. We've all been influential in the journey here as MDMs have progressed and adapted and understood that there's a problem, but also looked to solutions. So Natalie, I want to come back to you. I have a specific question and just it's more around military grade technology and techniques. How do you think that can really help secure medical devices and the infrastructure and hospital systems that they reside in? Yeah. Well, I think many times in the history, we saw that the military developed one of the cutting edge technologies in many areas in the industry. And as part of it, I think that security techniques are also well developed within the military. And when you talk about military grade security, I think this is what we want for medical devices, right? Because you don't want your security camera be protected the same way as your pacemaker. I think medical devices do require some higher extent of security and deeper level of security. And I think what we see in the military is wide range of attack scenarios and attack techniques and exploitation techniques. And you realize that for me, at least securing medical devices just by doing vulnerability patching or penetration testing or avoiding hard-coded password, it was not enough because I know and I'm familiar with how you can bypass those things pretty easily. And I think that taking some of the knowledge and basically military grade techniques can help you understand the kind of holistic and comprehensive security that these devices deserve. And one of the things that I think was significant in our way of thinking is that even if you secure the MDM's code or doing some vulnerability research or pen testing, it's not enough because those devices contain third-party code as well. And Ripple 20 is a great example, right? We see a TCPIP library affected millions of devices, power grids, medical devices, and most solutions today just can't handle third-party vulnerabilities. You can't really protect against vulnerabilities that are within code that you didn't develop and you don't have the source code to. And I mentioned in it because that in the military, we handle the lot with binary code and with embedded systems and with the ability to reverse engineer other people's code. And actually, we are leveraging these kind of techniques in our philosophy to embed protections and security into these closed-source components because in my view, the MDM has to be responsible for the security of the device regardless of the components within the device. So we have to give controls to the MDMs to secure these third parties. And I think these binary-level capabilities are well-established in the military and can be used to holistically secure medical devices, and this is what we try to do. Excellent. I just want to say, Natalie, as a patient and as someone that's been shouting about this stuff very loudly, it's like you're serenading my ears at the moment. I'm all for what you are saying. It is solely the MDM's responsibility. They have to take ownership and responsibility of the take-play ball. Right? As a patient. I agree with you, but on the other hand, I must say it's not an easy task, right? Because the MDM, it's very difficult to secure third parties and there is no way to avoid implementing third parties within your device. So until someone wouldn't take the responsibility to create such controls for MDMs and to create the security products that they can use to basically protect their devices, we really can't blame them. But we do need to ask them to use the cutting-edge tools to secure their devices, and this is indeed something that I believe in. Yeah, to embedding the security culture and how we look at devices, right? But Metronik is a good example from those learning from lessons learned, right? They've come from a place where they were in a really bad position to where they are now, which is never an easy thing taking that ownership and responsibility, saying, hey, we need to do more. We need help. We can't do it on our own. I often say it takes a stronger person to say, hey, I now need help and go to people that can help them versus having the persona of I know everything, we are a big manufacturer, we can do it on our own. Which I've seen so many times. Completely agree with you. That's great. I want to pull on that thread a little bit, V, and just talk a little bit more about your patient-hacker relationship and how being a patient maybe changes your perspective on device security and how the more you've learned about how devices are built and a little bit more under the hood, how that's also changed your perspective. Can you talk a little bit about that? Yeah, sure. So that brings back a memory of mine. I think it was two years ago, February. I was actually in ICU where I had some issues. I had some device issues and I had to be resuscitated. But I was lying in an ICU connected to 15 different kinds of machines doing infusion, monitoring. I had a specific external monitor monitoring my pacemaker at that time. And I was offered guest Wi-Fi, obviously, because hospitals want us to feel safe and connected to the world. And soon realizing that these systems weren't segmented and that I could potentially may have or may not have access to the central station that had my vitals on it. But just realizing from a perspective of a patient how interconnected these systems are. And the more that I watch and just observe the world or even attending talks, I realize that the word medical device is exclusively used for anything in healthcare and hospital and anything that a manufacturer makes, whether it's a Windows 10 machine or versus a complex embedded system. And I think until we start understanding each system is unique, I say language, linguistics or when you have someone that you're observing, you try and observe them and learn what they are, how they talk, all those kind of things. But we don't do that with devices. And I think I appreciate what Peter does and what Natty does is reverse engineer things to understand how they work, not only at a firmware level, but at a file system level, at a binary level. And as a patient, I wanted to know what keeps me alive. I wanted to know what libraries were used, what hardware was used. And I did that through OSINT. I literally Googled manuals and for manuals, I've permitted to get more information because the manufacturer wasn't disclosing it to me even as a patient. But I wanted to know that I can trust my device because I've seen that these devices almost understood and implemented in a way where we build bridges or walls around our networks. But we're so soft in the middle, but we never considered them malicious insider, which is a big thing because I've realized that the threat from hospitals might come from within, especially with everything with COVID-19 becoming borderless. I don't know where the border stops or the perimeter starts and stops anymore. So I think it's just we need to take the time to understand the devices, learn their language, and understand their constraints because they're all different. I always say beautifully broken, wonderfully flawed, meaning we can have the most secure and perfect device. There might still be a flaw and it still might be broken, but that doesn't take away from the beautiful synergy that goes into these devices. I geeked out because I spoke to one of the engineers and learned what my functions on my pacemaker and ICD does. And let's just say it was like the moment we sat back and said, this is such a simple, complicated device. But I trust it. It's the weirdest thing, but I geeked out knowing that the maps behind it is so wonderful that in a nanosecond it raises my heart rate up. So I'm actually getting emotional. Excuse me, but yeah, it's a good thing when you realize that you can trust what's in you. I can trust that it's going to do what it needs to do. I must mention just regarding one thing you said about getting the hardware specifications the self-cursifications being exposed to how the device has been built. There are also downsides into publishing this information, meaning bad actors having this information very accessible, having them being able to see what kind of third parties and start looking for vulnerabilities or understand the specs and extract the fee very easily. You want to make it as hard as possible. So I do think that we need to keep some sort of balance between what information we put public and what information we maybe expose just under certain terms. So understand you as a patient wanting to know as much as you can about your implantable device, but imagine that bad actors could have access to this information as well. So just to clarify, the reason that I said I own Synthesis was before I spoke to them and then I realized that I could get all the information. That's when I went to the MDM, right? So I'm also that certain things shouldn't be on the internet. And this is one of the first things I raised with them. So when I met as a patient, I went to them, I was concerned. I was petrified because I managed to get technical manuals from technical manuals jump to hardware manuals, which led me to more information than I certainly wanted to find in an OSINT exercise. So yeah, that's what happened. And that's when the legal team slapped down on me and like, where did you get this information? On the website? Yeah, we had the same experience where they asked, where did you get the devices? And we're like eBay. We know about that. Yeah. But I think that underscores the point of, I mean, I could understand the request to have a balance, but the minute that comes out, you can't take it back away. And I would caution the idea that hardware designers, software designers that rely on the concept of anonymity and hiding specifications of the device may make worse decisions predicated on the idea that no one's going to know what the hardware is or what the, you know, what radio chip they used, that kind of thing, right? That's an exercise in time. And when you think about the lifetime of these devices, I just caution that concept because once that comes out, we can't take it back away. Yeah, I mean. Go ahead, V. Sorry. So, so Peter, I think you and I, I mean, I didn't have to go by my device. I just got it expanded, right? And I got the doctor. I'm like, hey, hey, hey, I would like my device, please. Can I, can I keep it? And they gave it to me. I mean, your story of course is way cooler. I mean, I didn't have to. Yeah, I was talking a little bit more about that. Talk a little bit more about that story. So I'm a little bit of an empathic person. So like awkward situations tend to land strongly on me, I guess you might say. And amidst doing some of the work I've done, I'd taken apart and reversed the majority of the home monitor device, but I needed to see live communications to understand what so the implications of that work. So I tried to get my hands on some implantables and I think it was like between 30 and 40 morgues and corners offices I called trying to get my hands on before basically anyone that did cremation, right, because they removed the devices before cremation. And it was some really, really awkward conversations. I got yelled at a few times pretty, pretty aggressively, understandably so. They didn't see what I was trying to do. But yeah, that was a little bit awkward. Yeah, you should seriously try going to a cardiologist office and they Google to you and they've seen one of your talks and you get specifically watched doing everything. Yeah, that's a different patient perspective. I am officially banned from all major hospitals in my hometown from having a laptop or even getting Wi-Fi access. I think they've gone tired of me saying, hey, we should fix this, right? Or me spending time fixing it for them and saying, hey, I fixed this for you. Here's the credentials go for a while. It's just that whole culture of when you say to someone, but we can fix this for you. It's not an insult. It's genuinely people or researchers wanting to make things better. And perhaps not having the social, I don't sometimes have the social cues like you would say people like I can totally imagine having those conversations with coroners. I think I wanted to be a fly on the wall for that. So as a medical device manufacturer, I think I'm internalizing two takeaways. Over-reliant security by obscurity, but also make sure you keep operation security in mind and you're not just posting manuals and details that can be found through open source intelligence gathering. So two takeaways right there. So I want to switch gears and go to you, Pete. We talked a lot about your vulnerability discovery. Obviously, we hinted at a few of the CVs and things that you brought to Medtronic. But how do you see the testing landscape changing for devices? And what should medical device manufacturers do on their own to learn from what researchers have done in the testing space? A great question. Well, I think the testing is going to have to follow the path of development. And one of the major things I see is very important for the medical device community right now is there's a lot of devices that have update functionality, but there's a very, very small percentage of actually use it. And I think there's an opportunity right now to fix that problem before it gets out of hand. Secure update is one of those problems that if you don't design that in early on, you can kind of lose control of what it is you're trying to work with. It's a perfectly right target for attackers, especially when it comes to low-power, questionably connected embedded devices. So I would stress, like as far as something to develop on, work on secure update and get that working immediately so it can be used. The more confidence you have in that part of the tech stack, the more able you're going to be to respond to things like security incidents or updates because of some binary or open-source package that comes in. And that kind of, I think, will drive a lot more of the modifications to testing that's going to happen. As these devices, we've seen a trend now for devices that use homegrown protocols and bespoke like radio communication systems to communicate, largely shifting over to using things like Bluetooth and something that's a lot more standardized that also tends to work with a smartphone. And as that happens, we're seeing a shift into a lot more open-source library usage in these products. Because that particular thing is a problem near and dear to my heart, we're working on a tool to basically audit the open-source ecosystem and mine for malware, mine for backdoors. The vulnerability space, I think, is kind of, well, people are looking at that pretty aggressively right now. But no one's approaching it from the concept of who are the authors of these packages and how they work together. This is going to land very important on the medical device manufacturer. When you think about, I spent a little bit of time in the defense sector myself, and when you think about how nation-states approach problems, there's a tactical and a long-term strategic goal to some of these things. And compromising the GitHub credentials of a developer that writes a package that's three levels upstream from something that goes into a medical device is a great way to lay in weight for access into an entire fleet of these things. And again, you think about that kind of problem without a good secure update mechanism, and now you have something that is irreversible. So I see this as the trend of development changes with medical devices. The testing requirements are going to change as well. I would love to see a universe where when a device is designed, there's audit. We have automated testing through like fuzzing of the protocol. We have knowledge of different aspects of this that we can bolster and use things like computers to help us and have that built into the design such that when before release, there's all these different tiers that have happened aside from just someone manually reviewing source code. That is still a strong improvement over requiring people to buy these devices or call corners offices and take them apart, dump firmware, reverse engineer it and try to find bugs. The more people we can get involved with this at a productive level, I think is going to be more valuable too. And that's I think a large challenge of the medical device manufacturer. How do you adjust the signal-to-noise ratio such that you're getting competent quality people that really want to help without wading through the deluge of things that may happen if you just bug about me, I would say. Yeah, I think there's like a diverse approach to this. I think in a prior life, you were at a boutique shop and we've used all different types of testing companies. We've internalized some of this, but even finding those niche boutique shops or those individuals I can really get at certain elements have really helped us I know. If I may jump in, as a person who researched many platforms that are highly secured, highly being researched, highly being fuzzed and pentested, including Linux kernel and iPhone devices, I can tell you that it's impossible to put a device out there without vulnerabilities. And once it's out there and you have enough researchers, some of them will find the vulnerabilities. And if we'll take a look at long-term strategy and take a look at what the traditional IT world has gone through, we have endpoint security and we have network security. And the endpoint security is something sitting on the device in real time, capable of preventing and detecting attacks, regardless if the device is vulnerable, regardless what type of attack it is, and regardless of, you know, a secure design or where the vulnerability is. Is it in the OTA or improper input validation, etc. So for me, if you ask about what's the right approach, the right approach would be sustainable. Meaning I think secure design is cool. I think penetration testing is cool, but it will never be sufficient. You will never have 100% vulnerability free device, especially when you use third party code. So I don't know how much static analysis or vulnerability assessment tools you use, but they are not very good at finding vulnerabilities in binary code. They don't. And source code is not the only thing that goes into your device, not to mention hardware components that have software within them. So your Wi-Fi module or Bluetooth module, it contains vulnerabilities as well. You have vulnerabilities on the chip level. So in my view and in my opinion, only something that's operating in real time, capable of verifying the integrity of the device, capable of preventing damage, data theft, or basically preventing attacks, or on the other end, also monitor the device. Meaning you need to be alerted if something bad happens or maybe happens. This is the approach that I believe in more because I think this is why endpoint security has been so strong for many years now in the traditional IT space. And I think this is where IoT and IOMT should go to. And obviously there are challenges in installing something on those devices. They are low resource, they are real time operating systems, they are diversified, they are extremely different from traditional cell devices or pieces. But this is where innovation comes to the picture. I think we can solve this problem. I even think that we have solved part of the problem for sure. But I don't think that this challenge should keep us from putting something on the device to protect it. We should just do a breakthrough in how we see endpoint for IoT devices. Yeah, so I totally agree with what everyone is saying. Something dawned on me the other day. If we look at the longevity of medical devices, for example, could be a decade. So if you look at just some of the statistics, 600,000 medical devices implanted yearly in the US, well, those will last 10 years. So if you start adding the numbers up, you're dealing with an ocean of legacy devices that at one point in their lifetime will be vulnerable. And it's not technology that you can rip out of your body or some people only can have that monitor depending on what device you are talking about. But those things are built to last for a long time. So any solution will have to be a multidisciplinary approach, eating it from all sides, but need to grow with the device. Need to be updatable, need to be changeable, and basically grow with the times when the device is really caught. I'm glad you brought that up, V. So I'm interested and I'll go back around the panel and start with Pete. How do we approach this legacy device problem? I think V already teased out the updateability and forecasting of the lifecycle. But we have a lot of legacy debt right now that we're dealing with. So what are some ways that we can work through that? Pete, I'll start with you. That's a super challenging problem. I think there has to be some preparation for worst case scenario and worst case scenario being think about the attack surface. If that case is disabling radio connectivity on some of these things, working with some of the medical device manufacturers come to learn, this isn't a software change for a website that can be pushed into the CICD pipeline and show up in 10 minutes. This takes legal and regulatory guidance and preparation and submission to the FDA. That can take a long time. My suggestion is prepare for those scenarios now. Get ready for how do we do this if we have to? Because the reality of ex-planting devices from hundreds of thousands or millions of people is completely untenable. So how do you get... I realize that maybe there's going to be an inherent trade-off and quality of care provided. That's probably a situation you get to only as a worst case scenario. These devices keep people alive and that we want to keep enabling that because as Vee mentioned, these are things that some people wouldn't be here without those things. We don't want to instill the wrong level of fear, but planning for those scenarios now so that if those need to be enacted, I think is one of the only things you can do for the legacy devices that don't have an update mechanism. If they do, setting up the testing for this now and being ready for it, it's an inevitability. It's a when, not if. I think what we are doing together with Metronic, I think Metronic is a true pioneer in this support to legacy devices as what we are doing together, installing protection into five years old device, I think is five years old, enhancing the security in field, getting visibility, getting protection into really old medical device using the OTA. I think it's a true innovative play and I think that I truly support this kind of acts and I think that I have a lot of respect to Metronic in being pioneering doing such a thing. I think we can learn from it. I think we can provide enhancements to existing device flits. Of course, with the right controls and the right MDM to take it to the next level and to move forward. It's a good example of what we are doing together and I hope that we could pave the way. Absolutely. Baby steps in the journey, but exciting stuff. I know you have an opinion on this. I always have. You're good. You're on mute. Back on mute V. Oh, goodness. I'm having audio issues today. It's like the audio day over how old. My feelings on this is we can't even start facing the legacy problems until we stop making stupid decisions and choices going forward. We have to now nip this in the bird and say, going forward, we're going to do better. I haven't looked into lots of the things I've Googled it. I have read up on it. I'm very excited about what you guys are doing with Metronic. That certainly is a step in the right direction, but visibility is key. Pete and I have had discussions. It was like, we don't know if the ICD or pacemaker has been attacked. Do you even have the data to know that that's happened? We want to deal with legacy. We need to start getting visibility moving forward because otherwise we're adding this amount of, another year goes past. Now we have another group of legacy devices that's going to haunt us for 10 years. Get a drive going forward and then start dealing, finding solutions for those devices that you don't have visibility on. Find ways to get eyes on your products and your data because where you have a blind spot is most likely we're going to be attacked. It's not like a nation state actor is going to say, you know what, I have owned your product. Right? Researchers have the courtesy to come, you know, to have a discussion. Very bad people looking to do bad, bad things aren't going to have that discussion with you. You're not going to know they're there. You need one patient to have your device and they get attacked and they ultimately pay with their lives. I can tell you, you're going to have a string of patients wanting to explore on their devices, which is why something I don't want to have happen. It scares me because I look at where I was at 19, where I am now at 33 celebrating my birthday, having two kids, having a master's. Thanks to a device, it kept me living. Right? Otherwise it would be dead. It was as easy and as plain as that. It added years to my life I was not supposed to have. Take that technology away and as a human race, we go backwards. So patients need MDMs. Whether people in the security want to see them as an adversary, there are people like me that rely on them to develop the technology to keep us alive. Right? It's important to understand that it's a love-hate relationship. We're not all going to do it right, but if we can have the conversations and we can fight it out and we can find the solutions that are super cool and super techy and super new, we should try them. Right? What I think Sternum is doing, what Pete's doing, is hitting the same problem from a different side. I'm concentrating more on how do we detect and log these things? How do I investigate it? Mark and I have eyes on the prize sooner. That's my passion point. But we're all effectively covering this from a different side, which is good because all sides are vulnerable and all sides are needed. I think you're bringing it all together. How can we get better visibility? And Natalie talked a little bit about this, but I'd like you to go into more detail. What are your thoughts around proactive controls in the post-market, which is the term we just use for detection, logging, monitoring? I know we've thrown surveillance out there, but to be more in line with the community, it's incident response. It's logging detection, that capability. So how do you see proactive controls fitting into that model? Yeah. It's a great question. I think I want to learn from other industries, which already developed into these directions. So you don't see devices today within enterprise or in cloud infrastructures that are not monitored actively, that do not pop up alerts when something suspicious is happening. And I see the medical space behaving the exact same way. I think with solutions, I won't mention ours, but I think there are many solutions that can do that, provide monitoring and visibility into the device itself. And then I think that this kind of information and incident response should go into two main personas. One is the product security in the MDM. Monitoring is distributed device fleets, understanding if somebody is researching this device, selling the device on eBay, maybe trying to hack into the device, stealing information. This kind of things can be visible with the right controls. And of course, there is a technological challenge of supporting all devices, all code base, which didn't come with visibility inside without logging, without monitoring, but that can be fixed. It can be installed post market, and it's even easier to install it pre-market. The other persona is the hospital, the clinic. Those devices that if they come with built-in protection and monitoring, they can be the eyes of the hospital for a beginning of an attack attempt. Imagine an attack attempt just a month ago, there was a ransomware attack on hospital starting for a remote patient monitor. So the hacker penetrates to the internal network through the vulnerable IoT device. So imagine this device transmits information. Imagine this device is capable of detecting the attack attempt and even preventing it. Not only you prevented the attack, the hospital, that moment become aware that he is under attack and can act accordingly to secure other devices, maybe un-patch devices. So you don't have to have all the environment protected, but as you have more devices that are transmitting, visible, protected, you have more visibility into your entire enterprise or hospital and can respond accordingly. So I think both personas benefit from this kind of visibility. And I think moving forward, we can use these kind of tools to embed security and visibility. And I'm making a difference between the two because the kind of solution that I see in mind is first a deterministic solution to prevent attacks in real time, prevent the damage because in medical devices, there is no time to waste. A successful attack could lead to a little resorts and you don't have enough time to detect the attack and respond in a week or two weeks. Because in enterprise, it takes six months to respond to a security incident. You don't have this kind of time in medical devices, so you have to block the attack in real time. The other aspect is really to become aware. And to become aware means to get alerted when something is behaving differently or suspiciously or if there were a prevented attack attempt. And once you are aware that this kind of attack happened, let's say, in the US and you have devices that you can't update in another country with the same vulnerability because you know what the vulnerability at this point, because you have visibility into it, you are capable of providing fast response to alert your patients, to alert the hospital, to update the devices with a patch. So I think it's essential thing that we need to embed into the medical space. And we are on it. I love doing that because I think we're starting our journey to improve our visibility, improve our prevention in near real time, improve our detection capabilities. But we've thought into the future and how we need to better partner with healthcare delivery organizations, hospital systems, and provide some of that information to the example you gave about the ransomware outbreak. And having dealt with brands and one of myself in a past life, obviously time is of the essence. And that's something that we'd love to be able to help out with as an MDM in the future using these techniques and tools that we're talking about today. So V, I want to switch gears a little bit. We're talking about all different types of aspects of security controls and capabilities to give back. But you have a unique forensics background. How does that make you approach device security differently than say the traditional vulnerability disclosure scenarios? Yeah, so I think forensics is this unique focus on scientific processes. I think that's the one thing that was hammered into my head is we need to follow a scientific process. So you need to look at it from every aspect. But I was doing forensics for eight years straight, solely focusing on that and realizing that I wasn't quite understanding all sides of it. So I always say, we have a saying in forensics, we find the truth. So we reconstruct what happened. So I decided to actually start retrieving. So to learning how to attack. And then I learned how to defend. And then I learned how to investigate. And taking that, I decided to start applying that that type of mindset of taking a multidisciplinary view to things to saying, OK, well, I want to know if we're being attacked. I'm kind of tired of having it told to me that we don't have any data that supports any attack. And now knowing that we don't have the data actually available. So to have more visibility, we can start seeing whether devices are actually currently being attacked. Because we don't know, I spoke to multiple coroners around the world through law enforcement agency contacts. And the question I said to them, if you have a cardiac patient that has an implantable, right, they've passed away. That doesn't necessarily mean that it's suspicious circumstances. But do you do get a program, pull the data, look for the time of death, look of any strange activity surrounding the device itself? And I realized that, yeah, the devices get sent back to the manufacturer that does basically a memory review to see that everything is like it should be. But people forget that programmers can be compromised and something can happen from a programmer to a device. And we don't leverage the information that we have. So the important thing for me is we have no ability at the moment, unless a researcher comes to an NPM or someone makes a grand gesture that they've had to device, unless it causes chaos or becomes public. Somehow, we don't know. And that makes me uneasy as a forensics person. Because forensics, we want to know. We want to know the bits and bytes of how something functions. Men the local principles, a big thing that I live my life by. So everything that comes into connection with each other leaves a trace evidence. I want to know what it is. But if we don't have visibility, right, it's there, but we don't have the capabilities to make it visual. So I want to learn more of what we have, what we need, and what we need to do to kick ass to get there. So that's my approach to what I'm doing with Metronik is I'm assessing what you have. What we need and willing ass to get there. And I'm seeing it come together with the various aspects of you guys have brought together, you know, covering it from different angles. And the forensics in me is like saying, we can apply forensics in development. You know, we can apply for instance, extreme market, post market. It doesn't necessarily mean it's an investigation, but it's creating the evidence that we need for the future. It's creating the data now for when we do need it. I'm always drawn to the example of Microsoft and how they used other data sets to detect a large Windows vulnerability. And I think really was mining data in Windows event reporting. And I know that a big piece of what we're thinking about is we have a lot of remote monitoring information. We know what is above the line and what's below the line. And we're trying to develop, you know, that anomaly detection there. And it can't only be done, right, with that type of detection. That's one leg in the stool. But as we look at on device agents, as we look at other ways that we can pick this up with our fleet distribution infrastructure, I think that really has to come together to get this full picture. And all of you have hit on that element. And I think it's not to discount testing or threat modeling, all of that has to happen as well. But we really want to emphasize this prevention in real time and then this detection of the current devices and fleet that are legacy and are out there live today. And what can we learn from that? And I just, I really think that's important. And all of you have been bringing a different element of that to this discussion. And it's, it's helping us, I think, learn as a medical device manufacturer how to handle this situation. Yeah, I'm always sorry. I'm sorry. We should I always say data doesn't lie, right? It always said, there's a saying that follow the money or follow the evidence. But we have so much data, we're just not mining it. We're not learning. I think it's one of your members Sasha that said, we know, we need to learn to listen. Right. So we need to learn what the data is telling us. And I think that's the big thing. We have all this data, but we're not listening to it. And once we start intuitively tuning in and understanding the data, those numbers don't lie. Then actually, I think an MDM can only really do straight analysis. Because if you don't know what you have, how do you know what to protect? Because then you're always on the back foot. Right. You need to get ahead of the problem. You need to know where you're most vulnerable at. You shouldn't wait for that to become public knowledge. So I want to shift gears one more time here. Here the concept of zero trust in medical devices. And I've talked to, I believe each of you are on the same topic. How do you think that can be, that concept can be applied from an MDM perspective or from a medical device perspective? And I'll throw that out to the group whoever wants to latch onto that one can start us off. Okay, I'll roll with it. I was waiting for you. I know you got to be like, go ahead. I love zero trust. It makes me excited because for once we turn insecurity on it and saying, we're not going to trust but verify. That's not going to be, which is not going to trust. Because the nice thing about zero trust is you can actually understand devices. But the ideal thing is now we don't have a perimeter. We harden everything. We probe a device and if it meets the specific standards, that device is allowed to have access to the minimum it needs access to. Right? It's like a patient monitor that doesn't have to be on the wifi and doesn't have to link to the accounting system or the patient records. We have this thing trying to make everything accessible but too accessible. We take it to the extremes. We either make it too secure and unusable or we go to the other way. But zero trust has really big plus points for me because now we can attend to device manufacturers independently. We're not going to have the same controls across the board because everyone builds their devices different. You can understand the device and apply the appropriate rules, privilege and access. I think this is a really good solution as we move to a perimeterless remote monitoring and medical service. I had my first video consultation today which is something very strange but yet it felt normal. The perimeter has just been broken. COVID-19 came in, swept Kalske off its feet and we are facing new territory. We're having to build while trying to catch up. This virus has crippled health care and I think security should never put such a strain on health care that could cripple it more. We should be making it safer and easier to use. That's our responsibility as security people in this field. It's the responsibility of the MDM. Zero trust is the ability to do K-TED security based on a device, not necessarily the same rule for everyone. I'm very excited about it. I agree with you and I have a slightly different interpretation of zero trust in the concept of medical devices. For me, zero trust basically means we talked earlier about third parties and we talked about embedding communication models within the code and communicating with the patient's mobile app and the patient's maybe home router, each medical device with its communication. I think zero trust should really mean that we can't trust any of those. We can't trust any of the third party open source, closed source embedded. We can't even trust the operating system that a medical device use, whether it's commercial one, Linux based. We should be expecting vulnerabilities throughout the entire supply chain. The code, the hardware, the software within the hardware and of course we can't trust that the patient didn't install a malicious application on his mobile. The last thing we want to trust is the human being not making mistakes. For me, the concept of zero trust basically means that the kind of security that we choose to implement should take all of this under consideration and to make sure that we keep the integrity of maybe not the entire device, maybe it's impossible, but essentially the critical operation of the device should remain secure regardless of all the things that I mentioned. Like if we talk about insulin pumps, so you want the functionality of injecting insulin will be the most protected functionality of the device. Same goes for personal health information on the device itself. For me, zero trust basically means taking this into consideration when designing a security solution. Exactly, I like what Natalie said. I think it's the difference in design. I talk about this all the time, every time someone will listen. I look at it as a concept of, I think a great example is like cars. When the systems were built to allow a computing interface in a car, they weren't connected to anything. They designed according to that. They scaffolded this over years. Then all of a sudden someone came along and tacked on internet connections and Bluetooth and Wi-Fi. What you should do is go back and redesign everything to consider that new approach. The zero trust concept to me means we think about it from the initial idea stage of defending it in every place it can be. It's an analogy to what Natalie and V were saying about no one operational environment is any more or less secure than any other one because they're all the same. Everything to consider that takes concerted effort from the start, from the very, very start. I think approaching the problem from that way is another one of those shifts that we have to consider from legacy devices into what is going to be the new normal for this. Everyone's going to have to get there. The quicker a manufacturer of any kind of product you can start considering that, the easier their life is going to be in the long run. I must add just one thing about that because I think we are repeating a lot of thought. Think about it in advance. You have to design it. I must mention the other side. Security has always been the last part to be incorporated into things. Everybody would like to go to market faster. Everybody likes to just build their devices, build their technology. Nobody likes to think about security. I'm saying it's okay. I don't want to say you have to think about it in advance. You don't. History teaches that nobody thinks about everything in advance and it's okay. Security comes last always. So for me as someone who is looking for solutions and not just looking to emphasize the problem, I'm looking for solutions that can be developed and installed even if you didn't think about security. I have to say, again, it's the best thing to think about it in advance. But I'm just saying it's okay if you didn't. Nobody holds you responsible. I will hold you responsible only if you didn't try to fix it later on. I have to disagree there. I want to kick an Indian's ass and say, what the hell are you thinking? Oh, let me think. You're right. That's what happened there. It depends. It depends. If you have hard-coded paths for like one, two, three, four, then this is the place where you can think. What the hell were you thinking? But I'm just saying, the more advanced stuff, it's harder to think about. Yeah, so it's a two-fold problem. We dealing with legacy. I call it the legacy because that's what it's written in, that joke for the evening. The problem is we have to stop developing legacy problems. So we need to address it ahead of time. But okay, we have to face the fact that previously we didn't address it ahead of time and there's nothing you can do. Can't pull these things back. Can't tell me you're going to cut me open, take my device back, give me a new one. I'm not going to let that happen. So we have to deal with that. It's a two-fold problem. We have to be realistic. I think you are completely correct, but realistically looking ahead, I don't think we're going to be thinking about it in advance in the years to come because new problems will appear. And like in the 50 years prior to where we stand today, companies didn't think about it in advance. So we can teach that. We can say that. But to be realistic, I don't think it's going to happen. People will only handle the problem once it bites them in the ass, basically. You know, it's human, right? I can't disagree with you because history often repeats itself. I think what's interesting is recovering it like a triangle from different sides, which is very interesting. I'm concerned with we have these devices that are diversified. How do we include this on a healthcare network? Right? NACI's product literally deals with legacy devices and new devices. And the solution covers it from a different angle. So it's just like diversified opinion that's doing the same thing, but each in a different way. And this is why I think researching is important because we all think differently. So it's having, yeah, it's a big problem. It's massive. I think we're, yeah, I agree with what you're saying. We're all kind of coming at it from a little bit of a different perspective. And I do agree, Natalie, that like there's going to be new attacks we haven't thought of today that come out in the next year, three years, five years. But we're talking about medical devices today. And I think we absolutely have to require better work on the design. We got here because of the evolutionary walk of how medical device manufacturers built businesses to help patients and computers came part of that and here we are. How we go forward though can be changed. And I think the idea that we'd be accepting to someone not working hard at that right now is dangerous. I agree that we need to have things on the other side to prepare for the inevitable, the new things that come out that we haven't thought of the next thing that shakes the industry so to speak. And we want to be resilient to that. I completely agree. But in one case when I was looking at a medical device, I then started reverse engineering in e-bike. And the e-bike was orders of magnitude better because the e-bike wanted to prevent someone from bypassing the speed controller and going too fast in the bike that it wasn't regulated for. And they did a tremendous, they did an incredible job for that. But seeing the stark contrast between those two, the difference there was they designed it to be that way. And I know I harp on that a lot, but I think that's an important point. I think we can all agree that there's some fundamentals that we need to align with. I think this is why we want this diverse experience background, opinions, because it helps us grow in the industry. And we have time for one quick final question here, and I'll go around the panel and start out with you, Pete. How can researchers, smaller shops, those attending the biohacking village, get more involved with device makers? The way I did was eBay and calling. I think there would be a lot that could be drastically improved. If there's a way to get your hands on research devices to start learning this space, one of the challenges I think newer people to working in medical device research are going to run into is becoming aware of the monstrosity that is an MDM. And something like when you find a bug and you suggest a fix for it, the reality is its scale of making that happen. So on one hand, I would say it would be wonderful if MDMs would start exposing programs for researchers to apply to and be selected to start working on this stuff. And on the other hand, I think there would be a great spot for education on the MDM side to show what is it we're going to do. We need to do a hypothetical patch to this hypothetical device. What does that actually look like? The legal ramifications, the regulatory ramifications, because without that information, a lot of security researchers I think will be frustrated at the timeline it takes because they don't have any sort of understanding of what's really happening, especially coming from a place of the hacker ones and the bug crowds where that's a pretty smooth process when you're looking at web properties. And it's a very, very different industry. It's a very different threat model. It's a very different process. You have to go through and I think there's an education opportunity for that. Natalie, I know you've had your journey with medical device manufacturers. Same question to you. How do you think that researchers in smaller shops can get more involved in making a difference? So I completely agree with Peter and I think that bug bounties programs and exposing the inner processes that's happening within medical device development, which is extremely different from traditional development with different regulations and different constraints could help getting more engaged. I think assigning a person or a unit responsible for that is also super important in some of the medical devices. You just don't know who's the right person to approach. It's not the CISO. The CISO is not concerned about medical device security. It's concerned about the network. So I think getting this better approach is good. Transparency is good. Basically saying, hey, we want you involved. We're okay with it. We're not going to send you some terrifying legal documents if you find something. This can be helpful. And I think the research community maybe thinking about it in a different direction can also help educate. Meaning I think that what we sometimes do, we go to medical devices. We do some exploitation workshops. We explain what vulnerability means, how to exploit vulnerabilities, how to write code with security in mind to avoid vulnerabilities. We had this experience with Metronik as well. It was amazing. It was super satisfying for us. And I believe that it was also interesting for medical advice engineers and software developers to suddenly see the other side of the code and the other side of what can be done with the code and how devices are being exploited can also raise awareness and can also help them understand what the researchers are doing and why they're doing that. And this could really be like open mind and open hearted conversation which we had. And I think is a great example. It's not very common. I mean, device manufacturers, OEMs, some of them do not respond well when researchers approach them with vulnerabilities. And I think positioning yourself as an MDM saying we respect that, we would work with you is amazing and it's the right approach. Last but not least, V, you get the final word. Oh, awesome. I'm going to do a call out to all my fellow biohackers, my friends, my goons, my family. The biggest thing I've learned that the constraints we're dealing with vulnerabilities from an MDM's perspective is when you do a proof of concept, approach this like a report, approach it like scientifically, give us much information, as much code as you can for the MDM. They need to verify what you have said. And if your document doesn't consist of information that is comprehensive and easy to follow, they are going to have to reverse engineer things themselves. And then the 30 days that you expect to get back from them, it's going to take them 60 to 90 days just to figure out whether it's applicable to their product. So if you come with a problem, come with a solution. Let's not just focus on what we've broken. Let's try and fix it. So my challenge to all my hacker friends are, let's not just try to break things. Let's try and solve things. For me, the term hackers, obviously sometimes associated with cyber criminal. And for me, it's a passion point because hacking is what I do. I'm not a criminal. I try and figure out what's wrong so that I can fix it using alternate ways and means of thinking. That's what a hacker does. That is what a hacker is for me. But we're also scientists and in science, we need to be thorough. We need to do the project better. And for an MDM, it won't be such hard asses. We're trying to help. I promise you, we're not your enemy. Just be a little bit nicer. I have a conversation. Buy someone a coffee. If you see someone at Biohack Village, I promise you, I haven't had a hacker that bites unless asked to bite. We don't like having teeth. We like having tech conversations. And we like geeking out with you. But it comes from both ways. We both need to open our hearts and open our minds and realize we're working towards the same ideal and working against each other is not going to get us there any sooner. And from a patient's like, keep on doing the research. Make this stuff better. Because I think either part, you need to each other. It's a trifecta. It's the medical manufacturer. It's the researcher and it's the FDA or the regulatory body, depending on where you're from. Those are the things that are going to make the future better. And those are basic engineering practices. A triangle is the strongest thing you can enforce something with. So let's enforce this with teamwork. That's all I have to say. V out. With that, I want to thank the panel. Drop the mic. Pete, Natalie, V, we're good to go. Have a good DefCon Biohacking Village, everyone. Thank you. Thank you very much. Cheers.
I do get to work on solutions and help with relationship and how being a patient maybe and observe them and learn what they are, how Because that particular thing is a problem near legacy devices that at one point in their solution will have to be a multidisciplinary things, working with some of the medical device it all together. How can we get better What are your thoughts around proactive controls line with the community, it's incident response. everything to consider that new approach. The Security has always been the last part to be information, a lot of security researchers I