1
00:00:00,000 --> 00:00:11,060
In this talk, DIY Diabetics and a Million Boluses, we are three panelists that are going to discuss a common topic related to insulin pump hacking and its global impact.

2
00:00:11,080 --> 00:00:12,500
Hi, I'm Dina Truxius.

3
00:00:12,500 --> 00:00:16,480
I'm working for the Federal Office for Information Security in Germany.

4
00:00:16,520 --> 00:00:28,740
And my work mainly focuses on medical device cybersecurity, on all cybersecurity-related health, on project management, standardization, and a lot of comity work.

5
00:00:28,740 --> 00:00:29,940
I'm Julian.

6
00:00:29,940 --> 00:00:33,700
I'm Security Analyst and Researcher at EMW Research in Germany.

7
00:00:33,700 --> 00:00:42,200
And I perform cybersecurity assessments of medical devices, medical environments, and I'm having a deep dive into medical communication standards.

8
00:00:42,200 --> 00:00:44,520
And hey, I'm Mike Christianen.

9
00:00:44,520 --> 00:00:48,000
I'm the Director of Medical Security at Harbor Labs.

10
00:00:48,220 --> 00:00:55,380
I perform cybersecurity assessments of medical devices for a number of manufacturers and a number of different medical devices.

11
00:00:55,380 --> 00:01:02,460
I tend to focus on software, medical firmware, and device communication protocols, especially cryptography.

12
00:01:02,460 --> 00:01:11,520
So for our agenda today, our panel will introduce medical device cybersecurity practices and projects in Germany and the U.S.

13
00:01:11,520 --> 00:01:19,160
We'll provide a background for insulin pump technology, and we'll define a formal threat model for insulin pumps.

14
00:01:20,160 --> 00:01:26,620
Further, we will demonstrate an insulin pump attack and describe the response remediation effort.

15
00:01:26,720 --> 00:01:35,440
And then we'll discuss how this impacts the DIY diabetics community, something that if you have not heard of before, you will during this talk.

16
00:01:35,880 --> 00:01:38,920
Lastly, we'll conclude with some remarks from the team.

17
00:01:40,680 --> 00:01:46,120
So to kick us off first, we'll have Dina covering the global medical device cybersecurity.

18
00:01:46,920 --> 00:01:48,160
Thank you.

19
00:01:48,160 --> 00:01:59,580
So let me introduce you to the German federal landscape to demonstrate our duties and responsibilities in terms of health and IT security or cybersecurity.

20
00:01:59,880 --> 00:02:06,160
This schematic drawing intends to show a very simplified version of the complete German federal government.

21
00:02:06,440 --> 00:02:11,320
In Germany, you see below the gray field, we have various ministries.

22
00:02:11,320 --> 00:02:16,000
The two important ones are for now folded out.

23
00:02:16,040 --> 00:02:20,800
On the left, you see the Federal Ministry of the Interior, Building and Community.

24
00:02:20,860 --> 00:02:23,380
And on the right, you see the Ministry of Health.

25
00:02:23,480 --> 00:02:31,740
My employer, the Federal Office for Information Security, is the authority under the Ministry of the Interior on the left.

26
00:02:32,360 --> 00:02:39,700
We are the German cybersecurity authority and fulfill comparable tasks like DHS and CISA.

27
00:02:39,700 --> 00:02:42,500
We fulfill all our legal obligations.

28
00:02:42,500 --> 00:02:43,960
We have our own cert.

29
00:02:43,960 --> 00:02:49,480
We are experienced in coordinated vulnerability disclosures and in projects.

30
00:02:49,720 --> 00:02:54,680
Our legal mandate allows us to assess basically any IT device.

31
00:02:55,220 --> 00:03:12,780
In terms of medical devices, we have no direct legal mandate yet, except the fact that we can be included in the risk assessment of medical devices in terms of IT security by the Federal Institute for Drugs and Medical Devices, the BFARM.

32
00:03:12,780 --> 00:03:19,040
This authority carries out all regulation with regards to medical devices.

33
00:03:19,040 --> 00:03:21,880
The BFARM is comparable to FDA.

34
00:03:21,880 --> 00:03:25,340
They deal with safety and vigilance issues.

35
00:03:25,420 --> 00:03:32,640
Whenever any incident is reported in medical devices, the BFARM gets active and uses its established processes.

36
00:03:32,640 --> 00:03:41,740
We are working closely together with BFARM and our health ministry and for sure our authority in all terms of medical device cybersecurity.

37
00:03:44,760 --> 00:03:57,900
So the Federal Office for Information Security, the BSI, which stands for Bundesamt für Sicherheit in der Informationstechnik, it's a German abbreviation, is a thought leader in cybersecurity.

38
00:03:58,530 --> 00:04:13,130
We were already founded in 1991 and we enormously expanded within the last years and today we have more than 1,300 employees in total, mostly IT specialists and natural scientists.

39
00:04:13,540 --> 00:04:22,240
The federal government in Germany realizes and still sees the need to have a functional national cybersecurity authority.

40
00:04:22,240 --> 00:04:32,540
So we are covering all fields of work with respect to cybersecurity, from A to Z, from autonomous vehicles over medical devices to the Zoom app.

41
00:04:32,540 --> 00:04:43,440
We are cooperating with national, EU, international authorities and stakeholders and our budget is invested in various cybersecurity projects.

42
00:04:43,440 --> 00:04:47,320
And I'm really keen to give you some more insights during this talk.

43
00:04:50,520 --> 00:04:59,000
So our overall mission is to cover all issues related to cybersecurity and to make the world more secure.

44
00:04:59,000 --> 00:05:02,220
We believe we can and we do care about it.

45
00:05:02,220 --> 00:05:12,980
As a BSI employee, the following statement is somehow implanted into my brain and I know that every IT system is potentially vulnerable at any given time point.

46
00:05:12,980 --> 00:05:16,120
We know that it is not a matter of getting hacked.

47
00:05:16,120 --> 00:05:19,680
It will happen anyway and everywhere at one point.

48
00:05:19,680 --> 00:05:29,720
But for us, it's essential to keep in mind that it's important to be prepared and to know how to deal with vulnerabilities in a coordinated and responsible manner.

49
00:05:32,810 --> 00:05:44,270
In order to fill some of our legal obligations and to increase the awareness towards cybersecurity, we regularly publish technical guidelines and recommendations.

50
00:05:44,270 --> 00:05:54,390
In the field of medical device cybersecurity, we published a recommendation about cybersecurity requirements for network-connected medical devices in 2018.

