1
00:00:00,000 --> 00:00:08,020
So our next speaker is part of the healthcare security and privacy expert. He is an active

2
00:00:08,020 --> 00:00:15,560
member in the security community. He is also an author of such books as Visual Basic and

3
00:00:15,560 --> 00:00:25,700
Visual Basic.net for scientists and engineers as well as Pro Pearl parsing. And he is the

4
00:00:25,700 --> 00:00:32,440
project lead for OWASP's anti ransomware guide and OWASP secure medical device deployment

5
00:00:32,440 --> 00:00:39,280
standard projects. Now here to present his talk, standardizing the secure deployment of

6
00:00:39,280 --> 00:00:50,340
medical devices, ladies and gentlemen, Chris Frentz. Thank you. It should come as

7
00:00:50,340 --> 00:00:55,680
no surprise to anyone in this room, but hospitals are routinely pretty insecure. And

8
00:00:55,700 --> 00:01:00,400
going back the last few years, there's been a number of healthcare data breaches. We see in

9
00:01:00,400 --> 00:01:06,240
2015, MIT announced it was going to be the year of the hospital hack. We had a bunch of major

10
00:01:06,240 --> 00:01:11,460
breaches throughout 2016. And a lot of the security risks in hospitals were further

11
00:01:11,460 --> 00:01:16,040
emphasized with all of the ransomware attacks that were predominant last year within

12
00:01:16,040 --> 00:01:21,120
healthcare. The first being Hollywood Hospital, roughly March of last year. They were

13
00:01:21,120 --> 00:01:25,680
brought down for several days and ended up paying $17,000 to recover all their data. So we're

14
00:01:25,680 --> 00:01:29,200
going to talk about medical record data. And that was the first of many, many hospitals. We saw a

15
00:01:29,200 --> 00:01:33,920
similar trend with MedStar following shortly afterwards, as well as many other hospitals

16
00:01:34,300 --> 00:01:39,520
throughout the U.S. Now there's several reasons why hospitals like these and all other

17
00:01:39,520 --> 00:01:45,840
hospitals make prime targets for attackers. Number one being is medical record data is

18
00:01:45,840 --> 00:01:51,180
actually worth quite a bit. Much more so than a credit card. You steal a credit card number, you

19
00:01:51,180 --> 00:01:54,680
might get a few thousand dollars out of the account before the bank notices the fraud and cuts

20
00:01:54,680 --> 00:01:55,660
you off. You might get a few thousand dollars out of the account before the bank notices the fraud

21
00:01:55,680 --> 00:01:58,960
and cuts you off. A medical record has a lot more useful data. It could be used for much more

22
00:01:58,960 --> 00:02:03,300
comprehensive identity theft, because it contains social security numbers, all kinds of other

23
00:02:03,300 --> 00:02:08,760
stuff in it. You could establish false identities, open lines of credit with it. You could use it

24
00:02:08,760 --> 00:02:13,060
for insurance fraud. You can even use it to buy pharmaceuticals and medical devices that you

25
00:02:13,060 --> 00:02:18,940
could then resell for profit. So there's lots of things you can do with medical data that make it

26
00:02:18,940 --> 00:02:23,100
quite, quite valuable. And a lot of it, too, can be valuable in ways that you wouldn't normally

27
00:02:23,100 --> 00:02:25,660
expect. Like, for example, to get a medical record, you have to have a medical record. You can

28
00:02:25,660 --> 00:02:30,460
get a visa to the U.S. from a lot of different countries. They require a clean lung x-ray. And

29
00:02:30,460 --> 00:02:34,580
in countries where tuberculosis is prominent, like China and stuff like that, there's actually a

30
00:02:34,580 --> 00:02:39,420
huge black market for clean lung x-rays right now. So medical data can often be used in a lot of

31
00:02:39,420 --> 00:02:44,380
ways that you wouldn't typically expect. So that's one thing that makes hospitals a fairly

32
00:02:44,920 --> 00:02:51,980
ideal target for attackers to go after. The other and more concerning thing that makes hospitals an

33
00:02:51,980 --> 00:02:55,620
ideal target is, within health care, there are still a ton of bacteria that are tested against

