[00:03.400 --> 00:04.780]  Thanks, everyone, for coming out.
[00:07.220 --> 00:11.500]  So, real quick, I'm Scott Irvin, Associate Director at Protiviti.
[00:11.660 --> 00:15.000]  I head up healthcare and medical device security for the firm.
[00:15.320 --> 00:22.860]  I'm also a security researcher, so I've spent just over the last four years researching vulnerabilities in connected medical devices.
[00:23.160 --> 00:31.540]  And prior to coming over to the consulting world and helping on that side, I actually managed an information security team for a few years.
[00:31.560 --> 00:32.960]  to healthcare providers.
[00:33.200 --> 00:34.900]  So, I also come from industry.
[00:35.160 --> 00:37.000]  I've only been in consulting for a few years.
[00:37.440 --> 00:38.880]  There's my Twitter handle at the bottom.
[00:39.100 --> 00:45.820]  If you want to follow me, I tend to tweet on healthcare and more specifically on medical device security, you know, vulnerabilities and research.
[00:46.080 --> 00:47.740]  So, feel free to follow me.
[00:47.900 --> 00:50.320]  I'm going to turn it over to Adam Quick to get us kicked off.
[00:52.680 --> 00:53.200]  All right.
[00:53.320 --> 00:53.760]  Thanks, Scott.
[00:54.220 --> 00:55.200]  So, my name is Adam Brand.
[00:55.340 --> 00:57.800]  I'm also with Protiviti, Director of Privacy and Security.
[00:58.080 --> 01:00.160]  I work with him on healthcare security.
[01:00.160 --> 01:02.500]  Among other things, medical device security.
[01:02.740 --> 01:06.000]  I have a history of custom EEG manufacturing.
[01:06.160 --> 01:08.320]  I have some pictures of those later, which you might find interesting.
[01:09.600 --> 01:13.480]  I also volunteer with I Am The Cavalry, which we'll talk about a little bit later.
[01:13.780 --> 01:14.980]  And there's my Twitter handle.
[01:15.860 --> 01:16.200]  Okay.
[01:16.380 --> 01:24.760]  So, in terms of the agenda for today, there's a number of topic areas we'll cover related to medical device security, give you a sense of the landscape, some specific research.
[01:24.760 --> 01:33.740]  We'll start off with, you know, why we're interested in medical devices at all, go into some phase one research on device vulnerabilities.
[01:34.080 --> 01:36.280]  Just, you know, what in general do you see?
[01:36.560 --> 01:41.000]  And we'll talk about the, secondly, the Internet exposure of these devices.
[01:41.200 --> 01:42.740]  So, are these things actually on the Internet?
[01:44.400 --> 01:45.260]  Admin access.
[01:45.480 --> 01:47.680]  How difficult is it to achieve admin access?
[01:47.680 --> 01:50.120]  Do you need to create zero-days to achieve that?
[01:52.240 --> 01:53.000]  Honeypot research.
[01:53.220 --> 01:55.020]  So, are these attacks a reality?
[01:55.260 --> 01:58.020]  So, if you put some medical devices out there, what happens?
[01:59.140 --> 02:01.760]  And we'll get into a little bit in terms of the diagnosis.
[02:02.040 --> 02:06.900]  So, what do we think are some of the root causes for some of this activity or some of these vulnerabilities?
[02:07.200 --> 02:08.340]  And then some of the treatment plans.
[02:08.520 --> 02:10.160]  So, what do we think should be done about that?
[02:11.560 --> 02:19.500]  So, before we get into this too much, just by way of definition, when we talk about medical devices, that can mean different things to different people.
[02:19.660 --> 02:21.240]  It could mean a surgical instrument, for example.
[02:21.380 --> 02:28.540]  We're talking about software-driven and continually or periodically connected devices.
[02:28.860 --> 02:35.060]  So, these are devices that will, at some point, connect to a network and also have software in them.
[02:35.060 --> 02:46.160]  And when we talk about the medical device, sometimes you'll think of just the actual physical hardware thing that's maybe running embedded Linux or something like that, a real-time operating system.
[02:46.300 --> 02:48.620]  We're talking about the entire solution.
[02:48.620 --> 02:55.960]  So, if there's a device that's controlled by a computer and that's important for the function of that medical device, we include that in this definition.
[02:57.380 --> 03:05.040]  So, in terms of why we would research medical devices at all, I guess, firstly, there's certainly a personal impact.
[03:06.320 --> 03:09.040]  So, it's just... I mean, I can kind of see through these lights.
[03:09.100 --> 03:16.600]  In terms of the folks in the room, how many of you rely on a medical device daily or know somebody that relies on a medical device daily?
[03:18.120 --> 03:18.760]  Yeah, wow.
[03:18.900 --> 03:19.500]  A lot of you guys.
[03:19.640 --> 03:19.860]  Yep.
[03:20.340 --> 03:33.920]  And, you know, I think, similarly, if you think about maybe you don't personally or somebody you know doesn't on a daily basis, certainly within the past year, I'm sure each of us can think of examples where someone, either ourselves or someone we cared about,
[03:33.920 --> 03:37.820]  was in a situation in a hospital where they were connected to one of these devices.
[03:38.800 --> 03:44.600]  So, even if we're not personally affected at a given point, someone we care may be affected.
[03:44.960 --> 03:49.680]  And that's certainly a high personal motivation for looking at device vulnerabilities.
[03:50.280 --> 03:52.360]  An example that comes to mind for myself...
[03:52.360 --> 03:56.740]  So, a few years ago, my sister-in-law, she was pregnant with twins.
[03:56.740 --> 04:03.960]  She was... had to go to the NICU because it seemed like the twins might be arriving a few weeks early.
[04:04.700 --> 04:09.240]  And so, my wife and I went and sat with her and we're talking with her.
[04:09.380 --> 04:19.360]  And the nurses would come in periodically to check on the heartbeat of these babies to see if they were okay and whether or not they needed to do an emergency C or something like that.
[04:19.360 --> 04:26.440]  And the nurse had come in and we noticed that she kept messing with the device itself, with the sensor.
[04:26.580 --> 04:28.460]  And she seemed a little frustrated.
[04:28.740 --> 04:33.360]  And, you know, that, of course, made us all a little bit nervous in terms of what's going on.
[04:33.580 --> 04:35.100]  Do these... you know, is it time?
[04:35.260 --> 04:37.160]  I mean, do we need to have action here?
[04:37.540 --> 04:40.240]  And she said, well, you know, hang on, hang on.
[04:40.360 --> 04:42.340]  It may just be that I need to reboot the computer.
[04:44.340 --> 04:46.180]  Exactly what you want to hear in that situation.
[04:47.460 --> 04:54.120]  The second thing that you exactly want to see in that situation is when she reboots the computer, a certain logo appear on the screen.
[04:54.320 --> 04:55.980]  Can anyone guess what that logo is?
[04:57.780 --> 04:59.300]  Windows XP, yes.
[05:00.440 --> 05:03.020]  So, you know, I hadn't really thought about it at that point.
[05:03.140 --> 05:03.680]  I was like, what?
[05:03.860 --> 05:05.560]  This is a fetal heart rate monitor.
[05:05.640 --> 05:07.220]  This is actually a Windows XP machine.
[05:07.220 --> 05:12.860]  And it certainly got me thinking a lot more about the security implications that we're going to talk about today.
[05:14.500 --> 05:23.300]  One of the other things that we like to discuss when it comes to medical device security and vulnerabilities is sometimes we'll get the question, well, who would actually do this?
[05:23.360 --> 05:28.420]  Who would actually try and attack a medical device and exploit it or something like that?
[05:28.700 --> 05:35.480]  And getting beyond the fact of, you know, people do crazy things and we shouldn't rely on the, you know, trusting the Internet, right?
[05:36.560 --> 05:42.340]  One key point is that malicious intent is not a prerequisite to a patient safety issue.
[05:43.040 --> 05:57.240]  So an example of that is a few years ago, about five years ago, at a hospital in Austria, two gunshot patients were admitted and they were connected to morphine drips and morphine pumps.
[05:57.240 --> 06:02.360]  And, you know, as they were receiving this morphine, they're like, this is pretty good.
[06:03.800 --> 06:05.960]  You know what would be better than the morphine?
[06:07.160 --> 06:08.520]  More morphine, right.
[06:09.880 --> 06:19.940]  So they set out, they looked at these devices and they started to engage in some very APT style hacking using this technology called Google.
[06:19.940 --> 06:21.840]  I don't know if you guys have... have you heard of that?
[06:22.900 --> 06:34.880]  So they went on Google and they found the password for this device on Google and proceeded to up the maximum dose allowed and get addicted to morphine very quickly.
[06:35.860 --> 06:39.520]  And they were both... you know, the nurses recognized something was wrong.
[06:39.640 --> 06:41.180]  They switched them to patches after a time.
[06:41.300 --> 06:48.540]  But these guys were highly addicted to morphine, had respiratory events and definitely did not have a good day as a result.
[06:50.040 --> 06:52.740]  So, again, malicious intent, not a prerequisite.
[06:52.900 --> 06:55.820]  So it doesn't take a malicious person to go out and do this.
[06:55.940 --> 07:00.100]  Patients could potentially take advantage of security vulnerabilities and do harm to themselves.
[07:01.300 --> 07:03.000]  So what are we doing related to this?
[07:03.080 --> 07:07.160]  When I say we, I mean security researchers involved in I'm the Cavalry and Scott and I and others.
[07:07.320 --> 07:08.420]  So a few different things.
[07:08.600 --> 07:13.500]  So first is looking at the actual medical devices to discover patient safety issues.
[07:13.720 --> 07:16.240]  So with the device itself, what's going on?
[07:16.300 --> 07:18.060]  What's the vulnerability landscape there?
[07:18.060 --> 07:21.240]  What are the types of flaws we can see?
[07:21.400 --> 07:28.860]  And how can we equip, you know, the people that are doing these to prevent these vulnerabilities from being introduced to new devices?
[07:29.720 --> 07:32.040]  And secondly, coordination and notification.
[07:32.400 --> 07:44.620]  So as we uncover these vulnerabilities, coordinating the disclosure of those vulnerabilities, working with the affected parties, working with the manufacturers, working with the provider organizations to try and get these problems addressed.
[07:45.380 --> 07:47.580]  And then thirdly, public awareness.
[07:47.900 --> 08:00.260]  So talking about these issues in forms like this and for, you know, other broader groups, talking about just the idea of the fact that these are, you know, these are computers at the end of the day and there's an issue here that we need to start focusing on.
[08:01.900 --> 08:09.780]  So I'm gonna turn it over to Scott and I was gonna talk specifically about the phase one research and overall device vulnerabilities and then go into a few other areas of research.
[08:12.920 --> 08:15.900]  All right, so you see how that morphine story is pretty awesome, huh?
[08:17.540 --> 08:29.960]  I think the one thing that comes to mind before we start talking about all these super elite advanced vulnerabilities is that it paints a good picture that... who here has been on morphine?
[08:30.880 --> 08:35.860]  Yeah, so if you can hack into a medical device on morphine, it can't be that difficult.
[08:39.980 --> 08:41.080]  So here we go.
[08:41.260 --> 08:45.720]  So, like I said, it started on this kind of path like four and a half years ago.
[08:45.900 --> 08:50.380]  And for me, it was kind of this like personal passion thing of working at a healthcare organization.
[08:51.140 --> 08:59.080]  And really, you know, healthcare organizations as a whole have been, you know, focused on patient privacy and protecting patient information, which is important.
[08:59.320 --> 09:03.860]  But when I've seen these devices become connected, you know, to the network, to the...
[09:03.860 --> 09:06.480]  as you will see here, to the Internet, potentially.
[09:07.120 --> 09:12.060]  And I was able to identify vulnerabilities, work with the manufacturer to resolve that.
[09:12.420 --> 09:18.820]  That kind of went to, you know, every healthcare organization's mission and values of, you know, patient safety and quality care.
[09:18.820 --> 09:26.220]  And so I really felt, you know, passionate about that from the safety perspective, of really having an impact on the healthcare organization's mission.
[09:26.820 --> 09:28.560]  And so what we found overall...
[09:28.560 --> 09:33.760]  I've done a handful of talks over the last, you know, two and a half years on this research in detail.
[09:33.900 --> 09:40.260]  So you look at like DEFCON talks, for example, if you want, you know, hard level, hour-long technical detail talks on each of these phases.
[09:40.900 --> 09:46.020]  But the first thing was, when we started to look at device vulnerabilities, it was, are these advanced attacks?
[09:46.100 --> 09:53.080]  Or are these really security hygiene issues that we've had, you know, no one fixes for, for years?
[09:53.260 --> 09:54.580]  And that's kind of what we found out.
[09:54.700 --> 10:06.180]  Like, this is the top three that I would call, like, big mistakes or security hygiene issues that we still see in devices that are implemented in, you know, in hospitals, in the healthcare provider environment.
[10:06.180 --> 10:14.700]  And so that first one is, you know, weak default or hard-coded credentials, which I'm going to touch on later today and show you some of the awesome passwords that these systems use.
[10:15.380 --> 10:18.300]  The second is, you know, known software vulnerabilities.
[10:18.900 --> 10:34.320]  And that's, you know, to Adam's point, we still do have a lot of XP, even older, you know, 2000, NT, see regularly, still in operation, legacy devices and with known vulnerabilities that are, you know, open to exploit.
[10:34.320 --> 10:36.920]  And lastly is lack of encryption.
[10:37.240 --> 10:43.000]  And at first, when you look at this, like we said, we tend to focus on the patient safety impact.
[10:43.460 --> 10:45.320]  Privacy kind of gets wrapped up into that sometimes.
[10:45.400 --> 10:48.880]  And at first glance, this may seem like, well, this is a privacy issue solely, right?
[10:48.980 --> 10:49.820]  It's encrypted data.
[10:50.160 --> 11:03.340]  But as you start doing things like medical device integration to pump real-time data from, for example, an anesthesia card or a ventilator into the medical record and then you're treating on that, some of these systems, they don't use encryption in transit.
[11:03.520 --> 11:11.020]  So you can man in the middle that you can alter that data and ultimately cause data integrity issues and push incorrect data into the medical record system.
[11:11.440 --> 11:19.420]  So that comes up with, you know, stuff that research has been done on like bad data leading to, you know, misdiagnosis, mistreatment, those types of things.
[11:19.520 --> 11:22.680]  So it's definitely also a safety issue, not just a privacy issue.
[11:24.080 --> 11:28.760]  So after we finished that research, we said, okay, these devices are definitely vulnerable.
[11:29.420 --> 11:32.580]  But what's the real risk to an attacker being able to get to them?
[11:32.580 --> 11:34.840]  Are they going to have to have physical access?
[11:35.500 --> 11:37.720]  Are they going to have to, you know, send a phish email in?
[11:37.860 --> 11:41.040]  Or, you know what, are they directly connected to the Internet?
[11:41.440 --> 11:52.460]  Or are there hospitals that have misconfigurations that's exposing vulnerabilities in other systems that give direct access into the internal network and to the internal connected medical devices?
[11:53.000 --> 11:58.800]  So I worked with another researcher, Sean Merdinger, and we ended up looking into Shodan.
[11:59.600 --> 12:07.500]  And so at first we were, you know, going into Shodan and we were doing, you know, super elite hacker searches that you'd never think of for medical terms.
[12:08.120 --> 12:12.060]  And the one that I came up that was super awesome was anesthesia that no one would think of.
[12:13.380 --> 12:15.320]  And when we did that, I got a return.
[12:15.560 --> 12:17.440]  And I'm like, let me look at the system.
[12:17.440 --> 12:21.320]  I'm like, at first I'm like, okay, you know, this... I know enough.
[12:21.460 --> 12:22.200]  I've been doing this a while.
[12:22.400 --> 12:23.840]  Like, this clearly isn't a medical device.
[12:23.960 --> 12:25.280]  Like, what's going on?
[12:25.840 --> 12:30.700]  I mean, the only indication that it could have been a medical device is it was an XP system.
[12:32.440 --> 12:34.780]  But outside of that, I knew, like, this isn't a medical device.
[12:34.900 --> 12:38.580]  What I realized is SMB was actually open on this XP system.
[12:38.580 --> 12:43.500]  And it was... had an anonymous read to Active Directory.
[12:43.700 --> 12:48.920]  And so it was leaking intelligence out on all of their internal systems, host names, identifying information.
[12:49.100 --> 12:50.700]  I'm going to show you some of the examples of that.
[12:53.320 --> 12:59.060]  So the first organization that popped up on this anesthesia search was very large.
[12:59.240 --> 13:02.300]  So it was in the U.S., over 12,000 employees.
[13:02.520 --> 13:05.760]  It leaked intelligence and provided a direct attack vector that we'll talk about.
[13:05.760 --> 13:07.780]  So there were 68,000 in their internal systems.
[13:07.980 --> 13:09.000]  And third parties.
[13:09.300 --> 13:12.580]  So there was... hospitals oftentimes will make connections.
[13:12.940 --> 13:15.040]  One, for support of medical devices.
[13:15.280 --> 13:18.540]  But two, for, like, third parties doing radiology reading, for example.
[13:18.780 --> 13:21.600]  Or third parties doing lab testing.
[13:21.780 --> 13:22.420]  Those types of things.
[13:22.540 --> 13:33.540]  And so there were very well-known organization names that do those services inside this dataset, which indicated they were also, you know, connected and had open access between those networks and those systems.
[13:35.780 --> 13:40.260]  So did we just find and just happen to come across, like, one big massive problem?
[13:40.500 --> 13:41.320]  No, we didn't.
[13:41.400 --> 13:43.020]  So we took that search and showed in.
[13:43.140 --> 13:45.780]  And we basically looked at the organization names.
[13:45.780 --> 13:49.720]  And we did these quick searches, as you can see, for, like, health or clinic or hospital or medical.
[13:49.760 --> 13:51.600]  That would indicate it's a healthcare facility.
[13:51.920 --> 13:56.920]  And also had a misconfigured system with SMB that was leaking information about their medical devices.
[13:57.140 --> 13:58.200]  And so those were the returns.
[13:58.340 --> 13:59.420]  Very quickly, we found hundreds.
[13:59.960 --> 14:07.680]  Once we changed those to, like, subspecialties, so if we looked at, like, radiology or podiatry, for example, we ended up with thousands of healthcare organizations that had this problem.
[14:09.160 --> 14:10.020]  So what was it?
[14:10.480 --> 14:11.360]  What was the issue?
[14:11.600 --> 14:14.020]  A treasure trove of information was the first issue.
[14:14.140 --> 14:17.500]  As you can see here on the left, you would get stuff in here.
[14:17.620 --> 14:19.900]  So you're getting specific locations, right?
[14:21.060 --> 14:22.540]  OR1, echovascular OR2.
[14:22.540 --> 14:24.720]  You're getting screen lock zero exemption.
[14:25.040 --> 14:28.660]  So you know Active Directory with zero isn't enforcing, like, a timeout.
[14:29.020 --> 14:31.400]  Which one would, yeah, be a HIPAA violation, probably.
[14:31.820 --> 14:36.940]  But two, from an attacker perspective, if you walked up to that system, which we'll talk about, there wouldn't really be a screen lock.
[14:37.560 --> 14:39.800]  On the right, that's electronic medical records system.
[14:40.080 --> 14:43.640]  Now, this healthcare organization happened to use Epic, which is a very large provider.
[14:43.720 --> 14:45.080]  This isn't an Epic issue, right?
[14:45.280 --> 14:47.020]  This just happened that they used Epic.
[14:47.400 --> 14:51.800]  And they misconfigured their edge network with this, you know, vulnerability.
[14:51.800 --> 14:59.280]  But these are all of the Epic servers that hold all of that patient data, a treasure trove of information sitting out there.
[14:59.520 --> 15:04.100]  And so if you're familiar with Epic, like, down in the bottom and stuff, there's, like, MyChart and MyHealth.
[15:04.260 --> 15:10.180]  That's the actual patient portal backend server that you use as a patient to connect into the environment.
[15:11.320 --> 15:12.380]  This one, here we go.
[15:12.540 --> 15:14.240]  You know, cardiology systems, cath lab.
[15:14.580 --> 15:17.120]  You'll see first floor pediatric nuclear medicine.
[15:17.260 --> 15:20.100]  And on the far left, those are the actual host names of the system.
[15:20.100 --> 15:21.940]  They're scrubbed out, but they were full host names.
[15:22.440 --> 15:23.980]  You'll see anesthesia OR.
[15:24.180 --> 15:27.020]  It would tell you, hey, it was anesthesia OR7, for example.
[15:27.480 --> 15:30.100]  So very detailed information for an attacker to have.
[15:32.020 --> 15:34.580]  This overall was just that one organization.
[15:35.300 --> 15:42.640]  The types of data or the types of systems that were inside that organization that we had intelligence about and knew the system and host names on.
[15:42.640 --> 15:48.420]  So you can see a lot of cardiology systems, MRI systems, infusion pumps, PACS systems.
[15:48.580 --> 15:54.900]  PACS, for those of you that don't know what that is, that is basically an archiving system of all radiology images.
[15:54.900 --> 15:58.120]  So a lot of, you know, protected health information inside of that.
[15:58.200 --> 15:58.980]  A lot of PHI.
[15:59.400 --> 16:01.640]  And that is the backend storage.
[16:01.640 --> 16:09.800]  When you take it from any of those radiology images, it stores it in PACS systems, which traditionally have very poor security around backend storage.
[16:11.180 --> 16:13.660]  So outside of that, you kind of...
[16:13.660 --> 16:20.820]  Before I let Adam go on the attack perspective, one thing that was important, as I said in the beginning, was this was XP, right?
[16:21.020 --> 16:24.340]  It was an XP system with SMB open.
[16:25.780 --> 16:33.260]  And MSO8067, which is the vulnerability that Configure exploited, happened to exploit these vulnerable systems, right?
[16:33.360 --> 16:34.700]  XP, or 2003.
[16:35.360 --> 16:37.380]  But it also used SMB by default.
[16:37.640 --> 16:42.360]  So you also not only had this intelligence, you had a direct attack point into that network.
[16:42.540 --> 16:44.580]  So definitely a treasure trove of information.
[16:44.760 --> 16:52.660]  I'm just gonna turn it back over to Adam here, quick, to kind of talk about, you know, with that information, what types of attacks, and then we'll get into, you know, some of the further research that we've done beyond this.
[16:54.040 --> 16:54.560]  Thanks, Scott.
[16:54.740 --> 17:01.160]  So yeah, when you look at some of this stuff, I think at face value, you might think, oh, well, this is an information disclosure vulnerability, right?
[17:01.320 --> 17:01.840]  I mean, this is...
[17:02.540 --> 17:04.180]  What could you really do with this information?
[17:04.180 --> 17:11.280]  And I think certainly if you think about it a little bit further, you'll start to realize you can do something interesting with this information.
[17:11.500 --> 17:16.180]  So in terms of the types of attacks that you could leverage this, think about physical attacks.
[17:16.420 --> 17:22.360]  So you have the desire to go and physically access a particular station in a hospital.
[17:23.500 --> 17:25.180]  You know, before you...
[17:25.180 --> 17:26.200]  Before you...
[17:26.200 --> 17:28.420]  Or let's say you want to plug in a USB or something like that.
[17:28.520 --> 17:36.620]  Before you go into that facility, if you have this information available to you, you can see, you know, you already know the specific location for this healthcare organization.
[17:36.920 --> 17:38.740]  You know the floor and office number.
[17:38.880 --> 17:42.960]  So this equipment was tagged, and these systems were tagged with exactly where they were.
[17:43.880 --> 17:46.680]  And you also know which ones have lockout exemptions, right?
[17:46.680 --> 17:53.860]  So if you're gonna plug something in and run it, it'd be pretty nice if you didn't have to, you know, worry about a lockout coming on and having to have a password be entered.
[17:54.100 --> 17:58.480]  So it certainly makes a physical attack easier to conduct by having this type of information.
[17:59.280 --> 18:00.620]  Next would be a phishing attack.
[18:01.000 --> 18:07.420]  So the key with phishing really is you want to make it as, you know, realistic as possible so that the target feels like it's a legitimate email.
[18:07.780 --> 18:13.940]  With this type of information, you certainly have a lot of data to make a very effective phishing email.
[18:14.080 --> 18:15.800]  You know the employee names.
[18:16.000 --> 18:17.740]  You know the host names of these devices.
[18:17.980 --> 18:19.620]  You know, maybe they're with a label on that device.
[18:19.820 --> 18:27.680]  Oh, hey, you know, Jennifer, can you go over to host XYZ and please go to this website.
[18:27.680 --> 18:30.140]  We need to do an update to it, right?
[18:31.660 --> 18:40.100]  And furthermore, because you know the entire inventory of that organization, you know where there may be certain other vulnerable systems.
[18:40.100 --> 18:45.320]  For example, a medical device that you know has a, you know, a default password or something like that or an open share.
[18:46.020 --> 18:51.640]  You could create a custom payload so that it jumps in and then it goes right to the system that it needs to go to.
[18:51.760 --> 18:56.360]  You don't need to worry about, you know, the clock starting to tick on getting detected.
[18:58.020 --> 19:00.440]  And then, of course, there's the pivot, which Scott alluded to.
[19:00.640 --> 19:04.980]  So you have the system out there, Windows XP vulnerable to MSO8067.
[19:05.940 --> 19:09.080]  You know it's touching those back-end networks because you can see them enumerated.
[19:09.080 --> 19:13.480]  So if this thing can see that enumeration of devices, you know, there's a way to get to them.
[19:13.780 --> 19:24.680]  So you could create a custom payload when you exploit that to very quickly get in and then pivot off to another system that you find is interesting and that you want to have as the next point of attack.
[19:25.420 --> 19:30.620]  So certainly a few different varieties of types of attacks that you could do with just this fairly straightforward vulnerability.
[19:31.960 --> 19:38.340]  So now I'll turn over to Scott a little bit more and talk a little bit about how exceedingly difficult it is to obtain admin access.
[19:42.210 --> 19:47.370]  It's about as difficult as the two individuals in the beginning of going on to Google.
[19:50.130 --> 19:55.450]  So we said, okay, we have vulnerable devices, and you know what?
[19:55.590 --> 20:00.510]  They are directly accessible to the Internet either directly, which I didn't touch on.
[20:00.630 --> 20:14.410]  If you go and watch the DEFCON talk, we did find infusion pumps, patient monitoring, all the way up to high dosage radiation systems like linear accelerators directly connected to Internet facing IPs.
[20:14.550 --> 20:15.850]  So we did find that also.
[20:16.530 --> 20:20.910]  I focused on this kind of this hospital scenario, but we did find directly connected devices.
[20:21.210 --> 20:30.270]  And so then we said, okay, we have vulnerable devices directly connected, or there's lots of hospitals that have misconfigurations in their system that allow direct access into these medical devices.
[20:30.270 --> 20:35.550]  Well, how hard is it to get remote admin access if that's the case?
[20:35.550 --> 20:41.210]  And so this is a disclosure timeline for those of you who are interested in that.
[20:41.410 --> 20:46.250]  This happened to be with GE Healthcare and looking at their radiology equipment.
[20:46.870 --> 20:54.530]  As you will see as we go, I only threw a few examples in here, but previous talks have all of the examples so that we release them publicly.
[20:55.450 --> 21:14.510]  But if you go through that, all of this information was as simple as what those folks did in the hospital, of going online, going to their website, it was all publicly available documentation, with the intended use of providing, you know, shared passwords to support personnel,
[21:14.770 --> 21:16.950]  so that they can keep those systems operational.
[21:17.350 --> 21:20.630]  And the security is kind of that unintentional, you know, use case.
[21:20.790 --> 21:34.650]  And I think it's also very important to point out when we talk about this, that although this is specific to GE, what I'm going to show you, this, you know, problem, right, is not specific to GE.
[21:34.850 --> 21:36.650]  You see it across the industry.
[21:36.650 --> 21:40.570]  It's a systemic issue in healthcare and in medical devices.
[21:41.130 --> 21:46.910]  Historically, they were not designed or did not have security embedded during design or engineering.
[21:48.210 --> 21:49.030]  So here we go.
[21:49.430 --> 21:51.130]  So overall, I'm just going to do a subset.
[21:51.550 --> 22:01.470]  But overall, there's just over a total of like 30 CVEs for 150 sets of administrative remote credentials on systems.
[22:01.690 --> 22:03.250]  So this here... and this will be followed.
[22:03.370 --> 22:05.730]  The CVE will start this and then the CVSS score.
[22:05.850 --> 22:13.850]  So every CVE that we put out was given a CVSS score of 10 because they were remote admin access to the system.
[22:13.850 --> 22:18.970]  You'll also see the identifier of the year and you're like, hey, Scott, have you been hoarding this thing since 2006?
[22:19.270 --> 22:19.510]  No.
[22:19.670 --> 22:30.070]  As I mentioned, since they were publicly available, we go back to the last instance of when that documentation was found on the Internet and then we reactively request the CVE back to that year.
[22:30.170 --> 22:30.970]  So that's why it was 2006.
[22:31.710 --> 22:38.510]  But I think it's interesting to look at these years to see some of them you'll see are like 2013, a couple of years before we released the research or reported the research.
[22:38.650 --> 22:41.090]  So it's not just the issue of years ago.
[22:41.090 --> 22:48.130]  It was up until like two or three months before there was new products being released when we did this that still had these systemic issues.
[22:48.330 --> 22:52.070]  So this happens to be a nuke imaging system.
[22:52.230 --> 22:57.310]  And so you can see default user accounts, emergency accounts, those types of things, admin windows accounts.
[22:57.990 --> 23:00.290]  Here's another on the discovery on the nuke imaging.
[23:00.470 --> 23:01.430]  You get into remote management.
[23:01.590 --> 23:03.130]  So you get into Telnet, into root.
[23:03.130 --> 23:05.230]  Super awesome passwords like to get in.
[23:08.790 --> 23:09.310]  Yes.
[23:10.070 --> 23:18.230]  And then you get down to, you know, nuke imaging systems down below on like FTP and interfaces with like printers, things like that.
[23:20.590 --> 23:22.710]  So this is also a different version.
[23:22.850 --> 23:26.390]  You can see this one is from 2011 of nuclear imaging and CT scanners.
[23:26.390 --> 23:29.470]  And you have, you know, pound big guy, pound big guy one.
[23:29.890 --> 23:31.450]  Those are also really awesome.
[23:31.710 --> 23:46.830]  And the thing that you see across this is it's interesting when you look across all of them to see like a certain password where you're like, hey, this development team must have quit this product and now started on this product because big guy is like coming from like 2000 all the way to 2016 across like seven product lines.
[23:46.950 --> 23:47.030]  Right?
[23:51.730 --> 23:52.550]  So here you go.
[23:52.690 --> 23:54.650]  Really, you know, down at the bottom, this one's awesome.
[23:54.810 --> 23:58.050]  You see this a lot like these WinVNC logins or PC Anywhere logins.
[23:59.010 --> 24:01.910]  Again, intended use is to be able to support that system.
[24:02.310 --> 24:07.410]  But real poor, you know, practice and really weak passwords on those systems.
[24:08.910 --> 24:10.650]  So this is a word cloud.
[24:10.850 --> 24:14.050]  I mean, what better when you have a bunch of passwords than to create a word cloud?
[24:14.050 --> 24:20.950]  And so this is 150 sets of usernames and passwords in a word cloud.
[24:21.470 --> 24:24.810]  And big guy is definitely, you know, leading that charge.
[24:25.190 --> 24:28.630]  Did anyone notice anything interesting about the big guy though?
[24:29.730 --> 24:30.090]  No?
[24:30.750 --> 24:36.510]  So if you had looked when I had showed you the actual password, it was pound, pound big guy, pound big one, big guy one.
[24:36.930 --> 24:43.070]  Well, I quickly found out that word cloud app sec is much better and actually sanitizes your data input.
[24:44.630 --> 24:47.590]  So I couldn't get it to do a leading pound sign.
[24:52.080 --> 24:56.900]  So when we went through disclosure, some of the things were, hey, a lot of these are default.
[24:57.240 --> 24:59.040]  And in some cases, they are default.
[24:59.140 --> 25:09.380]  And in some cases, they do actually provide, you know, instructions in the manuals that are given to the installers or to the hospital systems that, hey, you should change this and this is how you should do it.
[25:09.380 --> 25:13.100]  But saying they're all default, I think is contradictory.
[25:13.600 --> 25:19.020]  Because I will show you some examples inside of that specific documentation that would indicate otherwise.
[25:19.320 --> 25:26.660]  And these are the installation guidance that either the manufacturer support staff or the hospital or third party are using to install.
[25:26.820 --> 25:28.280]  So there are still indeed issues.
[25:28.280 --> 25:38.160]  So if you wanted a customer to make this a default password and you wanted to ensure they would change that password, would you tell them to check user can never change password?
[25:38.780 --> 25:41.540]  Would you tell them to check password never expires?
[25:42.040 --> 25:45.720]  That's not something that's indicative of a default credential.
[25:45.720 --> 25:51.020]  And so these credentials, whether they're truly hard coded on the back end, in some cases, they definitely are.
[25:51.160 --> 25:57.880]  Or if they just are in the instructions told like this, like important, do not change the password or we will not support you.
[25:58.200 --> 26:04.780]  What hospital organization is not going to listen to that, especially when we put it in big and bold and say don't do it or we're not going to be able to support that system.
[26:04.980 --> 26:08.760]  So there's still issues that we see that are, you know, common here.
[26:08.940 --> 26:11.920]  Here's another one, again, in big and bold, do not change this password.
[26:13.960 --> 26:20.260]  Another one, hey, tech support will log into your system with our backdoor account and use this username and password.
[26:22.460 --> 26:27.180]  And hey, doctor, I know you love remembering passwords, so just click yes and you won't have to ever enter it again.
[26:30.460 --> 26:34.780]  Or ask the remote station operator to reset it to the super secure password of password.
[26:36.500 --> 26:38.700]  The bottom one here, this is a good example.
[26:38.700 --> 26:49.420]  This is kind of to get in the mindset of, you know, a hacker or how we look at intentional use versus how could you modify a system and, you know, bypass the intended use.
[26:49.520 --> 26:55.400]  So this is, if you read this really quick, it's basically you must generate x-ray radiation to follow safety precautions.
[26:55.480 --> 26:57.720]  So we know radiation is going to get emitted, right?
[26:57.860 --> 27:04.680]  And with those types of things, it's like dosing limits and also like exposure time limits, those types of things that could cause harm.
[27:04.680 --> 27:08.000]  And so we know if we run this, it's calibration.
[27:08.180 --> 27:10.180]  So it's probably not high-level radiation, right?
[27:10.260 --> 27:11.980]  It's just log in.
[27:12.320 --> 27:13.800]  Here, simple username and password.
[27:13.980 --> 27:14.960]  Do this and you'll run radiation.
[27:15.180 --> 27:22.040]  Well, if you capture that traffic between the application that actually posts to a web server on the actual x-ray system, it's not encrypted.
[27:22.220 --> 27:24.340]  It's an XML file that gets passed in many cases.
[27:24.540 --> 27:26.280]  You can modify those parameters.
[27:26.360 --> 27:30.980]  What happens if you modify those parameters to be higher or the exposure link to be different and then post it?
[27:30.980 --> 27:31.880]  Does it accept it?
[27:31.980 --> 27:34.180]  So that's the type of thing that we look at.
[27:34.460 --> 27:36.760]  This specific system, I haven't tested.
[27:36.960 --> 27:40.720]  I have done stuff exactly similar to this on other manufacturer systems.
[27:40.760 --> 27:45.720]  But that gives you an idea of, you know, how we try to find intentional use and then make it do something else.
[27:46.880 --> 27:49.120]  So we have vulnerable devices that are connected to the Internet.
[27:49.300 --> 27:50.860]  Not that difficult to get remote access.
[27:51.020 --> 27:53.980]  So I worked with another researcher, Mark Klau, and we...
[27:54.500 --> 27:56.080]  He's a massive, like, honeypot guy.
[27:56.300 --> 27:59.360]  And so with him to, you know, set up some honeypots and see what's happening.
[27:59.360 --> 28:02.600]  So we're basically looking at, you know, setting them up realistic.
[28:02.740 --> 28:07.220]  So if they had poor, you know, default login credentials like I showed you, we mimic that completely.
[28:07.560 --> 28:11.140]  We wanted to see, are there, you know, specific campaigns against specific vendors?
[28:11.320 --> 28:13.040]  Are they attacking medical devices?
[28:13.220 --> 28:15.360]  If they're attacking medical devices, is it targeted?
[28:15.540 --> 28:18.580]  Are they trying to steal intellectual property stuff, source code, things like that?
[28:18.940 --> 28:21.240]  Try to get an understanding of the motivations.
[28:22.220 --> 28:24.480]  So this is kind of the setup, what we did.
[28:24.640 --> 28:25.840]  Again, service connection strings.
[28:26.380 --> 28:30.740]  We did everything to where you could, you know, Google dork it and it would be exactly the same.
[28:31.100 --> 28:32.740]  We would replicate real world environments.
[28:32.900 --> 28:35.160]  So those systems that were XP that we did.
[28:35.320 --> 28:36.860]  So we did external defibrillators.
[28:37.020 --> 28:38.300]  We did some pack systems.
[28:38.420 --> 28:39.460]  We did some radiology equipment.
[28:39.520 --> 28:40.520]  We did some infusion pumps.
[28:40.900 --> 28:45.480]  We would mimic that XP with that vulnerability because that's really how it is in the environment.
[28:46.520 --> 28:48.820]  Remote web management services, those types of things.
[28:48.820 --> 28:52.680]  And then file structure attributes all the way down to make sure that those were accurate.
[28:52.920 --> 28:53.440]  Some of them...
[28:54.060 --> 28:59.740]  If the company actually had their source cards sitting in a file like three levels deep, you know, we mimicked that.
[29:00.780 --> 29:02.180]  And then we had to get the word out.
[29:02.340 --> 29:03.680]  So throw it out on a showdown, right?
[29:04.660 --> 29:06.500]  You know, John Matherly has been awesome to work with.
[29:07.540 --> 29:11.180]  And a lot of the research that we've done, you know, make those Google friendly searches.
[29:11.380 --> 29:12.260]  So they pick up.
[29:12.260 --> 29:22.200]  Also drop, you know, indicators of, you know, releasing CVEs or disclosing vulnerabilities with usernames and passwords and using systems that had been publicly disclosed to see if people were doing that.
[29:23.080 --> 29:27.300]  We also, you know, did Pastebin and Twitter dumps with Honeycreds that we'll talk about.
[29:28.380 --> 29:29.820]  So here's the data after six months.
[29:29.960 --> 29:30.960]  So we set up 10 honeypots.
[29:31.100 --> 29:32.640]  We had over 55,000 logins.
[29:32.760 --> 29:33.920]  Now, those weren't blank...
[29:33.920 --> 29:35.240]  Those were not blank logins.
[29:35.740 --> 29:37.260]  Now, they could have been weak, right?
[29:37.420 --> 29:44.580]  They could have been admin, admin if that system was, or they could have been very weak like big guy one or, you know, to get in or something like that if that was the type of system.
[29:44.880 --> 29:46.980]  But they were actually credentialed logins.
[29:47.740 --> 29:51.160]  We had 24 times that they actually went and ran the exploit on it.
[29:51.240 --> 29:53.480]  Most of that was 08067 on XP.
[29:54.420 --> 29:56.880]  Almost 300 unique malware samples dropped.
[29:57.200 --> 30:03.800]  Most of that that we've seen was actually just, you know, meant to, you know, scrape data, scrape credit card data, those types of things.
[30:04.360 --> 30:05.540]  Top three source countries.
[30:06.080 --> 30:09.480]  It was interesting, you know, and we're not doing attribution here.
[30:09.480 --> 30:11.460]  I'm just telling you the source country that the attack came from.
[30:12.080 --> 30:13.840]  It's Netherlands, you know, China and Korea.
[30:14.100 --> 30:17.440]  And Netherlands, we worked with the cert team over in the Netherlands.
[30:17.680 --> 30:20.860]  And ultimately, it ended up being a data center that was compromised over there.
[30:21.040 --> 30:23.660]  And then was pivoting and coming into our systems.
[30:24.200 --> 30:26.360]  Most importantly, overall, I think eight times.
[30:26.480 --> 30:28.840]  So we put those honey creds and we took a sub sample of that.
[30:29.100 --> 30:33.080]  And we threw unique username and password out onto Pastebin and out onto Twitter.
[30:33.280 --> 30:34.160]  And kind of publicized it.
[30:34.240 --> 30:36.180]  Like, hey, here's these medical devices sitting out here.
[30:36.220 --> 30:36.940]  Here's the creds.
[30:37.000 --> 30:37.780]  Go ahead and hack away.
[30:37.780 --> 30:40.280]  And eight times those were actually used against the system.
[30:42.740 --> 30:43.140]  So...
[30:43.600 --> 30:43.800]  Yeah.
[30:45.440 --> 30:45.840]  Yeah.
[30:46.120 --> 30:46.180]  Yeah.
[30:46.280 --> 30:47.360]  That was definitely south.
[30:48.140 --> 30:48.900]  I think...
[30:48.900 --> 30:49.760]  I don't know if...
[30:50.660 --> 30:51.460]  North Korea...
[30:51.460 --> 30:53.100]  How many Internet-connected systems do they have, too?
[30:54.300 --> 30:55.260]  They don't have too many.
[30:55.440 --> 30:57.880]  It's all, like, centered in the city.
[30:58.040 --> 31:01.040]  But real world attacks and conclusion, right?
[31:01.220 --> 31:01.920]  What did we see?
[31:02.520 --> 31:05.960]  Did we see any indication that it was, like, targeted to the actual device?
[31:05.960 --> 31:06.400]  No.
[31:07.040 --> 31:08.960]  What we saw was, hey, it was just random...
[31:09.480 --> 31:10.640]  You know, for the most part...
[31:10.640 --> 31:13.160]  I think those, like, honey cred logins were a little bit unique, right?
[31:13.240 --> 31:16.240]  But someone just scraped them off a Pastebin, probably put them in a word list, and then...
[31:16.240 --> 31:17.440]  I don't know if they just hit them.
[31:18.020 --> 31:20.040]  But we didn't see anything that was, like, targeted.
[31:20.220 --> 31:24.760]  We didn't see any indication once they got in that they actually knew what they were doing.
[31:24.760 --> 31:26.240]  They were definitely calling back.
[31:26.420 --> 31:27.020]  They were sitting there.
[31:27.440 --> 31:34.700]  But we didn't see any, you know, malicious intent from a patient harm perspective or trying to offload or steal, you know, any type of data.
[31:36.080 --> 31:43.100]  So I'm going to turn it over to Adam Quick to kind of wrap up on, you know, diagnosis, treatment plans, and then we'll shoot in the Q&A after that.
[31:46.300 --> 31:46.880]  Thanks, Scott.
[31:46.880 --> 31:55.500]  So, yeah, when I was looking at that honey... and that stuff, honeypot results, I was thinking to myself, you know, yeah, that's kind of... that's good in a way, right?
[31:55.580 --> 32:00.320]  We didn't see any direct attack factor, like, people going after a specific medical device.
[32:00.420 --> 32:05.200]  And I was thinking, you know, but how good does that really make me feel, right?
[32:05.200 --> 32:11.220]  If I'm a patient, I'm connected to a medical device, somebody didn't intend to compromise it, but it still is compromised.
[32:11.700 --> 32:16.760]  And I think there's certainly an element of, yeah, it's still an uncomfortable place to be.
[32:17.520 --> 32:18.860]  So, why is this stuff happening?
[32:19.460 --> 32:26.720]  So, in terms of the nature of the problem, we can talk about, you know, first of the fact, as I mentioned earlier, we're talking about software-driven systems.
[32:26.960 --> 32:28.400]  So, software has flaws.
[32:28.720 --> 32:31.160]  Has anyone designed a soft piece of software without a flaw out there?
[32:32.460 --> 32:32.860]  Okay.
[32:32.860 --> 32:33.220]  Oh, okay.
[32:33.320 --> 32:33.680]  A few of you.
[32:33.880 --> 32:34.160]  Great.
[32:36.080 --> 32:36.480]  Exactly.
[32:36.760 --> 32:37.160]  Exit.
[32:38.180 --> 32:38.580]  Return.
[32:40.020 --> 32:40.420]  Okay.
[32:40.660 --> 32:42.500]  So, yeah, all software has flaws, right?
[32:42.640 --> 32:46.800]  And when you connect something that's previously not been connected, you're increasing the interaction.
[32:46.880 --> 32:47.240]  point.
[32:47.480 --> 32:57.160]  So, if you have this great idea to have a, you know, software-driven, you know, connected medical device, it could be a vulnerable exposed one, right?
[32:57.260 --> 32:58.100]  So, it's just the nature.
[32:58.280 --> 33:00.160]  It's inherent to the thing that you're building.
[33:00.660 --> 33:09.120]  And then also, what we see is the lack of alignment from a patient safety perspective in terms of these medical device cybersecurity practices.
[33:09.120 --> 33:19.940]  So, we talked about this earlier that HIPAA certainly is a driver, but in terms of what is the potential impact from a patient safety perspective, that didn't seem to be as much there.
[33:21.320 --> 33:25.080]  So, in terms of problem awareness, so, we talked about a lot of this.
[33:25.200 --> 33:26.280]  I'm not going to go through it in detail.
[33:26.460 --> 33:29.280]  But essentially, we have all these medical devices connected to the Internet.
[33:29.380 --> 33:32.780]  This is going to be growing in terms of connected medical devices in general.
[33:32.780 --> 33:37.980]  This is not, you know, tomorrow people aren't going to be like, oh, you know what, we should really just unplug everything from the network.
[33:38.140 --> 33:38.960]  That's not going to happen.
[33:40.040 --> 33:42.460]  We still have HIPAA, which focuses on patient safety.
[33:43.760 --> 33:48.240]  We have the FDA, which does not validate cyber safety controls.
[33:48.460 --> 33:57.220]  So, I think a lot of people, especially, you know, new to this might think, well, the FDA should be or has been validating cyber safety controls on all these devices.
[33:57.500 --> 33:58.600]  That is not the case.
[33:59.240 --> 34:03.220]  And as we talked about, malicious intent is not a prerequisite.
[34:03.380 --> 34:09.260]  So, it doesn't really matter whether or not you believe that people are out there trying to do this to have a potential negative outcome.
[34:10.300 --> 34:20.500]  In terms of looking at the problem in a different way, if you look at the ecosystem of people that would need to be involved to address this problem, some of what we observed was that there seemed to be silos.
[34:20.700 --> 34:29.720]  So, you have the healthcare providers out there doing what they're doing, the device manufacturers doing what they're doing, security researchers doing what they're doing, but not enough communication.
[34:29.980 --> 34:34.000]  And this has certainly improved over the past few years, as Scott will talk about in a little bit.
[34:34.180 --> 34:37.840]  But one of the key fundamentals to this problem is getting people to talk.
[34:39.260 --> 34:45.880]  So, here's some attack scenarios that I like to call TV show scripts or risks to plan for.
[34:46.160 --> 34:46.260]  Right?
[34:46.440 --> 34:48.540]  So, is this a script or is this real?
[34:48.740 --> 34:53.280]  And the reason I say that is because you can certainly go down the path of FUD on a lot of these things.
[34:53.420 --> 34:55.700]  I'm not a huge FUD fan, I guess.
[34:56.020 --> 35:01.360]  But I do find it interesting just to think about these risks and make that risk determination.
[35:01.500 --> 35:03.680]  If you can't explore it, then you can't make a decision.
[35:03.920 --> 35:05.580]  So, here's an example of one.
[35:06.140 --> 35:14.920]  Fetal heart rate monitors in a NICU reboot periodically due to incorrectly operating malware, increasing stress among staff and patients.
[35:14.920 --> 35:17.940]  So, is this real or TV show?
[35:18.440 --> 35:19.400]  Anyone want to guess?
[35:20.360 --> 35:21.440]  Real, right?
[35:21.640 --> 35:21.740]  Yeah.
[35:22.900 --> 35:32.080]  Ransomware encrypts key application and configuration files on an MRI controller causing critical care patients to be relocated to another hospital.
[35:33.100 --> 35:33.780]  Okay.
[35:34.280 --> 35:37.200]  Yeah, I don't know that exact, but you can certainly foresee that.
[35:37.720 --> 35:45.260]  We have attacker compromises hospital network and periodically reboots medical device computers until a ransom is paid.
[35:46.260 --> 35:47.080]  TV, right?
[35:47.240 --> 35:48.100]  Yeah, this starts getting...
[35:48.100 --> 35:49.580]  These ones started getting the TV.
[35:49.760 --> 35:51.900]  I don't know of any examples of this happening.
[35:52.740 --> 36:04.280]  And you can certainly go down to these scenarios where you start talking about, you know, terrorism, where you have a coordinated attack between kinetic attack and then messing with the hospital's medical devices at the same time, causing confusion.
[36:04.280 --> 36:07.020]  These are all kind of the war gaming type things, right?
[36:07.360 --> 36:09.840]  And that make potentially for good TV shows.
[36:10.740 --> 36:18.520]  But I think it's something to consider when you're going through this list of, you know, maybe today we have a certain perspective on what that risk is.
[36:18.640 --> 36:23.200]  And maybe yesterday we had a certain perspective on the impact of ransomware on hospitals.
[36:23.280 --> 36:25.280]  And how has that changed over the past year?
[36:25.480 --> 36:29.160]  So many of these scenarios that we think about look like TV shows today.
[36:29.440 --> 36:30.540]  Maybe they never happen.
[36:30.620 --> 36:31.320]  They're too complicated.
[36:31.320 --> 36:34.020]  There's easier ways to get things done, as it were.
[36:34.940 --> 36:37.700]  It's certainly something to think about when you're doing your risk management.
[36:37.700 --> 36:49.380]  And I think the important point here, too, is that, you know, as we're increasing the use of technology and connectivity when providing patient care, right, it's going like this.
[36:49.480 --> 36:56.260]  We're ramping up all these new connected cool devices that are improving patient care, enabling people to respond more quickly.
[36:56.320 --> 37:01.680]  At the same time, our security resilience posture should not be like this, right?
[37:01.880 --> 37:07.480]  If we're increasing our use and increasing our dependency, we should be also increasing the security assurances.
[37:10.180 --> 37:13.560]  So to be fair, we talked a lot about these default passwords.
[37:13.760 --> 37:16.260]  So medical device security is hard.
[37:16.700 --> 37:20.080]  As I mentioned, I had done custom EEG manufacturing.
[37:20.080 --> 37:21.900]  So I've had firsthand experience with that.
[37:22.080 --> 37:23.480]  So we'll get into this in a second.
[37:25.320 --> 37:27.760]  So you have to worry about secure design and development.
[37:27.940 --> 37:32.440]  So here's a child laborer that I employed to build a custom EEG machine.
[37:32.440 --> 37:37.060]  Actually, this is me, age 12, I think, putting together a science project, an EEG.
[37:38.340 --> 37:42.200]  So certainly understand how difficult it is to do secure design and development.
[37:45.720 --> 37:46.320]  Don't worry.
[37:46.460 --> 37:47.820]  The voltage only goes one way.
[37:49.820 --> 37:50.840]  Oh, that poor kid.
[37:52.120 --> 37:53.780]  Yeah, look at that rocking turtleneck, too.
[37:54.160 --> 37:54.920]  What happened to that?
[37:55.040 --> 37:55.780]  Those were the 90s.
[37:57.680 --> 37:59.200]  Secure implementation, right?
[37:59.740 --> 38:02.360]  Does it get any more secure than DOS 3.0?
[38:03.080 --> 38:04.880]  Running on a Head Start Explorer?
[38:05.820 --> 38:07.040]  Yeah, I don't think so.
[38:08.800 --> 38:13.520]  So in all seriousness, in terms of treatment plans, so what can we do about this going forward?
[38:13.920 --> 38:15.280]  So a few different things.
[38:15.400 --> 38:22.900]  So first, I think, and this is part of the cavalry message as well, is, you know, it falls to all of us, and patient safety is not a spectator sport.
[38:23.140 --> 38:26.420]  So as we talked about earlier, all of us are going to be impacted by this.
[38:27.340 --> 38:29.320]  This is something that we all need to get involved with.
[38:29.420 --> 38:37.600]  So even if today you may have a certain expectation when you walk into hospital for a procedure that this has been taken care of, ask about it.
[38:37.780 --> 38:38.500]  Talk to your doctor.
[38:38.940 --> 38:40.060]  You know, have you...
[38:40.700 --> 38:43.940]  You know, what do you know about the cyber safety of this device I'm connected to?
[38:44.200 --> 38:47.180]  And maybe next time they talk to the vendor rep, they'll ask the same question.
[38:47.840 --> 38:51.880]  If you're a researcher, what are some of these devices that you can look at and research?
[38:52.180 --> 38:54.200]  How can you get involved and help solving this problem?
[38:55.580 --> 38:59.220]  So importantly, you know, we have to have the stakeholders understanding the prerequisites.
[38:59.300 --> 39:05.240]  You know, as I mentioned before, our increase in implementation is fairly rapid.
[39:05.460 --> 39:08.540]  Do the stakeholders understand that you can't just plug something into a network?
[39:08.720 --> 39:13.360]  That you can do that, but before that, you probably should do some other different things.
[39:13.720 --> 39:15.360]  How can we get people to talk together?
[39:15.360 --> 39:16.880]  Certainly important part of the treatment.
[39:17.600 --> 39:20.140]  Engaging with willing allies where we overlap with things.
[39:20.280 --> 39:26.880]  So not everyone's an expert in everything, but certainly this is a big enough problem where we can work with each other to try and find a common solution.
[39:27.180 --> 39:30.400]  And also incorporating safety into existing processes.
[39:30.600 --> 39:38.460]  So how can we work to make sure that when we have a process like procurement at a hospital, how can we incorporate cyber safety as part of that?
[39:39.740 --> 39:43.600]  So Scott's going to talk a little bit about highlights for the last 18 months.
[39:44.140 --> 39:47.840]  And then we'll... we have some time for questions after that.
[39:50.600 --> 39:54.520]  Yeah, so really quickly, you know, you might think like, well, this is a lost cause.
[39:54.700 --> 39:55.960]  Like nobody's doing anything about it.
[39:56.160 --> 39:57.360]  It's all due and gloom.
[39:57.660 --> 40:09.260]  And while I think we'd be ignorant to say there isn't a serious problem that needs to be addressed, there has been a lot of, you know, that stakeholder engagement and collaboration with the willing allies, right?
[40:09.420 --> 40:15.140]  And so over the last 18 months, so we've seen the U.S., the FDA actually take a stance now.
[40:15.920 --> 40:21.780]  They did historically a very good job of evaluating clinical efficacy and safety under intentional use.
[40:21.880 --> 40:24.600]  And the security stuff is definitely different, right?
[40:24.720 --> 40:28.080]  It's unintentional use or abuse cases of these devices.
[40:28.180 --> 40:29.500]  And so that's new to them.
[40:29.500 --> 40:33.220]  So they released pre-market and post-market draft guidance.
[40:33.400 --> 40:36.600]  The draft guidance from a security researcher perspective is awesome.
[40:36.760 --> 40:45.160]  It's awesome for a healthcare provider, too, that includes language that they have to have, you know, a coordinated vulnerability disclosure program and set some time limits around that.
[40:45.260 --> 40:46.800]  So that's a huge win.
[40:46.800 --> 40:51.440]  And that's a government agency working in collaboration even with security researchers.
[40:51.700 --> 40:59.780]  So, you know, I go and speak with them, many other members of, you know, that are associated with the cavalry or device researchers like Billy Rios.
[41:00.060 --> 41:06.600]  You know, we spend time to educate staff and let them know our perspective of that, that stakeholder perspective from the researcher.
[41:06.680 --> 41:07.880]  And they've been open.
[41:07.900 --> 41:08.740]  They've opened the doors.
[41:08.740 --> 41:13.060]  And a lot of what we've said in the message has been communicated and has pushed that forward.
[41:13.060 --> 41:18.900]  There was an IEEE workshop that was funded that was on a secure building code design that I was involved in.
[41:19.600 --> 41:21.820]  We've been embraced in the healthcare community conferences.
[41:22.100 --> 41:27.980]  So, you know, I speak at HIMSS, which is the largest, you know, healthcare IT conference in the world.
[41:28.120 --> 41:29.820]  I mean, it's over 40,000 people now.
[41:29.840 --> 41:31.480]  So I've spoken there the last few years.
[41:32.580 --> 41:34.060]  Vulnerability disclosure policies.
[41:34.060 --> 41:40.440]  Two years ago, we didn't have a single device manufacturer that had a coordinated vulnerability disclosure program.
[41:41.920 --> 41:48.360]  And now, two years ago at DEFCON, Philips Healthcare was the first one to announce that they were going to do it.
[41:48.480 --> 41:50.420]  And they finished it at the end of that year.
[41:50.660 --> 41:55.800]  And so they were the first healthcare organization to implement vulnerability coordinated disclosure.
[41:56.320 --> 41:58.040]  And now there's more.
[41:58.620 --> 42:00.560]  So now there's...Drager has done it.
[42:00.560 --> 42:02.440]  And they announced it at B-Sides last year.
[42:04.140 --> 42:07.000]  And Philips and Medtronic has a dedicated website.
[42:07.440 --> 42:09.980]  GE has, you know, a dedicated reporting method.
[42:10.140 --> 42:11.260]  So it's getting better.
[42:11.260 --> 42:12.580]  And now it's in the FDA guidance.
[42:14.040 --> 42:17.100]  The FDA actually issued a safety communication.
[42:17.380 --> 42:19.560]  And this was with Hospira pumps.
[42:19.740 --> 42:23.100]  It was a result of Billy Rios' research on the infusion pumps.
[42:23.320 --> 42:28.400]  But they actually issued a safety communication that said, Hospitals, look at these systems.
[42:28.660 --> 42:29.580]  They're vulnerable.
[42:29.580 --> 42:31.620]  We recommend you pull them out of service.
[42:31.820 --> 42:32.740]  That happened.
[42:32.860 --> 42:33.880]  That was precedent setting.
[42:34.020 --> 42:35.900]  That happened before evidence of harm.
[42:36.120 --> 42:44.640]  If you follow the FDA, recalls, things like that, typically don't happen until there's recorded loss of life or adverse events reported to the FDA.
[42:44.800 --> 42:46.000]  So that was precedent setting.
[42:46.120 --> 42:48.480]  They stood up and they said, hey, we're issuing the safety communication.
[42:48.480 --> 42:49.440]  So that was great.
[42:49.640 --> 42:50.780]  And I am the cavalry.
[42:51.460 --> 42:56.560]  Beau Woods, for those of you who know him, he's actually here at the conference.
[42:56.560 --> 42:58.160]  I highly encourage you to speak to him.
[42:58.480 --> 42:59.440]  I worked with him.
[42:59.580 --> 43:09.260]  But he was definitely the heavy lifter on kind of creating a Hippocratic Oath for connected medical devices, which outlines cyber safety capabilities that can be incorporated in these devices.
[43:09.260 --> 43:11.020]  So go and check that out as well.
[43:11.220 --> 43:17.860]  It's definitely of value for both manufacturers and providers.
[43:21.760 --> 43:24.380]  And other research or other resources, right?
[43:24.580 --> 43:28.580]  You can follow awesome researches on Twitter like my handle or Adam.
[43:29.000 --> 43:32.220]  And you can go to industry working groups if you're in healthcare.
[43:32.440 --> 43:34.000]  Like the ISACs, you can argue effectiveness.
[43:34.160 --> 43:37.060]  But if you're not out there talking to folks, you're really not doing much.
[43:37.260 --> 43:38.760]  You're just kind of being that antagonist.
[43:38.880 --> 43:40.080]  So get involved with that.
[43:40.180 --> 43:41.100]  MDIS is another group.
[43:41.520 --> 43:42.380]  You know, conferences.
[43:42.600 --> 43:49.100]  Everywhere from technical research conferences all the way to, you know, going to those other stakeholder groups and speaking to healthcare folks.
[43:49.100 --> 43:53.880]  That typically aren't aware that this is even an issue that have the power to make, you know, and influence change.
[43:54.520 --> 43:55.500]  And finally, I am the cavalry.
[43:55.780 --> 43:56.480]  I mean, check it out.
[43:56.660 --> 44:05.100]  It's a group of, you know, a grassroots group of researchers that focus on the intersection of, you know, security and public safety, right?
[44:05.360 --> 44:08.200]  And before, I am the cavalry even existed.
[44:08.400 --> 44:13.540]  I mean, me telling you my story why I was passionate is I was able to solve problems with these devices.
[44:14.020 --> 44:20.600]  Come, you know, all the way through remediating those vulnerabilities and having an impact on patient safety or public safety.
[44:20.720 --> 44:21.880]  And that was rewarding for me.
[44:22.060 --> 44:26.640]  So I can tell you as a security researcher, you know, everyone in this room is very smart and does awesome things.
[44:27.260 --> 44:34.880]  And I can tell you it's much more rewarding personally if you focus, you know, your research to things that actually impact public safety.
[44:34.880 --> 44:43.560]  Because with this emergence of IoT, with auto, you know, even, you know, ICS SCADA stuff, just general IoT medical devices, it's very important.
[44:43.760 --> 44:50.680]  And so the people and the skills that are in this room, you know, I highly encourage you to start looking at this stuff because you really can make a difference in the cavalry.
[44:51.000 --> 44:56.260]  You know, it's just a great group of folks to, you know, share ideas with and kind of move that message forward.
[44:56.440 --> 44:57.540]  So thanks for coming out.
[44:57.620 --> 44:58.840]  We'll open up for a few questions.
[44:58.860 --> 45:00.920]  And if we don't get to you, we'll be all back in the hallway.
[45:07.850 --> 45:13.470]  So it looks like you got a giant corpus of Shodan related exposed systems.
[45:13.630 --> 45:18.590]  Did you report that to the director of HHS for HIPAA enforcement under the security rule?
[45:19.010 --> 45:21.110]  So certain things, yes.
[45:21.870 --> 45:25.410]  So they're sent to typically in like disclosure, like it'll go to cert.
[45:25.690 --> 45:31.110]  In the early days, there wasn't really anyone that would even respond to us, right, when we would start to send in the disclosure.
[45:31.110 --> 45:34.070]  So then we just kind of started mass like sending everyone.
[45:34.230 --> 45:37.230]  So like HHS, sending it to FDA, sending it to ICS cert.
[45:37.970 --> 45:45.610]  ICS cert is the one that, rightly or wrongly, I don't know if that's the right place ultimately, but they started to respond to us and actually work through it.
[45:45.710 --> 45:52.150]  And some of the similarities, you know, with the ICS infrastructure were close enough to where some of these manufacturers even.
[45:52.150 --> 45:56.750]  And so like the GE or the Philips or the Siemens, they have an ICS type equipment.
[45:56.830 --> 45:58.230]  And so they had like a contact with them.
[45:58.310 --> 45:59.650]  And so they kind of started that route.
[45:59.710 --> 46:02.410]  And then now it does get shared through.
[46:02.590 --> 46:08.050]  I would say more so than HHS so far taking a stance has been, you know, the FDA involvement.
[46:08.210 --> 46:14.350]  It still has not been completely sorted out from like an OCR or HIPAA patient privacy perspective.
[46:14.610 --> 46:15.050]  But good question.
[46:15.050 --> 46:25.350]  And I was a little surprised that you didn't talk at all about installed customer hand medical devices like insulin pumps and cardiac pacemakers and that kind of thing.
[46:25.530 --> 46:25.690]  Yeah.
[46:26.310 --> 46:32.830]  Because, of course, there could be millions of those when there are only a few hospital-based fixed devices.
[46:33.370 --> 46:34.970]  So is that an area of interest to you also?
[46:35.210 --> 46:35.610]  Absolutely.
[46:35.730 --> 46:35.810]  Yeah.
[46:35.910 --> 46:42.550]  We've definitely taken a look at those types of systems all the way from implantable, you know, defibrillators to pacemakers.
[46:42.550 --> 46:45.070]  I think some good research has been done before.
[46:45.170 --> 46:53.410]  All the way back in 2008, Dr. Kevin Fu, who's now at University of Michigan and leads Archimedes, did some really good research, you know, back when we weren't using any type of encryption.
[46:53.950 --> 47:02.950]  They would call it proprietary, you know, but it was really just radio frequency over like, you know, the 400 band and lack of encryption and you could do near-field communication.
[47:03.130 --> 47:03.430]  For software updates.
[47:03.610 --> 47:04.390]  Yeah, absolutely.
[47:05.810 --> 47:07.110]  And, you know, insulin pumps.
[47:07.250 --> 47:09.070]  I think, you know, Jay Radcliffe has done that.
[47:09.410 --> 47:11.370]  Barnaby Jack kind of showed that as well.
[47:11.370 --> 47:12.530]  So that's there.
[47:12.650 --> 47:14.610]  I think with insulin pumps, it's interesting.
[47:14.750 --> 47:17.990]  There's this idea of artificial pancreas and kind of continual loop.
[47:17.990 --> 47:22.770]  And now you have these systems in development that's going to do a lot clinically for people, right?
[47:22.950 --> 47:26.370]  I mean, bottom line, it's going to help a lot more people than it harms.
[47:26.390 --> 47:34.110]  But the risks of that are you have the pump talking to the glucose monitor, talking to your smartphone, and it's a full relay.
[47:34.110 --> 47:42.310]  And it's taking that data integrity becomes an issue if you can compromise that because the system's automatically treating based on the software.
[47:42.490 --> 47:49.130]  And you didn't find any attempts at attacks on individuals who are in hospital, which I would expect to see at some point?
[47:49.130 --> 47:54.510]  I mean, you can think about targeted attacks, but I think it's important to look at, like, that can happen.
[47:54.690 --> 47:58.070]  But I'm more concerned, honestly, with unintentional consequences.
[47:58.310 --> 48:06.050]  So we have low assurance because these devices lack forensic logging capabilities in many cases, or, you know, forensically sound evidence capture.
[48:06.050 --> 48:12.250]  How do we know that that malware that we see that was meant to steal credit card data didn't cause a configuration change?
[48:12.930 --> 48:20.450]  And we actually reported... the clinical engineering team actually reported a medical device malfunction, but it's never adjudicated out of...
[48:20.450 --> 48:29.830]  It just goes to a general medical device malfunction-related death bucket, which several hundred thousand reports a year go into the FDA of medical device-related malfunction adverse events.
[48:29.970 --> 48:31.130]  And it's that generic.
[48:31.570 --> 48:33.810]  So how do we know with these connected devices that it's not?
[48:33.850 --> 48:34.570]  We have low assurance.
[48:34.570 --> 48:38.910]  And I think really unintentional is more realistic on a mass scale.
[48:39.950 --> 48:40.490]  Hi.
[48:40.890 --> 48:41.990]  I'm Greg Baker.
[48:42.150 --> 48:44.790]  I'm with the National Board of Medical Examiners.
[48:45.010 --> 48:45.310]  Awesome.
[48:45.390 --> 48:55.750]  For those of you who are unaware, the National Board is a 101-year-old nonprofit focused on protecting the health of the public through assessing the competence of the healthcare team.
[48:55.910 --> 49:02.410]  And as you've amply demonstrated, IT is an integral part of the modern healthcare delivery system.
[49:02.410 --> 49:05.010]  So I have two questions, if I may.
[49:05.290 --> 49:05.590]  Absolutely.
[49:05.870 --> 49:07.510]  First question, can I put you on the spot?
[49:08.990 --> 49:09.570]  Go ahead.
[49:10.250 --> 49:11.110]  Second question.
[49:11.230 --> 49:11.810]  Oh, time's up.
[49:12.970 --> 49:13.530]  No.
[49:13.770 --> 49:14.130]  Go ahead.
[49:15.070 --> 49:24.610]  Just thinking off the cuff, how would you recommend my organization think about assessing the competence of the individuals who've set up these healthcare delivery systems?
[49:25.570 --> 49:28.910]  So you're saying the individuals that are actually installing into the system?
[49:29.110 --> 49:29.450]  Absolutely.
[49:29.750 --> 49:33.930]  Yeah, so I think that's a good point of, you know, talking about how do you implement those securities.
[49:34.090 --> 49:35.390]  So you have secure design, right?
[49:35.470 --> 49:38.810]  And the focus right now, even from the FDA, has been putting pressure on the manufacturers.
[49:38.990 --> 49:43.490]  And oftentimes the providers, the healthcare systems say, well, it's the manufacturers, it's their problem.
[49:43.550 --> 49:47.210]  We're going to sit on our butts and we don't need to do anything until they secure these devices.
[49:47.210 --> 49:53.250]  But as we've shown like with that showdown stuff, that was actually the hospital's fault for implementing it in an insecure fashion.
[49:53.490 --> 49:56.670]  So there's certain things that you need to do things about.
[49:56.810 --> 50:02.170]  So that concept like that IEEE thing that I said was a concept of this was at a software perspective, but it was a building code, right?
[50:02.330 --> 50:13.130]  And so I see something like that of almost, you have inspector regimes that go in and specifically in a hospital now, if you put electrical into an OR, there's specific specifications you have to do and there's an inspector regime to do that.
[50:13.130 --> 50:19.010]  I see something like that on the provider side of securely, there's secure design and then there's secure deployment, and that needs to be addressed.
[50:20.010 --> 50:21.910]  I've got two minutes left, I guess.
[50:22.090 --> 50:22.470]  Thank you so much.
[50:22.850 --> 50:24.710]  Hugely informative and important.
[50:24.870 --> 50:27.350]  I'm wondering if you've been following along with the sensor pills.
[50:27.650 --> 50:29.550]  So like you said with the insulin device...
[50:29.550 --> 50:30.710]  Yeah, where you swallow them and then it measures...
[50:30.710 --> 50:35.290]  You swallow it, and the first one approved was an anti-psychotic abilify, which is being used for forced treatment.
[50:35.510 --> 50:43.310]  So on the flip side of this, like when the devices are being used against the interests of the patients, have you been doing any research to help protect the patients from the devices?
[50:44.350 --> 50:45.150]  Not necessarily.
[50:45.450 --> 50:49.350]  So like some of those newer like prototype devices, like these are like ingestible.
[50:49.530 --> 50:58.690]  So like you would digest them and then it would monitor something and then it would typically, it will talk over like Bluetooth actually to an app that then will treat you, right?
[50:58.830 --> 51:01.010]  Or just transmit like real-time data.
[51:01.290 --> 51:07.070]  And so we haven't done a whole lot on those because a lot of them are actually like prototype devices that would be super expensive to get a hold of.
[51:07.070 --> 51:10.970]  And so we haven't had any like research universities say, hey, come check this device.
[51:10.970 --> 51:12.030]  We're willing to let you have it.
[51:12.030 --> 51:12.810]  So no, we have not.
[51:12.810 --> 51:14.830]  But it's definitely an area of concern going forward.
[51:14.830 --> 51:18.710]  And I'm sorry to cut you off, but we're getting shoved out here.
[51:18.750 --> 51:23.730]  So if you have questions or want to talk, we'll try to jump here back out in the hallway.
[51:23.790 --> 51:24.590]  So thanks for coming out.