51
00:05:54,430 --> 00:06:01,090
This is available in German and English and it is defining best security practices.

52
00:06:01,090 --> 00:06:12,430
This publication is in accordance with national and EU-wide regulation requirements and cybersecurity is seen as a continuous process throughout the product lifecycle.

53
00:06:12,430 --> 00:06:17,850
Apart from this, this document can assist in terms of risk analysis.

54
00:06:20,070 --> 00:06:23,690
So, my cybersecurity requirements to go for you.

55
00:06:23,690 --> 00:06:33,190
When we look at cybersecurity and discover vulnerabilities in medical devices, we definitely have to consider and have to discriminate between the modes of action.

56
00:06:33,190 --> 00:06:37,550
There is a huge difference between the medical operation and the technical maintenance mode.

57
00:06:37,550 --> 00:06:40,650
For example, in terms of privileges and authentication.

58
00:06:40,650 --> 00:06:52,090
My cybersecurity to go message for you is that the required security updates and measures must not have a negative impact on safety.

59
00:06:52,190 --> 00:06:57,610
And not every vulnerability has an impact on patient safety, but it is possible.

60
00:06:57,610 --> 00:06:59,710
Now, I'm talking about our project money made.

61
00:06:59,710 --> 00:07:12,250
So, when I joined the BSI in 2018, there was a lot of rumor and discussion about medical devices, not only in press, especially about pacemakers and insulin pumps and potential or possible patient harm.

62
00:07:12,470 --> 00:07:17,190
So, I asked myself what can be done and what has been done so far.

63
00:07:17,230 --> 00:07:21,250
And the idea of a medical device hacking project came into my mind.

64
00:07:21,250 --> 00:07:29,930
I made use of our budget, entertained myself with paperwork and tended the project money made, which stands for manipulation of medical devices.

65
00:07:29,930 --> 00:07:34,430
The project started in 2019 and will end in December this year.

66
00:07:34,810 --> 00:07:40,490
The project aims to assess the current cybersecurity state of medical devices.

67
00:07:40,910 --> 00:07:49,330
And it aims to bring cybersecurity researchers like Mike and Julian, manufacturers and authorities like me to a table.

68
00:07:49,330 --> 00:08:01,730
I chose five different device categories, namely ventilators, patient monitors, ICDs and their environment, infusion pumps, and last but not least, insulin pumps.

69
00:08:01,930 --> 00:08:11,210
Out of each category, we aim to assess two devices, so in total 10 devices within the scope.

70
00:08:11,210 --> 00:08:17,450
To further restrict our market research, I asked for additional requirements when picking the devices.

71
00:08:17,450 --> 00:08:18,890
These are the following.

72
00:08:19,250 --> 00:08:24,290
First, the devices had to be no longer than five years on the German market.

73
00:08:24,590 --> 00:08:31,810
Second, and should be highly connected, having as many interfaces as possible for an appropriate attack surface.

74
00:08:32,650 --> 00:08:45,450
So, after picking the respective devices, we tried to get in contact with the top manufacturers found in our market research, explained our intention to pentest the respective devices, and ideally ended up with a signed testing contract.

75
00:08:45,450 --> 00:08:59,370
With this, the manufacturers provided us with the respective medical devices and lab environments, and in return, they received exclusive knowledge about their security state in the devices.

76
00:08:59,510 --> 00:09:09,290
After the security assessment, the manufacturers are provided with a detailed report about all findings, and a subsequent coordinated vulnerability process is initiated.

77
00:09:09,650 --> 00:09:13,610
All findings are published as soon as the vulnerabilities are fixed.

78
00:09:13,610 --> 00:09:20,810
We recommend to use ICSMAs and closely collaborate with CISA, and we recommend to assign CVEs.

79
00:09:21,170 --> 00:09:24,670
The project aims to increase transparency and awareness.

80
00:09:24,670 --> 00:09:36,350
Additionally, the trust for communication and cooperation among all stakeholders, which is seen as one of the highest goods in our whole process, and inspired by a classical coordinated vulnerability disclosure.

81
00:09:36,350 --> 00:09:51,150
We believe that the project results aimed to be published in December will allow for cyber security statements, as well as addressing certain questions and problems basically everyone is facing in the field of smart medical devices.

82
00:09:51,150 --> 00:10:00,310
This project that I'm leading is the basis for the security research on a smart insulin pump that will be shown by Julian, our technical project lead.

83
00:10:00,310 --> 00:10:10,090
When we will demonstrate these findings, please be aware that I make use of my legal mandate to inform about important security updates.

84
00:10:10,090 --> 00:10:16,210
My intention is to improve cyber security without finger pointing at anyone or anything.

85
00:10:16,210 --> 00:10:23,430
I want people to get a feeling, or better to say a sixth sense, a cyber security sense for vulnerabilities.

86
00:10:23,430 --> 00:10:29,590
I think that's really helpful to understand BSI and sort of your goal and your project and your aims.

87
00:10:29,790 --> 00:10:34,870
From the US side, we have FDA cyber security guidance that's in place.

88
00:10:34,870 --> 00:10:40,110
In particular, we have guidance for medical devices before they can be marketed.

89
00:10:40,290 --> 00:10:43,390
They have to have this pre-market evaluation.

90
00:10:43,870 --> 00:10:49,350
The strictness of controls that are a part of this evaluation are determined by the risk to patient safety.

91
00:10:49,350 --> 00:10:52,630
Medical devices are actually classified in three bins.

92
00:10:52,630 --> 00:10:54,370
We have one, two, and three.

93
00:10:54,650 --> 00:10:59,630
In terms of risk, this is lowest to highest, three being the highest.

94
00:11:00,810 --> 00:11:07,630
With respect to cyber security analysis that my team at Harvard Labs typically focuses on is class two and class three.

95
00:11:07,670 --> 00:11:13,130
These devices have, for example, network interfaces to communicate with other endpoints.

96
00:11:13,130 --> 00:11:20,310
They are communication patient data, and furthermore, they're actuating, which might be, say, to deliver a medicine.

97
00:11:20,710 --> 00:11:27,830
Now, depending on the classification of the device, the pre-market process, there's two specific processes that are taken.

98
00:11:27,950 --> 00:11:31,590
If it's a class two, you would submit a 510k pre-market notification.

99
00:11:31,670 --> 00:11:36,550
If it's a class three, you would submit a PMA for pre-market approval.

100
00:11:37,030 --> 00:11:41,050
Now, both of these submissions have cyber security requirements.

101
00:11:41,050 --> 00:11:46,370
I've actually worked with a number of clients to create these submissions.