34
00:02:55,660 --> 00:03:01,060
legacy systems. If we think about it, a lot of medical equipment is quite expensive, it's hard

35
00:03:01,060 --> 00:03:06,160
to replace, and it was designed with doing whatever clinical function it had in mind. It might

36
00:03:06,160 --> 00:03:10,340
do that clinical function well, might have a 10, 15 year life span in which it still does that

37
00:03:10,340 --> 00:03:16,460
clinical function very well. But a lot of that equipment was not built with security in mind. We

38
00:03:16,460 --> 00:03:21,960
see that in a lot of medical devices now. We're seeing reports almost daily of medical devices

39
00:03:21,960 --> 00:03:25,800
being vulnerable to hacking. There's been a number of demonstrations, even at this conference

40
00:03:25,800 --> 00:03:32,280
here, of various medical devices that were easily exploited. In the news recently, we saw

41
00:03:32,860 --> 00:03:37,340
both Hasbira, they made the news for the FDA recall for their infusion pumps, and we're

42
00:03:37,340 --> 00:03:41,560
probably all familiar with the issue with some of the St. Jude pacemakers that were also all

43
00:03:41,560 --> 00:03:47,380
over the media. Going back for some other examples, some medical devices, because of the

44
00:03:47,380 --> 00:03:51,500
usage of Windows XP and other stuff, it was found to have over 1,400 vulnerabilities,

45
00:03:51,500 --> 00:03:58,560
and just one system alone. This raises a lot of interesting questions, because a lot of the

46
00:03:58,560 --> 00:04:02,540
previous attacks, they focused on patient data, but what would occur if attackers targeted

47
00:04:02,540 --> 00:04:11,120
medical devices instead? And this was largely theoretical until about two months ago, when

48
00:04:11,700 --> 00:04:16,400
WannaCry broke out. We're all pretty familiar with it. It was pretty much a pandemic ransomware

49
00:04:16,400 --> 00:04:20,460
attack. Could have actually even been much worse than it actually was if the kill switch wasn't

50
00:04:20,460 --> 00:04:21,060
found in time.

51
00:04:21,500 --> 00:04:26,020
But even so, many, many companies throughout the entire world, you can see the map there,

52
00:04:26,160 --> 00:04:31,800
showing where they were struck. It was quite widespread, brought a lot of companies down, and

53
00:04:31,800 --> 00:04:37,420
most telling in healthcare actually occurred in Britain. Their National Health Service pretty

54
00:04:37,420 --> 00:04:43,920
much was brought to its knees by the WannaCry virus. But the malware and stuff outbreak wasn't

55
00:04:43,920 --> 00:04:48,260
unique to healthcare there. Hospitals throughout the world were affected, including in the U.S.

56
00:04:48,260 --> 00:04:53,320
But one of the distinct things that's different about WannaCry than a lot of past ransomware

57
00:04:53,320 --> 00:04:58,120
outbreaks is past ransomware outbreaks targeted the computer systems that housed patient data,

58
00:04:58,300 --> 00:05:02,280
which while that still has an impact on patient care, one of the interesting things about

59
00:05:02,280 --> 00:05:11,900
WannaCry is WannaCry actually spread to the medical devices themselves. Very, very different. A lot

60
00:05:11,900 --> 00:05:18,080
of radiology equipment in this particular case was actually brought down by WannaCry. Those systems had the

61
00:05:18,080 --> 00:05:23,340
same vulnerabilities that a lot of the computer systems affected by WannaCry actually had. Because if

62
00:05:23,340 --> 00:05:27,300
you think about it, all of these medical devices, basically under the hood, they are computers.

63
00:05:27,760 --> 00:05:32,520
They're either running some form of Linux or some form of embedded Windows. But those same

64
00:05:32,520 --> 00:05:37,700
vulnerabilities we find in our PCs, they're going to be present in these medical devices as well.

65
00:05:38,680 --> 00:05:43,800
And this is pretty scary because it really can give a whole new meaning to the term denial of

66
00:05:43,800 --> 00:05:48,060
service in a way that really could cause somebody to die, depending on what the device, you know, the

