[00:00.000 --> 00:09.480] Hi everyone, and welcome to How Do We Uniform November Foxtrot Uniform Charlie Kilo Unfuck [00:09.480 --> 00:17.920] Things. Can we really unfuck these things, or is it GARFU? And for those that don't know [00:17.920 --> 00:26.540] the military slang, this is... well, go Google it. It's more fun, right? I don't want to [00:26.540 --> 00:34.520] tell it all to you guys. Just go Google that. This talk is not your normal talk, right? [00:34.520 --> 00:39.240] This is an interpretive dance. This is me getting on my soapbox because I'm five foot [00:39.240 --> 00:44.700] nothing and tell you all the things that needs to be unfucked. This is my own opinion. This [00:44.700 --> 00:48.800] is no one else's opinion. This is conversations that have been had. This is observations that [00:48.800 --> 00:54.580] have been made. So if you're easily offended, this is not the talk for you. Scroll past, [00:54.580 --> 01:05.520] go do some other fluffy stuff. So who am I? I am a DEFCON goon. I'm the founder of DEC2751. [01:05.620 --> 01:13.020] We solely focus on reverse engineering medical devices and making things better. I'm also [01:13.020 --> 01:19.360] an avid biohacker village supporter. I think this is the best village at DEFCON. It's the [01:19.360 --> 01:26.120] one I certainly most enjoy. I'm also a current and independent researcher for Medtronic. And [01:26.120 --> 01:33.720] as you can see in the beautiful picture on the right, that is my Medtronic ICDR. It's what keeps [01:33.720 --> 01:40.840] me breathing and kicking and doing all the things. I'm also a DFIR lethal forensicator. I've been [01:40.840 --> 01:46.660] doing forensics and incident response for many, many years. Yes, I look very young, but I'm much [01:46.660 --> 01:52.560] older than I look. I'm a member of I Am The Calvary. I'm a patient and I proudly refer to [01:52.560 --> 02:02.080] myself as a cyborg. Now, I wanted to do a different talk this year because I believe that if we know [02:02.080 --> 02:09.540] what is wrong, we can find ways to fix them. So this is the talk for all medical device enthusiasts. [02:09.540 --> 02:14.550] Those that want to unfuck the things, those that want to fix it and make it better. [02:16.080 --> 02:22.600] So let's talk about the legacy of all problems, right? I sat down the day and I did the maths. [02:22.600 --> 02:30.320] In the US alone, there are 600,000 new implantable devices every year. These devices [02:30.980 --> 02:37.260] last for approximately a decade. So you start adding these up, [02:37.260 --> 02:44.420] we have a whole sea of devices that sooner or later will add to our technical debt. [02:45.220 --> 02:52.440] In a single hospital, if you put all the devices together within a hospital in the US, [02:52.440 --> 02:59.320] we'll have 10 to 15 million connected medical devices. That's about 10 to 15 connected devices [02:59.320 --> 03:06.340] per patient bed. To give you an example, I was in ICU because often than not, my heart's an asshole. [03:07.010 --> 03:14.180] And it lands me into ICU for some TLC, right? So I go have my holidays. If you look around, [03:14.180 --> 03:21.220] you have infusion pumps, you have monitors, you have external monitors monitoring your pacemaker [03:21.220 --> 03:31.700] or your ICD. And you have central stations. It is this big ocean of leaping lights. I know Jason [03:31.700 --> 03:38.120] Street always refers to it as a box with lengthy lights. Well, go be in an ICU bed, you'll see lots [03:38.120 --> 03:44.380] of those. So when we start realizing how many hospital beds there are, how many devices are [03:44.380 --> 03:50.440] attached to those beds, we start seeing the magnitude of the legacy. We see the ocean of [03:50.440 --> 03:57.580] devices we are faced to protect or to fix. Now, this is what led me down this path, [03:57.580 --> 04:02.540] is that I think we should start fixing the ship now. We can't wait for another year, [04:02.540 --> 04:05.840] can't wait for two, because we're adding to our problem. [04:07.380 --> 04:11.460] And now as we've seen COVID, healthcare has changed forever. [04:11.820 --> 04:15.720] The boundaries have been broken, the perimeters no longer exist. [04:17.900 --> 04:23.620] So you wonder why I say the legacy. Well, in case you did not know, most medical devices are coded [04:23.620 --> 04:35.630] in C. So I decided to do a dad joke. The question is, how are we getting it so wrong? And yeah, [04:35.630 --> 04:42.810] this someone said that someone was me. I want to know why in three years we've made no strides or [04:42.810 --> 04:49.350] why in three years we're doing the same things over and over. Well, let's start at the beginning. [04:49.490 --> 04:55.050] Lack of clear definitions. There's no consistencies in the terms that we use. [04:55.650 --> 05:02.910] I often go to talks and I realize, well, we're talking about medical device security, but the [05:02.910 --> 05:08.910] more that we are listening, I realize it is a Windows 10 endpoint within a healthcare establishment [05:08.910 --> 05:15.670] that we're talking about. Surely that's not the same as an insulin pump, an infusion pump, or even [05:15.810 --> 05:22.430] a pacemaker. Those things don't even look or act the same. So I decided to do what any good researcher [05:22.430 --> 05:28.630] does and I went to the dictionary. I looked up the terms. So let's explore healthcare. [05:29.430 --> 05:35.250] The field concerned with the maintenance and restoration of the health of the body and mind. [05:37.330 --> 05:43.490] It's hard, but this is what healthcare does. This is what hospitals do. [05:44.010 --> 05:50.610] So surely any device that they put there to help facilitate this should be called a healthcare [05:50.610 --> 05:59.490] device. So let's explore what is the meaning of medical relating to medicine or the practice of [05:59.490 --> 06:06.110] medicine. So it is something that allows us to practice medicine. Healthcare is something that [06:06.110 --> 06:14.330] we give to our patients. For me, I started to see the clear separation between the two. [06:14.530 --> 06:19.970] Each one has different responsibilities. Each one has a different function. It is very important [06:19.970 --> 06:26.390] that we start differentiating from the two. An interesting useless fact. Did you know that [06:26.530 --> 06:33.490] a cotton swab is seen as a medical device? Yes, that is for ICD-10 and billing purposes. [06:34.310 --> 06:37.970] I sure as hell don't think it's a device. I think it's a disposable. [06:38.010 --> 06:43.970] It's something we only use once. So let's see. What is a device? [06:43.990 --> 06:49.430] Something contrived for a specific purpose, usually a simple mechanical apparatus. [06:49.970 --> 06:57.250] Okay, so your insulin pump, your pacemaker, those are all a device, right? [06:57.790 --> 07:03.830] Well, now the question is, is it medical or is it healthcare? We need to start differentiating [07:03.830 --> 07:09.830] because each one of the two have different controls, different threats, different weaknesses [07:09.830 --> 07:16.470] and vulnerabilities. In fact, they have different operating systems. We need to clearly understand [07:17.070 --> 07:23.850] what we are dealing with. Now the question is, is it a healthcare or a medical device? [07:23.850 --> 07:31.090] Which button will you choose? Which one will you use? I get very confused because we're using the [07:31.090 --> 07:36.930] same terminology for everything because medical device sounds much more sexier than a healthcare [07:36.930 --> 07:44.450] endpoint or a healthcare device. But that leads me to the point that if we don't start defining [07:44.450 --> 07:51.050] these things out and understanding the ecosystem we are set to protect, we are setting ourselves [07:51.050 --> 08:01.150] up for a hiding. We are literally looking to be spanked. This is something that I'm living my [08:01.150 --> 08:05.950] life towards. When you talk, you are only repeating what you know, but when you listen, [08:05.950 --> 08:13.230] you learn something new. So I went on a year-long journey to understand what devices are telling me. [08:13.230 --> 08:17.370] I wanted to know what secrets they hold. [08:20.220 --> 08:27.260] Why things are so wrong is that we're not assigning responsibility accurately. I know [08:27.260 --> 08:31.560] it's a word that everyone fears because no one wants to be accountable or responsible [08:32.160 --> 08:38.760] for decisions or things they fault. So let's explore the MDM or the medical device [08:38.760 --> 08:47.220] manufacturer's responsibility. They have a responsibility to create devices that aren't [08:47.220 --> 08:51.900] unhackable because let's face it, nothing's unhackable. Everyone gets bored and someone [08:51.900 --> 09:00.280] figures out how to hack a device. But they need to have a device that is secure or as secure and [09:00.280 --> 09:07.100] safe as you can have it. But their responsibility is to deal with the devices both pre-market and [09:07.100 --> 09:13.940] post-market. Meaning that if a vulnerability is found pre-market, they need to fix it before going [09:13.940 --> 09:19.380] to market with the device. They need to do everything in their power to make sure what [09:19.380 --> 09:24.280] they are building, both on a firmware and a hardware level, takes into consideration the [09:24.280 --> 09:30.880] security challenges as well as the clinical features. Because let's face it, security is [09:30.880 --> 09:37.080] not a functional requirement for medical devices. They are there to offer medical care to patients. [09:38.000 --> 09:44.440] Often we see that security is slapped on after the fact, where it should be coming from design [09:44.440 --> 09:51.560] throughout manufacturing to when it goes to market. Now we have a fairly secure device that's [09:51.560 --> 09:58.580] gone to market. For example, an ICD lasts for 10 to 15 years. I can almost guarantee you that in [09:58.580 --> 10:04.500] that time, someone will find a vulnerability. Now we need to fix that vulnerability. [10:05.200 --> 10:11.500] The hospital or healthcare establishment has no power to fix the firmware or even fix the [10:11.500 --> 10:17.690] physical device if there's a vulnerability found. This remains the MDM's responsibility. [10:18.420 --> 10:23.400] Part of their responsibility is having a catalog or register of the information on everything that [10:23.400 --> 10:29.180] goes into their products. For every product they put on market, they have responsibility [10:29.180 --> 10:32.560] towards the end of the lifetime of that device. [10:33.380 --> 10:39.280] If it breaks, they are the only ones that have the power to fix it. No one else. [10:41.200 --> 10:51.500] Now we get to what is the FDA's responsibility? Well, I say the FDA because it's a US conference, [10:51.500 --> 10:57.400] but everyone follows suit of the FDA. If you start researching medical legislation around the world, [10:57.400 --> 11:02.740] you will see the terminology used by the FDA being rolled out in other countries, [11:02.740 --> 11:07.220] meaning they are the leader in this. They are the one that everyone looks up to. [11:07.720 --> 11:15.760] They need more legislative power. They need more teeth. They need to be an enforcer of [11:15.760 --> 11:23.380] what the standard is. They're the one that has to keep the MDM's on track. They are the ones [11:23.380 --> 11:28.500] that gatekeepers to the market for products. They are the ones that need to enforce the [11:28.500 --> 11:35.480] fixing of the problem. I know that they're currently working on new guidances, and I [11:35.480 --> 11:41.820] surely hope that it's got more teeth. An example of this is in the guidances currently at state, [11:41.820 --> 11:48.440] reasonable risk analysis needs to be done. However, the reasonable analysis that is required [11:48.440 --> 11:55.600] for it to meet the reasonable test is not specified. So again, we have guidances that [11:55.600 --> 12:03.140] don't have enough detail or standards out. I'm hoping that from a legislative point of view, [12:03.140 --> 12:08.020] we can actually start setting the tone of what is expected from a medical device, [12:08.020 --> 12:14.440] both on a clinical and both at a security level. And this is not just for implantables. [12:14.440 --> 12:22.480] I know it's a little bit harder when it's inside someone, but let's start categorizing it. [12:22.480 --> 12:27.080] Let's start standardizing the things and setting up the rules of engagement. [12:28.020 --> 12:34.940] What is expected of a device? How should it be used and how it should be updated? These are [12:34.940 --> 12:41.520] things that only can be done by the FDA. They are the rule setters. They are the rule enforcers. [12:41.520 --> 12:50.620] Let me look at what is the HDO's responsibility. Their responsibility is to keep their patients [12:50.620 --> 12:59.520] alive. Their responsibility is to have these diversities of devices on their networks, [12:59.520 --> 13:07.200] but they have to implement them in a safe way, taking into consideration the type of device it [13:07.200 --> 13:14.240] is, how it communicates, and how they are going to introduce it into their ecosystem. [13:14.600 --> 13:22.480] Those are the responsibilities of the HDO. They do not hold a responsibility for updating firmware [13:22.940 --> 13:30.200] or even vulnerability management of devices. That should be a manufacturing role. [13:30.720 --> 13:39.460] We've seen that during COVID-19, HDO's are crumbling globally. Healthcare is fracturing. [13:39.820 --> 13:45.980] And the fact is that they are designed, their purpose is to deal with pandemics and viruses. [13:46.240 --> 13:52.400] We are now expecting them to take on board cybersecurity and do the job of the manufacturer [13:52.400 --> 13:59.480] or do the job of the FDA. That is not what they're designed for. So how can we expect that [13:59.480 --> 14:05.920] they will not crumble and break even further? As a security researcher or a hacker, I don't [14:05.920 --> 14:10.700] want to be responsible for breaking healthcare more. I want to be responsible for making it [14:10.700 --> 14:17.080] better. So we should take into consideration that the decisions they make on a daily basis [14:17.080 --> 14:24.080] are life and death. They have patients connected to them. We shouldn't be making things harder for [14:24.080 --> 14:31.600] an HDO. We should be supporting them and making it safer for them to implement. The last thing I [14:31.600 --> 14:38.040] want is for someone to have a device breached and a patient to lose their life. It puts signs back [14:38.040 --> 14:44.700] tens of decades. And the fact of the matter is I would not be here without my device. [14:44.720 --> 14:52.740] I would be dead at the age of 19. It has extended my life and for that I'm grateful and thankful. [14:53.200 --> 14:59.420] So we cannot go forward and break things more until we have an understanding how we can build [14:59.420 --> 15:09.520] them up. Now the third problem is two worlds colliding, meaning we have this complex ecosystem [15:10.400 --> 15:16.460] that has different devices but we have one way of implementing them. We have a cookie [15:16.460 --> 15:20.420] cutter approach when it comes to infusing medical devices into a hospital [15:21.480 --> 15:29.540] because we don't define these out properly. Are we heading for a big bang or is it going to be [15:29.680 --> 15:36.800] a meeting of the minds? I think we are facing a situation where we're going to have a big bang [15:38.120 --> 15:47.120] because all we need to happen is for these controls to fail. And can you honestly tell me [15:47.120 --> 15:53.200] that you have the same controls for a Windows 10 machine versus a patient bedside monitor [15:53.200 --> 16:00.240] running something like BusyBox, VXWorks or proprietary software? Are these the same? [16:00.240 --> 16:06.340] Do they look the same? Do they sound the same? Do they crack the same? I don't think so. I think [16:06.340 --> 16:13.000] each one comes with different sets of challenges. I found that a hospital is the most complex [16:13.780 --> 16:19.860] sea of devices that I've ever seen and this is just me walking through a hospital. Have you [16:19.860 --> 16:26.220] ever noticed how many different manufacturers can be under one roof? Do you think that those [16:27.480 --> 16:32.860] devices are all made equally and the same? Do you think every manufacturer implies [16:33.480 --> 16:41.080] the same controls? Has the same way of thinking? No, everyone functions in a silo because there's [16:41.080 --> 16:47.800] no clear standard. The standards we are using are those for IoT devices or for regular computers [16:47.800 --> 16:55.820] or laptops or endpoints. There's no set of standards specifically catering to medical devices. [16:56.320 --> 17:02.280] And to be clear, when I say medical device, I mean that thing made by a manufacturer. [17:02.860 --> 17:07.740] Not a Windows 10 running software. That's a different conversation. [17:11.090 --> 17:16.510] Again, leading into this, it's the diversity of it all. [17:17.730 --> 17:22.790] Have you ever spent time in a hospital and just looked around [17:24.230 --> 17:31.050] and then think to yourself, I wonder how they've implemented this? A lot of hospitals will offer [17:31.390 --> 17:41.610] Wi-Fi. Those systems are often not segmented. There's the saying in security, trust but verify. [17:41.830 --> 17:46.990] Right? We just give everyone access. All the systems have access to everything [17:47.670 --> 17:55.190] because we want to make it easier. Now I ask you, if you look at this picture, [17:55.190 --> 18:03.330] most of those devices are connected onto the hospital network. These devices all have [18:03.330 --> 18:12.710] communications. But all these devices are most likely very different in how they apply security. [18:12.750 --> 18:17.290] And let me tell you, often we do this thing where security is an afterthought [18:17.290 --> 18:25.070] or a post-market situation. We don't give developers or hardware engineers [18:26.210 --> 18:34.430] the information to become security-minded developers, security-minded hardware engineers. [18:34.670 --> 18:42.190] Security can be built into every portion of your pipeline and should be. We should be taking this [18:42.190 --> 18:50.110] as a requirement to look at. I'm also big that one day these devices will be hacked. In fact, [18:50.110 --> 18:55.930] they might already be hacked because we don't have the data to pull from to say whether or [18:55.930 --> 19:02.410] not the device has been hacked. Always in incident response, we come after the fact and say, [19:02.410 --> 19:08.010] oh, if I only had logs, oh, if I only had this piece of evidence. We should be building in [19:08.010 --> 19:15.130] these controls to be able to visualize what's going on on the device. Now you might ask how I [19:15.130 --> 19:22.190] know this. Well, I have a whole room filled with medical devices. I have a whole library filled [19:22.190 --> 19:28.130] with firmware. I have been doing forensics for the last year. I'm trying to determine whether or not [19:28.130 --> 19:34.430] there's any logging or whether or not I even have the ability to do a forensic investigation. [19:34.430 --> 19:40.490] And I can tell you that no, because no one considers the fact that these devices [19:40.490 --> 19:45.610] will inevitably one day get reached if they have not already. [19:46.850 --> 19:53.650] A big thing that I want to see change is that we have proper standards and rigorous guidances. [19:54.030 --> 20:00.730] These things should be enforced. They should not be if you want to do the following. [20:01.080 --> 20:07.220] There should be repercussions for MDM not following standards and guidances. [20:08.310 --> 20:14.360] I have spent significant time looking at the NIST standards currently used for medical devices. [20:15.250 --> 20:24.500] These things are referencing machines that have Windows or Microsoft or different protocols. [20:24.500 --> 20:32.040] They don't take into consideration what a medical device is. I want to see controls. [20:32.140 --> 20:38.640] Controls are there for specific devices, but we need to categorize these first. [20:38.840 --> 20:43.980] And I think before we get ahead, the first and foremost thing that needs to change is the fact [20:43.980 --> 20:50.720] that we need to start understanding what a medical device is as well as subcategories of that device. [20:51.460 --> 20:57.800] I think once we have clearer understanding, we can have better standards. [20:58.040 --> 21:03.140] I would love to see a NIST standard specifically catering to medical devices, [21:03.640 --> 21:08.720] specifically taking into consideration the unique challenges they face. [21:12.040 --> 21:21.000] And how do I know these things? Data never lies. It's the one thing that you can listen to. [21:21.000 --> 21:28.260] Yes, data can be manipulated, but this is data that's collected over long periods of time. [21:29.040 --> 21:35.500] Healthcare has become the biggest target at the moment. Not only are they facing keeping people [21:35.500 --> 21:43.400] alive, they are facing attacks from all avenues. The internal threat or the malicious actor from [21:43.400 --> 21:50.080] within has certainly taken a rise. I was very shocked to learn the other day that 18% of [21:50.080 --> 21:57.160] healthcare workers stated that they would sell patient records for the right price. [21:57.460 --> 22:01.580] We never consider that the greatest threat might come from within. [22:04.130 --> 22:10.350] So now we've spoken a lot about the problems, but there is a saving grace. There's something [22:10.350 --> 22:16.990] that I really believe has the right approach to dealing with the complex problem that is [22:16.990 --> 22:22.750] medical devices within a hospital. It is called the Zero Trust Network. [22:23.530 --> 22:30.490] Trust is neither a zero nor a one. This turns the whole security on its head, where we no longer [22:30.490 --> 22:37.150] just trust but verify. We verify but never trust. We no longer have this perimeter-based defense [22:37.150 --> 22:45.010] structure that we used to have. I think most hospitals build this huge wall and make their [22:45.010 --> 22:51.370] perimeter hard, but never considering that patients walk in and out of a hospital wearing [22:51.370 --> 22:59.840] wearables with embedded devices or, you know, introducing medical devices that are connected. [23:00.590 --> 23:09.090] I've often seen that hospitals get breached via a phishing email or via a system that [23:09.090 --> 23:16.390] should not have access to the whole entire network. This is a very important thing for me, [23:16.390 --> 23:22.690] because this could lead to us defining that, you know, the least privilege and the least access [23:22.690 --> 23:28.750] that a device should have on a network. And especially with electronic healthcare records [23:28.750 --> 23:36.590] moving to the cloud, not every system needs to have access to that. We should be limiting what [23:36.590 --> 23:43.310] devices have access and how they have access. And I think one of the biggest things and the [23:43.310 --> 23:49.030] most promising things is if we find that a device is no longer conforming to the rules and the [23:49.030 --> 23:57.410] controls we've set up, you can revoke the access for that device. It breaks down the perimeter [23:57.410 --> 24:03.550] and makes it more secure. It makes it more manageable, because now we have the ability [24:04.190 --> 24:11.610] to differentiate between devices and we don't have to have a cookie-cutter approach [24:11.610 --> 24:21.770] to healthcare security. Another big thing I realized is us as researchers or the FDA or the MDM, [24:21.770 --> 24:27.590] we don't like to play nice together. We don't like to listen to someone that has a difference [24:27.590 --> 24:36.050] of opinion than we do. We don't like criticism. We don't like to debate situations. But the fact [24:36.050 --> 24:42.070] remains that working together is the only way that we get to solve healthcare. After all, [24:42.070 --> 24:50.570] it takes a village or even two for that to even happen. I think it's a smarter way [24:50.970 --> 24:56.990] to pull resources together and hit this problem from all sides. [24:56.990 --> 25:02.850] It needs to be a multidisciplinary approach to solving the problem that is healthcare and [25:02.850 --> 25:10.310] medical device security. So let's see some solutions. We need to define things better. [25:10.590 --> 25:15.410] We need to assign the responsibility and accountability to the parties involved. [25:16.190 --> 25:24.770] We need to not trust implicitly. We should not put devices into our networks and trust them [25:24.770 --> 25:31.150] with the keys to the kingdom. We should assume that a device is breached at all times, [25:31.150 --> 25:37.710] because most likely it is, because you don't know otherwise. At one point of time, we are gonna [25:37.710 --> 25:46.210] see medical devices breached. Well, they might already be. We need to standardize and set the [25:46.210 --> 25:52.430] tone, the rules of engagements, the rules that are expected from someone. And by someone, I mean [25:52.430 --> 25:59.290] the MDM. These things need to be defined and clarity needs to be given to what the expectation [25:59.290 --> 26:07.430] of a secure device is. I want to see these things on black and white. I don't want to have the [26:07.430 --> 26:14.850] conversation anymore. I want a call to action to make things better, to change it now before legacy [26:14.850 --> 26:25.450] comes and bites us in the ass. Because every year we wait, every year we take, it adds so much more [26:25.450 --> 26:33.030] to the problem. At one point, the problem will become unmanageable if we don't do something now. [26:33.830 --> 26:41.630] If you as a researcher find a vulnerability, do the proof of concept, reach out, [26:42.530 --> 26:49.070] make things better, but don't just find a problem, find a solution. Because [26:49.830 --> 26:56.130] finding problems are easy, breaking in is easy, but it's finding a way for things to work better [26:56.130 --> 27:02.190] that is going to change the world fundamentally. And it's not one person or two people, [27:02.190 --> 27:08.890] but a whole collective effort that will change the future of connected devices. [27:12.170 --> 27:20.050] Thank you very much and please feel free to reach out. Hit me up on Twitter, email me, [27:20.050 --> 27:24.610] go comment on my blog. But I'm looking forward to your questions and I'm looking forward to [27:24.610 --> 27:29.590] the discussion. And thank you for giving me an opportunity to get on my soapbox and for once [27:29.590 --> 27:34.110] be taught, shout in a room about things that are making me angry.