102
00:11:46,770 --> 00:12:05,430
And sort of as the rigor in the submission, some of the steps, if I could elucidate them quickly, my team and the manufacturers look to specify all the cyber security threat models, understanding what threats are to their systems, laying bare and plain the architecture and data flow,

103
00:12:05,430 --> 00:12:17,530
enumerating harm and non-harm risk to patient safety, and then identifying, implementing, and analyzing any potential mitigations that the system can possibly implement to reduce the risks and vulnerabilities in the systems overall.

104
00:12:17,530 --> 00:12:23,390
And what's nice, the really nice takeaway here is that the FDA does have post-market management recommendations.

105
00:12:23,390 --> 00:12:24,310
They exist now.

106
00:12:24,310 --> 00:12:29,850
I think that we could definitely learn from BSI's approach, especially since we're in the recommendation phase.

107
00:12:29,850 --> 00:12:35,270
I'm not a regulator, I'm just a security person, but I think this is a really great conversation to have.

108
00:12:35,270 --> 00:12:36,890
And that's where I see that crossover.

109
00:12:38,310 --> 00:12:44,090
So for today, all that said, our major focus is going to be on insulin pumps.

110
00:12:44,090 --> 00:12:56,250
And so for hacking and some of the community efforts and regulatory efforts, we will specifically focus on this type of medical device.

111
00:12:58,070 --> 00:13:09,250
So to get us started, I'm going to provide a brief background for insulin pump devices in general, and also provide a threat model so that way we can start thinking with our security hats.

112
00:13:11,090 --> 00:13:14,030
So to best describe this, Bob's going to help me out.

113
00:13:14,030 --> 00:13:20,090
So Bob has type 1 diabetes, and Bob uses an open loop insulin delivery system to manage his condition.

114
00:13:20,090 --> 00:13:24,010
So it's open loop in that Bob is the person that actually presses the button.

115
00:13:24,270 --> 00:13:32,510
Now, this system is comprised of a continuous glucose monitor, typically CGM, that's the acronym for that, insulin pump, and smartphone.

116
00:13:32,510 --> 00:13:40,950
So what's unique and interesting here is that we have a communication interface that's wireless between the insulin pump and the smartphone.

117
00:13:40,950 --> 00:13:43,430
So they pair, and that's over BLE.

118
00:13:43,450 --> 00:13:54,210
In terms of data flow, the common architecture is that logs can be sent from the insulin pump to the phone, and then commands can be sent from the phone to the insulin pump.

119
00:13:56,940 --> 00:14:10,460
Now, in terms of getting into the exact particulars of the insulin pump composition, as I think it will help understand Julian's part later when he talks about hacking insulin pumps, so we have to understand that it is an embedded system at the end of the day.

120
00:14:10,540 --> 00:14:16,940
So this is, it looks, it's a very common architecture that computer security professionals are familiar with.

121
00:14:16,940 --> 00:14:18,520
There's a system on chip design.

122
00:14:18,520 --> 00:14:20,260
Typically, this is ARM based.

123
00:14:20,260 --> 00:14:22,820
It has a Bluetooth radio.

124
00:14:22,940 --> 00:14:28,140
The idea of the Bluetooth radio is such that we can pair two separate devices speaking the same protocol.

125
00:14:28,200 --> 00:14:33,720
It's typically uses low energy because the pump itself is worn on the patient.

126
00:14:33,720 --> 00:14:35,280
We can't just connect it to a wall.

127
00:14:35,280 --> 00:14:39,340
So we don't have, I don't know, 240 volts to keep it powered.

128
00:14:39,820 --> 00:14:44,280
And so it's, you know, that's what motivates our selection of the communication protocol.

129
00:14:44,280 --> 00:14:47,520
Different pairing connections are supported.

130
00:14:47,520 --> 00:14:49,800
So we have legacy connections or secure connections.

131
00:14:50,000 --> 00:14:53,480
Hopefully, most of our manufacturers are leaning towards secure connections.

132
00:14:53,660 --> 00:14:56,920
Furthermore, there is no, it's bare metal, no operating system.

133
00:14:56,920 --> 00:15:04,680
So there's a, you typically might have a bootloader, but the rest of it is just instructions such that the pump can actuate and also receive data and send data.

134
00:15:05,320 --> 00:15:11,300
In terms of connecting to the other components or understanding what the other assets are in the system, of course, we have our patient.

135
00:15:11,300 --> 00:15:14,540
There's a catheter that connects the patient that delivers the insulin.

136
00:15:14,640 --> 00:15:18,840
And then of interest from a security perspective, we have the smartphone and the pump.

137
00:15:18,840 --> 00:15:21,400
And as I've just said, that connection is over VLT.

138
00:15:24,000 --> 00:15:27,520
So let's start thinking about this in the terms of cybersecurity.

139
00:15:27,740 --> 00:15:29,300
Let's think about the threat model, right?

140
00:15:29,300 --> 00:15:35,620
So first, when we're thinking insulin pumps, we have to understand what the patient harm and non harms are.

141
00:15:35,640 --> 00:15:40,840
So a harm, a patient harm is that the pump delivers too much insulin or maybe not enough insulin.

142
00:15:40,840 --> 00:15:43,940
And this could be detrimental to the overall health of the patient.

143
00:15:43,940 --> 00:15:47,480
And that's considered a patient's harm safety risk.

144
00:15:47,840 --> 00:15:56,280
Non-harm would be the pump, insulin pump leaks some private information about the user to an unauthorized user.

145
00:15:56,280 --> 00:16:00,820
Say maybe it's this passive eavesdropper that's listening on the Bluetooth communication.

146
00:16:00,820 --> 00:16:03,680
And that would be considered a non-harm risk to the patient.

147
00:16:03,680 --> 00:16:16,540
Now, what security researchers do when we're looking at medical devices is that we always apply a threat model approach to understanding what all the risks are to the particular device.

148
00:16:16,540 --> 00:16:20,480
And so what I'm using or what I'll detail here is something called Microsoft Stripe.

149
00:16:20,480 --> 00:16:25,380
And it's a way to categorize risks, and I've applied it to the general insulin pump case.

150
00:16:25,380 --> 00:16:28,820
So first we have spoofing, which is to impersonate a system.

151
00:16:28,820 --> 00:16:34,800
In an insulin pump case, the attacker can masquerade as a valid smartphone.

152
00:16:34,800 --> 00:16:38,700
That would be a spoofing-based attack that we would want to consider.

153
00:16:38,820 --> 00:16:42,240
We also have tampering, which is modifying data or code.