67
00:05:48,060 --> 00:05:52,500
device actually is. You know, if you have a stroke patient coming in and they can't get the cat's gun

68
00:05:52,500 --> 00:05:57,480
down in time to determine if you need surgery or something else like that, it could have fatal

69
00:05:57,480 --> 00:06:03,520
consequences. If a heart monitor misses a defect, the patient goes, starts to have a heart attack, the

70
00:06:03,520 --> 00:06:08,620
nurse doesn't notice because the monitor was shut off or brought down by some kind of virus. There's

71
00:06:08,620 --> 00:06:15,780
many indications like that where you could have potentially lethal outcomes. Okay. Now the question

72
00:06:15,780 --> 00:06:17,340
is, is what to do about it.

73
00:06:17,620 --> 00:06:18,040
There's a lot of information out there. There's a lot of information out there. There's a lot of

74
00:06:18,040 --> 00:06:22,920
organizations, thankfully, that are starting to look at it. One is I Am the Cavalry. About two

75
00:06:22,920 --> 00:06:28,060
years ago they released their Hippocratic Oath for Connected Medical Devices. And basically it

76
00:06:28,060 --> 00:06:33,980
covers things that manufacturers can do to help make devices more and more secure. Through a lot

77
00:06:33,980 --> 00:06:39,320
of their efforts to improve medical device security, I know they've been working with the FDA,

78
00:06:39,500 --> 00:06:44,920
and the FDA also has released a lot of guidance within the last couple of years. Some things

79
00:06:44,920 --> 00:06:47,920
about the FDA guidance, they released both premarket and

80
00:06:47,920 --> 00:06:54,500
post-market guidance. Basically that makes security recommendations for medical devices. Okay.

81
00:06:54,580 --> 00:06:59,180
The premarket guidance is mostly in terms of how the devices are manufactured. The post-market

82
00:06:59,180 --> 00:07:03,140
guidance mostly deals with things like keeping devices up to date and other stuff companies

83
00:07:03,140 --> 00:07:08,480
should ideally do once the device is put on the market. Now this is a huge, huge step in the

84
00:07:08,480 --> 00:07:14,800
right direction. Very essential. But one of the, I guess, downsides right now is the guidance is

85
00:07:14,800 --> 00:07:17,900
currently non-binding. So it's a recommendation to manufacturers. It's a recommendation to

86
00:07:17,900 --> 00:07:24,040
manufacturers, but not something they legally have to follow yet. And my other concern with this

87
00:07:24,040 --> 00:07:29,300
type of stuff is if we think about it, even if manufacturers comply with all this guidance

88
00:07:29,300 --> 00:07:34,500
tomorrow, they make the theoretically perfectly secure device starting tomorrow, there's still a

89
00:07:34,500 --> 00:07:38,240
lot of medical devices that are going to exist for a long time in hospital and health care

90
00:07:38,240 --> 00:07:43,360
institutions that are not going to be replaced overnight. You know, in many cases these systems

91
00:07:43,360 --> 00:07:47,380
cost hundreds of thousands, millions of dollars depending on the systems that are going to be

92
00:07:47,900 --> 00:07:53,120
used. And no hospital has the budget to go about and replace all their devices because a new, more

93
00:07:53,120 --> 00:07:58,020
secure model came on the market. So even in the perfect world where everything became secure

94
00:07:58,020 --> 00:08:03,840
tomorrow, which is not going to happen, it's still going to be years and years before all of the

95
00:08:03,840 --> 00:08:09,480
older and secure devices are removed from our health care institutions. So the real question is,

96
00:08:09,540 --> 00:08:16,920
is what can we do now to help make medical devices more secure? What can we do in our current

97
00:08:16,920 --> 00:08:17,400
environments?

98
00:08:17,900 --> 00:08:22,820
Okay. So how do health care institutions that have current deployments, where replacing them

99
00:08:22,820 --> 00:08:27,700
tomorrow is not going to be a possibility, what can they do to make devices more secure? And on

100
00:08:27,700 --> 00:08:32,760
top of that is even if we assume these perfectly securable devices will one day come to market,

