[00:00.000 --> 00:02.360]  I just dropped it in the private chat.
[00:17.780 --> 00:20.080]  And we're not streaming.
[00:20.080 --> 00:23.400]  We host DEF CON music and it takes a hot second to switch away from it.
[00:33.060 --> 00:34.900]  There we go.
[00:35.540 --> 00:37.420]  And you guys are live.
[00:39.660 --> 00:42.360]  Welcome DEF CON safe mode.
[00:42.360 --> 00:46.560]  We're here at the DEF CON 28 safe mode.
[00:46.560 --> 00:52.180]  Do no harm, a healthcare security conversation Q&A.
[00:52.660 --> 00:55.560]  If you haven't had an opportunity to check out our pre-recorded video,
[00:55.560 --> 00:57.780]  it's on the media server and it's also on YouTube.
[00:57.780 --> 01:01.280]  We go for about an hour talking about some various topics that
[01:01.280 --> 01:03.440]  we'll probably touch on again tonight.
[01:03.440 --> 01:07.660]  Your opportunity here is to ask us questions in the Discord text channel
[01:07.660 --> 01:10.040]  and then see us live on Twitch.
[01:10.040 --> 01:12.900]  If you have any questions or anything, go ahead and feel free to put them in there
[01:12.900 --> 01:15.760]  and we'll get them in no particular order.
[01:15.760 --> 01:19.040]  All right, I'm going to kick it off and let everyone introduce themselves briefly.
[01:19.040 --> 01:21.300]  And then we're going to go ahead and get to the first question.
[01:21.300 --> 01:22.420]  I'll start with myself.
[01:22.420 --> 01:23.440]  Hey, I'm Quadi.
[01:25.180 --> 01:25.820]  Replicant here.
[01:25.820 --> 01:27.400]  Hope everyone is safe and healthy.
[01:29.440 --> 01:30.980]  Hi, my name is Ash Luft.
[01:30.980 --> 01:35.780]  I'm an embedded software developer from Starfish Medical.
[01:40.920 --> 01:42.440]  I have no idea what order we're going in.
[01:42.440 --> 01:43.460]  So I'm Jessica Wilkerson.
[01:43.460 --> 01:46.120]  I'm from the FDA and I'm a cyber policy advisor.
[01:51.920 --> 01:53.100]  Hey, I'm Vidya.
[01:53.100 --> 01:55.560]  I am from MedCorp.
[01:55.560 --> 01:58.640]  We are a cybersecurity solution targeting medical devices.
[01:58.640 --> 02:00.280]  And V, I'll turn it to you.
[02:01.160 --> 02:02.280]  It's Ivy.
[02:02.440 --> 02:03.740]  I'm a goon.
[02:03.740 --> 02:06.440]  I am a patient, a hacker, and a researcher.
[02:06.600 --> 02:08.400]  And that's about all about me.
[02:08.400 --> 02:09.620]  Back to you, Quadi.
[02:10.200 --> 02:10.880]  Awesome.
[02:10.880 --> 02:13.620]  So I'm accepting some fantastic questions tonight.
[02:13.620 --> 02:17.360]  We're going to go ahead and kick off the first one with a user called Raziz,
[02:17.360 --> 02:22.060]  which has a multi-part question, but I think the heart of it is at the end here.
[02:22.060 --> 02:24.900]  And it's a question to everybody.
[02:24.900 --> 02:27.020]  Please don't be shy.
[02:27.100 --> 02:34.020]  Do we have the resources to adequately detect and respond to attacks against internet-connected
[02:34.020 --> 02:35.160]  medical devices?
[02:35.160 --> 02:40.340]  So right now, in the status quo, can we even detect these attacks as they're happening,
[02:40.340 --> 02:41.910]  specifically on the devices?
[02:43.360 --> 02:45.440]  Who wants to take it first?
[02:45.500 --> 02:46.800]  So I'll take a first pass.
[02:46.800 --> 02:53.080]  I think while there are several solutions that exist in the IoT space, their application
[02:53.080 --> 02:58.500]  to healthcare is what creates this problematic scenario where we're relatively inadequately
[02:58.500 --> 03:00.660]  equipped to sufficiently respond right now.
[03:00.660 --> 03:04.740]  I think we think about what's the worst thing that could happen when you put security on
[03:04.840 --> 03:07.460]  a thermostat, and we don't really think about, well, what's the worst that can happen when
[03:07.460 --> 03:10.620]  something happens to a medical device that's attached to a patient?
[03:10.720 --> 03:15.460]  And so being cognizant that while there is a potential to detect this from a technical
[03:15.460 --> 03:20.300]  perspective, there are ramifications for implementing that for real patient safety
[03:20.300 --> 03:21.940]  and actual patient care.
[03:24.800 --> 03:29.600]  I totally have to agree there, and it becomes even more complicated when we talk about implant
[03:29.600 --> 03:38.300]  tools. So to do any detection on those devices is very hard and not very robust at the moment.
[03:38.700 --> 03:44.600]  But the problem is, as well as Lydia said, the implementation of traditional cybersecurity
[03:44.600 --> 03:49.880]  tools in the healthcare space is problematic due to the fact that this is not your traditional
[03:49.880 --> 03:51.740]  cybersecurity space.
[03:52.300 --> 03:56.440]  Each hospital or healthcare institution faces their own challenges.
[03:57.280 --> 04:02.980]  So it's almost about having something that caters to your hospital and your healthcare
[04:02.980 --> 04:04.520]  institution.
[04:09.900 --> 04:19.020]  Yeah, I just want to chime in here for a second and say, yeah, I don't think many hospitals,
[04:19.020 --> 04:25.800]  under-resourced hospitals, have robust detection methods. You'll be surprised how many of them
[04:26.380 --> 04:31.220]  lack intrusion detection systems or have good endpoint security. You'd be surprised how many
[04:31.220 --> 04:35.020]  of them get regularly penetration tested or go through that entire process.
[04:35.020 --> 04:41.480]  And just to plug again, HHS and the FDA, the 2017 Health and Human Services Task Force report
[04:41.480 --> 04:47.360]  estimated that a good majority of hospitals in the United States lack a single full-time
[04:47.360 --> 04:54.580]  security professional on staff. So that's like a perfect storm to have a lot of attacks probably
[04:54.580 --> 04:56.280]  go undetected.
[04:56.420 --> 04:59.420]  The other little part of that, and I just want to just reflect on what Vee said, I completely
[04:59.420 --> 05:06.060]  agree. The home space is this complete black box. A lot of people who get medical devices,
[05:06.060 --> 05:11.620]  especially in the era of COVID, are given home monitoring equipment or they get an implantable
[05:11.620 --> 05:15.020]  and it has an accompanying base station. And when they're discharged from the hospital,
[05:15.020 --> 05:19.660]  they say, go plug this into your router at home. And there's really not a lot of work
[05:19.660 --> 05:23.620]  done to secure their home environments. And we don't know much about that space. It could
[05:23.620 --> 05:29.580]  be fine, or it could be a nightmare. I think what we lack is the ability to collect that
[05:29.580 --> 05:32.160]  information and then share it with people.
[05:33.120 --> 05:37.160]  I think that's a perfect point to raise around ownership, right? Like who is actually responsible
[05:37.160 --> 05:41.100]  for securing this? Is it really reasonable to ask someone to go home and secure their
[05:41.100 --> 05:45.900]  home network, not knowing their technical skillset or whether that's really part of
[05:45.900 --> 05:50.280]  getting care, right? And then you think about hospitals, is their core competency really
[05:50.280 --> 05:55.120]  going to become cybersecurity? And to the point of not even having resources, we have
[05:55.120 --> 05:59.920]  to really think about how we can think about where the ownership really needs to originate
[05:59.920 --> 06:02.380]  and what is most efficient and effective.
[06:05.810 --> 06:10.970]  One thing that I would say on this, I think is like the token government person on this
[06:10.970 --> 06:17.050]  panel, is I do have to plug all of the work that is happening at some of the national
[06:17.050 --> 06:23.510]  level policy issues, because I promise we are aware that these things are issues and
[06:23.510 --> 06:28.170]  they are being worked on. And so there are a lot of industry bodies, industry bodies,
[06:28.170 --> 06:33.030]  government bodies, and then bodies where the two come together, that have documented and
[06:33.030 --> 06:38.810]  just general conversations about this on a recurring basis. So I know as little respect
[06:38.810 --> 06:43.090]  as everybody can have for the myriad best practices guides and other things that, you
[06:43.090 --> 06:46.470]  know, white papers that the government puts out that sometimes just sit on shelves and
[06:46.470 --> 06:50.670]  never get used. But these are things that have been looked at and things like the medical
[06:50.670 --> 06:56.610]  device sectors, joint security plan, they've been looked at for healthcare delivery organizations,
[06:56.610 --> 07:00.410]  something called the HICUP. And if you paid me money right now, I could not actually tell
[07:00.410 --> 07:03.830]  you what that acronym stands for. But it's like the healthcare version, the hospital
[07:03.830 --> 07:10.890]  version of their best practices guide. And in the HICUP in particular, I want to say
[07:10.890 --> 07:14.870]  it is, or maybe it's the JSP, one of the two, they actually have like, it's separated out
[07:14.870 --> 07:18.510]  into what large organizations can do, and then what small and medium sized organizations
[07:18.510 --> 07:23.110]  can do. And they do different things for both or recommend different things for both. So
[07:23.110 --> 07:29.170]  this is an ongoing conversation that is happening at that national level. But we certainly don't
[07:29.170 --> 07:37.020]  claim to have all of those answers. Another thing that I think is important is
[07:37.020 --> 07:41.140]  we're moving into a thing where we want to do early detection and monitoring. But most
[07:41.140 --> 07:45.220]  of the instances where there has been hospital breaches, we've been left on the back foot,
[07:45.220 --> 07:50.720]  right? We needed to become aware of the breach before we could actually act on the breach.
[07:50.900 --> 07:57.460]  So I don't think there is that early... within healthcare at the moment. I can use an example
[07:57.460 --> 08:02.800]  of a healthcare attack in South Africa itself, they only became aware of it once the systems
[08:02.800 --> 08:08.160]  were encrypted. And once you know, the damage has been done. So often, we have to rely on
[08:08.160 --> 08:15.600]  the cyber criminals to make us aware of their presence in our networks. It would be awesome
[08:15.600 --> 08:20.180]  if we could detect it early and stop it. I mean, that is the golden standard. That is the dream.
[08:20.180 --> 08:26.320]  But I don't think we're there yet. I think the real dream is being proactive about this,
[08:26.320 --> 08:30.180]  and getting the security on the device so it doesn't even get to the point of there being
[08:30.300 --> 08:34.600]  a vulnerability that has to be detected. If we can just reduce the end of things that need to
[08:34.600 --> 08:40.180]  be detected, there's a better probability of actually coming up with it. But is that going
[08:40.180 --> 08:45.200]  to actually be something that we're going to get? Because I mean, these devices last for long. So
[08:45.200 --> 08:51.380]  inevitably, there is going to be vulnerabilities always. It's going to be there because as time
[08:51.380 --> 08:57.220]  progresses, research is done, and libraries become vulnerable, or hardware becomes vulnerable.
[08:57.440 --> 09:02.720]  Also, it's about the threat landscape, right? We're talking about risk here. And just like
[09:02.720 --> 09:06.040]  everything in life, there's nothing, there's no such thing as risk-free. We can't just
[09:06.040 --> 09:10.780]  have a device that has security or doesn't. There's always pros and cons. We can't think
[09:10.780 --> 09:17.640]  of every possible thing. So it's always, it's this combination, right, of, you know,
[09:17.640 --> 09:21.040]  building the devices and making them as secure as we can in a reasonable amount of time with
[09:21.040 --> 09:26.800]  the resources we have. And then once they're out into, you know, the healthcare ecosystem or the
[09:26.800 --> 09:31.100]  consumer ecosystem, in the case of, you know, medical devices that maybe have to be on a home
[09:31.100 --> 09:37.660]  network, there's so many pieces to that threat landscape, right? I don't, like, I'm not sure how
[09:37.660 --> 09:45.720]  we can fully secure it. Like, there's no, there's no perfectly secure network, right?
[09:47.320 --> 09:51.980]  I also want to throw one other wrinkle into this, which is that there's actually some
[09:52.720 --> 09:58.980]  systemic, systematic issues when it comes to healthcare. Usually in hospitals, what's
[09:58.980 --> 10:03.300]  traditionally been the paradigm is that the network's owned by IT, and that's where all
[10:03.300 --> 10:07.680]  the security folks live, and they're able to detect kind of the attacks that they're used to,
[10:07.680 --> 10:11.620]  and they can control some of that. But as soon as it comes to the medical device side of it,
[10:11.620 --> 10:17.960]  they kind of wash their hands or are told, don't go there, that's bioengineering, and they
[10:17.960 --> 10:23.480]  handle all the medical devices. And so what you often have is a dearth of cybersecurity knowledge
[10:23.480 --> 10:28.560]  in the bioengineering space. By no fault of their own, they have a lot of other things,
[10:28.560 --> 10:33.220]  they're fantastic people, but what we have as a result of that is this something we call the
[10:33.220 --> 10:38.480]  discovery dilemma, where if you don't have people thinking about these issues, and you have
[10:38.480 --> 10:44.620]  malfunctioning medical devices, you are unlikely to find a problem, even if there was some random
[10:44.620 --> 10:48.560]  malware that spread over your network, it affected some of your medical devices, and as a consequence
[10:48.560 --> 10:54.900]  they stopped working. Unless you are thinking about that as a potential etiology of your problem,
[10:54.900 --> 11:00.860]  you're not going to go and look the one and two steps further to figure out if that was the issue.
[11:01.000 --> 11:05.500]  So we talked a little bit before this panel started about the discipline of forensics. I've
[11:05.500 --> 11:11.360]  asked many bioengineering organizations and groups and hospitals across the country and asked how many
[11:11.360 --> 11:16.440]  of them do that type of forensic work on malfunctioning devices that are just really
[11:16.440 --> 11:21.040]  out of the ordinary, and none of them said that they did. It's something we have to change. So
[11:21.040 --> 11:25.900]  it's because the structure of these healthcare systems in such a way where there's a bright line
[11:25.900 --> 11:31.040]  between who handles medical devices and who handles the network, and because those two groups don't
[11:31.040 --> 11:35.820]  co-mingle and have equitable cybersecurity knowledge where we might have this problem,
[11:35.820 --> 11:39.660]  where this might be a very common thing, but just we're not detecting it.
[11:40.120 --> 11:43.900]  So I don't know if you want to, if we're like looking to move on to the next question here,
[11:43.900 --> 11:48.380]  but one thing that I would point out on that, that I've certainly experienced,
[11:48.380 --> 11:55.900]  especially over the last couple of months, is we're, we have experienced, I would say,
[11:55.900 --> 12:00.460]  less and less medical device specific vulnerabilities where it's like the pacemaker
[12:00.460 --> 12:05.440]  has a vulnerability or the MRI has a vulnerability. What we're now seeing are like higher level
[12:05.440 --> 12:11.980]  protocol vulnerabilities. Swintooth was a great example. There was the, all of the, the whole run
[12:11.980 --> 12:17.660]  of Bluetooth vulnerabilities. There was the Ripple 20. There was the Trek, which I think was, was the
[12:18.320 --> 12:23.640]  one part or Trek TCP IP was one part of Ripple 20 or whatever it was. But anyway, these are
[12:23.640 --> 12:29.020]  things that are not medical device specific. But what we're starting to see, and it goes to
[12:29.020 --> 12:35.880]  the detection point. And then I wanted to hit on something that Vidya had said. The, the, almost
[12:35.880 --> 12:39.880]  the nice thing that's happening about the fact that we have general IT vulnerabilities that are
[12:39.880 --> 12:44.000]  now making their way into the medical device space or becoming relevant to the medical device space
[12:44.000 --> 12:49.580]  is other sectors are detecting them for us. So even though there's maybe a little bit of a lag
[12:49.580 --> 12:55.260]  in detection and in, I don't know, identification capability within the sector itself, because that
[12:55.260 --> 12:59.500]  expertise may exist in other sectors. And because we're all relying on the same software, the software
[12:59.500 --> 13:04.240]  that's in a medical device is the same that's in a consumer product. We're ending up still being
[13:04.240 --> 13:09.940]  notified and still being able to notify others because it's happening in other sectors. But the
[13:09.940 --> 13:13.580]  other thing, you know, Vidya had a good point about like, we need to, we need to lessen essentially
[13:13.580 --> 13:18.100]  the attack space. And certainly acknowledging the fact that V and Ash are both right, like
[13:18.100 --> 13:23.140]  things are always going to be vulnerable. Another thing that we've noticed is that we have an
[13:23.140 --> 13:28.360]  increasing number of manufacturers who will tell them about vulnerabilities. And especially with
[13:28.360 --> 13:33.380]  the Bluetooth ones, we have certain manufacturers who are like, oh yeah, but like the way we
[13:33.380 --> 13:38.460]  architected our system, like our device doesn't trust the Bluetooth that's built into the device.
[13:38.460 --> 13:44.000]  So all of these Bluetooth vulnerabilities don't impact us. And I think that that's sort of what
[13:44.000 --> 13:49.560]  Vidya was getting at is like, we can build systems that are not impacted by certain types
[13:49.560 --> 13:58.580]  of vulnerabilities. We just have to actually put in the work to do that. And I think, sorry,
[13:59.240 --> 14:05.720]  Ash and I had this conversation, right? Security, the way that you change security and manufacturing
[14:05.720 --> 14:11.120]  Ash was, right, we said it needs to be cheap and it needs to be easy and it needs to be accessible
[14:11.120 --> 14:14.860]  and it should be the easiest thing to do. It shouldn't be the hardest thing to do and it
[14:14.860 --> 14:19.720]  shouldn't be the most expensive thing to do. And when I refer to expensive, I don't necessarily
[14:21.640 --> 14:28.860]  mean in terms of cost, it could be time, it could be design, it could be research, it could be CPU,
[14:28.860 --> 14:33.540]  it could be battery life, right? But the thing is at this point, I don't think,
[14:33.540 --> 14:40.240]  you know, at that end of the pipeline, that is very easily accessible for the smaller companies,
[14:40.240 --> 14:46.280]  I'm not talking about your big companies, but your smaller ones that are doing some innovative work.
[14:49.930 --> 14:55.390]  All right, we have a new question from Judo. And I think that this is going to be one we can all
[14:55.390 --> 15:00.730]  kind of chime in on. It's, I think, boiled down to what are the steps that industry and I'm going to
[15:00.730 --> 15:06.630]  add regulators in the space are taking to formalize stricter risk and controls around device development
[15:06.630 --> 15:12.350]  that we use in patients. They assume that a larger device manufacturer formalized basic
[15:12.350 --> 15:16.750]  security features, just like the payment brands have done, and set standards for the rest of the
[15:16.750 --> 15:20.590]  industry. So I think there's a lot that's already been done. I just want to quickly reflect on that
[15:20.590 --> 15:25.770]  to say, you know, the conversations that we were having 10 years in this space, we're asking for
[15:25.770 --> 15:30.710]  this. And I feel like so much has changed between now and then where we, we do have a lot more
[15:30.710 --> 15:35.530]  standards. And I think that the industry is moving forward in a lot of ways. And we can still talk
[15:35.530 --> 15:39.870]  about some of the criticisms. But what I really think is a lot of people that have been paying
[15:39.870 --> 15:45.630]  close attention will say, yes, we saw the problem of legacy devices. But we, you know, I said it in
[15:45.630 --> 15:52.710]  the video, we don't have this year, to my knowledge, and there's still some time left, a story of a
[15:52.710 --> 15:58.610]  device manufacturer threatening to sue a security researcher, for example, or something like that,
[15:58.610 --> 16:03.850]  like WannaCry happened in 2017. So can everyone reflect on kind of what the industry has been
[16:03.850 --> 16:07.810]  doing? And we can take it back a few years and give examples of some of the landmark documents
[16:07.810 --> 16:12.350]  and guidance that has come from the industry as well as the regulation space.
[16:21.120 --> 16:29.220]  Well, I can kick us off as the regulator. So I, you know, I think I was not at FDA,
[16:29.220 --> 16:35.380]  let me preface this by saying, when some of these documents came out, but the two in 2014,
[16:35.900 --> 16:41.820]  I want to say, there was, you know, one of the first drafts of a cybersecurity guidance,
[16:41.820 --> 16:45.900]  particularly cybersecurity guidance came out at FDA. A few years later, there was the
[16:46.340 --> 16:52.740]  postmarket cybersecurity guidance. And then in 2018, the most recent one, you know, there was
[16:52.740 --> 16:58.000]  the new postmarket draft. And this was the one that talked about coordinated disclosure,
[16:58.000 --> 17:03.500]  talked about cybersecurity bill of materials, it talked about a lot of the advancements that
[17:03.500 --> 17:07.940]  had been made in the sector over the past couple of years from the time that the guidance had been
[17:07.940 --> 17:11.800]  most recently updated. And actually, let me just really quickly, for those of you who don't know,
[17:11.820 --> 17:18.520]  is essentially how FDA tells industry, the best way to meet the regulations, because if you try
[17:18.520 --> 17:22.900]  and read FDA's regulations, they're pretty bare bones. It's pretty much like you must do risk
[17:22.900 --> 17:27.000]  assessments. But then like that, that's the end of the sentence, and it doesn't have any other
[17:27.000 --> 17:32.680]  detail. So the guidance allows FDA to elaborate a little bit more on what precisely that means in
[17:32.680 --> 17:38.640]  given contexts. And so, you know, credit to to Suzanne Schwartz and Dr. Seth Harmony, who
[17:39.500 --> 17:44.600]  was worked on a lot of this when he was still with the agency. You know, they actually like
[17:44.600 --> 17:50.680]  fought the good fight and got cybersecurity specific guidance out from the FDA to industry.
[17:50.680 --> 17:55.520]  And I think, you know, obviously, I'm biased here, but that was just a huge leap forward,
[17:55.520 --> 18:00.680]  I think, in many ways for, for not only us, but for the industry.
[18:05.660 --> 18:10.880]  Yeah, I think, to that point, I think there, the the conversation that's come from all of
[18:10.880 --> 18:15.080]  that initiative, right, you you have, you have this relationship that I think didn't exist before,
[18:15.080 --> 18:18.540]  even if we go back four or five years, like there wasn't such a collaboration or willingness
[18:18.540 --> 18:23.940]  to have manufacturers work with security researchers work with security vendors,
[18:23.940 --> 18:28.780]  right? It was more of Okay, who can get what off of eBay? What can we prove doesn't work and then
[18:28.780 --> 18:33.620]  try to try to get the best headline that we can get out of it. And I think the if you listen to
[18:33.620 --> 18:37.560]  the recorded version of this, there's a lot of hope that we all have for where this conversation
[18:37.560 --> 18:41.120]  is going, and that there are going to be solutions coming out of this, I think on
[18:41.120 --> 18:43.960]  on all sides that are actually sustainable and efficient.
[18:45.920 --> 18:51.060]  So I can add a positive story. So three years ago, I had my first DEF CON, came as a patient,
[18:51.060 --> 18:56.100]  had some concerns about my own device, it was, as I would say, beautifully broken and wonderfully
[18:56.100 --> 19:03.040]  flawed. And I made Suzanne Schwartz at that one. But except for that, before coming to DEF CON,
[19:03.040 --> 19:07.960]  I actually reached out to my manufacturer and had a discussion with him and I was met with
[19:07.960 --> 19:15.580]  legal. You know, it was like running into a wall. It was a cold, unloving situation.
[19:16.300 --> 19:21.480]  Three years later, I'm working with that same manufacturer on things that I bought to them
[19:21.480 --> 19:27.140]  three years ago. It took us since December to find a footing where, you know, the discussion
[19:27.140 --> 19:31.700]  is not incriminating. It's not me pointing a finger. It's not them pointing a finger. It's
[19:31.700 --> 19:35.580]  finding a unison and what they bring to the table, what I bring to the table
[19:37.020 --> 19:42.920]  and working together. But except for that, I mean, we had conversations. I've been on the patient.
[19:44.360 --> 19:47.620]  I don't know what the word is that you guys, that Jessica,
[19:49.420 --> 19:55.480]  that gave patients the opportunity to give their experiences, right?
[19:56.660 --> 20:01.140]  So generally in three years that I've been involved in this, we've made leaps and bounds.
[20:01.700 --> 20:07.180]  Is that necessarily enough yet? No, I don't think we should lose momentum. I think we should kick
[20:07.180 --> 20:11.300]  ass and keep going. I think we should push the envelope. I think we should have the hard
[20:11.300 --> 20:22.820]  conversations. And I don't think we should stop now. Yeah, I would agree. I think that the
[20:22.820 --> 20:28.620]  landscape is shifting really quickly. When I started working on medical devices, which was
[20:28.620 --> 20:36.360]  over five years ago, already the technology has changed so much. Even in the last 15 years,
[20:36.360 --> 20:40.980]  if you think about, you know, smartphones and, you know, 20 years ago, I don't think most of us
[20:40.980 --> 20:46.520]  would have predicted that ubiquitousness of it and the impact that it would have on our daily lives.
[20:46.520 --> 20:53.920]  And so, you know, historically medical devices were electromechanical and, you know, as medical
[20:53.920 --> 20:59.340]  device manufacturers, we come, we have a system about approaching things from a risk and from a
[20:59.340 --> 21:03.940]  safety perspective, like how do we make sure that people are safe? And a lot of medical devices
[21:03.940 --> 21:08.600]  didn't have software in them. And then we started putting software in and then we started connecting
[21:08.600 --> 21:14.920]  that software to the internet. And then all of a sudden the risk just blew open because now we can,
[21:14.920 --> 21:19.120]  we have, we have IOT devices, we have clinical IOT devices, we have medical IOT devices,
[21:19.120 --> 21:24.300]  we have implantable IOT devices. And so everything has been changing so fast. And I think,
[21:24.300 --> 21:31.720]  you know, getting regulatory and getting standards in place takes time. And, you know,
[21:31.720 --> 21:36.140]  especially from a software perspective, how many standards exist? Like we have so many standards
[21:36.140 --> 21:41.360]  in software that are competing standards. If everyone would just follow my standard,
[21:41.360 --> 21:46.340]  it would all be fine. But then there's 20 other people who also have a standard that they want
[21:46.340 --> 21:50.520]  everyone to follow. And so it's, you know, it's tough. It's like the wild, wild west for software,
[21:50.520 --> 21:56.520]  right? And so I've seen like a lot of these different groups coming together, you know,
[21:57.320 --> 22:03.360]  obviously FDA is a part of it, but, you know, you know, most of our customers are,
[22:03.360 --> 22:07.320]  they want to serve American markets. So we actually talk about FDA a lot every single day.
[22:07.900 --> 22:13.520]  But there is the rest of the world that isn't governed by the FDA. And so there's a lot of
[22:13.520 --> 22:19.000]  different bodies working together. And yeah, I see it as hopeful. I know IEEE is working on
[22:20.000 --> 22:24.760]  international standards for clinical IOT and medical devices and interoperability.
[22:25.460 --> 22:31.740]  And yeah, I think people are working on it, but I don't think we're there yet. Certainly.
[22:32.380 --> 22:38.320]  I actually have to jump on that because I think if I don't, one of my bosses is going to find me
[22:38.320 --> 22:44.180]  at home. But to the point about international regulation, there is a body called the
[22:44.180 --> 22:49.520]  International Medical Device Regulators Forum. And speaking of, you can never get government to
[22:49.520 --> 22:54.180]  do anything in any reasonable amount of time. That's just sort of a default law of the universe.
[22:54.300 --> 22:59.060]  But that group, which is a group of, it's like a nested group of regulators. So you would have
[22:59.060 --> 23:04.620]  thought that this would have taken significantly longer than it did. But they actually just came
[23:04.620 --> 23:10.060]  out with a cybersecurity guidance document. And so that's another thing that's been really
[23:10.060 --> 23:14.520]  valuable for us. And I would actually encourage everybody to go look at it. It's got a really
[23:14.520 --> 23:20.760]  fun definition of legacy that you all might have thoughts on. So anyway, IMDRF guidance.
[23:25.220 --> 23:29.120]  The only thing I can add is that we're never going to be done, right? So as much as we've
[23:29.120 --> 23:32.640]  progressed, and absolutely take a moment to recognize the accomplishments here,
[23:32.640 --> 23:35.280]  there's certainly a path that we need to continue pursuing
[23:35.280 --> 23:40.080]  in order to even maintain a baseline of security across the board.
[23:41.280 --> 23:46.620]  I think what I want to see, and this would make me like as a patient super happy, is if we had
[23:48.300 --> 23:54.760]  in the manufacturing, we had security standards for secure manufacturing, because it's one thing
[23:54.760 --> 23:59.280]  having a cybersecurity framework, right? Or a guidance in terms of that. But it's a different
[23:59.280 --> 24:05.760]  thing and having a standard for, you know, how we are going to securely manufacture these devices,
[24:05.760 --> 24:11.420]  because often than not, you know, hardware is the constraint. Because when we talk medical devices,
[24:11.420 --> 24:17.520]  we are designing, you know, firmware to run on hardware. So I think we need to, you know,
[24:17.520 --> 24:23.100]  completely start at the beginning, when they conceptualize the requirements is that we need
[24:23.100 --> 24:29.640]  to build security in there, right? It shouldn't be this, you know, after the fact, kind of like,
[24:29.640 --> 24:36.180]  let's put it on the end and, you know, hope for the best. And that's, you know, normally done,
[24:36.180 --> 24:42.880]  because we didn't consider it in the beginning, and it hasn't been in that, you know, that practice.
[24:42.880 --> 24:48.940]  But there are companies doing that, and that is changing. But you know, it's also been an industry
[24:48.940 --> 24:55.620]  that's been around for a very, very long time. And it's got some bad behavior and bad things that
[24:55.620 --> 25:01.140]  it's been doing. It's also got good things, right? I mean, how many lives have medical devices saved?
[25:01.140 --> 25:06.680]  I mean, you're always focusing on the negative. I mean, I wouldn't be here. I would have died at 19.
[25:07.300 --> 25:10.400]  I'm not much older, I'm not going to tell you my age, but you know,
[25:11.720 --> 25:12.580]  so I mean,
[25:12.580 --> 25:15.980]  So Vi, are you saying, are you saying push left? Is that the summary of what you're saying?
[25:15.980 --> 25:21.480]  Yes, I think you and I said that, let's push all the way left, right? Let's not do this at the end.
[25:22.000 --> 25:27.260]  I've worked with the developers and the engineers, right? You know, everyone thinks like security is
[25:27.260 --> 25:33.540]  the answer. You want to change this shit? Get them to start doing with security in mind, and you know,
[25:33.540 --> 25:38.680]  you're not going to deal with future problems. I literally have found that security and forensics
[25:39.340 --> 25:45.160]  forms part of hardware engineering and forms part of software development and firmware design.
[25:45.160 --> 25:51.180]  You know, it just, there's this synergy when we start working as a team and as a collective
[25:51.180 --> 25:56.020]  instead of, you know, silos. And I know there's people that are going to argue the silos are good
[25:56.020 --> 26:02.200]  because everyone needs to focus on the independent thing. But when we bring different minds together,
[26:02.200 --> 26:07.600]  that's when we start seeing things come together in a different way. And I think that's going to
[26:07.600 --> 26:13.180]  be the answer, is working together instead of against each other. And, you know, that
[26:13.180 --> 26:18.140]  multidisciplinary approach. Because we're not all experts. I mean, I shouldn't be doing any hardware
[26:18.140 --> 26:25.960]  design. It will break. You know, that's not my speciality. But I can tell you from a security
[26:25.960 --> 26:32.200]  and a logging perspective or forensics perspective what would work. So I think we need to get that
[26:32.200 --> 26:40.060]  multidisciplinary approach. All right. Iona, go ahead and get our next question kicked off by
[26:40.060 --> 26:44.780]  Ken in the DEF CON Discord. He says there's been a lot of progress in the last five years. I think
[26:44.780 --> 26:49.660]  we've all talked about the optimism that we've had, you know, guarded optimism. But there's still
[26:49.660 --> 26:53.660]  problems with smaller device manufacturers. There's problems with smaller hospitals. How do we motivate
[26:53.660 --> 26:59.220]  them? How do we get them to do the right thing? And I think, Ash, on the recorded talk, you had,
[26:59.220 --> 27:03.680]  you know, talked about how that's a big part of medical device development are kind of these
[27:03.680 --> 27:10.040]  smaller boutique consultant shops like your own. Yeah, I wish I had a I think that's a fantastic
[27:10.040 --> 27:16.060]  question. I have that question every day. How do we how do we motivate them? How do we make the
[27:16.560 --> 27:22.400]  how do we get there, right? Because we've got constraints on lots of sides. And, you know, at
[27:22.400 --> 27:26.840]  the end of the day, you know, most of the people who are working on this, we are really passionate
[27:26.840 --> 27:31.820]  about the end patients, especially, you know, some of the smaller shops, like everyone that I work
[27:31.820 --> 27:38.640]  with actually cares about the patients. And a lot of our clients are doctors who have an idea for
[27:38.640 --> 27:43.820]  some medical device that they think will save lives, and they only have so much budget. So,
[27:43.820 --> 27:49.980]  yeah, how do we motivate them? I think I think everyone is motivated. Or at least for some of
[27:49.980 --> 27:56.120]  the smaller ones. We are motivated how to actually get there, how to implement how to how to
[27:56.120 --> 28:03.340]  communicate to clients, and even to other engineers about what the risks are with software,
[28:03.340 --> 28:08.540]  because sometimes, again, we're so used to see thinking about things as, you know,
[28:09.600 --> 28:14.240]  electromechanical device, you know, we think about safety is like, the lock on the door,
[28:14.240 --> 28:17.240]  you know, people who aren't in software all the time, people who don't come from a security
[28:17.240 --> 28:21.540]  background, they don't think about all the creative ways, they just kind of think, well,
[28:21.540 --> 28:26.840]  this is secure, we put a lock on it. You know, it's like, I put my phone into a little like box,
[28:26.840 --> 28:31.000]  and then I put a lock on it, how could it not be secure? Well, because I can connect to your phone
[28:31.820 --> 28:37.240]  through Wi Fi, and then exploit it somehow, right? Like, so it's not actually immediately obvious to
[28:37.340 --> 28:44.020]  a lot of people. So then, when you're trying to, you know, trying to set up a project and talking
[28:44.020 --> 28:48.120]  about budget, and how much time we allocate, and, you know, what, what sort of security things do
[28:48.120 --> 28:54.040]  care about? And, you know, everything is pulled in all these directions. So I, I don't have an
[28:54.040 --> 28:58.240]  answer for how to balance all of those perfectly. I think we're trying to do that every single day.
[28:58.400 --> 29:02.460]  But I think it's a really great question. And I think we should keep asking it.
[29:04.280 --> 29:06.460]  Yeah, that's what I have to say.
[29:12.330 --> 29:17.210]  I think the phone's a great analogy. Sorry, just two seconds here, right? I think that the fact
[29:17.210 --> 29:21.050]  that you bring up this notion of, okay, people understand security on a phone, and they say,
[29:21.050 --> 29:25.170]  I'm comfortable that my iPhone is going to do this. And I know Bea and I had this conversation.
[29:25.170 --> 29:30.590]  But how do we translate that into the expectation that a medical device will be secure in and of
[29:30.590 --> 29:35.230]  itself, independent of how it's going to connect to whatever the clinical care is? And I think
[29:35.230 --> 29:40.630]  part of it is, we have to be fair to all these clinical innovations that are really trying to
[29:40.630 --> 29:46.110]  bring something to the patient experience and change it for the better, and not try to force
[29:46.110 --> 29:51.150]  them to become cybersecurity experts. There has to be a way for us to enable them to get there
[29:51.150 --> 29:58.150]  without having to become pros at cybersecurity. I will say, though, and I have to say it. Sorry,
[29:58.150 --> 30:01.850]  everyone. I think I disappeared for a moment. My computer decided it didn't want to be part
[30:01.850 --> 30:09.790]  of this panel anymore. So there is pre-market guidance. And the current version is not nearly
[30:09.790 --> 30:18.190]  as detailed as I think some of the things that we're working on now. But to get on the market,
[30:18.190 --> 30:23.510]  medical devices have to go through the FDA in most cases. I'm not going into the class system.
[30:23.510 --> 30:27.770]  None of us need that. But if they're going to have software and other things like that,
[30:27.770 --> 30:32.270]  chances are they have to get pre-market approval to even go on the market. And so to a certain
[30:32.270 --> 30:38.110]  extent, they have to demonstrate through FDA, whatever the device is, however small the
[30:38.110 --> 30:42.750]  manufacturer is, that they have provided reasonable assurance of safety and effectiveness.
[30:42.750 --> 30:48.910]  And we check for cybersecurity concerns. I think I made some clever comment about Matt being my
[30:48.910 --> 30:54.250]  elementary school best friend. But Matt is the lead for a lot of the cybersecurity reviewers at
[30:54.250 --> 30:59.970]  FDA. And like I said in the recording, we're getting better at that every day. But this is
[30:59.970 --> 31:07.570]  something where FDA is rightfully by statute, by law, the gatekeeper of what can and can't be
[31:07.570 --> 31:12.950]  put on the market. And so I think, you know, for better or worse, you can argue whether or not
[31:13.390 --> 31:17.870]  it's good or bad that we're doing what we're doing. The smaller manufacturers
[31:17.870 --> 31:22.090]  still have to go through us. So there is still going to be that part of it.
[31:23.930 --> 31:28.190]  I also just want to say, we had talked multiple times about how you have to make security
[31:29.270 --> 31:34.690]  the easy thing to do. And for some of these rural access hospitals, smaller organizations,
[31:34.690 --> 31:42.170]  they're just not going to be able to do the job right. And so I think collaboration,
[31:42.170 --> 31:46.650]  I've said this a couple times, there shouldn't be a competitive advantage in cybersecurity when
[31:46.650 --> 31:50.730]  it comes to hospitals, right? So you shouldn't see a billboard as you drive down the street that
[31:50.730 --> 31:54.990]  says, you know, when you have your heart attack, come to hospital A because we didn't get hacked
[31:54.990 --> 32:01.210]  last year like hospital B did, right? So that shouldn't be like that. And I think, luckily,
[32:01.210 --> 32:05.430]  there's been a lot of momentum towards collaboration, information sharing,
[32:06.250 --> 32:10.150]  through a lot of these organizations and bodies we've already talked about. But, you know, what
[32:10.150 --> 32:16.210]  was an alien concept to hospitals five years ago is probably not that crazy now, which is,
[32:16.210 --> 32:20.170]  hey, if we get hit with ransomware, you know, we're going to go through our protocol of
[32:20.170 --> 32:26.030]  incident response. And guess what? I'm going to call the CISO at competitor hospital B and let
[32:26.030 --> 32:32.070]  them know this happened to us. And did you see anything? Collaborate. What normally was a very,
[32:32.670 --> 32:35.930]  we're not going to share, we're not going to talk, we're not going to collaborate in the space,
[32:35.930 --> 32:40.050]  has clearly gone out the window for some of the more forward thinking organizations. Now,
[32:40.050 --> 32:44.570]  let's take that information. For example, all the great work that larger organizations have
[32:44.570 --> 32:50.490]  done, like Mayo, looking at particularly secure devices compared to others, share that information
[32:50.490 --> 32:54.790]  with other rural hospitals, so they don't have to go and reproduce all that work from scratch,
[32:54.790 --> 32:59.870]  they're doing that. Being able to share in that space is so, so key. So let's not reinvent the
[32:59.870 --> 33:06.270]  wheel at every single hospital. Let's not try to build gigantic teams that do vulnerability testing,
[33:06.270 --> 33:10.290]  penetration testing on every medical device and reproduce that work time and time again. Instead,
[33:10.290 --> 33:14.930]  it's a community. We got to recognize that it doesn't follow the same competition that you
[33:14.930 --> 33:18.410]  normally would where you're not sharing. This is a different world. This is about patient safety,
[33:18.410 --> 33:23.970]  though. We all have to be on the same page. Yeah, but I mean, I'm going to say something
[33:23.970 --> 33:29.590]  that's going to be very unpopular, right? If you take a medical device, functional requirement is
[33:29.590 --> 33:35.690]  not security. Functional requirement is keeping someone alive or healthcare, right? We need to
[33:35.690 --> 33:40.490]  understand that because we are superimposing security onto these devices when that's not
[33:40.490 --> 33:46.730]  their main functionality. Yes, as they advance, they are connected and they need to be secure.
[33:46.730 --> 33:52.330]  But I don't think we should solely focus on having such secure devices that might just never see the,
[33:52.330 --> 33:58.610]  market. They might never save their life. That one patient's life that they can change.
[33:58.610 --> 34:02.350]  I think we should never lose sight of what the purpose of these devices are
[34:03.530 --> 34:08.950]  when we try and attempt the security implementations onto them.
[34:14.390 --> 34:23.370]  Awesome. All right. We're going to go to the next question here. This is from Synapsys.
[34:24.230 --> 34:29.950]  Questions about where the industry is going insofar as what are the new, and perhaps we can
[34:29.950 --> 34:33.910]  even talk about the pre-market guidance in this regard, like what types of requirements
[34:33.910 --> 34:38.270]  are we going to be putting into some of these new devices as they go for approval
[34:39.270 --> 34:44.710]  to push that forward? To perhaps, of course, always respect that these devices are security,
[34:44.710 --> 34:50.250]  or sorry, that was not a slip, I promise. They're medical devices meant to help patients,
[34:50.250 --> 34:54.430]  but they have to be secure. Are we going to be deploying things like stack protection,
[34:54.430 --> 34:59.810]  ASLR, DEP, and other things like modern, like language changes that have better security
[34:59.810 --> 35:04.410]  kind of baked in from the start? Are we seeing trends in this space towards utilizing more
[35:04.410 --> 35:09.710]  secure tools and development of these medical devices so that they are less prone to some
[35:09.710 --> 35:15.990]  of the scary vulnerabilities we've seen in legacy devices? So I think you called me out there a
[35:15.990 --> 35:23.010]  little bit with the cybersecurity guidance. So yes, you know, I think I had made the comment
[35:23.010 --> 35:29.270]  earlier that the FDA, the actual regulation parts of FDA's regulations are pretty high level. I
[35:29.270 --> 35:33.850]  really would be amused if any of you were like that motivated to go look at literally the code
[35:33.850 --> 35:40.230]  for federal regulations and go look at our regulations. They're very dry. And then you have
[35:40.230 --> 35:44.710]  guidance, and then you have what companies are actually doing to meet the guidance or to meet
[35:44.710 --> 35:51.370]  regulations. And I think from the FDA standpoint, it would help no one if we picked like the one way
[35:51.370 --> 35:55.250]  of doing security to rule them all and then told all the manufacturers that they have to do that
[35:55.250 --> 36:01.130]  one thing. So instead, essentially, what we've we have been communicating to them, and we continue
[36:01.130 --> 36:04.950]  to work with manufacturers on and continue to work with our own internal processes on is essentially
[36:04.950 --> 36:09.130]  saying like, you need to have a secure architecture. We're not going to tell you what the
[36:09.130 --> 36:13.750]  architecture looks like. But you need to, it needs to be secure. And you need to be able to produce
[36:13.750 --> 36:18.450]  the documentation to us that proves and validates that it's secure. You need to have security
[36:18.450 --> 36:22.330]  controls that are the same thing. You need to be able to not only have them, you need to prove that
[36:22.330 --> 36:27.570]  they work. And so and then but but then at that point, it's sort of like and it's now the ball
[36:27.570 --> 36:32.010]  is in your courts, manufacturers, you tell us what your security controls are, you tell us what your
[36:32.010 --> 36:40.090]  secure architecture is. Because I think like going down into the the ASLR level and things like that,
[36:40.090 --> 36:43.830]  to V's and Asher's and videos and some of the other points that have been raised,
[36:43.830 --> 36:47.570]  each individual medical device is very unique, you know, the things that you're going to do
[36:47.570 --> 36:51.650]  to secure drug infusion pump are not going to be the things that you're going to do to secure an MRI.
[36:52.230 --> 36:57.130]  And so we do need to have that flexibility built into the regulations built into the guidance,
[36:57.130 --> 37:02.990]  so that, you know, we can we can allow the manufacturers to figure out, you know,
[37:02.990 --> 37:08.590]  what is the best, most efficient way to secure the device to V's point that we don't, you know,
[37:08.590 --> 37:15.690]  impose such rigid constraints on it that certain devices just can never meet them,
[37:15.690 --> 37:18.710]  you know, maybe they can do something else. So that's what I would say.
[37:23.440 --> 37:29.080]  Didn't mean to call you out. I just think it's such a great segue. All right, who's up on that
[37:29.080 --> 37:34.340]  question? So I mean, you had mentioned Ash, like how much things are changing? And do you see
[37:34.340 --> 37:39.700]  trends towards more kind of baking in these controls from the start? And do you see exciting
[37:39.700 --> 37:46.480]  trends emerging? I mean, I think I agree with what Jessica said, I think.
[37:48.540 --> 37:53.700]  I'm not sure, you know, I come from software and engineering development background,
[37:53.700 --> 37:58.720]  and I'm learning more and more about security. But so traditional security controls, I don't
[37:58.720 --> 38:02.820]  have a huge history with that. But I think every device is really different. And from
[38:02.820 --> 38:08.880]  security perspective, or from a safety perspective, we make sure that the device is secure,
[38:08.880 --> 38:13.300]  so that it provides safety, so that patient outcomes are,
[38:15.040 --> 38:22.080]  are successful or positive, right? Every device is different. I think that more people are
[38:22.080 --> 38:26.860]  learning more people are like me, there's more engineers who care about the security part. And,
[38:26.860 --> 38:32.180]  you know, obviously, with FDA and guidances, and with regulatory, we have to meet standards.
[38:32.700 --> 38:38.560]  That's absolutely correct. How we choose to meet those standards is up to each manufacturer. So
[38:38.560 --> 38:43.340]  we have an internal process of how we approach that. At the end of the day,
[38:43.920 --> 38:48.620]  you know, it's, it's literally different every time we make a device. So we're different too,
[38:48.620 --> 38:53.440]  because we are a consulting firm. So we make a lot of different devices, we have no, we have
[38:53.440 --> 39:00.440]  none of our own in house products that we are continually sort of like, building. So every,
[39:00.440 --> 39:06.660]  every device is unique, and it has a unique solution has unique architecture. And as technology
[39:06.660 --> 39:14.020]  is changing as Wi Fi's in everything now, more and more and more. Yeah, I mean, we're using
[39:14.020 --> 39:19.380]  different approaches. Yes, we have to make more, we have to have a bigger focus on security because
[39:19.380 --> 39:27.800]  of that. But, but I think it's just we're just following the trends with technology itself.
[39:33.830 --> 39:39.650]  Yeah, the only thing I'd add there is I think there are there are a variety of ways to approach
[39:39.650 --> 39:43.790]  it. And we have to absolutely keep patient care at the center of it to make sure we don't introduce
[39:43.790 --> 39:50.230]  new problems by trying to solve the security problem. But I think there's there's a fundamental
[39:51.290 --> 39:55.230]  expectation now that there is security built into this, it's not something that can be bolted on
[39:55.230 --> 39:58.790]  afterwards, where we're seeing the narrative more and more that it has to be part of the
[39:58.790 --> 40:02.310]  initial requirements discussion, it has to be part of how the device is going to connect how
[40:02.310 --> 40:05.870]  it's going to be patched. If we don't think about it from the onset of these fundamental
[40:05.870 --> 40:10.410]  architecture decisions, I think we'll we'll continue to have this problem of trying to
[40:10.410 --> 40:15.830]  solve the quick regulation question that came back and try to get it through so it so it can
[40:15.830 --> 40:23.050]  get to the hospitals. No, definitely. I don't think we can get to a granular level that we can start
[40:23.050 --> 40:28.590]  dictating architecture, because again, those things depend on the type of device and the
[40:28.590 --> 40:35.450]  requirements that you need the device to fulfill. But I am looking forward to better guidances. And
[40:35.450 --> 40:39.530]  yes, I was that boring person that went and read that because I wanted to understand
[40:39.530 --> 40:45.030]  our pre-market post-market book. But after some discussions with Jessica and Suzanne,
[40:45.030 --> 40:50.570]  I'm excited to see the new ones coming out and the more robust nature of them because
[40:50.570 --> 40:56.390]  we are moving towards a place where we are going to be enforcing better manufacturing.
[40:59.020 --> 41:03.940]  So let's transition to our next question into a little bit outside the medical device space and
[41:03.940 --> 41:10.000]  more into the hospital. Ken brings up another question about who's keeping the hospitals
[41:11.500 --> 41:17.360]  in line? Meaning the Joint Commission is, and there's a couple other bodies,
[41:17.360 --> 41:22.300]  are the ones that accredit hospitals. So when you go by a hospital, and they can be a hospital,
[41:22.300 --> 41:27.940]  some type of regulatory body has to make sure that they are to meet certain standards. The
[41:27.940 --> 41:32.740]  Joint Commission is probably the most famous one of those. And so a lot of what we talk about on
[41:32.740 --> 41:37.860]  the hospital side actually would never be FDA jurisdiction. Those are medical devices in their
[41:37.860 --> 41:43.940]  approval. This is the Joint Commission's probably space or other organizations that accredit
[41:43.940 --> 41:50.100]  hospitals. So the question that Ken poses is, you know, has the Joint Commission jumped in here?
[41:50.100 --> 41:57.000]  And how do we make sure that hospitals do what they're supposed to do? We've talked at length
[41:57.000 --> 42:01.400]  about how we can do better with medical devices, but I think we need to start moving also into the
[42:01.400 --> 42:06.240]  space of, like, hospitals need to be held accountable in some cases, and in accordance
[42:06.240 --> 42:10.200]  to what they're able to do. But we need to move that needle as well, because we've all heard
[42:10.200 --> 42:17.260]  stories of devices with certain security controls from the manufacturers that get turned off,
[42:17.260 --> 42:22.380]  or aren't deployed appropriately, or deployed on horribly secured networks at hospitals.
[42:22.380 --> 42:28.540]  And so part of the responsibility has to be this multiple people, right? How do we get hospitals
[42:28.540 --> 42:34.280]  to do the right thing? Knowing that, especially in times like COVID, it's not going to be the
[42:34.280 --> 42:37.380]  place they're going to be putting their resources in, right? They're worried about their ventilators
[42:37.380 --> 42:43.660]  in the ICU. They're not necessarily worried about this problem right now. Is there a way that we can
[42:44.120 --> 42:47.280]  move forward and make sure hospitals do the right thing?
[42:51.400 --> 42:56.960]  To be flippant, but like, do we? I feel like there's such a burden here that we're trying to
[42:56.960 --> 43:02.540]  historically pass on to hospitals that maybe was unfair, right? Like, yes, hospitals,
[43:02.540 --> 43:07.080]  if they're told in a user guide that they need to have certain controls in place, and they didn't,
[43:07.080 --> 43:11.040]  sure, there's something there. There's a flaw there in the plan. But at the same time,
[43:11.040 --> 43:16.200]  is it a fair expectation for a device vendor to say, okay, we want you to have these 32 different
[43:16.200 --> 43:20.500]  controls in place, times a hospital having a bunch of different vendors? Like, I think
[43:21.260 --> 43:26.720]  there's a balance there. So I think, yes, you have to enable hospitals to be
[43:26.960 --> 43:31.020]  more successful in having some of the basic security in place. But I think it's also
[43:31.020 --> 43:38.840]  somewhat unfair to place the onus on them so much. Yeah, I mean, I think I could just share
[43:38.840 --> 43:43.120]  something. You know, we talk all the time about shared responsibility. And actually,
[43:43.120 --> 43:47.780]  Christian, thank you so much for pointing out that FDA does not actually regulate hospitals.
[43:48.100 --> 43:54.500]  Because I think sometimes people forget that we actually have a very small slice of the pie. And
[43:54.500 --> 43:59.820]  we like to think we're very effective, whether or not we are, as I suppose, for debate from others.
[43:59.820 --> 44:06.740]  But, you know, that's not something we have any control over. But, you know, there are multiple
[44:06.740 --> 44:10.460]  federal agencies and state-level agencies. And actually, that's part of the problem,
[44:10.460 --> 44:16.560]  is the sheer number of regulators who are active in this space, who may or may not have harmonized
[44:16.560 --> 44:20.800]  regulatory requirements that hospitals are expected to meet. You know, that's challenging
[44:20.800 --> 44:26.140]  enough as it is. But something that Vidya said I wanted to hit on, because we were...
[44:26.940 --> 44:30.160]  one of these, you know, public-private partnership bodies that I'm a part of,
[44:30.160 --> 44:35.720]  we were recently talking, and one of the core CISOs was like, I have a spreadsheet of 400
[44:35.720 --> 44:40.940]  different websites that I have to continually check to figure out what updates I need to make
[44:40.940 --> 44:45.780]  to all of the different devices that I have. And it's not something where, you know, they're not
[44:45.780 --> 44:49.760]  always getting active notification from the vendors as, like, you should go check one of
[44:49.760 --> 44:56.480]  these 400 websites. And there's just, it seems, you know, almost an infinite variety of procedures
[44:56.480 --> 45:01.460]  that each individual manufacturer can try and impose on a given hospital, and that just can add
[45:01.460 --> 45:08.480]  up so fast. So, you know, in that sense, like, there are certainly things that we can do better.
[45:10.420 --> 45:16.480]  I don't know necessarily that punishment is always the way to go with that. You know,
[45:16.480 --> 45:20.320]  I don't know how many of you know about the Office of Civil Rights wall of shame,
[45:20.320 --> 45:23.980]  but literally if you have a breach of more than 500 people, or at least this was the way that
[45:23.980 --> 45:29.260]  it was a couple of years ago, you go up on a portion of HHS's website with, like, your name,
[45:29.260 --> 45:35.880]  and how many records were breached, and how you got breached, and etc. etc. And it's not exactly
[45:35.880 --> 45:41.960]  the most helpful way to do it, because you also get fined in that case, which is then, that's
[45:41.960 --> 45:46.500]  resources that you have now lost, that you then cannot put towards your security, because you
[45:46.500 --> 45:52.200]  just had to pay it, you know, to somebody else. And so, you know, there's, I think, and this is,
[45:52.200 --> 45:57.900]  these are conversations that happen at the federal government level all the time, is like, how do we,
[45:57.900 --> 46:03.640]  how do we regulate, holistically, how do we regulate in such a way that, you know, we are,
[46:03.640 --> 46:10.000]  we are helping the industry move forward, rather than, you know, continuing to perpetuate some of
[46:10.000 --> 46:17.580]  the problems that we see? I want to touch on that, because this is something that is really
[46:17.580 --> 46:24.220]  near and dear to my heart, is hospitals. And the one thing that I've realized is we've created this,
[46:24.220 --> 46:28.600]  this shameful thing of finger-pointing when a hospital gets breached, right?
[46:29.500 --> 46:33.620]  Where we make it this negative connotation that they don't want to come out and say, hey, we've
[46:33.620 --> 46:38.920]  been breached, we need help. We've made it impossible for them to turn to the security industry and ask
[46:38.920 --> 46:46.020]  for help, because we shame them when they have been breached, right? When they are having to deal
[46:46.020 --> 46:51.860]  with medical care and then sophisticated attacks from cybercriminals. You know, and on top of that,
[46:51.860 --> 46:57.000]  implementing different patches and different software updates, different systems, and now
[46:57.000 --> 47:02.980]  how they're going to connect all these things up. I think we are expecting them to take ownership
[47:02.980 --> 47:09.700]  and accountability for things that aren't theirs to do. And then still, we punish them for not
[47:09.700 --> 47:17.700]  being able to do it. It's a very negative connotation to, you know, we need help.
[47:19.960 --> 47:24.780]  I agree. I don't think punishment is necessarily the right way, but I think
[47:24.780 --> 47:29.940]  that they're not being punished. The only hammer that really they pay attention to is HIPAA,
[47:29.940 --> 47:37.840]  because it's tied to a fine and an embarrassment on a wall. There isn't really, for example,
[47:37.840 --> 47:44.980]  rural hospitals, AIDS gets owned and there isn't a HIPAA breach. No one knows about that. And there
[47:44.980 --> 47:50.560]  is likely going to be little remediation efforts, probably because they've been owned for years and
[47:50.560 --> 47:54.820]  they don't even know. What I'm trying to say is that I don't think we should shame hospitals,
[47:54.820 --> 48:04.640]  but the status quo is likely untenable for a long term, because there is an increasing
[48:05.380 --> 48:11.420]  attack surface. There's less resources being put into this. And then on top of it, there's just,
[48:11.420 --> 48:17.200]  it's going to have to be looked at in some way, because we can't have the most secure medical
[48:17.200 --> 48:23.640]  devices on the planet with phenomenal protections, and then put on networks that no one cares about,
[48:23.640 --> 48:27.140]  or that no one's doing a good job at securing because there isn't that
[48:27.140 --> 48:31.900]  pressure. So how do you incentivize the hospitals? Do you say, for example,
[48:31.900 --> 48:36.760]  we're going to give you 0.25% more on your Medicaid reimbursement if you meet these
[48:36.760 --> 48:41.460]  cybersecurity requirements, right? Are you going to say we're going to cut your reimbursement from
[48:42.760 --> 48:46.680]  insurance claims on this if you don't meet these requirements? Is the joint commission going to
[48:46.680 --> 48:51.600]  say, hey, we're not going to credit your hospital unless you meet these requirements? These are the
[48:51.600 --> 48:56.780]  questions we should be talking about, whether or not it's a carrot or a stick. This is how we're
[48:56.780 --> 49:00.360]  going to have to figure it out. But what I do know is, you can look at many different healthcare
[49:00.360 --> 49:05.360]  organizations across the globe, and know that that's just, we can't keep going in that realm,
[49:05.360 --> 49:10.660]  because the patient information is just too valuable. And the risks of compromises to these
[49:10.660 --> 49:16.740]  networks are just too great for patient safety. And so we have to have that conversation sometime.
[49:17.560 --> 49:22.220]  Again, I don't want to shame anybody, but we have to do better on all fronts of this,
[49:22.220 --> 49:26.320]  because if you just secure one side, our patients are still vulnerable on the other side.
[49:26.320 --> 49:29.440]  It's really got to circle the wagons. Everyone's got to get on board.
[49:30.700 --> 49:35.740]  I think to your point, right? I think cybersecurity in healthcare was defined as HIPAA for the
[49:35.740 --> 49:40.460]  longest period of time, and nobody ever connected it to patient safety. So I think that's why there
[49:40.460 --> 49:46.120]  is disincentive, but in absence of an incentive for a hospital to really build security beyond
[49:46.120 --> 49:55.180]  just what the UCR is going to find them for. It's a change of how they perceive security,
[49:55.180 --> 49:59.620]  right? Cybersecurity is always the stick that's beating you, that's saying you need to do X, Y,
[49:59.620 --> 50:03.840]  and Z. It's never the thing, well, if you don't do this, this is what's going to happen,
[50:03.840 --> 50:08.080]  and it's going to impact your patients. I think we need to change the narrative.
[50:08.640 --> 50:14.560]  And the way that we approach this is by getting the hospitals to believe that this is
[50:14.560 --> 50:21.560]  the best for their patients. This is not just something that needs to be done because HIPAA
[50:21.560 --> 50:26.220]  says so, or any other organization says so. I don't know the Joint Commission, and I'm going
[50:26.220 --> 50:32.580]  to be honest with you, I don't follow that because I'm not from the US. But I do feel
[50:32.580 --> 50:39.040]  that if you change the way security is perceived within a hospital, and you make it more patient
[50:39.040 --> 50:44.940]  safety, you will see people change the way that they approach the problem.
[50:48.890 --> 50:51.650]  You're absolutely right. And I think there's a balance there, right? We don't want people
[50:51.650 --> 50:56.530]  declining clinical care because they now understand the potential risk. But I absolutely
[50:56.530 --> 51:00.850]  think you're right. The focus here should always be about the patient safety that we're trying
[51:00.850 --> 51:07.090]  to ensure collectively. I mean, COVID's kind of broken the perimeter, right?
[51:07.730 --> 51:14.170]  It's, I mean, they are sending home monitors. I mean, which angle do you defend from?
[51:14.250 --> 51:20.790]  Where is our perimeter at the moment? I think it's just, we're going to have to rebuild healthcare,
[51:20.790 --> 51:26.750]  I think, after COVID globally. And that's an opportunity to do things different, right?
[51:26.750 --> 51:33.930]  We now have a way to move forward positively without having to reinvent the wheel because
[51:33.930 --> 51:40.030]  the wheel's kind of broken down now. So I see the positive in that as well.
[51:40.990 --> 51:45.830]  And I'm excited for it, personally. All right, everybody, we're going to have
[51:45.830 --> 51:49.290]  to wrap up here soon. But I want to give everyone an opportunity to just say
[51:49.690 --> 51:53.730]  where they're going to go party after this Q&A. So I'm going to start off with Jeff.
[51:54.130 --> 51:58.710]  Where are you going to party? His internet is having a seizure, he told me. So I'm not
[51:58.710 --> 52:01.230]  sure if he'll be able to respond. He's going to go party with me, I bet.
[52:01.230 --> 52:02.670]  Yeah, somewhere with better...
[52:04.590 --> 52:07.130]  He's going to go to Starbucks and steal some internet.
[52:07.130 --> 52:09.510]  Ash, where are you going to go party after this Q&A?
[52:10.750 --> 52:15.890]  I'm going to open the new record player that I got that arrived in the mail today
[52:15.890 --> 52:19.410]  and set it up and probably party here.
[52:19.550 --> 52:21.530]  V, where are you going to go party after this?
[52:22.170 --> 52:29.050]  It is 6am, so I am going to go party at Club Duvet. It is a very, very, very warm, toasty club.
[52:29.050 --> 52:31.210]  And that's where I'm going to be spending the rest of my morning.
[52:31.970 --> 52:34.170]  Nice. Vidya, where are you going to go party?
[52:34.430 --> 52:36.970]  Going to hit up the beach, all day, every day.
[52:37.110 --> 52:41.370]  All day, every day. And Jessica, take us home.
[52:41.610 --> 52:46.830]  I was going to say I was going to Club BED with DJ Pillow, because that's exactly what I'm going to do.
[52:48.250 --> 52:54.910]  Well, on that note, we want to say thank you to DEF CON, the CFP board for giving us another
[52:54.910 --> 52:58.830]  shot at this, and everyone out there watching us on Twitch to say thank you for attending our
[52:58.830 --> 53:02.830]  Do No Harm panel. Again, stay connected with this. This is really important work.
[53:02.830 --> 53:05.410]  Let's keep our patients safe. And everyone, take care.