154
00:16:42,240 --> 00:16:46,320
In this particular case, an attacker man-in-the-middle is the pump to smartphone communication.

155
00:16:46,700 --> 00:16:50,380
We have repudiation, claiming to not have performed an action.

156
00:16:50,380 --> 00:16:59,540
And so imagine the scenario where an attacker has successfully man-in-the-middle communication between smartphone and insulin pump, and they're able to, say, inject commands.

157
00:16:59,540 --> 00:17:03,520
Well, the pump is unaware because these are unauthorized, unauthenticated commands.

158
00:17:03,520 --> 00:17:06,660
They can't distinguish between if it was valid or not.

159
00:17:06,660 --> 00:17:14,060
And so if the pump even has a log, it's not going to say, well, this definitely came from Mike's phone, because it has no notion of the sentence.

160
00:17:16,940 --> 00:17:19,540
Continuing on in Stripe, we have information disclosure.

161
00:17:19,540 --> 00:17:22,780
This is exposing information to unauthorized users.

162
00:17:23,240 --> 00:17:27,920
So in this particular case, we can imagine an attacker that eavesdrops on pump-to-smartphone communication.

163
00:17:27,940 --> 00:17:33,860
They're not looking to inject commands, simply see what information they can see going across the wire.

164
00:17:34,600 --> 00:17:37,980
Next, we have denial of service, which is to deny or degrade access.

165
00:17:37,980 --> 00:17:44,380
I always say this is the bane of cybersecurity professionals, because it's really hard to protect against, especially if it's directed.

166
00:17:44,700 --> 00:17:49,020
And then the insulin pump case, this is where the attacker overruns the pump with requests.

167
00:17:49,020 --> 00:17:54,080
Which would deny the valid or authenticated user from using the pump as it's intended.

168
00:17:54,480 --> 00:17:59,960
Lastly, we have elevation privileges, which is to gain access to unauthorized capabilities.

169
00:18:00,280 --> 00:18:15,940
And so when we're thinking about this in terms of insulin pump, we would like to consider an attacker that gains access to the smartphone app, maybe by exploiting a smartphone OS vulnerability, and thus gaining unauthorized access to our insulin pump application,

170
00:18:15,940 --> 00:18:19,420
and then directly impacting the pump operation itself.

171
00:18:20,160 --> 00:18:29,160
So just to be completely encompassing, another step that my team at Harper Labs really likes to take, we have our threat model, but we also have an attacker model.

172
00:18:29,160 --> 00:18:32,160
And the idea here is to understand the attacker's goals and capabilities.

173
00:18:32,160 --> 00:18:43,040
This is where security gets real, because we want manufacturers and the community to understand, well, what is the absolute goal of attacking an insulin pump, for example?

174
00:18:43,040 --> 00:18:44,560
Well, it's to cause patient harm.

175
00:18:44,560 --> 00:18:54,520
If that is really the focus, whenever we're looking at a medical device, we're trying to find vulnerabilities that could actually impact the patient and their safety.

176
00:18:54,800 --> 00:19:02,680
Now, also, an attacker could be, say, just this arbitrary software execution, like malware.

177
00:19:03,300 --> 00:19:05,140
Mirai botnet would be a great example.

178
00:19:05,140 --> 00:19:07,180
That's just trying to pivot into the network.

179
00:19:07,180 --> 00:19:18,420
And so if we're not securing our medical devices that are essentially network endpoints, we may allow a pivot into the network, and then any other unexpected behavior that might come of that, which could still impact patient safety.

180
00:19:18,860 --> 00:19:22,360
And, of course, we have to consider things like the position of the attacker in the system.

181
00:19:22,460 --> 00:19:25,660
Are they an insider manufacturer that knows all the gory details?

182
00:19:25,740 --> 00:19:30,060
Are they simply just a person on the outside with a high-gain antenna and some equipment?

183
00:19:30,400 --> 00:19:38,860
I also wanted to point out, too, in terms of capabilities, since this is BLE, we're looking at maybe 300 US dollars in terms of BLE hacking equipment.

184
00:19:41,000 --> 00:19:45,120
And I'll summarize quickly, because visuals are the best way to depict this.

185
00:19:45,120 --> 00:19:50,280
There are a number of attack surfaces that exist in our general insulin pump model.

186
00:19:50,280 --> 00:19:54,280
We have our physical interface, being able to connect to serial or press buttons.

187
00:19:54,480 --> 00:20:04,400
We have our wireless interface, which is communication that's happening over Bluetooth, which Julian will talk in depth about as the attack surface that he focused on.

188
00:20:04,660 --> 00:20:07,140
And he also focused a bit on the app interface.

189
00:20:07,140 --> 00:20:09,140
So what can the application tell you?

190
00:20:09,140 --> 00:20:10,540
What can you learn from it?

191
00:20:10,540 --> 00:20:17,960
You know, this is another attack surface that an attacker could leverage to compromise an insulin pump.

192
00:20:19,080 --> 00:20:23,540
And so with that, I'll turn it over to Julian to talk about insulin pump hacking.

193
00:20:24,260 --> 00:20:25,220
Thanks.

194
00:20:25,320 --> 00:20:35,860
In the following minutes, I will explain the communication protocol of the Dana Diabica RS insulin pump, which is sold by the Korean manufacturer Soil Developments, as well as vulnerabilities we identified.

195
00:20:35,860 --> 00:20:49,840
I want to state that the presentation of the vulnerabilities shall not be understood as finger-pointing towards the manufacturer, but may shed light on design problems more manufacturers are facing with building interconnected medical devices.

196
00:20:50,080 --> 00:20:58,700
The manufacturer intends patients to use the pump as a central component of an open-loop system in combination with the respective mobile applications.

197
00:20:58,820 --> 00:21:07,920
With these mobile apps' safety-critical functionality of the pump, such as manual administration of boluses or changing the basal rates of profiles is possible.

198
00:21:07,980 --> 00:21:19,320
Besides, patients are creating less restrictive ways in controlling their therapy devices, as, for example, the We Are Not Waiting initiative demonstrated in the past by building closed-loop systems on their own.

199
00:21:19,320 --> 00:21:22,320
We will come back to this later in the talk, I think.

200
00:21:22,320 --> 00:21:30,540
And further, the Dana Diabica RS insulin pump is supported by publicly-awaited looping apps such as Android APS.

201
00:21:33,190 --> 00:21:47,570
The security assessment of medical devices is highly specialized and is dependent on the device's medical use case, present interfaces, users and their backgrounds, use technologies, but also assumptions, for example, to its environment.