101
00:08:33,000 --> 00:08:37,180
you could have a device with all the security features in the world in your environment, but if

102
00:08:37,180 --> 00:08:41,200
you don't take the time to configure and deploy it properly, it's still going to be highly

103
00:08:41,200 --> 00:08:47,220
insecure. So one of the things that was heavily lacking was a standard for how hospitals should go

104
00:08:47,220 --> 00:08:53,800
about and securely deploy medical devices. Okay. And that's one of the things a lot of my work is

105
00:08:53,800 --> 00:08:58,900
focused on. I did release the standard through OWASP, but basically what the goal of this project

106
00:08:58,900 --> 00:09:03,940
is, is it's designed to complement the work done by the FDA, complement the work done by I Am the

107
00:09:03,940 --> 00:09:10,460
Cavalry, and not focus on the manufacturing side, but focus on the hospital side, on the actual

108
00:09:10,460 --> 00:09:17,200
people who will be deploying these devices. Okay. Now some of the things that we've done in the

109
00:09:17,200 --> 00:09:22,000
guidance, I'm not going to go through every control in depth. There was the Google link in the

110
00:09:22,000 --> 00:09:27,000
preceding slide, and I'll make the slides available to anybody who wants them. But one of the

111
00:09:27,000 --> 00:09:32,360
first things I think should be touched upon by hospitals is purchasing controls. This is one of

112
00:09:32,360 --> 00:09:37,240
the most effective ways to get organizations to change over the long term, to get manufacturers

113
00:09:37,240 --> 00:09:44,020
to increasingly adopt security and put security into their products. So in my opinion, any

114
00:09:44,020 --> 00:09:47,180
hospital is going to be acquiring new medical devices. One of the first things that we're going to

115
00:09:47,200 --> 00:09:52,540
do is they should audit the devices that they're going to buy for both security and privacy.

116
00:09:52,820 --> 00:10:00,240
Which devices, before they purchase them, are going to best meet the needs in terms of keeping the

117
00:10:00,240 --> 00:10:05,360
data secure and keeping the patients secure. And when doing this, organizations should remind

118
00:10:05,960 --> 00:10:10,900
doctors and stuff that that is a big part of patient safety nowadays. Because if the device is

119
00:10:10,900 --> 00:10:15,380
not secure and it goes down, that really can put patients at risk. So that needs to be considered

120
00:10:15,380 --> 00:10:15,800
as well.

121
00:10:15,800 --> 00:10:22,080
In terms of evaluating the patient, the privacy and the security controls, some of the other

122
00:10:22,080 --> 00:10:28,640
things to consider is also this long-term support for the device. Which vendors are willing

123
00:10:28,640 --> 00:10:33,720
to provide patches and other stuff over the long term for those devices? Because the reality is,

124
00:10:33,740 --> 00:10:38,460
is these devices do have 10 to 15 year lifespan sometimes. So which vendors are going to

125
00:10:38,460 --> 00:10:45,780
continue to keep those platforms under support? And another recommendation, not going to go

126
00:10:45,800 --> 00:10:49,880
into the guide yet, but what I'm going to add in the next version of the guide, is I think when

127
00:10:49,880 --> 00:10:54,440
people do buy these devices, they should request a list of all the software components that are

128
00:10:54,440 --> 00:10:58,900
contained in the device. Because it's not uncommon to find that even if they have an up-to-date

129
00:10:58,900 --> 00:11:02,500
version of Windows or Linux or something else in the device, that they're using an ancient

130
00:11:02,500 --> 00:11:06,700
version of Apache or some other old library and stuff like that. And having a list of all the

131
00:11:06,700 --> 00:11:12,440
components can help you in your security auditing. So my number one thing, and I think more and

132
00:11:12,440 --> 00:11:15,780
more hospitals should do it, is vote with their wallet. And only if you have a device that's not

133
00:11:15,800 --> 00:11:20,420
a security device. And only bring devices into the environment that do meet some semblance of

134
00:11:20,420 --> 00:11:29,560
security and privacy principles. Additionally, one of the scary things, particularly exposed by

135
00:11:29,560 --> 00:11:34,360
WannaCry, but exposed in other sources as well, is a lot of the medical devices that were

