[00:00.000 --> 00:04.940] Hi, I'm Mitch Parker, Information Security Officer at IU Health in Indianapolis, Indiana. [00:04.940 --> 00:10.500] And today's topic is going to be advancing medical device security, how collaboration [00:10.500 --> 00:16.820] between providers, manufacturers and pen testers is advancing what's possible with security. [00:16.920 --> 00:21.740] And with us today, we have an incredibly distinguished panel of people we've been able to find who [00:21.740 --> 00:26.040] I'd like to have introduce themselves right now. We're going to start with Florence Hudson. [00:26.040 --> 00:30.140] Very good. Thank you so much, Mitch, for having me join you. And hey, [00:30.140 --> 00:38.040] DEF CON crowd. Geeks and all. And goons. So I'm Florence Hudson, and I'm Founder and CEO of FDHint, [00:38.040 --> 00:41.900] which is an international consulting firm for advanced technology and diversity and inclusion. [00:42.220 --> 00:47.520] I also work for the NSF Cybersecurity Center of Excellence at Indiana University. [00:47.520 --> 00:52.500] I lead the Cybersecurity Research Transition to Practice Program. And I'm also Executive [00:52.500 --> 00:56.560] Director for the Northeast Big Data Innovation Hub at Columbia University, [00:56.560 --> 01:00.860] leading translational data science opportunities in the Northeast US. [01:02.900 --> 01:10.520] Oh, and I should say, I'm also Working Group Chair for IEEE UL P2933. For those who aren't [01:10.520 --> 01:16.640] acronym queens and kings, it stands for Institute for Electronic Engineers and Underwriters [01:16.640 --> 01:21.640] Laboratories. Working group on creating a standard around clinical innovative things, [01:21.640 --> 01:27.260] data, and device interoperability with TIPS, which stands for Trust, Identity, Privacy, [01:27.260 --> 01:31.920] Protection, Safety, and Security. And Mitch is one of our Co-Vice Chairs. So thank you very [01:31.920 --> 01:35.880] much for having me, Mitch. Thank you, Florence. We'll take it over to Rob Suarez. [01:37.460 --> 01:43.500] Hi. Hi, DEF CON. This is... My name is Rob Suarez, and I'm the Chief Information Security [01:43.500 --> 01:50.460] Officer for BD. That's Beckton Dickinson. And we're a global medical technology [01:51.640 --> 01:56.480] company offering some of the most advanced products across the continuum of care. [01:56.620 --> 02:04.020] It's my job at BD to make sure that we are protecting those products that we're delivering [02:04.220 --> 02:09.600] a secure product and also the environment in which they reside in, which is typically a hospital, [02:09.600 --> 02:17.200] but increasingly, you know, a patient bedside at home as well. And so I'm very excited to talk to [02:17.200 --> 02:21.700] my fellow panelists today about medical device cybersecurity. This is a passion of mine, [02:21.700 --> 02:28.640] and I've had the honor actually of working alongside Mitch and Michael as well on several [02:28.640 --> 02:35.000] industry initiatives. And so again, looking forward to the discussion today. Thank you. [02:35.360 --> 02:42.400] And last but not least, Mr. Michael McNeil. Hi, DEF CON. This is Michael McNeil. I'm the [02:42.400 --> 02:47.640] Senior Vice President and Global Chief Information Security Officer at McKesson, [02:47.640 --> 02:56.280] and just recently got to the organization. But as, you know, Rob has just stated, have had a [02:56.280 --> 03:03.080] number of years collaborating, you know, with the team here. And my days go back into [03:03.080 --> 03:09.280] Philips as well as into Medtronic from a medical device perspective over the past 10 years. [03:09.280 --> 03:16.480] Really looking forward to this particular session and again have collaborated with these guys in a [03:16.480 --> 03:22.100] number of different industry and forums. And again, I think you'll find our conversations [03:22.100 --> 03:28.200] today to be pretty enlightening because it takes that ecosystem and for us to come together [03:28.200 --> 03:34.660] to really execute here. Thank you so much, Michael. So I'm going to launch right into [03:34.660 --> 03:39.720] the first question here. First question is, what are the biggest concerns that each of you [03:39.720 --> 03:47.800] sees related to medical device security? So I'll start if I might. So what I mentioned [03:47.800 --> 03:52.980] when we were first opening up, I talked about tips, tips for the Internet of Things. [03:53.080 --> 03:57.260] This is a framework we've been creating with IEEE for four years now. As I mentioned, [03:57.260 --> 04:02.300] it stands for trust and identity, privacy, protection, safety, and security. I'm worried [04:02.300 --> 04:07.080] about all those things. I'm worried about the trust and identity of the devices, the device [04:07.080 --> 04:11.880] to device communication, the device to human, the doctor to the device to the human, human to [04:11.880 --> 04:16.780] everything. So I'm concerned about trust and identity, how we're going to maintain that and [04:16.780 --> 04:22.020] make sure we're vigilant about it. I'm concerned about privacy of data, whether you're in your home [04:22.020 --> 04:26.180] country or another country and what the different regulations are and how we're going to manage it. [04:26.180 --> 04:30.380] I'm concerned about protection and safety, how we're going to keep the humans safe, how we're [04:30.380 --> 04:34.960] going to keep the device safe, the infrastructure, the financial side of the institution, if your [04:34.960 --> 04:40.240] device is hacked and everybody finds out, like some of the FDA and DHS and U.S. CERT recalls. [04:40.240 --> 04:46.620] And I'm concerned about the cybersecurity. So we have a lot to do as the leaders in this space for [04:46.620 --> 04:53.340] IT and for cybersecurity and for medical devices. So I look forward to continuing the collaboration [04:53.340 --> 04:58.280] we're doing through groups like this and also like in the IEEE working group where we have [04:58.280 --> 05:03.600] over 250 humans from 22 countries and six continents who are worried about this too, [05:04.120 --> 05:08.780] including device manufacturers and providers and payers and regulators and everybody as we know, [05:08.780 --> 05:13.580] Mitch. So I'm worried about all that stuff. What about the rest of you? Are you worried? [05:15.340 --> 05:24.300] So I'll go next on that one. Thank you, Florence. For me, it's actually very similar to what you'll [05:24.300 --> 05:31.200] find was reported out and I believe it was 2017 and what was the healthcare industry [05:31.200 --> 05:37.020] cybersecurity task force report. In fact, on that task force, I got to serve alongside Michael [05:37.020 --> 05:43.100] McNeil and several other individuals across the industry and produce a report that outlined [05:43.100 --> 05:50.680] observations and recommendations for improving cybersecurity across the industry in healthcare. [05:50.680 --> 05:56.280] There was a specific section that was dedicated just for medical device cybersecurity, [05:56.280 --> 06:02.520] and I got to tell you, that was three years ago. A lot of those findings still apply to this day. [06:02.800 --> 06:09.780] And one that pops out to me immediately is that medical devices are in hospital settings for 15 [06:09.780 --> 06:17.620] to 20 years, but new cybersecurity threats emerge daily. And every hospital and every patient [06:17.620 --> 06:25.060] environment is unique. So there's no one-size-fits-all approach. And at BD, we're [06:25.060 --> 06:32.520] working closely with healthcare providers on understanding medical device cybersecurity as it [06:32.520 --> 06:38.620] exists out in a clinical setting, out in the real world. And we're also working, we're really [06:38.620 --> 06:46.080] committed to transparency. And for example, providing coordinated vulnerability disclosures [06:46.080 --> 06:54.420] on medical device vulnerabilities. But unfortunately, it's just not enough. There's [06:55.060 --> 07:02.640] really a long time span to medical devices in these environments. And so increasing transparency [07:02.640 --> 07:08.560] absolutely helps, but we also need to build stronger relationships and stronger collaborations [07:09.420 --> 07:14.980] across... Florence, as you really described, across the continuum of stakeholders that we have [07:14.980 --> 07:22.760] when it comes to just using a medical device and managing it when it's in use. [07:23.600 --> 07:32.520] Yeah. And from my perspective to build on what Rob has just stated, he's hit the nail on the head, [07:32.520 --> 07:40.800] and we've been having these kinds of conversations and discussions even before the 2017 and earlier [07:40.800 --> 07:50.320] when we go back a few years on this particular topic. I think people have heard me talk in the [07:50.320 --> 07:57.020] past and it really doesn't... It's kind of interesting. It doesn't change. It just perpetuates [07:57.020 --> 08:06.080] itself. So as Rob just talked about, legacy devices as we call them in the ecosystem and how [08:06.080 --> 08:13.020] we manage that, that to me ties right into what I've always said is sort of the three deadly sins [08:13.020 --> 08:19.340] that I've kind of communicated over time. Because you have these types of devices, you need to make [08:19.340 --> 08:24.100] sure that you can patch and update them in a timely manner. So one of the deadly sins, if I [08:24.100 --> 08:29.640] can't patch and update a device, I'm not going to be able to maintain the security of that solution [08:29.640 --> 08:37.100] out in the marketplace. When I look at the types of devices and a number of them when they were [08:37.100 --> 08:41.740] designed and developed and they're in these environments, if they got hard-coded credentials, [08:41.740 --> 08:46.940] those are the keys to the kingdom. If I open the keys up and I let anybody come in, front, back, [08:46.940 --> 08:52.900] side doors, any way that you have, then you have access and you're going to be able to align. [08:52.900 --> 08:59.280] And then for us, when it comes to the type of information, again, as I would say that [08:59.280 --> 09:05.380] Florence had talked about in terms of thinking of the type of data and the type of information [09:05.380 --> 09:12.000] that needs to be held secure, if you don't do encryption and de-identify and make sure that [09:12.000 --> 09:18.920] that's not available to cause the kinds of harm to individuals, to the solution itself, [09:18.920 --> 09:25.320] you get to those deadly sins. So the sins are there and we're doing a much better job, [09:25.320 --> 09:31.640] I believe, in having an awareness around the design and how we need to build that into our [09:31.640 --> 09:39.580] solution set. But it's how do you manage that legacy that's sitting out there in the current [09:39.580 --> 09:47.980] environment? And as we've also said in the past, because of the nature of the marketplace, [09:48.480 --> 09:57.140] it's like prying those systems out of their cold, dead hands in some of these hospitals and other [09:57.140 --> 10:03.860] types of entities, because they don't have, obviously, with Mitch, the wherewithal to just [10:03.860 --> 10:08.980] immediately turn around, you know, your capital and your inventory for some of these types of [10:08.980 --> 10:16.160] solutions. Yeah, so I totally agree. It's the products we have today. It's the new products [10:16.160 --> 10:21.720] and how we create design-in plans so that you design in a defense-in-depth level of security [10:21.720 --> 10:27.500] at the hardware, firmware, software, and service level. I suggest we go all the way down to the IP [10:27.500 --> 10:32.260] of the design of the chip. You know, we need to go all the way down and all the way up. [10:32.260 --> 10:37.400] And we also need, I know in the standards work we're doing, we're saying that we need to be able [10:37.400 --> 10:42.360] to look forward too. I'm an old rocket scientist, or experienced. My girlfriend's saying not to [10:42.360 --> 10:46.020] use the term old, but I'm an experienced rocket scientist. I used to work on future missions [10:46.020 --> 10:49.780] around Jupiter. Did we know exactly what we were doing? No, but we had a planet, you know, [10:49.780 --> 10:54.140] and you look forward, you say, what's going to happen? So in the standards work that we're doing, [10:54.140 --> 10:59.600] we're agreeing that it has to be a standard that is extensible into the future. You know, [10:59.600 --> 11:03.300] so what we're also doing is envisioning, well, how can we use artificial intelligence [11:03.300 --> 11:08.300] and machine learning better? What about when it's a hologram and the doctor's like, oh my gosh, [11:08.300 --> 11:12.300] she's right here. You look a little jaundiced. I'm like, how do you know that? You know, [11:12.300 --> 11:18.500] I'm in my pajamas. How did that just happen? Right? So when we're in XR, AR, VR, how's all [11:18.500 --> 11:22.900] this stuff going to play? And then if you want to get excited about protocols, think of what, [11:22.900 --> 11:26.500] you know, communications protocol, that's going to be all about. You know, that's going to get [11:26.500 --> 11:31.880] into your EHR or how they're going to read, you know, from your, from your little devices. So [11:31.880 --> 11:37.560] we're also trying to think of what could happen. So being an aerospace engineer and designing, [11:37.560 --> 11:42.660] you know, not just spacecraft, but also planes and jets, you have your heads down display, [11:42.660 --> 11:46.500] right? Your altimeter. And then you have your heads up display. We need both. [11:48.640 --> 11:53.810] I am in full agreement with you and can tell you the biggest challenge I saw [11:54.610 --> 12:00.430] with all these years of working for healthcare and hospitals. I've been in the provider space [12:00.430 --> 12:05.230] for about a dozen years as a CISO. And biggest challenge I've always found has actually been [12:05.230 --> 12:12.290] paying for it all because a lot of, a lot of hospitals out there, especially with COVID, [12:12.290 --> 12:19.630] have significant financial challenges these days. And right now, I mean, every hospital [12:19.630 --> 12:25.210] has a problem paying. Before January or February of this year, you still would have had about, [12:25.210 --> 12:29.270] I'd say about half the hospitals in the United States, whereby I asked them to update a good [12:29.270 --> 12:34.170] chunk of their clinical engineering equipment. They would have likely looked at me and said, [12:34.170 --> 12:38.930] when I can fix my roof, when I can fix my floor, and when I can patch the hole in the boiler. [12:39.510 --> 12:43.330] And what do you want? Do you want a roof over your head or do you want secure medical devices? [12:43.330 --> 12:49.110] And I've actually once had a clinical chair from the department sit me down and say, [12:49.110 --> 12:54.050] I'd like to update my devices, but I need to get different ones in here because I'm not able to do [12:54.050 --> 13:02.710] women's health properly. And to me, that put a lot of items in perspective. And I've always worked [13:02.710 --> 13:08.290] with my customers to make sure that we can get them on at least a good path to where they need [13:08.290 --> 13:14.910] to be using minimal cost solutions. Because to be very blunt, it's 15 to 20 years also, because [13:14.910 --> 13:20.510] it's all I have money for. And that's sadly the situation in the United States. And after things [13:20.510 --> 13:27.930] happen, after we have some leveling off with COVID, we're going to be in a much different [13:27.930 --> 13:33.530] place, more like 2009 when it comes to the economy. But to get these good items in place, [13:33.530 --> 13:38.490] you need to have standards. And that leads me to the second question, which is, what standards [13:38.490 --> 13:43.070] efforts are in play for medical device security that you're currently working with? So again, [13:43.070 --> 13:49.650] to you, Florence, because of all the IEEE work. Absolutely. I have to apologize. I have a robo [13:49.650 --> 13:54.610] caller who won't give up. So you're going to hear my phone in the background. So anyone else been [13:54.610 --> 14:01.770] through this? So the standards efforts, we have a number of standards efforts in play, and we're [14:01.770 --> 14:09.070] trying to hold hands and work together. So at IEEE, we have this IEEE UL P2933, which is the [14:09.070 --> 14:13.790] for clinical IOT data and device interoperability with TIPS, as we discussed. There are also [14:13.790 --> 14:19.190] efforts on blockchain for healthcare and how that plays in. There are efforts going on with ISO and [14:19.190 --> 14:25.810] IEC and open mobile health and communications interoperability. So we actually just had a [14:25.810 --> 14:30.690] really cool session last week, where Mitch and I presented along with a number of our colleagues [14:30.690 --> 14:36.350] from around the world regarding addressing clinical IOT interoperability and security [14:36.350 --> 14:42.490] challenges globally. And so one of our colleagues representing Underwriters Laboratories, [14:42.490 --> 14:47.650] after we each spoke about P2933, you know, this kind of IOT thing, and then open mobile health, [14:47.650 --> 14:52.650] and a few other things, he got up and said, okay, here's one page with like all this stuff on it. [14:52.830 --> 14:56.830] You know, we have a pyramid here, we have a triangle, and we have all these other pieces. [14:56.930 --> 15:01.530] We have to figure out how we're going to work together. So if any of you out there are [15:01.530 --> 15:07.470] interested in getting involved in this, we're actually hoping to have a longitudinal plan here. [15:07.530 --> 15:12.930] We had Julian Goldman from Harvard, and Mass General, who was on the panel, [15:12.930 --> 15:20.870] and Ida Sim from UCSF. We had Mitch, me, Ken Fuchs, McGregor, Anura, Fernando from Underwriters [15:20.870 --> 15:27.230] Laboratories. And I always forget at least one. Oh, and Ken, I think that's most of it. [15:27.230 --> 15:30.950] And so we're all going to be getting together again in the fall. And we're interested in [15:30.950 --> 15:35.570] anybody else who wants to join us. So Mitch, I don't know if we're giving out our email addresses [15:35.570 --> 15:45.330] or how you want to do that. But, you know, we'll find a way to make the P2933 web page [15:45.330 --> 15:53.030] completely accessible and get information over there. So in the meantime, you can send me an [15:53.030 --> 16:00.130] email along with my robocaller at florence.com. And I think I'm going to give them my email address [16:00.130 --> 16:02.570] so they're not so disruptive the next time. [16:04.090 --> 16:12.030] Hey, Florence, I'm really excited to hear that IEEE is getting involved in this space. [16:13.230 --> 16:18.350] And, you know, it's exciting to hear that. There's not enough that we can do [16:19.010 --> 16:24.570] actually to really formalize the process of multiple device cybersecurity [16:25.120 --> 16:32.030] across the lifecycle of these technologies. I would like to also recognize, you know, [16:32.250 --> 16:37.150] a lot of the work that the FDA has done in producing cybersecurity guidance documents [16:37.150 --> 16:46.410] over the last, oh my gosh, you know, many years. And so, you know, whether it's pre-market [16:46.410 --> 16:52.910] requirements for submissions and cybersecurity, or it's post-market surveillance, right? And [16:52.910 --> 16:57.270] knowing how to do coordinated vulnerability disclosures, those guidance documents are very [16:57.270 --> 17:04.190] helpful. Also very relevant today, you know, is cybersecurity for off-the-shelf software [17:04.190 --> 17:10.350] components. Again, you know, FDA has some good guidance documents, a good guidance document on [17:10.350 --> 17:17.230] that. Recently, and, you know, they've taken a very collaborative approach to cybersecurity [17:17.230 --> 17:23.030] engaging very different stakeholders. And a great example of that, you know, FDA has engaged NTIA [17:23.630 --> 17:30.790] on creating a software bill of materials standard and a set of deliverables around that as well. [17:30.790 --> 17:37.650] And it's all around how manufacturers can be more ready to identify vulnerabilities in third-party [17:37.650 --> 17:42.530] components, and then extending that capability out to hospitals, you know, who have this technology [17:42.530 --> 17:49.510] in an operational environment. And, you know, the last two things here I'll mention is [17:50.050 --> 17:55.810] International Medical Device Regulators Forum. You know, it's not just the U.S. and FDA that's [17:55.810 --> 18:01.490] going through this problem. This is a global issue in medical device cybersecurity. And the [18:02.050 --> 18:07.690] International Medical Device Regulators Forum, INDRS, has come together to produce a cybersecurity [18:07.690 --> 18:15.710] guidance document that really sets to harmonize... provide harmonized guidance to regulators [18:15.710 --> 18:21.490] globally. So, you know, different countries and regions can set up their own guidance [18:21.490 --> 18:28.730] documents and map that to their own regulatory bodies. And the last one here I'll mention, [18:28.730 --> 18:35.430] I have to mention it because, boy, it was a lot of work, but the Healthcare Sector Coordinating [18:35.430 --> 18:43.690] Council. And, you know, Michael also and Mitch, you know, were contributors to this effort as well, [18:43.690 --> 18:48.530] produced what's called the Joint Security Plan, the MedTech Joint Security Plan, [18:48.530 --> 18:54.310] otherwise referred to as the JSP. And, you know, in this document, you know, anyone can find... [18:55.170 --> 19:00.070] it's not just... it's not standard. It's actually a plan, a way to put in motion [19:01.250 --> 19:08.450] a security program from design, development, all the way out to, you know, complaint handling for [19:08.450 --> 19:13.530] medical devices, and what to do when these devices are out in the field, and risk management, [19:13.530 --> 19:17.550] again, throughout the continuum of care. So if you want to know how to do a risk assessment [19:17.550 --> 19:22.830] on medical devices, if you want to know, you know, when to do a penetration test, [19:22.830 --> 19:27.350] what types of design requirements are helpful for medical device and cybersecurity, [19:27.350 --> 19:33.110] how to structure your organization, you know, those things you can find in the JSP today. [19:33.110 --> 19:40.490] And working with MDIC, we're also developing an effort to actually benchmark against those [19:40.490 --> 19:46.990] different capabilities. So that way, if you're a small medical device manufacturer or a large one, [19:46.990 --> 19:52.470] you want to know where to go next, and how to build out your program, and what's good enough. [19:52.470 --> 20:01.570] And so this benchmarking initiative with MDIC will help us create that set of metrics, [20:01.570 --> 20:07.430] and again, the benchmark itself, so that we can share it openly across our industry stakeholders, [20:07.430 --> 20:12.870] and collectively improve our programs, be able to speak to our executive leadership, too, as well, [20:12.870 --> 20:18.010] that have to pay and make and commit to this investment in medical device cybersecurity. [20:18.010 --> 20:22.630] That sounds really cool. Do they have guidance for manufacturers as well as providers? [20:24.350 --> 20:32.230] So, Healthcare Sector Coordinating Council also has, yes, guidance for healthcare providers, [20:32.230 --> 20:39.130] too. It's called HICP, H-I-C-P. And then you have the Joint Security Plan, [20:39.130 --> 20:46.350] which is focused on medical devices and healthcare IT solutions. And so, yes, [20:46.350 --> 20:55.210] they have guidance for both sets of stakeholders. Right. And yeah, so as Rob stated, the IMDRF, [20:55.210 --> 21:04.050] also, the way it was documented, it addresses, here's what's the pertinent areas for the [21:04.050 --> 21:10.830] manufacturer, the health delivery organization, the different stakeholders, even patients, [21:10.830 --> 21:15.710] as it pertains to the different topics that was put into that type of guidance. And again, [21:15.710 --> 21:22.110] that one was global. A couple of others that I would just want to make sure that we have included [21:22.110 --> 21:30.030] when you talk about health delivery organizations, MIDA has always championed and updated their, [21:30.030 --> 21:37.230] you know, MDS2 documentation, which is utilized for the procurement process with health delivery [21:37.230 --> 21:44.270] organizations. And that MDS2 is something that has been maintained as a part of the release schedule [21:44.270 --> 21:50.390] and with the inclusion of the SBOM as a component and a deliverable of that, [21:50.390 --> 21:57.610] it gives organizations like Mitch's the ability of being able to understand the ingredients of [21:57.610 --> 22:02.990] the product and the solutions that they are acquiring and how they need to develop and [22:02.990 --> 22:10.810] execute that. And then as Rob said, the AAMI organization has taken on the ability of taking [22:10.990 --> 22:17.550] a look at some of those, you know, pre-market and post-market type of guidance documentation, [22:17.550 --> 22:24.830] and then they created their technical, you know, references in their TIR 57 and 97, which allows [22:24.830 --> 22:31.470] you to provide some of the how-to on those different stakeholders in the industry, how they [22:31.470 --> 22:38.190] need to execute against those particular technical references and standards. So I think that kind of, [22:38.190 --> 22:45.850] we gave you the alphabet soup and then some in response, Mitch. Yeah, absolutely. No excuses now. [22:46.970 --> 22:51.970] I can tell you that that 2019 MDS2 form, thank you very much for that, Michael. That's been [22:51.970 --> 22:57.030] incredible in our organization. We've actually started using that a lot. The first vendor that [22:57.030 --> 23:04.050] actually gave us one was Philips. So very happy that... I'll take the old pats on the back for [23:04.050 --> 23:07.030] that. We're starting to get those in from our vendors and they've been helping us out with a [23:07.030 --> 23:14.550] lot of different purposes. So my next question here is, what are the most difficult medical device [23:14.550 --> 23:19.190] security issues to solve? I want to throw a real ringer in there. [23:22.670 --> 23:29.650] I'll take the first. Okay, go ahead, Rob. Yeah, I'll take a first stab at that. So [23:30.710 --> 23:36.450] I think one of the most difficult issues to solve, just to change it up here, aside from... [23:37.010 --> 23:43.930] and it does relate to the issue of legacy medical devices, is also that hospital environments [23:44.290 --> 23:51.710] may have hundreds of thousands of connected medical devices at one time and from thousands [23:51.710 --> 24:03.110] of different vendors. And so while I may not directly feel that pain, I feel for our customers [24:03.110 --> 24:10.930] at BD that are healthcare providers and have to manage this tremendous complexity. [24:11.710 --> 24:19.610] And what compounds this situation is that not every medical device manufacturer [24:19.610 --> 24:27.310] is doing things like patching of their medical devices or routine updates to their medical [24:27.310 --> 24:37.290] devices. And also, that's why transparency is so important, because these new threats emerge [24:37.290 --> 24:44.330] daily. And boy, I'm sure there's a lot of homework that healthcare providers have to do when a new [24:44.330 --> 24:51.710] security vulnerability pops up and you don't find a timely and effective or meaningful communication [24:52.230 --> 25:01.130] from a medical device manufacturer to facilitate a response. So yeah, I think those are [25:01.950 --> 25:06.690] really, really important issues that we need to address. [25:07.450 --> 25:15.150] You know, one of the things I would add on where Rob is at, and again, I do agree that the [25:15.770 --> 25:21.410] level of connectivity and the complexity of the type of solutions is definitely [25:22.530 --> 25:28.030] a critical one, but let me be a little bit more provocative and throw something else out there. [25:28.030 --> 25:35.990] I think when you look at potentially, and again, and this gets back to, again, I think [25:35.990 --> 25:42.350] where Florence was at when we talk about taking it down to the chip level. I think when I look [25:42.350 --> 25:50.990] at the greed that exists in society around the revenue that either wants to be made or [25:50.990 --> 25:58.170] maintained on devices, and then what that would be from your brand and impression. I think one of [25:58.170 --> 26:06.650] the best things that happened was the fact when the Health Sector Coordinating Council and HISAC [26:06.650 --> 26:12.510] and others have come together and petitioned organizations like Microsoft, especially during [26:12.510 --> 26:20.810] this time of COVID, to extend the patching and the updates for Windows 7 and to make that [26:20.810 --> 26:28.410] date in the hospital sector not to extend it. So the more that we can [26:28.410 --> 26:36.790] do activities as a community like that to either extend the life or to be much more [26:37.670 --> 26:44.010] economical around how these products and solutions are being used. And again, [26:44.010 --> 26:50.670] my provocativeness, get away from the potential greed that might exist out there. I think [26:50.670 --> 26:57.230] that'll help us to try to address some of the issues that might exist [26:57.230 --> 27:00.750] in the ecosystem. It's one thought. [27:04.470 --> 27:11.990] Yeah, greed and jealousy are motivators that we can use in business to get people to do [27:11.990 --> 27:20.130] things. And so it's the human condition, I think. So if we could [27:20.130 --> 27:27.110] figure out how to leverage that, I think that would be good. So in the standards work that we do, [27:27.570 --> 27:32.930] you know, it's IEEE, it's at the individual level, it doesn't cost anything to join the [27:32.930 --> 27:37.010] working group. And what I tell people is, you know, this will be like a take-home test [27:37.010 --> 27:42.010] if you get involved now, because you can help define it, you know, and then you could be the [27:42.010 --> 27:46.730] first ones to have it. And you could be at the leading edge when, you know, I was at Yale New [27:46.730 --> 27:52.050] Haven a couple years ago talking about this tips framework, and very bright as they are, [27:52.050 --> 27:55.790] the chief information and chief medical officers looked at me and said, [27:55.790 --> 27:59.750] so do you have a tips maturity model that you could hand us today that we could use tomorrow [27:59.750 --> 28:03.490] to look at all these hundreds of thousands of devices in our hospital and our patients? [28:03.490 --> 28:09.030] Like, whoa, I wish the answer to that was yes, but it's going to take a village, right? Ah, [28:09.030 --> 28:13.070] the biohacking village, look where we are, how handy is this? So maybe that's something, you [28:13.070 --> 28:17.930] know, we can end up working on together. And people can get involved in creating this tips maturity [28:17.930 --> 28:23.650] model, validating it, certifying it, you know, maybe that's, you know, what we can do is get [28:23.650 --> 28:28.390] other people jealous, like, ooh, you know, I want to go to the head of the class. That would be great. [28:30.130 --> 28:35.170] I, I agree with you. And I think, and again, there's other challenges as well. And I'm going [28:35.170 --> 28:39.170] to be just as provocative as Michael right here and bring out another big one, which is the [28:39.170 --> 28:46.270] electronic medical records systems of record themselves. So we have to make sure that these [28:46.270 --> 28:51.370] systems of record that we eventually store all this information in, we have to make sure we keep [28:51.370 --> 28:59.450] them as updated and up to date and able to support these devices just as much as the devices [28:59.450 --> 29:03.590] themselves. There was actually an interesting paper I read from the late Michael Sinow and [29:03.590 --> 29:10.190] some other people that had put together the best model for electronic medical record system [29:10.190 --> 29:17.170] implementation at a health system in New Jersey they were at. And what it came down to is that [29:17.170 --> 29:26.350] 25% of the cost was the EMR. 75% was the cost of the ancillary devices themselves. So I think [29:26.350 --> 29:32.870] we could stand to make sure that we have a good budgeting model that we make sure that we [29:32.870 --> 29:41.130] understand what devices work, what version of an EMR and be able to cost it all out. And we can solve [29:41.130 --> 29:48.210] that challenge with simply doing a lot of good financial work and making sure also that the [29:48.210 --> 29:55.970] system of record aka the EMR also stays updated. Easier said than done. So talking about other [29:55.970 --> 30:00.190] challenges to your future leads to question number four which is how do you solve the [30:00.190 --> 30:07.930] challenges today with an anticipatory eye and what the next threats may be? [30:07.930 --> 30:13.330] First on that right here I'll start off again with Florence. Oh heads down display heads up [30:13.330 --> 30:18.850] display. What is it you're trying to deal with today? And we have we'll start with with that [30:18.850 --> 30:23.950] and we have to have the guts to look at what we haven't done yet. Now we're all talking about [30:23.950 --> 30:27.490] standard this you know we haven't done with SNOMED and low ink and this and that and fire [30:27.490 --> 30:31.330] and HL7. Oh my god this stuff is so incredible because people who are brilliant who created it [30:31.330 --> 30:36.670] right. But it's not done and it will probably never be done right because there's a lot of [30:36.670 --> 30:42.890] hacking that you know continues to evolve as we know. The the bad dudes and dudettes and robots [30:42.890 --> 30:48.610] are just as smart as the good ones unfortunately. So what we have to do is not be afraid to look [30:48.610 --> 30:53.970] at what haven't we done yet. So as an example so we're talking about trust and identity and [30:53.970 --> 30:59.670] security and devices. So what if we had you know what if we figured out a federated identity [30:59.670 --> 31:04.690] management system for devices with you know digital identifiers, decentralized identifiers, [31:04.690 --> 31:09.630] and we try to do that globally. People go oh we haven't done that yet. I'm like exactly [31:10.150 --> 31:17.330] that's exactly the point. So is that exactly what we need? Maybe not. But go wide and then decide [31:17.330 --> 31:22.430] you know how we start today and where we need to go. So we have the guts we have to have the guts [31:22.430 --> 31:28.790] to say we haven't figured it all out yet. Figure out what we can do today and then build a step [31:28.790 --> 31:33.690] function you know a plan going forward. And you know you should we should do some brainstorming [31:33.690 --> 31:38.410] like I was about holograms and VR and AR and XR and your R and my R and all this other kind of [31:38.410 --> 31:42.550] stuff that's going to happen. And stuff that we don't even have terms for yet. They're going to [31:42.550 --> 31:48.730] be part of this. So I'd say that you know we have to start by being brave enough to understand what [31:48.730 --> 31:52.650] we already have from AIME and ISO and IEC and IEEE and all this other cool stuff and all the [31:52.650 --> 31:58.250] providers and all the manufacturers. Then look at what we haven't done yet. Have the guts to do that. [31:58.250 --> 32:02.450] Figure it out and then create a step function toward the future. So that's my recommendation. [32:03.020 --> 32:10.730] Yeah I love the comments from Florence and the direction. I've built a few homes [32:10.730 --> 32:17.530] because of having to relocate. And I always look at what your current environment is [32:17.530 --> 32:23.730] as an organization, as a team. And to her point, I want to make sure that foundation is in place. [32:23.730 --> 32:30.510] And one of the biggest hurdles is to be able to consistently execute in a number of these [32:30.510 --> 32:37.410] organizations that foundational piece that she described. In terms of making sure that [32:37.410 --> 32:43.090] we're doing consistently the activities and efforts that we should have in place right now. [32:43.090 --> 32:49.910] And so when you have multinational organizations, different business units, [32:49.910 --> 32:57.390] different variations of releases and schedules of products and devices, different mixes of [32:57.950 --> 33:03.990] solutions, whether or not they're capital related or implantables. And I mean, [33:03.990 --> 33:09.670] there's a myriad of things that exist out there, but you have to be pretty consistent with [33:09.670 --> 33:15.070] how am I developing that solution? How am I maintaining that? How am I updating that? How [33:15.070 --> 33:20.350] are we interacting and getting the right information at a consistent level like those [33:20.910 --> 33:28.170] MDS2s updated on that entire product portfolio? That's the basics in terms of the blocking and [33:28.170 --> 33:35.210] tackling that usually isn't the most sexy thing that you think of, and sometimes is really [33:35.210 --> 33:42.310] overlooked. And so we really need to get that foundational areas in place across all of the [33:42.310 --> 33:50.110] elements of, as we say in the ecosystem, for devices and solutions. And even as Mitch just [33:50.110 --> 33:56.250] pointed out from his earlier statements around the electronic health and medical records, [33:56.830 --> 34:01.910] Rob and I know that our counterparts in some of those entities, when we were on the cybersecurity [34:01.910 --> 34:06.610] task force, it was like pulling teeth to get them to want to even come to the table [34:07.150 --> 34:11.990] and having the discussions. And even when you have certain solutions where [34:12.610 --> 34:19.530] we're there was astonished to say, man, you had the ability to maintain the certain level [34:19.530 --> 34:28.210] of the release and not go back multiple inversions. But you did that to want to be [34:28.210 --> 34:33.830] supposedly in compliance and supporting your customers, but you were doing a total detriment [34:33.830 --> 34:39.670] to the industry by not aligning and forcing that you couldn't have stuff out there. But [34:39.670 --> 34:45.950] they were in a much easier position to maintain their devices at the most current levels and [34:45.950 --> 34:50.630] updates. And we were sitting there like, man, are you kidding? Because we don't have that luxury [34:50.630 --> 34:57.890] when it came to some of the devices, especially for organizations that had implantables and pumps [34:57.890 --> 35:04.090] and other things of those natures. So... Don't hold back, Michael. [35:04.930 --> 35:14.910] It's DEF CON. So when I think about what we can do right now, I think about the current [35:14.910 --> 35:21.070] environment that we're in. And it touches on a little bit of what you've heard [35:21.070 --> 35:27.130] from others on this panel, actually. We're in an environment where I think most of our [35:27.130 --> 35:34.010] organizations, if you work in healthcare, we're distracted. Really distracted. If you're even just [35:34.010 --> 35:41.430] the general public, you're distracted. Okay? COVID has taken a lot of the focus away from [35:41.430 --> 35:50.030] other things like cybersecurity. If we're not careful in tying the story behind how cybersecurity [35:50.550 --> 35:56.910] is the underpinning to providing a resilient and thriving healthcare system. [35:57.030 --> 36:05.690] It's just essential. We can't have resilient and effective healthcare without securing it. [36:05.690 --> 36:12.750] They go hand in hand. And I say that because the other issue we're facing here is that [36:13.070 --> 36:20.670] most healthcare delivery organizations don't even have a single person dedicated to [36:20.670 --> 36:26.890] cybersecurity. And this is one of the findings of the Healthcare Industry Cybersecurity Task [36:26.890 --> 36:35.570] Force report that went to Congress in 2017. So there's not enough people working in this space [36:35.690 --> 36:42.450] we need to bring in more stakeholders from different backgrounds into the healthcare [36:42.450 --> 36:49.910] industry and into the cybersecurity industry to really... and even if it's not their title, [36:49.910 --> 36:56.730] but to build a community of practice around everyone's shared responsibilities around [36:56.730 --> 37:03.350] cybersecurity. And the last thing I'll say from the stuff that we can control as the cybersecurity [37:03.350 --> 37:14.130] professionals, I think especially Michael and Mitch and myself, we need to as healthcare and [37:14.130 --> 37:19.590] medical technology companies, as healthcare providers, we need to look at our investment [37:19.590 --> 37:27.490] in security and ask ourselves this, are we protecting what society values most? [37:27.490 --> 37:34.450] And if you ask anyone, what is important to protect in healthcare to protect, [37:34.450 --> 37:41.050] they will tell you most likely, even if it's my mom, all right, she will tell you, [37:41.050 --> 37:47.590] it's probably going to be patient safety, patient health, right? And probably also patient privacy. [37:48.510 --> 37:55.570] And so look at our investment today and figure out if there's changes that we need to take in [37:55.570 --> 38:02.470] our approach. And maybe touching on Florence's idea there to make it even more tangible around [38:02.470 --> 38:08.150] creating some sort of model for identity management in healthcare, you don't have to go [38:08.150 --> 38:15.070] too far. I mean, for many years, the cybersecurity industry has been talking about what's called [38:15.650 --> 38:23.230] zero trust principles. And so the idea behind zero trust principles are instead of trusting [38:23.230 --> 38:29.390] devices inside the network, you know, in this approach, it means trusting no one by default [38:29.390 --> 38:35.690] and operating as though the network had already been compromised. And so this means incorporating [38:35.690 --> 38:41.470] different types of criteria for authenticating and authorizing users. And the fundamental [38:41.870 --> 38:47.570] technologies exist today. It's just changing your strategy as a cybersecurity professional [38:47.570 --> 38:52.410] to focus on the idea that you've already been compromised. And how do we strengthen authentication [38:52.410 --> 38:58.530] through multi-factor authentication, through conditional access for devices and users [38:58.530 --> 39:04.610] connecting to the network? And so those types of technologies exist today. There is hope in, [39:04.610 --> 39:09.710] again, what's available to cybersecurity professionals today. But I would also go [39:09.710 --> 39:14.890] back and say, we need to expand our community of practice. So if we get all geeky-weeky, [39:14.890 --> 39:18.310] which we could do with each other, fire this and HL7 that, and we're so cool, [39:18.690 --> 39:25.730] you know, trust zone and hardware. I got upgraded for free one day on a plane when I was flying [39:25.730 --> 39:30.250] planes. And I was sitting next to a guy who runs a hospital, a doctor. And I was telling him what [39:30.250 --> 39:33.750] we're doing. He said, well, you know what? I'm glad you're working on that because my job is [39:33.750 --> 39:40.990] to keep that patient on the table alive. That's what I focus on all day. So in our working group, [39:42.330 --> 39:49.410] 2933 working group, actually it's all about, we always talk about it, protecting the humans, [39:49.410 --> 39:54.890] keeping the humans alive. That's why we're doing this. That's exactly why, you know, my background, [39:54.890 --> 39:58.610] my mother died the day I was born. It was a medical error, you know, whole stuff here. So [39:58.610 --> 40:03.530] I carry this with me. How do you keep the humans alive? And that's what we're focused on. And if [40:03.530 --> 40:08.170] you actually read our project authorization request at IEEE, it says to improve health [40:08.170 --> 40:12.670] outcomes. We're not doing this for us geeky weekies. We're doing it to improve health outcomes [40:12.670 --> 40:18.690] and to keep the humans alive. And eventually what I would love to see, and we actually had a meeting [40:18.690 --> 40:24.210] at my last firm and with Microsoft a few years ago, we were talking about creating like a [40:24.210 --> 40:28.930] cybersecurity learning hub for humans, you know, normal people. And we said, oh, cradle to grave. [40:28.930 --> 40:33.870] And we said, oh, that's kind of rude. Let's say pre-K to AARP. And we're going to teach them [40:33.870 --> 40:38.730] what TIPS is. You know, so when I was a little girl, remember I'm a geek, I was a rocket scientist. So [40:38.730 --> 40:44.470] I used to look for the little UL tag on my, on my electric cords. Any of you guys? I did. I always [40:44.470 --> 40:50.970] look for them because that meant safety, right? And so what we want to do is teach them why they [40:50.970 --> 40:55.370] should ask for this. So someday, I don't know if it's two, three or five years from now, some little [40:55.370 --> 40:58.870] five-year-old is going to be at the doctor and they're going to try to give her an insulin pump. [40:58.870 --> 41:04.530] And she's going to say, does that have TIPS? And she doesn't need to know what it stands for. [41:04.530 --> 41:10.170] We do. We're the geeks. We need to understand that it's trust and identity and federated identity [41:10.170 --> 41:14.770] management. And when the doctor, you know, goes into the little device next to grandma's bed that [41:14.770 --> 41:20.890] goes into her implanted pacemaker, you check the credentials of that doctor every single time. [41:21.110 --> 41:26.170] You make sure they're still, you know, related to whatever their provider is. You make sure they [41:26.170 --> 41:31.170] still are credentialed. You make sure it's really the doctor and you have to figure out how to do it. [41:31.230 --> 41:36.570] So that's our vision is that we really want this to protect the humans and make the humans aware of [41:36.570 --> 41:41.270] it. Just like I looked for that little UL tag, which not everybody did, I know, but you know, [41:41.270 --> 41:45.770] how do we teach them and then make sure that the manufacturers are delivering that because [41:45.770 --> 41:50.790] then you have demand, you have push and pull from the citizens, from the patients, right? [41:50.790 --> 41:55.350] And then the providers and the payers should care about this. It reduces their liability. [41:55.350 --> 41:59.390] You know, I used to work on smart buildings years ago when we were first creating a smart [41:59.390 --> 42:05.070] building strategy when I was a VP at IBM. And I remember, you know, we were talking to these [42:05.070 --> 42:09.230] building management system companies and one of them said, oh, you know what? Security is like [42:09.230 --> 42:13.610] number 11 on my list of top 10 things to worry about. And their device was hacked nine months [42:13.610 --> 42:19.190] later and the whole leadership team was out. And now it's part of their brand promise. Oh, [42:19.190 --> 42:24.830] imagine that, right? So we need to make that a requirement. You know, we need people to be [42:24.830 --> 42:30.430] incented to do that and to have the citizens and patients asking for it. [42:31.650 --> 42:37.650] Absolutely, Florence. And also one other thing that my organization's had a big challenge with [42:37.650 --> 42:44.430] has also been privacy because one of the areas we've got to worry about is not only do we have, [42:44.430 --> 42:50.090] we're collecting all this data on people and we have numerous data points on all the people we're [42:50.090 --> 42:54.990] collecting from these devices. And we need to make sure that we're protecting that. So [42:54.990 --> 43:01.290] important question I have here is what about privacy? How are we incorporating this into [43:01.290 --> 43:06.510] our products? How are we incorporating it into our data governance plans? So to lead off here, [43:06.510 --> 43:14.170] I believe this is going to be our final question for the three of you. So start off with Michael. [43:14.710 --> 43:22.170] Sure. I think that the, you know, privacy takes on, you know, from a legal perspective, [43:22.170 --> 43:29.070] you want to understand, you know, the requirements by the different geographies, [43:29.070 --> 43:34.770] by the different jurisdictions, by, you know, what the hospitals and, you know, [43:34.770 --> 43:40.590] the different entities have in terms of managing that type of information. But to me, Mitch, it's [43:41.350 --> 43:47.510] nothing more than another component of your requirements. So if you design privacy as you [43:47.510 --> 43:52.790] would security by design in your development process, you take into account what are those [43:52.790 --> 43:58.430] sets of requirements and you have to harmonize for, you know, some of us, you know, like, you [43:58.430 --> 44:06.070] know, Rob and I and others out there that deal in multi, you know, geographies, you know, multi [44:06.070 --> 44:13.130] types of regulatory and compliance environments, and you have to develop what your baseline is. [44:13.130 --> 44:17.630] And then once you develop that baseline, and you include those sets of requirements, [44:17.630 --> 44:23.510] I would look at the steward of, you know, the CISOs, you know, and it's three of us on the call [44:23.510 --> 44:29.550] to be able to make sure that we're executing against that. We go to our legal teams and the [44:29.550 --> 44:35.410] privacy organization, really for that foundation to make sure that we're interpreting those [44:35.410 --> 44:40.570] requirements, and we're executing those requirements, you know, effectively with the [44:40.570 --> 44:47.970] tools and the solutions that we then deploy out in the marketplace. And so I have always had, [44:47.970 --> 44:55.070] you know, kind of a mix of the privacy and the data protection elements kind of be able to be [44:55.070 --> 45:00.990] co-mingled within, you know, the team. Operationally, if you do it right, you want the CISO side of the [45:00.990 --> 45:06.150] house to be managing that, and you want your legal and your compliance arms to be able to [45:06.150 --> 45:12.290] help you develop and, you know, and document what those requirements need to be, you know, [45:12.290 --> 45:20.440] from a privacy perspective, in my opinion. So I got to tell you, I don't think I could [45:20.440 --> 45:30.400] describe it any better than Michael, or I should say Professor McNeil. It's so well said, really, [45:30.400 --> 45:37.780] I can't do better than that. I mean, you know, to address privacy requirements alongside security [45:37.780 --> 45:43.540] requirements, I absolutely agree. As security professionals, like, you know, bring your privacy [45:43.540 --> 45:50.140] friends along with you. And absolutely right that, you know, there's things that, you know, [45:50.140 --> 46:00.380] we think of in security that sometimes are counterintuitive to privacy. And then also, [46:00.380 --> 46:06.480] again, what Michael said around, you know, treating, bringing your legal professionals, [46:06.480 --> 46:11.320] especially, you know, when you're addressing privacy requirements, the complexity is, [46:11.320 --> 46:18.060] as he mentioned, this is different across every single country. And you do have to, [46:18.060 --> 46:25.980] you know, establish as a company, a common foundation, based off of values, based off [46:25.980 --> 46:31.440] of values and principles, you know, as a company, what do we stand for? What is it that we want to [46:32.060 --> 46:41.720] do when it comes to this huge civil rights issue, you know, of privacy? And sometimes that means we [46:41.720 --> 46:46.280] want to do everything that we can, and we are going to establish, you know, the strictest, [46:46.280 --> 46:51.480] you know, governance of privacy across all of our technologies and product platforms, you know, [46:51.480 --> 46:56.240] that is, again, a decision that companies need to make. And I got to tell you, I don't think [46:56.240 --> 47:03.420] there's many customers that would complain, you know, about a company creating a position [47:03.420 --> 47:08.460] and a very robust and comprehensive position on privacy across their different technologies for [47:08.460 --> 47:14.100] customers. So... Agreed. So I'll make a couple of comments. I'm sorry, Mitch. I couldn't agree [47:14.100 --> 47:19.680] more with you. So what do you think? Oh, you know, Mia, I always think something. So there [47:19.680 --> 47:24.360] are a couple of things. One is on the privacy side, it's one of our subgroups, it's part of [47:24.360 --> 47:28.320] TIPS, you know, Trust, Identity, Privacy, right in the middle, Protection, Safety, and Security. [47:28.320 --> 47:32.520] And we have a woman from the European Union who's leading that subgroup, which is great, [47:32.520 --> 47:39.400] because she actually found the privacy rules by country in Europe. Not surprising, right? [47:39.400 --> 47:44.540] So what we're doing is making sure that we're going deep on those, identifying the patterns, [47:44.540 --> 47:48.580] and then figuring out what are the little things we have to worry about here if we're creating a [47:48.580 --> 47:53.420] standard that's international. So if I'm wearing an implanted device, I'm in the U.S., I'm in the [47:53.420 --> 47:57.560] U.K., I'm in Russia, I'm in China, I'm in South Africa, am I going to be safe? You know, is my [47:57.560 --> 48:01.840] data going to be private? What does that mean? What are the implications? So we're already baking [48:01.840 --> 48:09.840] that in to the plan. The other thing is that I was at an event at my alma mater at Princeton, [48:09.840 --> 48:13.880] and Sonia Sotomayor was there. She's a Supreme Court Justice in the U.S. for those of you who [48:13.880 --> 48:18.580] don't know her. She's brilliant. And so I asked her, what do you think about privacy and security [48:18.580 --> 48:22.740] and the Internet of Things, all these devices all over the place? I said, I'm working on security. [48:22.740 --> 48:27.700] She said, that's good because I'm working on privacy because I don't think the citizens realize [48:27.700 --> 48:32.740] the human rights that they're giving up. Very interesting. So she's on it, and she's already [48:32.740 --> 48:36.960] written a couple of things on it if you want to look at what she's done. And then the other thing [48:36.960 --> 48:41.300] I just want to mention very quickly, we were talking about, you know, what's our goal here? [48:41.300 --> 48:45.480] I spoke at an event at Academic Medical Center Conference a few years ago, and then about a year [48:45.480 --> 48:50.320] or so ago, a gentleman reached out to me and said, oh, I wrote a book, and I found your presentation, [48:50.320 --> 48:54.920] and I referred to you in my book. I was like, oh, I'm so honored. What's the name of your book? [48:54.920 --> 49:03.380] The Doctor Will Kill You Now. And he talked about the security and privacy issues, [49:03.380 --> 49:08.660] and this guy who, like, you know, lives in his mother's basement and then moves to another [49:08.660 --> 49:13.180] state. It's not bad living in your mother's basement, I have that going on too, but moves to [49:13.180 --> 49:20.520] another state, fakes a PA license, gets into a doctor's office, gets into the system, actually [49:20.520 --> 49:27.380] turns off the power in the hospital so someone on event dies. Then he gets into somebody's personal [49:27.380 --> 49:32.880] medical record, changes his blood type, they're given a transfusion, and they die. And then his [49:32.880 --> 49:39.700] next target is a children's hospital. So if anybody is looking at, so why should I worry [49:39.700 --> 49:45.640] about this security and privacy stuff? That's a good book. It's only 15 bucks. And the guy who [49:45.640 --> 49:51.400] wrote it is an MD, and he used to lead the IEEE chapter in Rochester, New York, years ago. [49:51.400 --> 49:56.900] So he, you know, he's on both sides. He's an electrical engineer, computer scientist, more double [49:57.440 --> 50:03.720] and then he's also a doctor. So we all have to work on this. This is serious. It's just going [50:03.720 --> 50:09.360] to get worse. A lot more things are connected. There are attack surfaces all over the place. [50:09.360 --> 50:16.920] We need a defense in depth strategy. And it's for privacy and security and protection and safety. [50:21.830 --> 50:26.790] I'm impressed by the depth of knowledge everyone brings here. And I speak from the provider [50:26.790 --> 50:31.890] perspective here. I'm very happy to be working with you all, especially from the standards [50:31.890 --> 50:37.410] perspective as well. I think we have a good foundation. We just all need to continue to keep [50:37.410 --> 50:43.790] working together. And you have my commitment and for all of you in the medical device industry know [50:43.790 --> 50:49.290] you have my organization's commitment as well. So thank you so much for all taking the time today. [50:49.290 --> 50:55.350] This is incredibly appreciated and hope all of you out there appreciate this today as well. So [50:55.350 --> 51:00.430] thank you all so much for taking the time. And this is the group here signing off.