202
00:21:47,930 --> 00:21:56,550
In scope of the test was the proprietary communication protocol between the insulin pump and its mobile applications, which was built on top of Bluetooth Low Energy.

203
00:21:56,550 --> 00:22:02,070
So the Bluetooth Low Energy capabilities were just used to implement some application-related protocol.

204
00:22:02,070 --> 00:22:11,710
In a special, the assessment focused on the used and implemented cryptography, as well as on the authentication and pairing process between the pump and its mobile apps.

205
00:22:11,850 --> 00:22:24,270
The testing methodology was a black-box test without source code inside, and we were voluntarily provided with two insulin pumps by the manufacturers and downloaded the mobile applications from the App Store and the Google Play Store.

206
00:22:27,860 --> 00:22:33,760
I will first demonstrate the normal communication flow we observed between the pump and its mobile applications.

207
00:22:33,760 --> 00:22:37,160
We will start with the application layer pairing process.

208
00:22:37,320 --> 00:22:44,620
The first byte demonstrates whether the message is a request with 0.1 or a response with 0.2.

209
00:22:44,700 --> 00:22:53,160
We will talk about the names of the keys that are used on the following slides, so don't hesitate to identify all the keys and understand their usage.

210
00:22:53,160 --> 00:22:54,600
So we will come to this.

211
00:22:55,140 --> 00:23:00,620
This and similar figures will present the different encryption layers with different colors.

212
00:23:00,620 --> 00:23:04,980
Yellow color states that this information is transmitted in plain.

213
00:23:04,980 --> 00:23:09,620
Blue color shows that the messages need to be encrypted using the device key.

214
00:23:09,620 --> 00:23:18,360
And red color is showing that user interaction is needed, as well as green color indicates that messages need to be encrypted using free keys.

215
00:23:18,580 --> 00:23:26,900
Every communication starts with the mobile app sending a 0100 message to the pump together with its serial number.

216
00:23:26,900 --> 00:23:32,480
The pump indicates that the serial is matching and afterwards the pairing is requested.

217
00:23:32,840 --> 00:23:40,640
The pump immediately answers the request and shows a pairing prompt on its display, which needs to be confirmed manually by pressing a key on the pump.

218
00:23:40,760 --> 00:23:43,580
A photo of this pairing prompt can be seen here.

219
00:23:46,320 --> 00:23:57,440
After having a user confirming the pairing, the pump sends the pairing key to the mobile application, which then may use the key to encrypt messages after requesting a session key.

220
00:23:57,440 --> 00:24:02,900
With these free keys, higher-privileged requests, such as ballast administration, may be performed.

221
00:24:03,140 --> 00:24:06,420
For now, the free keys may be a bit confusing.

222
00:24:06,420 --> 00:24:12,120
I believe that it becomes way more clear when seeing the post-pairing communication flow.

223
00:24:12,120 --> 00:24:21,200
The next time the pump and the app are communicating, no user interaction is needed, as the app only needs to send a pairing key to show that both entities are already paired.

224
00:24:21,440 --> 00:24:26,140
After requesting a new session key, high-privileged requests can be sent.

225
00:24:26,140 --> 00:24:28,540
Here we see the free keys again.

226
00:24:28,600 --> 00:24:30,960
The device key is used to encode all messages.

227
00:24:30,960 --> 00:24:35,940
The pairing key and the session key are used to authenticate the session, which is shown in green.

228
00:24:36,840 --> 00:24:43,120
An interesting find works that the communicating party does not need to be paired to extract the PIN.

229
00:24:43,260 --> 00:24:44,880
This is shown in the next slide.

230
00:24:45,920 --> 00:24:50,860
The PIN is not directly transmitted, but can be calculated with the information transmitted.

231
00:24:50,860 --> 00:24:59,380
We omitted the respective formula not to give some more insights on the protocol, because we do not want to have you building exploits for this.

232
00:24:59,380 --> 00:25:12,040
This enables adhocs to extract the lock key PIN, and every Dana RS pump in the adhocs range, Bluetooth range, is possible to be read out.

233
00:25:12,040 --> 00:25:16,860
The next finding we want to elucidate is about weakly generated encryption keys.

234
00:25:16,860 --> 00:25:23,080
The device key is derived from the pump's serial number, does not contain any randomizing element, and will never change.

235
00:25:23,200 --> 00:25:26,660
The serial number can be obtained from BLE advertisements.

236
00:25:27,100 --> 00:25:31,320
The session key can be calculated from the pump's lock PIN as well as configured time.

237
00:25:31,340 --> 00:25:34,660
We saw the respective request on the previous slide with the PIN disclosure.

238
00:25:34,940 --> 00:25:43,020
Having these three occurrences of doubtful calculations of secrets, we further investigated all the other keys and recognized that also the pairing key is not random.

239
00:25:43,020 --> 00:25:48,340
This key is calculated on the pump, so we had no ability to reverse this calculation.

240
00:25:48,380 --> 00:25:57,280
Though we wrote a script that requested pairing multiple times a second, and saw that the same key will be returned in a second.

241
00:25:57,340 --> 00:26:07,220
Therefore, we tried multiple combinations of calculations, and finally found the formula to calculate the pairing key being derived from the pump's time during pairing.

242
00:26:07,220 --> 00:26:11,680
So it's fixed, as the key is calculated from the time of the pairing.

243
00:26:11,680 --> 00:26:16,520
As a result, any secret of the Dana-RS system is generated insecurely.

244
00:26:16,520 --> 00:26:21,460
In addition to the lock PIN disclosure, no active verification of the pump's identity is present.

245
00:26:21,460 --> 00:26:26,960
Therefore, attackers can spoof both communication partners and therefore get in many the middle position.

246
00:26:26,960 --> 00:26:35,520
How realistic this is with Bluetooth Low Energy is up to you, because I want to present a more easy attack for later.

247
00:26:35,520 --> 00:26:37,960
Another example is the missing replay protection.

248
00:26:37,960 --> 00:26:42,200
By checking the Bluetooth Low Energy session, attackers may replay sniffed messages.

249
00:26:42,480 --> 00:26:48,640
But still, the most easy way to issue trusted commands is to capture a single communication flow between the pump and an app.

250
00:26:48,640 --> 00:26:51,240
We will get into this on the next slide.

251
00:26:54,120 --> 00:27:01,340
As we already have seen, the whole authentication mechanism relies on encryption using multiple keys.

252
00:27:01,460 --> 00:27:12,760
This pairing key is the only key that is needed to issue higher privileged commands, as the session key can be requested by anyone and as the device key is known to everyone without even connecting to the pump.