136
00:11:34,360 --> 00:11:38,660
brought down by WannaCry were brought down because they were publicly accessible over the

137
00:11:38,660 --> 00:11:44,720
internet. Now that's pretty scary because in 99% of the cases, there's probably no need for

138
00:11:44,720 --> 00:11:45,780
those devices to be run. So if a device is being used to run it, you can get a lot of data, but it's not going

139
00:11:45,780 --> 00:11:52,320
accessible over the Internet. So, I mean, not going to go through in depth with a firewall,

140
00:11:52,500 --> 00:11:57,920
that kind of stuff is, but taking basic mechanisms to ensure that your medical devices are

141
00:11:57,920 --> 00:12:02,240
not publicly reachable, pretty simple, straightforward security control, missing in an

142
00:12:02,240 --> 00:12:07,220
awful lot of hospitals. So one section of the guide does go through different perimeter

143
00:12:07,220 --> 00:12:13,080
protections you can put in place to ensure that these devices are not publicly available. And

144
00:12:13,080 --> 00:12:17,040
if they do need access to the Internet and other stuff like that, things you can do to actually

145
00:12:17,040 --> 00:12:20,280
control and restrict access to just what is needed.

146
00:12:25,660 --> 00:12:29,880
Additionally, just like you should have defense at the perimeter, a lot of organizations fail in

147
00:12:29,880 --> 00:12:35,820
this area as well, is these devices do not need to talk to every other device on your network.

148
00:12:36,140 --> 00:12:41,620
Yes, all modern medical equipment is pretty much network enabled, often for perfectly valid

149
00:12:41,620 --> 00:12:42,940
reasons to improve patient

150
00:12:42,940 --> 00:12:49,380
care, because, you know, let's say you have a heart monitor sitting on a patient, and, you

151
00:12:49,380 --> 00:12:52,540
know, the heart rate can automatically be sent to a nursing station where the nurse is monitoring

152
00:12:52,540 --> 00:12:57,340
it, and having that kind of stuff networked, it can improve response times much better for

153
00:12:57,340 --> 00:13:02,160
patient care. There's a lot of valid reasons for having this equipment networked. But the

154
00:13:02,160 --> 00:13:07,140
output of that heart monitor does not need to go to every device in your organization.

155
00:13:07,560 --> 00:13:12,360
Likewise, every device in your organization does not need to connect to that particular heart

156
00:13:12,360 --> 00:13:12,700
monitor.

157
00:13:12,940 --> 00:13:18,920
So a lot of the controls here focus on, you know, very basic network security, but stuff you often

158
00:13:18,920 --> 00:13:25,120
find lacking in a lot of hospitals, basic things like network segmentation, taking time to do

159
00:13:25,120 --> 00:13:30,440
vulnerability scanning of devices you have inside, making sure they're secure, making sure patches

160
00:13:30,440 --> 00:13:35,920
are applied, things like that. Very basic controls we commonly reply to, regular desktop endpoints

161
00:13:36,320 --> 00:13:41,780
or servers in our environment are oftentimes missing from medical device deployments. So this

162
00:13:41,780 --> 00:13:42,560
section here, basically,

163
00:13:42,560 --> 00:13:47,940
advocates putting those types of controls inside. And even things like internal firewalls and stuff

164
00:13:47,940 --> 00:13:52,060
like that, you know, if you're going to spend three quarters of a million dollars on an MRI machine,

165
00:13:52,300 --> 00:13:56,720
spending an extra $300 on a small sonic wall to put in front of it and protect it is really not,

166
00:13:56,780 --> 00:14:04,180
you know, too much to ask. So, okay. Now, device security controls. What are the security

167
00:14:04,180 --> 00:14:08,920
controls that should be configured on the devices themselves? And, yes, once again, a lot of

168
00:14:08,920 --> 00:14:12,540
these things are very, very basic. Changing the default credentials on the device, changing the

169
00:14:12,560 --> 00:14:16,660
default password on the device. It should be common sense to do, but if you look at a recent outbreak

170
00:14:16,660 --> 00:14:22,860
like Mirai, it was a list of pretty much 61 passwords that were used to compromise hundreds of

