WEBVTT 00:00.770 --> 00:03.490 All right, well welcome folks. 00:03.490 --> 00:07.390 It's my pleasure and honor to introduce some great friends of mine. 00:07.390 --> 00:10.650 They are all hackers, and we have our moderator today. 00:10.650 --> 00:15.770 I'll do a brief introduction for him, but first and foremost, welcome to the biohacking panel. 00:15.770 --> 00:22.770 How independent security researchers, vis-a-vis hackers, work with MDMs, or that notorious medical device manufacturer. 00:22.770 --> 00:27.430 This is the bad, the ugly, and the great, also affectionately known as bug. 00:27.430 --> 00:29.810 My name is the Red Dragon 1949. 00:29.810 --> 00:31.570 You know me as the volunteer coordinator. 00:31.570 --> 00:34.110 But more importantly, I'd like to introduce you to the panelists. 00:34.110 --> 00:38.410 First and foremost, ladies first, we have Veronica, or Bea Schmidt. 00:38.410 --> 00:41.090 Yesterday was her birthday, so happy birthday Bea. 00:41.230 --> 00:45.670 She is a former federal law enforcement in South Africa. 00:45.670 --> 00:47.770 She has done forensic investigations. 00:48.030 --> 00:58.310 She is a cardiac implant patient three times, and she is doing some great forensic work for one of the MDMs that will be showcased here at the Biohacking Village Medtronic. 00:58.870 --> 01:00.090 Welcome Bea. 01:00.290 --> 01:01.450 Second, we have Ms. 01:01.450 --> 01:02.430 Natalie Shuva. 01:02.430 --> 01:06.390 She is the CEO for Sternum out of Tel Aviv, Israel. 01:06.390 --> 01:10.810 She comes to us from the UDIN 8200 of the Israeli Defense Force. 01:11.030 --> 01:18.130 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. 01:18.530 --> 01:20.350 And then last but not least, we have Mr. 01:20.350 --> 01:23.070 Peter Morgan out of San Diego, California. 01:23.330 --> 01:23.670 Mr. 01:23.670 --> 01:39.170 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. 01:39.170 --> 01:46.310 He has notable common vulnerabilities and exposures to his name associated with some Medtronic devices, so welcome Peter. 01:46.650 --> 01:49.230 And then last but not least, our moderator, Mr. 01:49.230 --> 01:50.010 Kyle Erickson. 01:50.010 --> 01:58.170 He's the Director for Product Security Engineering with the Cardiac Rhythm Heart Failure Business Division at Medtronic out of Minneapolis, Minnesota. 01:58.170 --> 02:12.710 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. 02:12.710 --> 02:14.010 So welcome, Mr. 02:14.010 --> 02:16.130 Erickson, and I will turn it over to you. 02:18.030 --> 02:20.590 Thank you, Red Dragon, for those great introductions. 02:20.590 --> 02:37.990 I have the luxury to be here on the panel with Pete, Natalie, and Vi, 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. 02:38.050 --> 02:42.910 So I want to start out with an origin story, and I'm going to start with Natalie. 02:42.930 --> 02:49.850 Natalie, what makes you a hacker, and how did you really get involved in the security movement around medical devices? 02:50.850 --> 02:59.110 Yeah, well, I actually don't refer to myself as a hacker, but I can tell you basically my story. 02:59.110 --> 03:07.630 I grew up with four big brothers and started my undergraduate degree at the age of 14, computer science. 03:07.790 --> 03:17.930 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. 03:17.990 --> 03:36.870 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. 03:36.870 --> 03:54.210 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. 03:54.210 --> 04:15.850 So during my time in Cetebrite, I did a lot of vulnerability research and exploitation, mainly on Linux kernel 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, 04:15.850 --> 04:26.790 because using the vulnerabilities and exploitation, we were able to extract forensics and basically evidence from the mobile devices, including encrypted ones. 04:26.790 --> 04:32.650 So for me, it was the passion and the impact that such tools can create. 04:33.270 --> 04:38.790 And the medical device was actually not a coincidence. 04:38.790 --> 04:43.150 I was always dreaming and thinking about becoming a doctor. 04:43.150 --> 04:51.730 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. 04:51.730 --> 05:07.130 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. 05:07.310 --> 05:32.830 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 patients' lives and improve quality of care and treatment. 05:32.930 --> 05:41.970 And I saw how the knowledge that we have from the cybersecurity industry could leverage this kind of technology. 05:41.970 --> 05:46.270 And this is what actually attracted me to Cofan External. 05:47.230 --> 05:48.550 That's excellent. 05:48.550 --> 05:53.470 Obviously, you may not call yourself a hacker, but you have the tactics, techniques, and capabilities. 05:54.730 --> 05:55.390 Correct. 05:55.450 --> 05:58.010 So, Vee, I'd like to go to you. 05:58.010 --> 06:00.530 And obviously, we know you have a unique story. 06:00.530 --> 06:08.230 You're not only a hacker, a researcher, a goon, but you have implanted a medical device and refer to yourself as a cyborg. 06:08.330 --> 06:15.510 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. 06:17.210 --> 06:21.250 Yeah, so I wasn't a very good hacker when I was a child. 06:21.250 --> 06:27.210 And I basically got caught changing records at school, because I felt everyone should have a good year. 06:27.910 --> 06:33.510 Unfortunately, that led me down a path that my parents weren't very proud of. 06:33.950 --> 06:47.030 But going back at the age of 18, I joined the Special Emergency Learning Unit, which is a law enforcement agency that deals with cross-border human trafficking, child pornography, some really nasty things. 06:47.030 --> 06:49.030 We actually made use of Celebrite. 06:49.030 --> 06:52.050 So I'm very familiar with what Nati's referring to. 06:52.050 --> 06:59.650 And let me tell you, if you want to get a physical image, those things that they develop are key. 06:59.810 --> 07:06.970 But at 19, I also had about approximately two weeks left to live when I got my device implanted. 07:07.030 --> 07:09.790 And I know the quality of life that it gave me. 07:09.790 --> 07:18.610 But since then, I was obsessed with what my device does, for the pure fact that I believed in the saying, trust but verify. 07:18.610 --> 07:22.210 But I could never verify what was keeping me alive. 07:22.210 --> 07:24.830 And that was the biggest, greatest frustration. 07:24.890 --> 07:33.130 I reached out to you guys about three years ago, and I was met with the ugly part of Medtronic, sadly. 07:33.750 --> 07:36.490 I got met with the legal team. 07:37.350 --> 07:40.750 And I felt that the conversation wasn't going very well. 07:40.830 --> 07:45.750 I remember these words, and Tara, that used to work with you, knows this well. 07:45.750 --> 07:50.930 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. 07:51.850 --> 07:53.670 But that's where it ended. 07:53.830 --> 07:56.910 And in walks Biohack Village three years ago. 07:57.690 --> 08:02.470 Nina, being forever the master planner, put me on the path for Bill. 08:02.950 --> 08:11.690 But then I came to severe loggerheads last year, because he could not confirm to me that he was from Medtronic, even though I knew he was. 08:11.870 --> 08:16.090 And we went at it, and we had our conversation. 08:16.230 --> 08:24.990 And fast forward a couple of months, I'm now finding my feet within Medtronic and doing research into early detection. 08:25.090 --> 08:27.610 Because I didn't want to focus on the problem. 08:27.690 --> 08:31.210 I wanted to find the problem and then solve it. 08:31.270 --> 08:34.590 So it's not just about whether the device can be hacked. 08:34.590 --> 08:36.370 We all know everything can be hacked. 08:36.370 --> 08:42.350 But it's actually about having some tangible evidence to deal with, to early detect and to mitigate it. 08:42.350 --> 08:50.350 For me, literally close to my heart is the embedded implanted devices that are often misunderstood, forgotten about. 08:50.970 --> 08:54.930 And these are the things that are connected to people, flesh and bones. 08:55.870 --> 09:03.150 And I just decided to take this on and put my story out there and say, you know, these things are cool, but they're also scary. 09:03.210 --> 09:05.550 But that doesn't mean we need to go burn the internet. 09:05.550 --> 09:08.230 It just means we need to do more to make it safer. 09:10.830 --> 09:11.630 Absolutely. 09:11.750 --> 09:14.050 And we're glad that we can make some inroads there. 09:14.050 --> 09:16.890 I know it's been a journey, to say the least. 09:17.110 --> 09:18.950 Pete, you've had a similar journey. 09:18.950 --> 09:24.770 I'd love to just kind of hear your origin story and what got you interested in medical device security. 09:24.770 --> 09:30.210 And not only do you have vulnerability discovery on your side, you've also looked at solutions and improving the problem. 09:30.210 --> 09:31.970 So give us your background. 09:31.970 --> 09:32.790 Sure. 09:32.790 --> 09:42.610 So I started out as a kid learning how to hack video games and change them before the advent of client mutual authentication. 09:43.530 --> 09:45.150 And that really got me hooked. 09:45.430 --> 10:03.090 And as I grew up learning about software development, networking, reverse engineering, exploitation, going forward into things like software-defined radio and actually understanding RF better, it was kind of like I picked up these skills along the way. 10:03.230 --> 10:13.110 And as I was able to escalate in a career path and get better jobs, I finally got into a spot where I was able to affect what direction our team was going. 10:13.550 --> 10:20.610 And previously, I'd spent some time at a hedge fund kind of protecting a billionaire, making sure their billionaire is still worth billions. 10:21.030 --> 10:26.530 And there wasn't a ton of job satisfaction out of that other than the interest of how that works. 10:27.290 --> 10:32.890 And I got a project at doing a small medical device in a consulting relationship. 10:32.890 --> 10:47.990 And it was really neat because the problem set was really interesting from like 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. 10:47.990 --> 10:53.130 But also, when you make improvements to something like that, it has a direct impact on people's lives. 10:54.310 --> 10:58.490 And it was a lot more interesting to work on those types of problems. 10:58.490 --> 11:15.110 That's when I got kind of started just doing some research on some of the Medtronic gear and was able to publish some vulnerabilities after maybe an ugly or bad initial interaction that then turned quite positive. 11:15.770 --> 11:34.650 And then one of the things I'm most proud of, I think, is having the patience to work through that process with Medtronic 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, 11:34.650 --> 11:36.890 sending a vulnerability report, and walking away. 11:36.930 --> 11:38.410 So that's been really rewarding. 11:39.450 --> 11:40.070 Absolutely. 11:40.070 --> 11:41.650 And we thank all three of you. 11:41.650 --> 11:50.530 You'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. 11:51.290 --> 11:53.190 So Natalie, I want to come back to you. 11:53.190 --> 11:58.210 I have a specific question and it's more around military-grade technology and techniques. 11:58.210 --> 12:05.770 How do you think that can really help secure medical devices and the infrastructure and hospital systems that they reside in? 12:06.410 --> 12:07.470 Yeah. 12:08.070 --> 12:20.630 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. 12:20.630 --> 12:26.630 And as part of it, I think that security techniques are also well-developed within the military. 12:26.810 --> 12:33.410 And when you talk about military-grade security, I think this is what we want for our medical devices, right? 12:33.450 --> 12:40.530 Because you don't want your security camera to be protected the same way as your pacemaker. 12:40.650 --> 12:51.070 I think medical devices do require some higher extent of security and deeper level of security. 12:51.090 --> 13:00.930 And I think what we see in the military is wide range of attack scenarios and attack techniques and exploitation techniques. 13:00.930 --> 13:20.950 And you realize that for me, at least, securing medical devices just by doing vulnerability patching or penetration testing or avoiding hard-coded passwords, it was not enough because I know and I'm familiar with how you can bypass those things pretty easily. 13:20.950 --> 13:35.190 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. 13:35.190 --> 13:52.950 And one of the things that I think was significant in our way of thinking is that even if you secure the MDMs code or doing some vulnerability research or pen testing, it's not enough because those devices contain third-party code as well. 13:52.950 --> 13:55.650 And Ripple 20 is a great example, right? 13:55.650 --> 14:07.350 We see a TCPIP library affected millions of devices, power grids, medical devices, and most solutions today just can't handle third-party vulnerabilities. 14:07.350 --> 14:14.590 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. 14:14.590 --> 14:26.310 And I mention in it because that in the military, we handled a lot with binary code and with embedded systems and with the ability to reverse engineer other people's code. 14:26.310 --> 14:36.730 And actually, we are leveraging these kinds of techniques in our philosophy to embed protections and security into these closed-source components. 14:36.730 --> 14:47.110 Because in my view, the MDM has to be responsible for the security of the device regardless of the components within the device. 14:47.110 --> 14:51.950 So, we have to give controls to the MDMs to secure these third parties. 14:51.950 --> 15:02.330 And I think these binary-level capabilities are well-established in the military and can be used to holistically secure medical devices. 15:02.330 --> 15:04.310 And this is what we try to do. 15:05.590 --> 15:06.610 Excellent. 15:06.610 --> 15:18.530 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. 15:18.530 --> 15:21.630 You know, I'm all for what you are saying. 15:21.630 --> 15:24.970 It is solely the MDM's responsibility. 15:25.230 --> 15:30.730 They have to take ownership and responsibility of the tick label, right? 15:30.730 --> 15:34.370 As a patient... I agree with you. 15:34.370 --> 15:38.190 But on the other hand, I must say it's not an easy task, right? 15:38.190 --> 15:42.010 Because the MDM, it's very difficult to secure third parties. 15:42.010 --> 15:46.210 And there is no way to avoid implementing third parties within your device. 15:46.210 --> 16:02.910 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. 16:02.910 --> 16:11.050 But we do need to ask them to use the cutting-edge tools to secure their devices. 16:11.050 --> 16:13.790 This is indeed something that I believe in. 16:14.190 --> 16:19.690 Yeah, it's embedding the security culture in how we look at devices, right? 16:20.030 --> 16:25.130 But, you know, Medtronic is a good example from this learning from lessons learned, right? 16:25.130 --> 16:35.010 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. 16:35.010 --> 16:36.350 We need help. 16:36.350 --> 16:38.310 We can't do it on our own. 16:38.370 --> 16:51.790 I often say it takes a stronger person to say, hey, I now need help and go to people that can help him versus having the persona of, I know everything, we are a big manufacturer, we can do it on our own. 16:51.910 --> 16:56.210 Completely agree with you. 16:57.770 --> 16:58.490 That's great. 16:58.490 --> 17:14.210 I want to pull on that thread a little bit, Vy, 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, 17:14.210 --> 17:16.150 how that's also changed your perspective. 17:16.150 --> 17:18.130 Can you talk a little bit about that? 17:18.710 --> 17:19.310 Yeah, sure. 17:19.310 --> 17:21.470 So, that brings back a memory of mine. 17:21.470 --> 17:23.490 I think it was two years ago, February. 17:23.630 --> 17:27.750 I was actually in ICU where I had some issues. 17:27.750 --> 17:32.070 I had some device issues and I had to be resuscitated. 17:32.070 --> 17:40.150 But I was lying in an ICU connected to 15 different kinds of machines doing infusion, monitoring. 17:40.190 --> 17:45.490 I had a specific external monitor monitoring my pacemaker at that time. 17:45.990 --> 17:52.990 And I was offered guest Wi-Fi, obviously, because hospitals want us to feel safe and connected to the world. 17:52.990 --> 18:05.730 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. 18:05.730 --> 18:12.330 But just realizing from a perspective of a patient how interconnected these systems are. 18:12.350 --> 18:31.530 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. 18:32.010 --> 18:49.490 And I think until we start understanding each system's unique, I say language, linguistics or, you know, when you have someone that you're observing, you try and, you know, observe them and learn what they are, how they talk, all those kind of things. 18:49.490 --> 18:51.790 But we don't do that with devices. 18:51.790 --> 19:05.230 And I think I appreciate what Peter does and what Nathalie does because we reverse engineer things to understand how they work, not only at a, you know, firmware level, but at a file system level, at a binary level. 19:05.350 --> 19:09.670 And as a patient, I wanted to know what keeps me alive. 19:09.670 --> 19:14.070 I wanted to know what libraries were used, what hardware was used. 19:14.070 --> 19:16.190 And I did that through OSINT. 19:16.190 --> 19:24.490 I literally Googled manuals and from manuals I pivoted to get more information because the manufacturer wasn't disclosing it to me even as a patient. 19:24.490 --> 19:42.610 But I wanted to know that I can trust my device because I've seen that these devices are misunderstood 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 consider the malicious insider, 19:42.610 --> 19:52.890 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. 19:52.890 --> 19:58.050 I don't know where the border stops or the perimeter starts and stops anymore. 19:58.910 --> 20:09.610 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. 20:10.130 --> 20:26.890 I always say, you know, 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. 20:26.890 --> 20:34.910 I know I geek out because I spoke to one of the engineers and learned what my functions on my pacemaker and ICE does. 20:35.730 --> 20:43.830 And let's just say it was like a moment where I sat back and said, this is such a simple, complicated device, but I trust it. 20:43.830 --> 20:53.690 And it's the weirdest thing, but I geeked out knowing that the maths behind it is so wonderful that in a nanosecond it raises my heart rate up. 20:53.690 --> 20:55.990 So I'm actually getting emotional. 20:55.990 --> 21:02.930 Excuse me, but yeah, it's a good thing when you realize that you can trust what's in you, right? 21:02.930 --> 21:05.610 I can trust that it's going to do what it needs to do. 21:05.610 --> 21:20.770 I must mention just regarding one thing you said about getting the hardware specifications, the software specifications, being exposed to how the device is being built. 21:20.770 --> 21:41.510 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 firmware very easily. 21:42.350 --> 21:45.710 You want to make it as hard as possible. 21:45.710 --> 21:58.910 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. 21:58.910 --> 22:11.210 So I 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. 22:11.690 --> 22:15.490 Sorry, Peter. 22:15.490 --> 22:26.190 So just to clarify, the reason that I said I OSINT this was before I spoke to them and then I realized that I could get all the information. 22:26.210 --> 22:29.070 That's when I went to the MDM, right? 22:29.070 --> 22:32.890 So I'm all for that certain things should be on the internet. 22:32.990 --> 22:36.470 And this was one of the first things I raised with them. 22:36.490 --> 22:40.550 So when I meant as a patient, I went to them, I was concerned. 22:40.630 --> 22:55.970 I was petrified because I managed to get technical manuals from technical manuals jump to hardware manuals, which led me to more information that I seriously wanted to find in an OSINT exercise. 22:56.250 --> 22:59.050 So yeah, that's what happened. 22:59.050 --> 23:04.510 And that's when the legal team slapped down on me and like, where did you get this information? 23:04.510 --> 23:06.230 And I'm like, your website. 23:06.730 --> 23:11.950 Yeah, we had the same experience where they asked, where did you get the devices? 23:11.950 --> 23:13.450 And we're like, eBay. 23:14.370 --> 23:15.790 We know about that. 23:15.950 --> 23:16.690 Yeah. 23:18.470 --> 23:31.990 I think that underscores the point of, I mean, I can understand the request to have a balance, but the minute that comes out, you can't take it back away. 23:31.990 --> 23:53.570 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, 23:53.570 --> 23:56.710 you know, what radio chip they used, that kind of thing, right? 23:57.210 --> 23:59.170 That's an exercise in time. 23:59.310 --> 24:07.770 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. 24:09.050 --> 24:12.030 Yeah, well, I mean... Go ahead, Vi. 24:12.730 --> 24:13.270 Sorry. 24:13.270 --> 24:18.370 So Peter, I think you and I, I mean, I didn't have to go buy my device. 24:18.370 --> 24:20.750 I just got it and I got the doctor. 24:20.750 --> 24:23.710 I'm like, hey, hey, hey, I would like my device, please. 24:23.770 --> 24:25.250 Can I keep it? 24:25.730 --> 24:27.190 And they gave it to me. 24:27.190 --> 24:29.750 I mean, your story, of course, is way cooler. 24:29.750 --> 24:31.930 I mean, I didn't have to buy it. 24:32.130 --> 24:32.930 Yeah. 24:33.450 --> 24:35.050 Talk a little bit more about that. 24:35.050 --> 24:36.830 Talk a little bit more about that story. 24:37.110 --> 24:39.810 So I'm a little bit of an empathic person. 24:39.810 --> 24:45.490 So like awkward situations tend to land strongly on me, I guess you might say. 24:45.770 --> 24:54.770 And amidst doing some of the work I've done, I've taken apart and reversed the majority of the home monitor device. 24:54.770 --> 25:00.430 But I needed to see live communications to understand what some of the implications of that were. 25:00.790 --> 25:16.310 So I tried to get my hands on some implantables and I think it was like between 30 and 40 morgues and coroner's offices I called trying to get my hands on before basically anyone that did cremation, right, because they remove the devices before cremation. 25:16.490 --> 25:20.120 And it was some really, awkward conversations. 25:20.120 --> 25:23.380 I got yelled at a few times pretty aggressively. 25:23.400 --> 25:27.320 Understandably so, they didn't see what I was trying to do. 25:27.320 --> 25:29.660 But yeah, that was a little bit awkward. 25:30.460 --> 25:41.320 Yeah, you should seriously try going to a cardiologist's office and they Googled you and they've seen one of your talks and you get specifically watched doing everything. 25:41.960 --> 25:44.780 Yeah, that's a different patient perspective. 25:44.780 --> 25:52.140 I'm officially banned from all major hospitals in my hometown from having a laptop, or even getting Wi-Fi access. 25:52.140 --> 25:55.860 I think they've grown tired of me saying, hey, we should fix this. 25:56.140 --> 25:56.640 Right? 25:56.640 --> 26:00.800 Or me spending time fixing it for them and saying, hey, I fixed this for you. 26:00.800 --> 26:04.260 You know, here's the credentials go, you know, go wild. 26:04.600 --> 26:10.720 It's just that whole culture of when you say to someone, but we can fix this for you. 26:10.720 --> 26:12.260 It's not an insult. 26:12.260 --> 26:16.840 It's genuinely people, researchers wanting to make things better. 26:17.160 --> 26:24.500 And perhaps not having the social... I don't sometimes have the social cues like you would say Pete. 26:24.500 --> 26:28.520 I can totally imagine having those conversations with coroners. 26:28.660 --> 26:35.520 Like, you know, I can just... I think I wanted to be a fly on the wall for that. 26:37.020 --> 26:41.700 So as a medical device manufacturer, I think I'm internalizing two takeaways. 26:41.700 --> 26:54.500 Don't rely on 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. 26:54.500 --> 26:56.880 So two takeaways right there. 26:57.440 --> 26:59.900 So I want to switch gears and go to you, Pete. 26:59.900 --> 27:02.880 You know, I know we talked a lot about your vulnerability discovery. 27:02.880 --> 27:07.260 Obviously, we hinted at a few of the CVEs and things that you brought to Medtronic. 27:07.280 --> 27:11.060 But how do you see the testing landscape changing for devices? 27:11.120 --> 27:18.260 And what should medical device manufacturers do on their own to learn from what researchers have done in the testing space? 27:18.800 --> 27:20.460 A great question. 27:20.620 --> 27:25.460 Well, I think the testing is going to have to follow the path of development. 27:25.900 --> 27:39.520 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 that actually use it. 27:40.380 --> 27:45.620 And I think there's an opportunity right now to fix that problem before it gets out of hand. 27:46.560 --> 27:55.180 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. 27:55.480 --> 28:03.880 It's a perfectly ripe target for attackers, especially when it comes to low power, questionably connected, embedded devices. 28:03.980 --> 28:12.100 So I would stress as far as something to develop on, work on secure update and get that working immediately so it can be used. 28:12.100 --> 28:24.780 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. 28:25.800 --> 28:33.640 And that kind of, I think, will drive a lot more of the modifications to testing that's going to happen. 28:33.640 --> 28:54.640 As these devices, we've seen a trend now for devices that used to use homegrown protocols and bespoke radio communication systems to communicate, largely shifting over to using things like Bluetooth and something that's a lot more standardized but also tends to work with a smartphone. 28:55.640 --> 29:03.180 And as that happens, we're seeing a shift into a lot more open source library usage in these products. 29:03.620 --> 29:06.760 That particular thing is a problem near and dear to my heart. 29:06.760 --> 29:17.920 We're working on a tool to basically audit the open source ecosystem and mine for malware, mine for backdoors. 29:18.100 --> 29:28.500 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. 29:28.500 --> 29:32.960 This is going to land very important on the medical device manufacturer. 29:33.560 --> 29:45.780 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. 29:45.940 --> 30:00.860 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 weigh in weight for access into an entire fleet of these things. 30:01.080 --> 30:08.340 And again, you think about that kind of problem without a good secure update mechanism, and now you have something that is irreversible. 30:09.000 --> 30:16.240 So I see this as the trend of development changes with medical devices. 30:16.740 --> 30:19.340 The testing requirements are going to change as well. 30:19.340 --> 30:29.660 I would love to see a universe where when a device is designed, I mean, we have automated testing through like fuzzing of the protocol, right? 30:29.660 --> 30:48.800 I mean, 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, you know, before release, there's all these different tiers that have happened aside from just someone manually reviewing source code. 30:49.560 --> 31:02.680 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. 31:03.840 --> 31:11.480 The more people we can get involved with this at a productive level, I think, is going to be more valuable too. 31:11.480 --> 31:15.100 And that's, I think, a large challenge of the medical device manufacturer. 31:15.100 --> 31:31.500 How do you adjust the signal-to-noise ratio such that you're getting competent, quality people that really want to help without, you know, wading through the deluge of things that may happen if you just bug-bounty it, let's say. 31:32.100 --> 31:34.240 Yeah, I think there's like a diverse approach to this. 31:34.240 --> 31:49.240 I think, you know, in a prior life, you were at a boutique shop and, you know, we've used all different types of testing companies, we've internalized some of this, but, you know, even finding those niche boutique shops or those individuals that can really get at certain elements have really helped us, 31:49.240 --> 31:49.940 I know. 31:50.760 --> 32:20.200 I can, if I may jump in, as a person who researched many platforms that are highly secured, highly being researched, highly being fuzzed and pen-tested, including Linux kernel and iPhone devices, I can tell you that it's impossible to put a device out there without vulnerabilities. 32:20.320 --> 32:26.360 And once it's out there and you have enough researchers, some of them will find the vulnerabilities. 32:26.360 --> 32:40.900 And if we'll take a look at the long-term strategy and take a look at what the traditional IT security world has gone through, we have endpoint security and we have network security. 32:40.900 --> 33:00.960 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, secure design or where the vulnerability is. 33:00.960 --> 33:06.160 Is it in the OTA or improper input validation, etc. 33:06.200 --> 33:13.120 So for me, if you ask about what's the right approach, the right approach would be sustainable. 33:13.240 --> 33:20.280 Meaning I think secure design is cool, I think penetration testing is cool, but it will never be sufficient. 33:20.300 --> 33:29.920 You will never have a 100% vulnerability-free device, especially when you use third-party code. 33:29.920 --> 33:40.620 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. 33:40.620 --> 33:41.460 They don't. 33:41.460 --> 33:48.840 And source code is not the only thing that goes into your device, not to mention hardware components that have software within them. 33:48.840 --> 33:54.080 So your Wi-Fi module or Bluetooth module, it contains vulnerabilities as well. 33:54.080 --> 33:56.740 You have vulnerabilities on the chip level. 33:56.900 --> 34:13.680 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. 34:13.680 --> 34:21.980 And on the other end, also monitor the device, meaning you need to be alerted if something bad happens or maybe happens. 34:22.080 --> 34:35.320 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. 34:35.320 --> 34:41.620 And I think this is where IoT and IOMT should go to. 34:42.100 --> 34:48.860 And obviously there are challenges in installing something on those devices. 34:48.860 --> 34:50.500 They are low resource. 34:50.500 --> 34:53.060 They are real-time operating systems. 34:53.060 --> 34:54.420 They are diversified. 34:54.420 --> 34:59.620 They are extremely different from traditional servers or PCs. 34:59.620 --> 35:02.680 But this is where innovation comes to the picture. 35:02.680 --> 35:04.660 I think we can solve this problem. 35:04.660 --> 35:09.540 I even think that we've solved part of the problem for sure. 35:09.540 --> 35:15.780 But I don't think that this challenge should keep us from putting something on a device to protect it. 35:15.860 --> 35:23.620 We should just do a breakthrough in how we see endpoints for IoT devices. 35:24.220 --> 35:28.120 Yeah, so I totally agree with what everyone's saying. 35:28.120 --> 35:30.200 Something dawned on me the other day. 35:30.240 --> 35:36.580 If we look at the longevity of medical devices, for example, could be a decade. 35:36.580 --> 35:45.660 So if you look at just some of the statistics, 600,000 medical devices implanted yearly in the US, those will last 10 years. 35:45.720 --> 35:54.740 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. 35:55.860 --> 36:05.300 And it's not technology that you can rip out of a body or, you know, some people only can have that monitor depending on what device you are talking about. 36:05.300 --> 36:08.140 But those things are built to last for a long time. 36:08.180 --> 36:24.220 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 necessarily can't. 36:26.000 --> 36:28.880 I'm glad you brought that up, Vy. 36:28.880 --> 36:32.840 So I'm interested and I'll go kind of back around the panel and start with Pete. 36:33.000 --> 36:35.360 How do we approach this legacy device problem? 36:35.360 --> 36:44.880 I think Vy already teased out the updatability and the forecasting of the life cycle, but we have a lot of legacy debt right now that we're dealing with. 36:44.880 --> 36:47.760 So what are some ways that we can work through that? 36:47.760 --> 36:48.720 Pete, I'll start with you. 36:50.040 --> 36:52.660 That's a super challenging problem. 36:53.700 --> 37:01.520 I think there has to be some preparation for a worst-case scenario. 37:01.520 --> 37:05.940 And worst-case scenario being, think about the attack surface. 37:06.660 --> 37:26.120 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. 37:26.280 --> 37:36.840 This takes legal and regulatory guidance and preparation and submission to the FDA, and that can take a long time. 37:36.840 --> 37:41.040 And my suggestion is prepare for those scenarios now. 37:41.540 --> 37:45.060 Get ready for, how do we do this if we have to? 37:45.460 --> 37:53.780 Because the reality of explanting devices from hundreds of thousands or millions of people is completely untenable. 37:54.160 --> 38:08.820 So how do you get... and I realize that maybe there's going to be an inherent trade-off in the quality of care provided, and that's probably a situation you get to only as a worst-worst-case scenario. 38:09.120 --> 38:25.000 These devices keep people alive, and that we want to keep enabling that, because like, you know, as V mentioned, these are things that some people wouldn't be here without those things, and we don't want to instill the wrong level of fear. 38:25.460 --> 38:36.440 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. 38:37.420 --> 38:46.540 If they do, I mean, like setting up the testing for this now and being ready for it, it's an inevitability. 38:46.540 --> 38:48.700 It's a when, not if. 38:50.700 --> 39:13.860 I think what we are doing together with Medtronic, I think Medtronic is a true pioneer in this support to legacy devices, as what we are doing together, installing protection into a five-year-old device, I think is five years old, enhancing the security infield, 39:13.860 --> 39:22.700 getting visibility, getting protection into a really old medical device using the OTA. 39:22.700 --> 39:44.360 And 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 Medtronic in being a pioneer in doing such a thing. 39:45.920 --> 39:47.360 So I think we can learn from it. 39:47.360 --> 40:00.500 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. 40:01.140 --> 40:12.460 But it's a good example what we are doing together, and I hope that we could pave the way. 40:14.180 --> 40:14.820 Absolutely. 40:14.820 --> 40:17.100 Baby steps in the journey, but exciting stuff. 40:17.100 --> 40:19.060 Vi, I know you have an opinion on this. 40:22.020 --> 40:23.720 I always have. 40:24.780 --> 40:26.040 You're good. 40:29.310 --> 40:30.470 You're on mute. 40:30.710 --> 40:32.070 Back on mute, Vi. 40:32.450 --> 40:34.730 Oh goodness, I'm having audio issues today. 40:34.730 --> 40:36.650 It's like the audio day of a howl. 40:38.150 --> 40:48.650 So my feelings on this is we can't even start facing the legacy problems until we stop making stupid decisions and choices going forward, right? 40:48.650 --> 40:54.270 We have to now nip this in the bud and say, going forward, we're going to do better. 40:55.370 --> 40:58.350 I haven't looked into a lot of other things. 40:58.350 --> 40:59.190 I've Googled it. 40:59.190 --> 41:00.170 I have read up on it. 41:00.170 --> 41:02.930 I'm very excited about what you guys are doing with Medtronic. 41:03.470 --> 41:08.430 That certainly is a step in the right direction, but visibility is key, right? 41:08.870 --> 41:15.130 Like Pete and I have had discussions where everyone's like, we don't know if the ICD or pacemaker has been attacked. 41:15.270 --> 41:18.570 Well, do you even have the data to know that that's happened? 41:18.570 --> 41:20.630 So we want to deal with legacy. 41:20.630 --> 41:27.470 We need to start getting visibility moving forward because otherwise we're adding this amount of... another year goes past. 41:27.470 --> 41:32.990 Now we have another group of legacy devices that's going to haunt us for 10 years, right? 41:32.990 --> 41:41.530 So get it right going forward and then start dealing, finding solutions for those devices that you don't have visibility on. 41:41.530 --> 41:50.170 Find ways to get eyes on your products and your data because where you have a blind spot is most likely where you're going to be attacked. 41:50.170 --> 41:53.690 And it's not like a nation state actor is going to say, you know what? 41:53.690 --> 41:55.830 I have owned your product, right? 41:55.890 --> 42:00.110 Researchers have the courtesy to come, you know, have a discussion. 42:00.230 --> 42:04.730 Very bad people looking to do bad, bad things aren't going to have that discussion with you. 42:04.730 --> 42:06.450 You're not going to know they're there. 42:06.870 --> 42:23.610 And if 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 explode their devices, which is why something I don't want to have happen. 42:23.610 --> 42:35.930 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 that kept me living, right? 42:35.930 --> 42:37.250 Otherwise I would be dead. 42:37.250 --> 42:39.610 It's as easy and as plain as that. 42:39.730 --> 42:43.370 It added years to my life I was not supposed to have. 42:43.490 --> 42:48.270 Take that technology away and as a human race, we go backwards. 42:48.270 --> 42:50.550 So patients need MDMs. 42:50.810 --> 43:03.050 Whether people in 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? 43:03.050 --> 43:06.470 It's important to understand that it's a love-hate relationship. 43:06.990 --> 43:22.210 You know, we're not all going to do it right, but if we can have the conversations and we can fight it out, we can find the solutions that are super cool and super techy and super new, we should try them, right? 43:22.610 --> 43:28.650 What I think Sternum is doing, what Pete's doing, is hitting the same problem from a different side. 43:28.650 --> 43:32.790 I'm concentrating more on how do we detect and log these things? 43:32.790 --> 43:34.090 How do I investigate it ? 43:34.090 --> 43:38.330 How can I, you know, have eyes on the prize sooner? 43:38.350 --> 43:39.770 That's my passion point. 43:39.770 --> 43:48.650 But we're all effectively covering this from a different side, which is good, because all sides are vulnerable and all sides are needed. 43:50.250 --> 43:53.110 And I think you're bringing it all together, right? 43:53.110 --> 43:55.190 Like, how can we get better visibility? 43:55.430 --> 43:59.250 And, you know, Natalie talked a little bit about this, but I'd like you to go into more detail. 43:59.250 --> 44:09.110 What are your thoughts around proactive controls in kind of the post-market, which is a term we just use for detection, logging, monitoring. 44:09.110 --> 44:17.290 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. 44:17.290 --> 44:20.350 So how do you see proactive controls fitting into that model? 44:21.210 --> 44:24.370 Yeah, it's a great question. 44:24.370 --> 44:31.570 And I think I want to learn from other industries, which already developed into this direction. 44:31.570 --> 44:44.790 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. 44:44.790 --> 44:49.730 And I see the medical space behaving the exact same way. 44:49.730 --> 45:00.570 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. 45:00.570 --> 45:08.650 And then I think that this kind of information and incident response should go into two main personas. 45:08.650 --> 45:12.150 One is the product security in the MDM. 45:12.150 --> 45:15.150 Monitoring is distributed device fleets. 45:15.150 --> 45:23.870 Understanding if somebody is researching this device, selling the device on eBay, maybe trying to hack into the information. 45:23.870 --> 45:28.150 These kinds of things can be visible with the right controls. 45:28.150 --> 45:40.910 And of course, there is a technological challenge of supporting old devices, old code base, which didn't come with visibility inside without logging, without monitoring, but that can be fixed. 45:40.910 --> 45:47.010 It can be installed post-market, and it's even easier to install it pre-market. 45:47.010 --> 46:01.330 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. 46:01.330 --> 46:09.130 Imagine an attack attempt just a month ago, there was a ransomware attack on hospital starting for a remote patient monitor. 46:09.190 --> 46:15.590 So the hacker penetrates to the internal network through the vulnerable IoT device. 46:15.590 --> 46:18.690 So imagine this device transmits information. 46:18.730 --> 46:23.550 Imagine this device is capable of detecting the attack attempt and even preventing it. 46:23.550 --> 46:36.390 Not only you prevented the attack, the hospital that moment become aware that is under attack and can act accordingly to secure other devices, maybe unpatched devices. 46:36.390 --> 46:52.110 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. 46:52.110 --> 47:00.190 So I think both personas benefit from this kind of visibility. 47:00.190 --> 47:08.910 And I think moving forward, we can use these kind of tools to embed security and visibility. 47:08.910 --> 47:25.270 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. 47:25.270 --> 47:34.530 A successful attack could lead to a little resource, and you don't have enough time to detect the attack and respond in a week or two weeks. 47:34.530 --> 47:39.870 Sometimes in enterprise, it takes six months to respond to a security incident. 47:39.870 --> 47:45.250 You don't have this kind of time in medical devices, so you have to block the attack in real time. 47:45.310 --> 47:48.270 The other aspect is really to become aware. 47:48.270 --> 47:57.970 And to become aware means to get alerted when something is behaving differently or suspiciously, or if there were a prevented attack attempt. 47:57.970 --> 48:14.830 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, 48:14.830 --> 48:23.390 you're capable of providing fast response to alert your patients, to alert the hospital, to update the devices with a patch. 48:23.430 --> 48:34.930 So I think it's an essential thing that we need to embed into the medical space, and we're on it. 48:36.090 --> 48:43.870 I love that, because I think we're starting our journey to improve our visibility, improve our prevention in near real time, improve our detection capabilities. 48:43.870 --> 48:55.530 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, right, to the example you gave about the ransomware outbreak. 48:55.530 --> 49:02.210 And just, you know, having dealt with ransomware myself in a past life, you know, obviously, time is of the essence. 49:02.210 --> 49:10.090 And, you know, 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. 49:11.090 --> 49:13.570 So V, I want to switch gears a little bit. 49:13.850 --> 49:23.030 We're talking about all different types of aspects of, you know, security controls and capabilities to give back, but you have a unique forensics background. 49:23.190 --> 49:29.750 How does that make you approach device security differently than, say, you know, the traditional vulnerability disclosure scenarios? 49:31.310 --> 49:36.310 Yeah, so I think forensics is this unique focus on scientific processes. 49:36.310 --> 49:42.370 I think that's the one thing that was hammered into my head is we need to follow a scientific process. 49:42.370 --> 49:45.950 So you need to look at it from every aspect. 49:45.950 --> 49:54.930 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. 49:55.030 --> 50:00.190 So I always say, we have a saying in forensics, we find the truth. 50:00.190 --> 50:02.410 So we reconstruct what's happened. 50:02.410 --> 50:07.770 So I decided to actually start re-achieving, so learning how to attack. 50:07.770 --> 50:10.070 And then I learned how to defend. 50:10.170 --> 50:12.970 And then I learned how to investigate. 50:13.010 --> 50:25.530 And taking that, I decided to start applying that type of mindset of taking a multidisciplinary view to things, saying, OK, well, I want to know if we're being attacked. 50:25.590 --> 50:32.310 I'm kind of tired of having, you know, it told me that we don't have any data that supports any attack. 50:32.630 --> 50:38.210 And now knowing that we don't have the data actually available. 50:38.210 --> 50:45.370 So to have more visibility, we can start seeing whether devices are actually currently being attacked. 50:45.590 --> 50:47.230 Because we don't know. 50:47.230 --> 50:53.030 I spoke to multiple coroners around the world through law enforcement agency contacts. 50:53.030 --> 51:03.210 And the question I said to them, if you have a cardiac patient that has an implantable, right, they've passed away, doesn't necessarily mean that it's, you know, suspicious circumstances. 51:03.210 --> 51:14.190 But do you, do you, you know, get a program, pull the data, look for the time of death, look of any strange, the device itself. 51:14.210 --> 51:24.350 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. 51:24.350 --> 51:30.810 But people forget that programmers can be compromised and something can happen from a programmer to a device. 51:31.230 --> 51:35.370 And we don't leverage the information that we have. 51:35.470 --> 51:55.170 So the important thing for me is we have no ability at the moment, unless a researcher comes to an NDM, or someone makes a grand gesture that they've hacked a device, unless it causes chaos, or becomes public, somehow, we don't know. 51:55.270 --> 52:03.950 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. 52:03.950 --> 52:07.630 I mean, the LaCroix principle is a big thing that I live my life by. 52:07.770 --> 52:12.690 So everything that comes into connection with each other leaves a trace evidence. 52:13.030 --> 52:14.370 I want to know what it is. 52:14.370 --> 52:21.610 But if we don't have visibility, right, it's there, but we don't have the capabilities to make it visual. 52:21.770 --> 52:29.130 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. 52:29.850 --> 52:41.150 So that's my approach to what I'm doing with Medtronic is I'm assessing what you have, what we need, and holding ass to get there. 52:42.090 --> 52:49.690 And I'm seeing it come together with the various aspects that you guys have brought together, you know, covering it from different angles. 52:49.910 --> 52:54.490 And the forensics in me is like saying, we can apply forensics in development. 52:54.490 --> 52:58.070 You know, we can apply forensics pre-market, post-market. 52:58.070 --> 53:04.990 It doesn't necessarily mean it's an investigation, but it's creating the evidence that we need for the future. 53:05.370 --> 53:09.070 That's creating the data now for when we do need it. 53:09.890 --> 53:18.970 You know, I'm always drawn to the example of Microsoft and how they used other data sets to detect a large Windows vulnerability. 53:18.970 --> 53:22.510 And I think really was mining data in Windows event reporting. 53:22.510 --> 53:28.190 And I know that a big piece of what we're thinking about is we have a lot of remote monitoring information. 53:28.190 --> 53:35.010 We know what is above the line and what's below the line, and we're trying to develop that anomaly detection there. 53:35.010 --> 53:38.530 And it can't only be done with that type of detection. 53:38.530 --> 53:40.290 That's one leg in the stool. 53:40.290 --> 53:51.370 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. 53:51.370 --> 53:53.970 And all of you have hit on that element. 53:53.970 --> 53:57.470 And I think it's not to discount testing or threat modeling. 53:57.470 --> 53:59.830 All of that has to happen as well. 53:59.830 --> 54:08.830 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. 54:08.830 --> 54:09.970 And what can we learn from that? 54:09.970 --> 54:11.630 And I just, I really think that's important. 54:11.630 --> 54:15.510 And all of you have been bringing a different element of that to this discussion. 54:15.510 --> 54:21.210 And it's helping us, I think, learn as a medical device manufacturer how to handle this situation. 54:21.810 --> 54:23.910 Yeah, I'm always... Sorry. 54:24.330 --> 54:25.550 I'm sorry. 54:25.610 --> 54:29.550 I always say data doesn't lie, right? 54:29.910 --> 54:33.810 There's a saying, let's follow the money or follow the evidence. 54:34.410 --> 54:37.670 But we have so much data, we're just not mining it. 54:37.670 --> 54:38.910 We're not learning. 54:39.090 --> 54:45.850 I think it's one of your members, Sasha, that said, we need to learn to listen, right? 54:45.850 --> 54:48.770 So we need to learn what the data is telling us. 54:48.950 --> 54:50.730 And I think that's the big thing. 54:51.230 --> 54:55.450 We have all this data, but we're not listening to it. 54:56.430 --> 55:03.150 And once we start intuitively tuning in and understanding the data, those numbers don't lie. 55:03.410 --> 55:07.830 Then actually, I think an MDM can only really do threat analysis. 55:08.610 --> 55:15.090 Because if you don't know what you have, how do you know what to protect? 55:15.230 --> 55:17.590 Because then you're always on the back foot, right? 55:17.590 --> 55:19.090 You need to get ahead of the problem. 55:19.090 --> 55:21.450 You need to know where you're most vulnerable at. 55:21.450 --> 55:25.330 You shouldn't wait for that to become public knowledge. 55:28.070 --> 55:30.770 So I want to shift gears one more time here. 55:30.930 --> 55:34.770 We hear the concept of zero trust in medical devices. 55:35.250 --> 55:38.810 And I believe each of you are on the same topic. 55:39.170 --> 55:45.350 How do you think that concept can be applied from an MDM perspective or from a medical device perspective? 55:45.350 --> 55:46.530 And I'll throw that out to the group. 55:46.530 --> 55:49.870 Whoever wants to latch onto that one can start us off. 55:55.190 --> 55:56.530 Okay, I'll roll with it. 55:56.530 --> 55:57.750 I was waiting for you, V. 55:59.070 --> 56:01.250 Pete, I know you got some insight on this, too. 56:01.750 --> 56:02.410 Go ahead. 56:02.410 --> 56:04.010 I love zero trust. 56:04.010 --> 56:10.670 It makes me excited because for once we turn security on its head and say, you know, we're not going to trust but verify. 56:12.210 --> 56:15.390 That's not going to be... we're just not going to trust, right? 56:15.670 --> 56:20.690 Because the nice thing about zero trust is you can actually understand devices. 56:21.050 --> 56:24.350 But the ideal thing is now we don't have a perimeter. 56:24.410 --> 56:26.370 We harden everything. 56:27.230 --> 56:36.370 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? 56:36.370 --> 56:45.070 It's like a patient monitor doesn't have to be on the Wi-Fi and doesn't have to link to the accounting system or, you know, patient records. 56:45.070 --> 56:51.170 We have this thing trying to make everything accessible but too accessible. 56:51.170 --> 56:52.950 We take it to the extremes. 56:52.950 --> 56:58.510 We either make it too secure and unusable or we go to the other way. 56:58.510 --> 57:08.530 But zero trust has really big plus points for me because now we can attend to device manufacturers independently, right? 57:08.530 --> 57:15.190 We're not going to have the same controls across the board because everyone builds their devices different. 57:15.350 --> 57:20.490 You can understand the device and apply the appropriate rules, privilege, and access. 57:20.490 --> 57:29.290 So I think this is a really good solution as we move to a perimeterless remote monitoring and medical service. 57:29.290 --> 57:41.750 I mean, I had my first video consultation today which is something very strange but yet it felt normal and the perimeter has just been broken. 57:41.750 --> 57:51.510 COVID-19 came in, swept healthcare off its feet and we are facing new territory we'll be having to build while trying to catch up. 57:51.510 --> 58:02.130 And this virus has crippled healthcare and I think security should never put such a strain on healthcare that we cripple it more. 58:02.130 --> 58:05.850 We should be making it safer and easier to use. 58:05.910 --> 58:09.730 And that's our responsibility as security people in this field. 58:10.030 --> 58:12.890 It's the responsibility of the MDM. 58:12.890 --> 58:22.010 But zero trust is the ability to do catered security based on a device, not necessarily the same rule for everyone. 58:22.010 --> 58:24.670 So I'm very excited about it. 58:25.070 --> 58:38.330 So I agree with you and I have a slightly different interpretation of zero trust in the concept of medical devices. 58:38.330 --> 59:00.630 For me, zero trust basically means we talked earlier about third parties and we talk about embedding communication models within the code and communicating with the patient's mobile app and the patient's maybe home router, you know, each medical device with its communication. 59:00.690 --> 59:05.550 And I think zero trust should really mean that we can't trust any of those. 59:05.550 --> 59:09.850 We can't trust any of the third party, open source, closed source, embedded. 59:09.850 --> 59:17.350 We can't even trust the operating system that a medical device use, whether it's commercial one, Linux based. 59:17.350 --> 59:23.430 We should be expecting vulnerabilities throughout the entire supply chain. 59:23.490 --> 59:28.890 The code, the hardware, the software within the hardware. 59:28.890 --> 59:35.030 And of course, we can't trust that the patient didn't install a malicious application on his mobile, right? 59:35.030 --> 59:41.070 Like the last thing we want to trust is the human being not making mistakes. 59:41.450 --> 01:00:05.970 So 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. 01:00:05.970 --> 01:00:15.890 Like if we talk about the insulin pump, so you want the functionality of injecting insulin will be the most protected functionality of the device. 01:00:16.390 --> 01:00:21.370 Same goes for personal health information on the device itself. 01:00:21.370 --> 01:00:28.870 So for me, zero trust basically means taking this into consideration when designing a security solution. 01:00:30.710 --> 01:00:31.450 Exactly. 01:00:31.450 --> 01:00:34.350 I like what Natalie said. 01:00:35.350 --> 01:00:37.630 I think it's the difference in design. 01:00:38.070 --> 01:00:52.710 And some of you might be, I talk about this all the time, every time someone will listen, but I look at it as a concept of, I think a great example is like cars. 01:00:53.390 --> 01:01:01.930 When these systems were built to allow a computing interface in a car, they weren't connected to anything. 01:01:02.610 --> 01:01:04.710 And they designed according to that. 01:01:04.710 --> 01:01:06.910 And they scaffolded this over years. 01:01:06.910 --> 01:01:11.210 And then all of a sudden, someone came along and tacked on internet connections and Bluetooth and Wi-Fi. 01:01:12.850 --> 01:01:17.670 What you should do is go back and redesign everything to consider that new approach. 01:01:17.670 --> 01:01:29.650 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. 01:01:29.650 --> 01:01:42.230 And it's an analogy to what I think 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. 01:01:42.770 --> 01:01:50.910 And building to consider that takes concerted effort from the start, from the very, very start. 01:01:51.290 --> 01:02:04.530 And 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. 01:02:06.870 --> 01:02:08.930 Everyone's going to have to get there. 01:02:09.830 --> 01:02:18.590 The quicker a manufacturer of any kind of product can start considering that, the easier their life is going to be in the long run. 01:02:20.950 --> 01:02:30.590 I must add just one thing about that, because I think we are repeating a lot of think about it in advance. 01:02:30.590 --> 01:02:31.950 You have to design it. 01:02:31.950 --> 01:02:34.490 I must mention the other side. 01:02:34.550 --> 01:02:42.150 Security has always been the last part to be incorporated into things. 01:02:42.150 --> 01:02:45.030 Everybody would like to go to market faster. 01:02:45.030 --> 01:02:48.730 Everybody likes to just build their devices, build their technology. 01:02:48.730 --> 01:02:51.090 Nobody likes to think about security. 01:02:51.110 --> 01:02:56.150 And I'm saying it's okay, meaning I don't want to say you have to think about it in advance. 01:02:56.150 --> 01:02:56.930 You don't. 01:02:56.930 --> 01:03:01.650 History teaches us that nobody thinks about everything in advance, and it's okay. 01:03:01.650 --> 01:03:04.750 And security comes last, always. 01:03:05.030 --> 01:03:20.230 So for me, as someone who's 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. 01:03:20.230 --> 01:03:29.530 And 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. 01:03:30.350 --> 01:03:32.430 Nobody holds you responsible. 01:03:32.430 --> 01:03:38.430 I will hold you responsible only if you didn't try to fix it later on. 01:03:39.010 --> 01:03:40.810 Oh, dude, I'm sorry. 01:03:40.810 --> 01:03:42.110 I have to disagree there. 01:03:42.110 --> 01:03:49.070 Like, I want to kick some, you know, I sometimes want to kick an Indian's ass and say, what the hell were you thinking? 01:03:52.910 --> 01:03:54.450 That's what's happened there. 01:03:54.450 --> 01:03:55.370 It depends. 01:03:56.390 --> 01:04:04.250 It's like you have how could it pass for like one, two, three, four, then this is the place where you can think, what the hell were you thinking? 01:04:04.250 --> 01:04:11.190 I'm just saying, you know, the more advanced stuff, it's harder to think about. 01:04:11.890 --> 01:04:13.910 Yeah, so it's a twofold problem. 01:04:13.910 --> 01:04:16.790 We're dealing with legacy, right? 01:04:16.830 --> 01:04:22.690 I call it the legacy, because that's what it's written in, that joke for the evening. 01:04:23.830 --> 01:04:30.250 So the problem is we have, we have to stop developing legacy problems, okay? 01:04:30.250 --> 01:04:32.950 So we need to address it ahead of time. 01:04:32.950 --> 01:04:37.750 But okay, we have to face the fact that previously, we didn't address it ahead of the time. 01:04:37.750 --> 01:04:39.690 And there's nothing you can do. 01:04:40.090 --> 01:04:45.010 Can't pull these things back on, tell me you're going to cut me open, take my device back, give me a new one. 01:04:45.050 --> 01:04:47.070 I'm not going to let that happen. 01:04:47.810 --> 01:04:50.010 So we have to deal with that. 01:04:50.310 --> 01:04:51.910 It's a twofold problem. 01:04:52.170 --> 01:04:56.930 We have to be realistic, meaning I think you are completely correct. 01:04:56.930 --> 01:05:06.110 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. 01:05:06.350 --> 01:05:14.870 And like in the 50 years prior to where we stand today, companies didn't think about it in advance. 01:05:14.870 --> 01:05:19.770 So we can teach that, we can say that, but to be realistic, I don't think it's going to happen. 01:05:19.770 --> 01:05:25.190 People will only handle the problem once it bites them in the ass, basically. 01:05:25.830 --> 01:05:27.710 That's human nature, right? 01:05:27.830 --> 01:05:32.630 I can't disagree with you because history often repeats itself. 01:05:32.630 --> 01:05:39.890 I think what's interesting is we're covering it like a triangle from different sides, which is very interesting. 01:05:39.890 --> 01:05:43.890 I'm concerned with, we have these devices that are diversified. 01:05:43.890 --> 01:05:47.450 How do we include this on a healthcare network, right? 01:05:47.450 --> 01:05:52.490 Naki's product literally deals with legacy devices and new devices. 01:05:53.090 --> 01:05:56.270 And Pete's solution covers it from a different angle. 01:05:56.310 --> 01:06:03.090 So it's this like diversified opinion that's doing the same thing, but each in a different way. 01:06:03.470 --> 01:06:08.250 And this is why I think researching is important because we all think differently. 01:06:09.370 --> 01:06:12.630 So it's having, yeah, it's a big problem. 01:06:12.670 --> 01:06:13.610 It's massive. 01:06:14.410 --> 01:06:16.610 I think, yeah, I agree with what you're saying. 01:06:16.610 --> 01:06:18.910 We're all kind of coming at it from a little bit of a different perspective. 01:06:18.910 --> 01:06:26.650 And I do agree, Natalie, that there's going to be new attacks we haven't thought of today that come out in the next year, three years, five years. 01:06:27.610 --> 01:06:30.270 But we're talking about medical devices today. 01:06:30.270 --> 01:06:36.790 And I think we absolutely have to require better work on the design. 01:06:37.950 --> 01:06:49.490 We got here because of the evolutionary walk of how medical device manufacturers built businesses to help patients. 01:06:49.710 --> 01:06:51.770 And computers came part of that. 01:06:51.770 --> 01:06:53.230 And here we are. 01:06:53.690 --> 01:06:56.390 How we go forward, though, can be changed. 01:06:56.430 --> 01:07:06.110 And I think the idea that we'd be accepting to someone not working hard at that right now is dangerous. 01:07:07.130 --> 01:07:14.570 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. 01:07:16.810 --> 01:07:20.870 The next thing that shakes the industry, so to speak. 01:07:20.970 --> 01:07:22.730 And we want to be resilient to that. 01:07:22.730 --> 01:07:24.190 I completely agree. 01:07:24.190 --> 01:07:32.970 But in one case, when I was looking at a medical device, I then started reverse engineering an e-bike. 01:07:33.270 --> 01:07:38.530 And the e-bike was orders of magnitude better. 01:07:38.630 --> 01:07:48.590 Because the e-bike wanted to prevent someone from bypassing the speed controller and going too fast on the bike that it wasn't regulated for. 01:07:49.270 --> 01:07:52.010 And they did an incredible job for that. 01:07:52.010 --> 01:07:57.490 But seeing the stark contrast between those two, the difference there was they designed it to be that way. 01:07:57.510 --> 01:08:00.910 And I know I harp on that a lot, but I think that's an important point. 01:08:00.970 --> 01:08:04.770 I think we can all agree that there's some fundamentals that we need to align with. 01:08:04.770 --> 01:08:13.150 I think this is why we want this diverse experience, background, opinions, because it helps us grow in the industry. 01:08:13.150 --> 01:08:19.850 And we have time for one quick final question here, and I'll go around the panel and start out with you, Pete. 01:08:20.290 --> 01:08:27.070 How can researchers, smaller shops, those attending the Biohacking Village, get more involved with device makers? 01:08:29.730 --> 01:08:32.970 The way I'd put it was eBay and calling. 01:08:33.210 --> 01:08:44.130 I think there would be a lot that could be improved if there's a way to get your hands on research devices to start learning this space. 01:08:44.130 --> 01:08:56.190 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. 01:08:56.490 --> 01:09:04.670 And something like when you find a bug and you suggest a fix for it, the realities at scale of making that happen. 01:09:05.450 --> 01:09:19.310 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. 01:09:19.330 --> 01:09:26.730 And on the other hand, I think there'd be a great spot for education on the MDM side to show what is it we're going to do. 01:09:26.730 --> 01:09:30.450 We need to do a hypothetical patch to this hypothetical device. 01:09:30.450 --> 01:09:32.130 What does it actually look like? 01:09:32.310 --> 01:09:47.450 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. 01:09:47.450 --> 01:09:56.930 Especially coming from a place of like the hacker ones and the bug crowds where that's a pretty smooth process when you're looking at web properties, right? 01:09:56.930 --> 01:09:59.870 And it's a very, very different industry. 01:09:59.870 --> 01:10:00.770 It's a very different threat model. 01:10:00.770 --> 01:10:02.910 It's a very different process you have to go through. 01:10:02.910 --> 01:10:05.310 And I think there's an education opportunity for that. 01:10:05.970 --> 01:10:09.270 Natalie, I know you've had your journey with medical device manufacturers. 01:10:09.270 --> 01:10:10.090 Same question to you. 01:10:10.090 --> 01:10:15.150 How do you think that researchers in smaller shops can get more involved in making a difference? 01:10:16.190 --> 01:10:44.090 So I completely agree with Peter, and I think that bug bounties programs and exposing the inner processes that happen within medical device development, which is extremely different from traditional development with different regulations and different constraints could help getting more engaged. 01:10:44.090 --> 01:10:49.370 I think assigning a person or a unit responsible for that is also super important. 01:10:49.370 --> 01:10:54.170 In some of the medical devices, you just don't know who is the right person to approach. 01:10:54.450 --> 01:10:55.850 It's not the CISO, right? 01:10:55.850 --> 01:10:58.990 The CISO is not concerned about medical device security. 01:10:58.990 --> 01:11:00.610 It's concerned about the network. 01:11:00.970 --> 01:11:07.770 So I think getting this better approach is good. 01:11:07.950 --> 01:11:09.450 Transparency is good. 01:11:10.210 --> 01:11:13.390 Basically saying, we want you involved. 01:11:13.390 --> 01:11:14.390 We're okay with it. 01:11:14.390 --> 01:11:22.330 We're not going to send you some terrifying legal documents if you find something. 01:11:22.330 --> 01:11:24.870 This can be helpful. 01:11:25.310 --> 01:11:34.050 And I think the research community, maybe thinking about it in a different direction, can also help educate. 01:11:34.150 --> 01:11:53.270 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. 01:11:53.270 --> 01:11:55.610 We had this experience with Medtronic as well. 01:11:55.610 --> 01:11:56.650 It was amazing. 01:11:56.650 --> 01:11:59.510 It was super satisfying for us. 01:11:59.510 --> 01:12:34.450 And I believe that it was also interesting for medical device 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 And this could really be an open-minded and open-hearted conversation, 01:12:34.450 --> 01:12:37.830 which we had, and I think is a great example. 01:12:37.830 --> 01:12:40.190 And it's not very common. 01:12:40.270 --> 01:12:51.430 I mean, device manufacturers, OEMs, some of them do not respond well when researchers approach them with vulnerabilities. 01:12:51.710 --> 01:13:02.530 And I think positioning yourself as an MDM saying, we respect that, we want to work with you is amazing, and it's the right approach. 01:13:03.770 --> 01:13:06.690 Last but not least, Vi, you get the final word. 01:13:07.530 --> 01:13:08.590 Oh, awesome. 01:13:09.290 --> 01:13:15.810 I'm going to do a call out to all my fellow biohackers, my friends, my goons, my family. 01:13:16.390 --> 01:13:37.250 Biggest thing I've learned that the constraints with dealing with vulnerabilities from an MDM's perspective is when you do a proof of concept, okay, approach this like a report, approach it like scientifically, give as much information, as much code as you can for the MDM. 01:13:38.130 --> 01:13:41.910 They need to verify what you have said. 01:13:41.910 --> 01:13:52.710 And if your document doesn't consist of information that is comprehensive and easy to follow, they're going to have to reverse engineer things themselves. 01:13:52.710 --> 01:14:02.530 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. 01:14:02.830 --> 01:14:07.990 So if you come with a problem, come with a solution, right? 01:14:07.990 --> 01:14:11.390 Let's not just focus on what we've broken, let's try and fix it. 01:14:11.390 --> 01:14:17.610 So my challenge to all my hacker friends are, let's not just try to break things, let's try and solve things. 01:14:18.230 --> 01:14:23.290 For me, the term hacker is obviously sometimes associated with cyber criminal. 01:14:23.450 --> 01:14:26.930 And for me, it's a passion point because hacking is what I do. 01:14:26.930 --> 01:14:28.110 I'm not a criminal. 01:14:28.730 --> 01:14:34.470 I try and figure out what's wrong so that I can fix it using alternate ways and means of thinking. 01:14:34.470 --> 01:14:35.910 That's what a hacker does. 01:14:35.910 --> 01:14:38.150 That is what a hacker is for me. 01:14:38.730 --> 01:14:43.490 But we're also scientists and in science we need to be thorough. 01:14:43.490 --> 01:14:45.430 We need to do the approach better. 01:14:45.530 --> 01:14:48.470 And for an MDM, don't be such hard asses. 01:14:48.470 --> 01:14:49.890 We're trying to help. 01:14:50.230 --> 01:14:53.250 I promise you we're not your enemy, right? 01:14:53.250 --> 01:14:54.930 Just be a little bit nicer. 01:14:55.070 --> 01:14:56.650 I have a conversation. 01:14:56.870 --> 01:14:58.290 Buy someone a coffee. 01:14:58.290 --> 01:15:05.770 If you see someone at Biohack Village, I promise you I haven't had a hacker that bites unless asked to bite. 01:15:05.770 --> 01:15:06.550 Right? 01:15:06.550 --> 01:15:07.950 We don't like having teeth. 01:15:07.950 --> 01:15:11.890 We like having tech conversations and we like geeking out with you. 01:15:12.030 --> 01:15:14.230 But it comes from both ways. 01:15:14.230 --> 01:15:20.450 We both need to open our hearts and open our minds and realize we're working towards the same ideal. 01:15:20.690 --> 01:15:24.390 And working against each other is not going to get us there any sooner. 01:15:24.470 --> 01:15:27.590 And from a patient's side, keep on doing the research. 01:15:27.590 --> 01:15:29.590 Make this stuff better. 01:15:30.310 --> 01:15:33.190 Because I think either party needs each other. 01:15:33.190 --> 01:15:34.110 It's a trifecta. 01:15:34.110 --> 01:15:35.570 It's the medical manufacturer. 01:15:36.130 --> 01:15:41.730 And it's the FDA or the regulatory body, depending on where you're from. 01:15:42.190 --> 01:15:44.710 Those are the things that are going to make the future better. 01:15:44.710 --> 01:15:46.770 And those are basic engineering practices. 01:15:46.770 --> 01:15:49.910 A triangle is the strongest thing you can enforce something with. 01:15:49.990 --> 01:15:52.210 So let's enforce this with teamwork. 01:15:52.210 --> 01:15:53.790 That's all I have to say. 01:15:54.250 --> 01:15:55.110 V out. 01:15:55.150 --> 01:15:57.450 With that, I want to thank the panel. 01:15:57.450 --> 01:15:58.730 Drop the mic. 01:15:58.730 --> 01:16:01.850 Pete, Natalie, V, we're good to go. 01:16:01.950 --> 01:16:04.130 Have a good DEF CON Biohacking Village, everyone. 01:16:04.130 --> 01:16:04.990 Thank you. 01:16:04.990 --> 01:16:06.670 Thank you very much.