253
00:27:13,120 --> 00:27:20,080
When having a look at the authentication flow, the pairing key is transmitted being encrypted with the device key as marked in the red box.

254
00:27:20,180 --> 00:27:25,920
This encryption is completely deterministic and everyone sniffing the communication is able to extract this key.

255
00:27:26,000 --> 00:27:28,720
We will not show how the encryption works in detail.

256
00:27:31,700 --> 00:27:40,440
The weak pins are low-hanging fruit and only pose a risk for attackers with physical access to the pump, as our threat model already showed that Mike presented.

257
00:27:40,440 --> 00:27:49,100
The communication of the vulnerabilities in the communication protocol empowers attackers to hijack the pump and use all functionalities that are offered via Bluetooth Low Energy.

258
00:27:49,240 --> 00:27:56,900
To exploit this, an attacker needs to be in proximity to the pump, sniffing a single communication between the insulin pump and the paired mobile application.

259
00:27:56,900 --> 00:28:02,000
This attack can be performed automatically in productive environments and we want to demonstrate this.

260
00:28:02,000 --> 00:28:07,480
The manufacturer prepared an update for the pump fixing the vulnerabilities, but let us first have the demo.

261
00:28:09,400 --> 00:28:15,340
Now I'd like to present you the attack in a short video demonstrating the criticality of the automated attack.

262
00:28:15,340 --> 00:28:17,640
A few words I needed to explain the video.

263
00:28:17,680 --> 00:28:25,320
In the following video, an attacker captures messages between an insulin pump, a mobile app, and extracts the key from this communication.

264
00:28:25,320 --> 00:28:35,700
He hijacks and terminates the session between the pump and its paired app, creates a new session impersonating the app using the parent key and administers multiple insulin boluses.

265
00:28:36,180 --> 00:28:43,980
I was just clicking on a pump to reactivate the display, so there's no need to have this interaction at this point.

266
00:28:44,120 --> 00:28:50,420
The patient may notice the administration and is able to cancel the single administration on the pump.

267
00:28:50,420 --> 00:28:55,120
But as you can see in the following, more boluses are following.

268
00:28:57,560 --> 00:29:04,960
I filled the whole tubing system with blue ink so you can see that in real life this would have been insulin.

269
00:29:06,580 --> 00:29:17,300
As you can see, the patient is trying to cancel all the administrations one after another, but just another administration will follow this until the attacker stops.

270
00:29:17,440 --> 00:29:20,800
Wow, Julian, thank you for the stunning video.

271
00:29:20,800 --> 00:29:22,960
I'm always impressed when I see it.

272
00:29:22,960 --> 00:29:32,460
When we now draw a conclusion from what we just heard, we can say that most of the vulnerabilities found are design defects.

273
00:29:33,160 --> 00:29:36,900
The manufacturer collaborated at all time with us.

274
00:29:36,900 --> 00:29:43,620
He prepared and provided an update, as Julian already said, and that was rolled out in April 2020.

275
00:29:43,620 --> 00:29:50,700
So the whole process was accompanied by an FSN, which was published on our regulatory's website.

276
00:29:50,700 --> 00:29:57,100
An example of this from a UK regulatory authority in English is shown on the right.

277
00:29:57,380 --> 00:30:12,340
Although we found vulnerabilities that are affecting the communication between the pump and the app, the device could still be operated when disabling Bluetooth functionality as a temporary fix.

278
00:30:12,340 --> 00:30:21,560
As mentioned in the FSN, the device can be securely operated when the airplane mode is enabled, thereby preventing its functionality.

279
00:30:21,980 --> 00:30:28,100
Moreover, the device has several safety features already implemented preventing from a misuse.

280
00:30:28,420 --> 00:30:37,280
In summary, the pump could be used when the airplane mode was enabled to prevent potential risk when we discovered these vulnerabilities.

281
00:30:37,280 --> 00:30:42,740
But I guess you're not only interested in the disclosure itself, but in the timeline.

282
00:30:42,740 --> 00:30:48,640
So, as stated before, we aim to lift cybersecurity and act accordingly.

283
00:30:48,660 --> 00:30:55,160
In our opinion, a coordinated vulnerability disclosure process is desired whenever findings are reported.

284
00:30:55,160 --> 00:31:00,520
We use usually 90 days and give an extension upon a justified reason.

285
00:31:00,740 --> 00:31:05,940
Julian, me and our team colleagues managed and coordinated the whole disclosure process.

286
00:31:05,940 --> 00:31:17,260
We believe that it's essential to identify vulnerabilities in medical devices in an ethical way to strengthen cybersecurity, consumer protection, and patient safety.

287
00:31:17,320 --> 00:31:23,220
Thereby, we all maintain a basis of trust to allow for mutual exchange and efficient communication.

288
00:31:23,600 --> 00:31:27,920
As mentioned before, I have no intention to blame anyone here.

289
00:31:27,920 --> 00:31:37,740
As a project team, we believe that ethical publishing of vulnerabilities is possible, thereby increasing transparency and the willingness to update devices in time.

290
00:31:37,860 --> 00:31:45,260
However, it has to be ensured at all time that the publication does not pose serious harm to patients.

291
00:31:45,320 --> 00:31:52,780
In our case, short-term measures and workarounds exist and existed, and an innovative device was not withdrawn from the market.

292
00:31:52,780 --> 00:32:01,180
I believe that security and safety are not contradicting each other and that secure connected devices are pioneering.

293
00:32:01,260 --> 00:32:02,280
Awesome work, guys.

294
00:32:02,420 --> 00:32:04,400
Especially, I like to see the ink on the napkin.

295
00:32:04,400 --> 00:32:06,280
Every time I see it, it's so amazing.

296
00:32:06,380 --> 00:32:18,540
But then to follow it up with the process of, you know, patient safety being paramount, not pulling the device, but working directly with the manufacturer and having a great story about it is all the more compelling for the work that we do.

297
00:32:18,540 --> 00:32:21,340
So I commend the team for great, great effort there.

298
00:32:21,340 --> 00:32:21,880
Great work.

299
00:32:21,880 --> 00:32:22,820
Great job.

300
00:32:23,320 --> 00:32:30,660
With that, I'm going to segue the remainder of the talk into the impact of hacking on DIY diabetic community.

301
00:32:31,260 --> 00:32:44,560
Now, the way that we've tied this together, because Julian and Dina had disclosed, as an anecdote to me, their process with Dana RS, the pump, and then the remediation effort.

302
00:32:44,560 --> 00:32:50,480
And that remediation effort had caused some issues with Android APS compatibility.