171
00:14:22,860 --> 00:14:29,580
thousands of devices. So, in a lot of cases, just having basic mechanisms like this in place can be a

172
00:14:29,580 --> 00:14:34,060
huge improvement. So, you know, there are basic controls to prevent attacks similar to what we saw at

173
00:14:34,060 --> 00:14:38,880
Mirai, like changing default credentials, account lockouts, things like that. But there's a lot of

174
00:14:38,880 --> 00:14:42,460
other things that hospitals don't think of to do. Like, let's say you have something like WannaCry,

175
00:14:42,560 --> 00:14:47,040
hit your environment. Do you actually have a spare copy of your firmware? How are you going to

176
00:14:47,040 --> 00:14:51,980
restore that device to a functional state if it's taken down? Much better to prepare for that kind of

177
00:14:51,980 --> 00:14:57,980
stuff ahead of time, be ready for it, than to go, uh-oh, I have no way to recover this device once

178
00:14:57,980 --> 00:15:02,860
an attack hits. You're having a backup of your configuration. Okay, maybe you applied the new

179
00:15:02,860 --> 00:15:07,340
firmware. You got it back in place, but that device probably had special settings to make it work

180
00:15:07,340 --> 00:15:10,860
in your environment. Do you have those backed up as well? Things like that that can help you

181
00:15:10,860 --> 00:15:11,920
recover from an attack.

182
00:15:12,620 --> 00:15:19,740
Baseline configurations, make sure things are deployed securely. Having the ability to encrypt data,

183
00:15:19,880 --> 00:15:25,340
things like that. Having update mechanisms in place, making sure that you do go around, have the

184
00:15:25,340 --> 00:15:31,720
latest firmware on each device. Compliance monitoring to make sure devices stay secure. Physical

185
00:15:31,720 --> 00:15:36,080
security, make sure the devices can't be tampered with. And also things like asset management as

186
00:15:36,080 --> 00:15:42,200
well. You'll find in most hospitals, if biomedical devices were to come under attack, it probably

187
00:15:42,200 --> 00:15:46,060
wouldn't be IT or security that was notified right away. It would probably be the group that

188
00:15:46,060 --> 00:15:51,840
handles the medical devices. And what they'd probably do to start is they'd probably swap the

189
00:15:51,840 --> 00:15:55,500
device out for a new one and wouldn't even think to troubleshoot it. So having proper asset

190
00:15:55,500 --> 00:15:58,980
management in place if you were to come under attack would be good because it would help you

191
00:15:58,980 --> 00:16:03,440
track what devices were compromised, what were not, and help you from putting an affected device

192
00:16:03,440 --> 00:16:12,060
back into production. Okay. Another thing you'll find in a lot of medical device deployments is

193
00:16:12,200 --> 00:16:17,060
they're either what they call an interface or central stations that the devices connect to. So

194
00:16:17,060 --> 00:16:21,420
basically how I'm going to define the central station is let's say you have a series of heart

195
00:16:21,420 --> 00:16:27,200
monitors. There's going to be a computer that all that data is going to. Okay. So it's used to

196
00:16:27,200 --> 00:16:31,940
collect and analyze a lot of the data collected by these devices. And that may function as an

197
00:16:31,940 --> 00:16:35,920
interface even if you have an isolated network for your medical devices where that particular

198
00:16:35,920 --> 00:16:41,380
computer is then used to send data off to your medical record system or something else. So you

199
00:16:41,380 --> 00:16:42,180
might have proper network for your medical system. You might have a network for your medical system.

200
00:16:42,180 --> 00:16:45,560
You might have network segmentation and everything else. But this particular interface device

201
00:16:45,560 --> 00:16:49,500
is going to be a potential weak point because that's going to be what links the rest of your

202
00:16:49,500 --> 00:16:53,960
production network from your isolated medical device network. So you want to make sure that

203
00:16:53,960 --> 00:16:59,220
there's proper steps here as well in order to secure the devices. Things like standard OS

204
00:16:59,220 --> 00:17:06,640
hardening, making sure the data is encrypted as you transport it. Basically have message