303
00:32:51,420 --> 00:32:54,020
And so let me define that first.

304
00:32:54,020 --> 00:32:58,920
Android APS is just open source application that's used to create an artificial pancreas system.

305
00:32:58,920 --> 00:33:01,540
That's where the APS acronym comes from.

306
00:33:02,300 --> 00:33:07,020
And an APS system just delivers insulin injections on the patient's behalf.

307
00:33:07,020 --> 00:33:08,340
So it's completely automated.

308
00:33:08,340 --> 00:33:11,980
It's also called a closed loop system in case anyone's interested.

309
00:33:11,980 --> 00:33:20,920
Now, there's an entire open source and DIY diabetics community that was well invested into creating these artificial pancreas systems.

310
00:33:21,060 --> 00:33:24,200
And they were integrating and working.

311
00:33:24,200 --> 00:33:29,000
So the manufacturers, Dana RS, actually worked with Android APS.

312
00:33:29,000 --> 00:33:31,840
So there was that nice sort of community overlap.

313
00:33:31,840 --> 00:33:43,300
And of course, when the hack happened, and there's some remediation processes and steps, this caused a disconnect with the community, because there needs to be a rework, right?

314
00:33:43,300 --> 00:33:49,580
There needs to be a manufacturing community sitting down to understand, well, how could these two things still continue to work together?

315
00:33:49,920 --> 00:33:52,580
And so I have some thoughts about this.

316
00:33:52,580 --> 00:34:01,120
I'm going to put them forward for everyone watching our panel to also formulate their own opinions and hopefully come up with some stuff in the Q&A.

317
00:34:01,120 --> 00:34:04,220
Before I do that, I just want to make a public service announcement.

318
00:34:04,440 --> 00:34:11,720
Everyone in this panel supports the DIY diabetics community, their hard work, their dedication, and just advancing the technology.

319
00:34:11,720 --> 00:34:18,740
I mean, wow, these artificial systems, like regulatory barriers, have really caused this to not be a thing.

320
00:34:18,740 --> 00:34:21,760
And I think the DIY community just pushed so hard to make it happen.

321
00:34:21,760 --> 00:34:22,680
So that's great.

322
00:34:22,680 --> 00:34:30,200
To give everyone else that's listening an idea, I've cribbed some data from the OpenAPS website.

323
00:34:30,340 --> 00:34:37,900
And as of May of 2020, there's at least almost 12,000 people reporting to use these DIY systems.

324
00:34:37,900 --> 00:34:40,540
And these are just people that actually report that they're using the system.

325
00:34:40,540 --> 00:34:43,600
It doesn't cover people that are not reporting, for example.

326
00:34:43,600 --> 00:34:57,720
And if we take a look at the graph that I've also cribbed from OpenAPS, we see that there's this nice reduction in A1Cs, which if you're a diabetic, your target A1C, you'd want it to be closer to six.

327
00:34:57,720 --> 00:35:02,400
It's indicative of just better overall health outcomes.

328
00:35:03,860 --> 00:35:06,740
So now I pivot to the next point.

329
00:35:06,740 --> 00:35:19,460
The current DIY community has leveraged vulnerabilities, quite frankly, of insulin pump devices to be able to construct their solutions.

330
00:35:19,460 --> 00:35:38,200
Simply to say, they've used insulin pumps that have open and known vulnerabilities that have been well known, such that they could use that system and bootstrap on some applications and some back-end servers and a communication protocol to make their systems function.

331
00:35:38,200 --> 00:35:44,900
And so this is worrying from a cybersecurity professional's perspective because its foundation is built on antiquated hardware.

332
00:35:44,900 --> 00:35:47,520
It's no longer supported by the manufacturer.

333
00:35:47,520 --> 00:36:01,140
Outdated firmware, insecure reverse-engineered device communications, and in some cases even requires hardware adapters or shims, so another device, to be able to send and receive communication.

334
00:36:01,140 --> 00:36:09,980
And so this DIY solution, while it was great when it first came out, it lacks a formalized threat model.

335
00:36:10,000 --> 00:36:18,720
I haven't seen anywhere in the community yet where someone went through the steps of providing, say, Stride and understanding all the risks.

336
00:36:18,900 --> 00:36:21,940
And let me also put a caption on that.

337
00:36:21,940 --> 00:36:31,120
I have talked to the community before, and one of the colleagues or people in the community said, well, we do understand the risks, and that's fine.

338
00:36:31,120 --> 00:36:40,260
But at the same time, I want to just kind of elevate that, so that way we can understand, okay, we get it, there are security risks, what's the best way forward?

339
00:36:41,020 --> 00:36:53,320
And I think the best way forward is definitely to work with manufacturers, like the manufacturer of the Dana-RS, and not to continue to rely on these insecure foundations and antiquated systems.

340
00:36:55,160 --> 00:36:58,720
So, as I alluded to, this is not late-breaking news.

341
00:36:58,720 --> 00:37:03,080
The DIY community knows about these issues, and we can actually see it pretty easily.

342
00:37:03,080 --> 00:37:23,880
So, if you go to OpenAVS's website and you pull their architecture diagram, well, this is more of a data flow, but if you pull this particular diagram, the first thing we note, which I have denoted in the red thatched rectangle, is that the models of Medtronic devices that they require are old hardware that Medtronic no longer supports,

343
00:37:23,880 --> 00:37:26,780
the 512, 515, and 522 models.

344
00:37:26,780 --> 00:37:42,000
Furthermore, if you have their newer equivalents, you actually have to rely on outdated firmware, because what happens, Medtronic patched the vulnerabilities that allowed the device communication to happen unauthenticated in the first place, and therefore,

345
00:37:42,000 --> 00:37:47,900
you can only have the older version of the software in the device to be able to integrate it into this open solution.

346
00:37:49,160 --> 00:38:01,380
Furthermore, as a sort of a side point, there's also a look on Craigslist to find medical devices, which always kind of makes me worried, eBay and Craigslist medical devices, but I'll leave that there.

347
00:38:01,380 --> 00:38:05,760
I'm a cybersecurity person, not a medical person, so I have no advice for that.

348
00:38:07,120 --> 00:38:16,740
Kind of furthering the point on, if you're not well aware of the Medtronic devices that I enumerated, there's an ICS medical advisory on these particular devices.

349
00:38:16,740 --> 00:38:29,620
And as you can see, this was released, what, 2019, but it covers a large number of Medtronic pumps, of which OpenAPS uses some of those devices to implement their system.

350
00:38:32,140 --> 00:38:34,800
So, I wanted to take an additional step.