205
00:17:06,640 --> 00:17:12,160
security in place and that once again you keep these devices and all of the software in place.

206
00:17:12,160 --> 00:17:19,280
The software that runs on them is up to date as possible. This is an area I particularly like,

207
00:17:19,320 --> 00:17:25,500
there's a lot of recommendations that we have so far, but I don't think you can consider anything

208
00:17:25,500 --> 00:17:30,160
secure until you actually go ahead and test it and prove it's secure. Yes you might have put a

209
00:17:30,160 --> 00:17:34,420
great firewall in, you might have put a bunch of rules in your firewall, but how do you know those

210
00:17:34,420 --> 00:17:39,580
rules actually do what you think they're doing unless you actually go ahead and actually go

211
00:17:39,580 --> 00:17:42,140
ahead and test it. So I'm a big advocate of once you actually have these systems, have a few rules,

212
00:17:42,140 --> 00:17:46,120
actually do these deployments once you put the controls in place that you actually go ahead

213
00:17:46,120 --> 00:17:52,680
and run a penetration test. See, does my security actually keep this device secure? I'm also

214
00:17:52,680 --> 00:17:57,440
big on having instant response plans done ahead of time and I'm very, very big on doing mock

215
00:17:57,440 --> 00:18:03,240
incidents to actually run through scenarios where you will actually simulate the device being

216
00:18:03,240 --> 00:18:07,320
under attack. How would you respond to it? You don't want a situation where the first time

217
00:18:07,320 --> 00:18:12,360
you're dealing with an incident is when the incident actually happens and people are lost and

218
00:18:12,360 --> 00:18:16,560
don't know what to do because they've never run through the drill before. You can actually see a

219
00:18:16,560 --> 00:18:21,200
screenshot here. It wasn't done for medical devices, it was done for desktop PCs, but it's an

220
00:18:21,200 --> 00:18:25,640
incident that we actually did at the hospital I work at. We actually did take over some desktops.

221
00:18:25,740 --> 00:18:31,280
I changed out Explorer EXE for another EXE that popped up this ransomware screen. And we

222
00:18:31,280 --> 00:18:36,040
actually saw how IT and the staff actually dealt with a simulated ransomware outbreak like

223
00:18:36,040 --> 00:18:37,300
that. So I'm very, very proud of that.

224
00:18:37,320 --> 00:18:42,300
I'm very big on actually testing stuff ahead of time. Okay. Now some things about the

225
00:18:42,300 --> 00:18:46,780
standard is it is starting to gain some attention. So there is some growing adoption. It's been

226
00:18:46,780 --> 00:18:52,280
covered in magazines such as CSO Magazine, the IAPP Privacy Perspectives, Health Net

227
00:18:52,280 --> 00:18:57,180
Security, Health System CIO, a few other things. Also pretty interesting is it was recently

228
00:18:57,860 --> 00:19:02,420
translated into Turkish because the Turkish Ministry of Health is actually considering adopting

229
00:19:02,420 --> 00:19:06,540
some of the recommendations as part of their own internal policies. So that's pretty interesting.

230
00:19:06,540 --> 00:19:11,380
And hopefully the adoption of something like this continues to develop and continues to grow because

231
00:19:11,380 --> 00:19:17,080
I think it's a heavily unaddressed area of security right now. Just as a side note, if anybody's

232
00:19:17,080 --> 00:19:22,100
interested, doesn't directly deal with the talk, but I'm also the author of the OWASP Anti-Ransomware

233
00:19:22,100 --> 00:19:28,520
Guide. And that's another guide. It has a set of 45 different controls in the categories. They are

234
00:19:28,520 --> 00:19:35,240
designed to protect an organization against ransomware using a defense in-depth approach. At this

235
00:19:35,240 --> 00:19:36,360
point, I'll take any questions.

236
00:19:38,580 --> 00:19:46,240
Some devices have been taken home and they control and plant medical devices. Obviously, you can't have all that primitive stuff over there.

237
00:19:46,720 --> 00:19:47,340
That's true.

238
00:19:47,520 --> 00:19:50,560
Through iPhone applications and stuff. Can you speak about that?

239
00:19:51,220 --> 00:19:54,460
Sure. Most of the framework I've laid out so far.

240
00:20:08,740 --> 00:20:27,100
Some devices, the patients take them home, they connect to implantable medical devices. In fact, some software may be like on iPhones. So you can't have this level of perimeter security with it. They may have to talk back to the medical provider. Could you give some advice on that? Thank you.

241
00:20:28,080 --> 00:20:36,520
Sure. That's definitely true. Most of the guide I did focus on was for hospital and healthcare institutions. So I was focusing more on, I guess, the institution-level

242
00:20:36,540 --> 00:21:06,520
institutions themselves. But implantable devices are definitely a risk. That's part of what we saw at the St. Jude pacemakers was, it was their Merlin at home transmitter that was used to communicate with the device, was found to be insecure. And yes, home users are not going to follow the same kind of security recommendations and things like that. I think that that much more falls to the manufacturing standards the FDA is putting out to basically put security in place that way because you have much less control over what you can do with a person at home. So I think that's a big risk.

243
00:21:06,540 --> 00:21:19,260
I guess my standard was more focused on things hospital IT security staff can do to secure their deployments. But that's definitely a real valid concern. And I think that's better addressed, though, by the FDA guidelines rather than the project I was working on.

244
00:21:20,280 --> 00:21:36,520
So jumping on the kind of the last question there, I know it's not exactly the topic of this conversation, but for blood glucose meters, insulin pumps, things that are embedded or worn on the actual patient, what is the FDA even trying to address these sorts of concerns?

245
00:21:36,540 --> 00:21:40,680
Are there any sorts of security concerns on those devices, things that are connecting to their iPhones and Androids?

246
00:21:40,920 --> 00:21:47,720
They did release some guidance. It's non-binding right now, but there is some FDA both pre- and post-market guidance that has recently been released.

247
00:21:48,840 --> 00:21:56,620
But like I said, it's currently non-binding. So there's recommendations to manufacturers. And I think the rally on most implantable devices, it comes down to a question of risk.

248
00:21:56,780 --> 00:22:06,520
If you consider a pacemaker, prior to the devices being wireless in some form, you could adjust the settings. If you needed your pacemaker adjusted, you had to go back in for surgery and stuff like that.

249
00:22:07,080 --> 00:22:13,280
There's a huge risk for surgery. Making these devices wireless did take away a lot of that risk.

250
00:22:13,420 --> 00:22:18,220
So yes, some risk was reintroduced by making it wireless in a different way.

251
00:22:18,520 --> 00:22:26,240
But for a lot of it too, it comes down, for the average person, is the risk of dying from surgery worse than the risk of having their pacemaker hacked?

252
00:22:26,580 --> 00:22:31,020
And maybe for a real famous person, like you saw with Cheney, he had the special shielded pacemaker.

253
00:22:31,860 --> 00:22:33,980
The hacking risk was greater than the surgical risk.

254
00:22:34,320 --> 00:22:36,520
But for the average person, there's a lot of risk.

255
00:22:36,540 --> 00:22:41,840
It's a question that there's not an answer to yet, but that's really what I think the question comes down to in a lot of cases.

256
00:22:42,760 --> 00:22:43,300
Thank you.

257
00:22:45,520 --> 00:22:52,240
A quick point of clarification. The FDA guidance is actually legally binding. The methodology to achieve the effect is not.

258
00:22:52,380 --> 00:22:57,160
So in the post-market example that you gave, there is a risk assessment methodology that's provided in there.

259
00:22:57,380 --> 00:22:59,100
That is non-binding. That's a suggestion.

260
00:22:59,440 --> 00:23:03,640
But actually, to address cybersecurity risk in the post-market, that is actually a legal requirement.

261
00:23:04,060 --> 00:23:06,240
To address the gentleman's question that came up before.

262
00:23:06,540 --> 00:23:09,800
There is no specific device guidance with respect to cybersecurity.

263
00:23:10,080 --> 00:23:15,380
But the pre- and post-market largely apply to all devices that come through the center for devices.

264
00:23:15,640 --> 00:23:16,260
Thank you.