351
00:38:34,800 --> 00:38:45,420
It's one thing to look at the architecture and the data that's already available, provided by the community, but I also wanted to understand, the source code was open and available.

352
00:38:45,420 --> 00:38:53,320
So, I wanted to run a stack analysis against the source code to kind of understand what vulnerabilities may exist there.

353
00:38:53,320 --> 00:39:02,120
Now, as an aside, and it's to all the security people, yes, we all understand that stack analysis tools give false positives and false negatives.

354
00:39:02,120 --> 00:39:11,240
It really comes down to the security professional taking the time to follow up and understand if those are actual weaknesses and vulnerabilities.

355
00:39:11,240 --> 00:39:17,180
That being said, I was able to quickly use SonarQube, which is freely available, they have a community edition.

356
00:39:17,340 --> 00:39:25,700
Scan the OpenAPS source code that's also available and open on GitHub, and to be able to identify some security hotspots.

357
00:39:26,240 --> 00:39:36,040
And in particular, there are a number of high vulnerabilities with respect to command injection, because there's a large number of Python and shell scripts that take inputs from the command line.

358
00:39:36,040 --> 00:39:41,200
And these things are not being adequately validated or verified, so there's no input sanitization.

359
00:39:41,240 --> 00:39:58,560
And because these scripts and code are executed as a root user, if an attacker was to take advantage of this vulnerability, this weakness, they could achieve root access on the devices that make up the OpenAPS system.

360
00:40:00,460 --> 00:40:09,040
So to understand that a little bit better, OpenAPS just happens to be one of the systems that involves one of those shims or adapters that I talked about.

361
00:40:09,040 --> 00:40:12,400
And in particular, they're using a Raspberry Pi.

362
00:40:12,460 --> 00:40:16,900
Now, the Raspberry Pi is this nice single board computer, but it has a lot of different interfaces.

363
00:40:16,900 --> 00:40:25,280
It has a wireless interface and Bluetooth so that it can communicate over the network, which makes a great adapter to make an OpenAPS type of system work.

364
00:40:25,440 --> 00:40:30,720
But it comes with additional properties that shouldn't really exist here.

365
00:40:30,720 --> 00:40:36,480
It has a full Linux operating system, which comes with all the complexities of managing the security of an operating system.

366
00:40:36,480 --> 00:40:44,320
For example, firewall configuration or managing access and server service level accesses to files and data.

367
00:40:45,180 --> 00:40:49,920
And it requires remote access or root remote access just to function.

368
00:40:49,920 --> 00:40:55,820
And so this is usually the security 101 things that we'll talk about and say, well, you should never allow root remote access.

369
00:40:55,820 --> 00:41:00,460
And it just so happens it's a system, you know, you need to leverage it to make it function.

370
00:41:01,700 --> 00:41:09,780
So to wrap up all of what I was saying about the DIY community and, you know, hacking and efforts from Julian's team, etc.

371
00:41:09,960 --> 00:41:18,180
Is that what's nice is that DIY started it and they had these solutions and they were using pumps and whatever they could to meet their ends.

372
00:41:18,180 --> 00:41:19,140
And that's fantastic.

373
00:41:19,140 --> 00:41:20,440
They really pushed the envelope.

374
00:41:20,440 --> 00:41:35,140
But now we're seeing manufacturer involvement, where they want to be able to expose secure interfaces to help leverage this communication to do it in a way that's going to mitigate, say, remote attacks or eavesdropping, man in the middle, etc.

375
00:41:35,140 --> 00:41:44,500
And I think that I would like for there to be a larger conversation with regulators, policymakers, manufacturers, and of course the community.

376
00:41:44,500 --> 00:41:55,280
I think this is already happening because, you know, I can't be well aware of all the conversations, but, you know, they're, they're just very straightforward foundational issues with the stuff in the past.

377
00:41:55,280 --> 00:41:57,440
And I'm really hopeful that going forward.

378
00:41:57,440 --> 00:41:59,660
There's just a better answer and a better solution.

379
00:42:01,280 --> 00:42:01,600
All right.

380
00:42:01,600 --> 00:42:07,680
With that, I will leave some concluding remarks to Dina for the MoneyMed release.

381
00:42:07,680 --> 00:42:09,560
Yeah, thank you very much.

382
00:42:09,560 --> 00:42:19,740
So here comes a small teaser about our MoneyMed release, because the insulin pump is actually not the only product that was assessed during the scope of the project.

383
00:42:19,760 --> 00:42:25,520
So our project results will be published in German and English in December 2020.

384
00:42:25,520 --> 00:42:27,900
And I hope you're all waiting for this.

385
00:42:27,900 --> 00:42:31,700
So our final report will include the findings presented here.

386
00:42:31,700 --> 00:42:37,340
And as I said, those from the remaining devices, but not on a technically deep level.

387
00:42:37,340 --> 00:42:37,940
Why?

388
00:42:37,940 --> 00:42:43,400
Because we want to allow basically everyone to read and understand our project results.

389
00:42:43,400 --> 00:42:53,880
All manufacturers have to review or can review their respective sections prior to our publication and decide whether to be named.

390
00:42:53,880 --> 00:43:03,820
In the final report, we will demonstrate how we cooperated with different manufacturers and dealt with individual vulnerabilities and their disclosure.

391
00:43:03,820 --> 00:43:10,640
And this report will provide and probably inspire you with our lessons learned.

392
00:43:10,780 --> 00:43:18,620
And the overall intention, as I already said, is to improve cybersecurity without finger pointing at anyone or anything.

393
00:43:18,840 --> 00:43:28,360
We want people to get a feeling for vulnerabilities and to ideally have a sustainable effect on the cybersecurity of medical devices with our project.

394
00:43:28,380 --> 00:43:32,520
And we are willing to do more research in that field.

395
00:43:32,520 --> 00:43:33,620
Thank you.

396
00:43:36,070 --> 00:43:39,430
And I'll conclude with some future research.

397
00:43:39,630 --> 00:43:48,010
The entire team, our panels, are interested in contributing to security as a software development lifecycle best practices to the DIY community.

398
00:43:48,010 --> 00:43:54,370
Also just understanding threat modeling those devices in the DIY community as well.

399
00:43:54,370 --> 00:43:56,930
And pursuing additional medical device research.

400
00:43:56,930 --> 00:44:01,410
So it may not be just diabetes technology, as Dina pointed out.

401
00:44:01,410 --> 00:44:07,710
But just holistically all medical devices, especially ones that are connected or network connected.

402
00:44:07,710 --> 00:44:10,330
And with that, we would like to take some questions.