1
00:00:00,000 --> 00:00:02,540
Hello, my name is Bill Daugherty.

2
00:00:02,580 --> 00:00:05,440
I'm the CISO of Omada Health.

3
00:00:05,440 --> 00:00:09,160
Joining me today is Patrick Curry, our Senior Director of Compliance.

4
00:00:09,160 --> 00:00:13,400
And today we're going to talk about threat modeling in digital health care.

5
00:00:13,520 --> 00:00:20,200
Patrick and I are the co-authors of the Includes No Dirt threat model, which we'll be discussing today.

6
00:00:20,620 --> 00:00:26,700
If you'd like to follow along with us, you can go to includesnodirt.com and download our white paper on that threat model.

7
00:00:26,700 --> 00:00:30,820
We've also got some specific exhibits that we've created just for this discussion.

8
00:00:31,120 --> 00:00:35,900
That's at includesnodirt.com slash defcon.pdf.

9
00:00:36,020 --> 00:00:40,840
And thank you for paying attention and watching our talk here today.

10
00:00:40,840 --> 00:00:53,880
Standard disclaimer, we have put together a discussion that is based on some real-world concepts, but this is not a real-world situation.

11
00:00:53,880 --> 00:01:07,100
So any information we share today should not be construed as being related to the products or services of our employer, Omada Health, or any of our partners or our customers.

12
00:01:07,140 --> 00:01:09,760
Now, if that's out of the way, we can dive into it.

13
00:01:10,480 --> 00:01:12,400
A little bit of background on us.

14
00:01:12,400 --> 00:01:14,920
Omada Health is a digital health care company.

15
00:01:14,920 --> 00:01:17,200
And what is digital health care really?

16
00:01:17,200 --> 00:01:26,720
It is the combination of technology and clinical expertise and humans to deliver better health outcomes.

17
00:01:26,720 --> 00:01:31,440
And we've been doing this for about nine years now, I think.

18
00:01:31,440 --> 00:01:35,100
And we really focus on digital care made human.

19
00:01:35,100 --> 00:01:39,160
So it's not just the machine that you're interacting with.

20
00:01:39,520 --> 00:01:42,020
We do it a little bit differently.

21
00:01:43,020 --> 00:02:01,640
We try to partner up devices, applications, with remote monitoring, and specialists who can provide assistance in our specific diseases to help improve health outcomes.

22
00:02:01,640 --> 00:02:24,900
And we do that through behavior change, remote monitoring with digital devices, care delivery, lab diagnostics, medication tracking, and a whole bunch of back-end systems that are necessities in health care, like outreach to patients, enrollment and eligibility,

23
00:02:24,900 --> 00:02:25,980
billing and reporting.

24
00:02:25,980 --> 00:02:29,520
That's all of the messy stuff behind the scenes.

25
00:02:29,520 --> 00:02:39,850
We have four diseases that have been kind of our core, which is type 2 diabetes prevention, type 2 diabetes treatment, hypertension.

26
00:02:40,420 --> 00:02:45,500
And last year, we added behavioral health, so treating anxiety and depression.

27
00:02:45,500 --> 00:02:56,710
Recently, we just bought a company called Physera that does digital physical therapy, so for muscular, skeletal, or pain treatment.

28
00:02:57,080 --> 00:02:58,660
So that's us.

29
00:02:58,660 --> 00:03:01,400
We're going to talk today a little bit about Sam.

30
00:03:01,400 --> 00:03:07,500
Sam is representative of a real participant in our program.

31
00:03:07,500 --> 00:03:08,740
She is not real.

32
00:03:09,280 --> 00:03:18,180
But Sam would be a participant who has type 2 diabetes and is using our program to try to better manage her disease state.

33
00:03:18,180 --> 00:03:21,840
And she does that through tracking her blood values.

34
00:03:21,840 --> 00:03:24,400
That information gets shared with her coach.

35
00:03:24,400 --> 00:03:37,200
Her coach is then giving her advice on meals and exercise and potentially talking about her insulin levels, things like that.

36
00:03:37,360 --> 00:03:40,860
And ultimately, what we're driving towards is behavior change.

37
00:03:40,860 --> 00:03:49,000
We're trying to give our participants lifestyle improvements that will help them better manage their chronic diseases.

38
00:03:49,000 --> 00:03:57,680
And we're going to come back to Sam and how she's managing her diseases in a little bit in the context of a threat model.

39
00:03:57,940 --> 00:03:59,400
But this is what OMADA does.

40
00:03:59,400 --> 00:04:01,160
We do whole person health care.

41
00:04:01,680 --> 00:04:10,960
And we do this with connected devices and lesson plans and coaching and all kinds of stuff.

42
00:04:10,960 --> 00:04:12,780
And we do a lot of it.

43
00:04:12,980 --> 00:04:18,360
We have, since our inception, served more than 350,000 participants.

44
00:04:18,360 --> 00:04:22,560
We have over 1,000 satisfied customers.

45
00:04:22,560 --> 00:04:31,820
And one of the largest data sets in behavioral health, as of last week, we had over 80 million weigh-ins from our digital connected scales.

46
00:04:31,820 --> 00:04:35,660
And our participants really seem to like our program.

47
00:04:35,660 --> 00:04:37,780
We have a 92% CSAT.

48
00:04:38,220 --> 00:04:39,680
So that's enough about OMADA.

49
00:04:39,680 --> 00:04:46,060
We shared that with you because we want you to understand who we are and why we came to do this.

50
00:04:46,060 --> 00:04:48,160
So why should we do threat models?

51
00:04:49,720 --> 00:04:53,900
Patrick and I started this about two years ago.

52
00:04:55,160 --> 00:04:58,360
In health care, we are required to do annual risk assessments.

53
00:04:58,360 --> 00:05:01,340
The problem with that is nobody ever tells you how.

54
00:05:01,340 --> 00:05:03,040
And we've been doing them for a couple of years.

55
00:05:03,040 --> 00:05:07,020
And we decided that we needed to up our game.

56
00:05:07,020 --> 00:05:19,900
And the reason we needed to up our game is because we were doing kind of a typical risk assessment process where we'd sit in a room and we'd just think about things that could go wrong and then we'd assess our risks.

57
00:05:20,940 --> 00:05:29,240
And the reality about all things in security and compliance is everybody's got to plan until they step into the ring and the first punch comes.

58
00:05:29,300 --> 00:05:30,560
And then your plans go to hell.

59
00:05:30,560 --> 00:05:32,680
And we knew we had blind spots.

60
00:05:32,980 --> 00:05:34,980
And we wanted to get rid of those blind spots.

61
00:05:34,980 --> 00:05:37,520
I love this cartoon, by the way.

62
00:05:38,360 --> 00:05:41,920
On the left side, this is typically how we would deal with things in health care.

63
00:05:41,920 --> 00:05:47,140
We're going to encrypt the laptop because HIPAA says that all the data has to be encrypted at rest.

64
00:05:47,220 --> 00:05:54,200
And then what would actually happen is somebody would force us to reveal our password anyway.

65
00:05:56,100 --> 00:06:00,080
Every time we give a talk on this, we update this slide.

66
00:06:00,080 --> 00:06:07,360
And sadly, I'm never out of companies that have had major breaches in the last six months to update.

67
00:06:08,080 --> 00:06:12,340
But these are examples of really bad things that have happened.

68
00:06:12,340 --> 00:06:17,220
Health care is by far the number one most breached industry, but everybody gets breached.

69
00:06:17,220 --> 00:06:37,100
And the underlying factor for all of these companies is they all had really, really good, smart security teams that were working really hard, that had lots of controls and lots of vendors and lots of stuff in place to try to protect their systems.

70
00:06:37,100 --> 00:06:38,960
And yet they still had problems.

71
00:06:38,960 --> 00:06:41,940
And the reason they had problems is because they had blind spots.

72
00:06:41,940 --> 00:06:48,520
So threat modeling is a way to try to eliminate some of those blind spots.

73
00:06:50,500 --> 00:06:58,100
And the fundamental truism in our business is nobody ever says thank you for the work you did to prevent the disaster that never happened.

74
00:06:58,100 --> 00:07:03,460
So there's no A for effort here.

75
00:07:03,480 --> 00:07:12,320
But doing threat modeling and doing them consistently will, over time, improve your security and your compliance and your privacy.

76
00:07:12,860 --> 00:07:15,900
And it is by far the right thing to do.

77
00:07:16,120 --> 00:07:17,900
So let's define it a little bit.

78
00:07:17,920 --> 00:07:21,840
In order to really talk about this, we have to have a taxonomy.

79
00:07:21,840 --> 00:07:23,420
We have to all be using the same language.

80
00:07:23,420 --> 00:07:26,260
Lots of people interchange the word threat with risk.

81
00:07:26,260 --> 00:07:28,080
We do that, too, accidentally.

82
00:07:28,080 --> 00:07:30,340
But we had to come to a common language.

83
00:07:30,340 --> 00:07:36,380
And when Patrick and I were working on this model, we were using the same word to mean different things.

84
00:07:36,380 --> 00:07:38,340
So we eventually wrote it down.

85
00:07:38,900 --> 00:07:40,380
This is our taxonomy.

86
00:07:40,460 --> 00:07:41,980
First thing is a system.

87
00:07:41,980 --> 00:07:45,520
And a system is anything you want to model.

88
00:07:45,780 --> 00:07:50,320
Lots of threat modeling focuses on applications, on software.

89
00:07:50,320 --> 00:07:56,340
And that is certainly a system that can be modeled, but so can a business process or a network or a vendor.

90
00:07:56,900 --> 00:08:04,140
And the defining characteristic of it is we want to protect it from specific threats.

91
00:08:04,500 --> 00:08:09,140
We just did our annual risk assessment and just completed it.

92
00:08:09,140 --> 00:08:13,740
And this time around, we modeled 26 business processes end-to-end.

93
00:08:13,740 --> 00:08:17,460
So systems typically have defined borders.

94
00:08:17,460 --> 00:08:20,160
You know what the entry point into the system is.

95
00:08:20,160 --> 00:08:21,400
You know what the exit is.

96
00:08:21,760 --> 00:08:24,660
And you can then model it for threats.

97
00:08:25,040 --> 00:08:31,140
Those borders are sometimes called trust boundaries, which are areas where principles can interact.

98
00:08:31,480 --> 00:08:34,520
Sometimes they're called attack surfaces.

99
00:08:36,500 --> 00:08:44,380
The key point is understanding all of the areas that an attack or a risk or a threat can come from.

100
00:08:45,020 --> 00:08:47,520
Vulnerability is a weakness in your system.

101
00:08:47,520 --> 00:08:49,720
Vulnerabilities are things that can be exploited.

102
00:08:49,720 --> 00:08:53,200
So if you have a weak password policy, that is a vulnerability.

103
00:08:53,200 --> 00:08:54,340
It can be exploited.

104
00:08:54,340 --> 00:08:57,700
If you leave your front door unlocked, that is a vulnerability.

105
00:08:57,900 --> 00:09:04,300
That doesn't actually mean that someone will breach your password or open your door, but it is vulnerable for exploitation.

106
00:09:04,820 --> 00:09:07,380
A threat is an actor.

107
00:09:07,640 --> 00:09:09,940
A threat can be a person.

108
00:09:09,940 --> 00:09:13,220
It can be an employee of a third party.

109
00:09:13,220 --> 00:09:15,460
It could be its own business process.

110
00:09:15,460 --> 00:09:17,020
It could be a piece of code.

111
00:09:18,720 --> 00:09:22,460
And threats exploit vulnerabilities.

112
00:09:22,460 --> 00:09:27,360
And we call that an attack vector in our taxonomy.

113
00:09:27,800 --> 00:09:35,300
Risk in this world, then, is the bad outcome that results when a threat exploits a vulnerability.

114
00:09:35,300 --> 00:09:39,700
And we can then measure risks by measuring the likelihood of it happening.

115
00:09:39,700 --> 00:09:41,260
That's the probability.

116
00:09:41,380 --> 00:09:46,280
And the impact, or the cost, if it does happen, that's the impact.

117
00:09:47,300 --> 00:09:49,960
And that's typically how people think about risks.

118
00:09:50,440 --> 00:09:52,260
You'll see this often.

119
00:09:52,400 --> 00:09:59,480
People trying to measure the impact by putting a dollar amount on it, a probability, and that gets you to an adjusted risk score.

120
00:09:59,480 --> 00:10:03,340
And then we talk about inherent risks and residual risks.

121
00:10:03,340 --> 00:10:06,380
And that's often how risk assessments are done.

122
00:10:06,700 --> 00:10:13,320
In our taxonomy, controls are things we do to reduce the probability or the impact of a risk.

123
00:10:13,320 --> 00:10:17,360
So, if your door is unlocked, that is a vulnerability.

124
00:10:17,740 --> 00:10:21,880
The key and lock is a control.

125
00:10:21,880 --> 00:10:23,220
And you can lock your door.

126
00:10:23,220 --> 00:10:29,300
That doesn't necessarily mean that nobody will open your front door.

127
00:10:29,300 --> 00:10:32,960
It just has lessened the probability of it.

128
00:10:33,300 --> 00:10:35,480
It might have increased the impact, by the way.

129
00:10:35,600 --> 00:10:40,660
So, controls have... there's no panacea to them.

130
00:10:40,660 --> 00:10:46,900
But we do need to model what are the risks and then what are the controls.

131
00:10:46,900 --> 00:10:51,500
And when we do that, we can then figure out what are the residual risks.

132
00:10:51,740 --> 00:10:53,700
Threat modeling is just an analysis.

133
00:10:53,700 --> 00:11:00,540
It's a way of systematically going through and looking at vulnerabilities and controls and threats against a defined list of risks.

134
00:11:00,540 --> 00:11:04,440
And defined list of risks is really important.

135
00:11:06,320 --> 00:11:11,360
Because we can sit around and talk about every bad outcome under the sun.

136
00:11:11,820 --> 00:11:19,900
A meteor may strike the planet, but that really isn't a risk we're going to try to go model as threat modelers.

137
00:11:20,620 --> 00:11:22,160
And then lastly, action items.

138
00:11:22,160 --> 00:11:23,420
This is the result.

139
00:11:23,420 --> 00:11:26,080
This is what we're trying to get out of a threat model.

140
00:11:26,560 --> 00:11:29,500
We've looked at all the bad things that could happen.

141
00:11:29,500 --> 00:11:31,720
We've measured the probability of impact.

142
00:11:31,720 --> 00:11:33,860
We've assessed the controls we have.

143
00:11:33,860 --> 00:11:39,720
And then now we've got a whole bunch of work that we want someone to go do to reduce the risk.

144
00:11:39,720 --> 00:11:45,820
And we're going to reduce the risk by creating new controls that either reduce the probability or the impact.

145
00:11:46,060 --> 00:11:47,600
So that's our taxonomy.

146
00:11:47,600 --> 00:11:50,500
If I can add to that while you change slides on that.

147
00:11:50,500 --> 00:11:56,020
One thing that was super critical for us is just exactly that taxonomy.

148
00:11:56,020 --> 00:12:05,380
Coming from different disciplines, from IT security and from healthcare compliance, we spoke very different languages when it came to risk and threats.

149
00:12:05,380 --> 00:12:14,940
And realizing that, reconciling that, and making sure that we had a consistent discussion was really important for us to be able to make breakthroughs on this.

150
00:12:14,940 --> 00:12:27,080
So if you decide to adopt this model and go forward with it, don't underestimate how important it is to create that taxonomy when you're speaking to your risk organization or your compliance team or your privacy office.

151
00:12:27,080 --> 00:12:30,280
Getting on the same page is really important.

152
00:12:31,120 --> 00:12:31,740
Absolutely.

153
00:12:31,740 --> 00:12:32,880
I could not agree more.

154
00:12:32,880 --> 00:12:34,800
And thank you for jumping in so I can take a drink.

155
00:12:37,500 --> 00:12:43,980
We would love to think that we were the inventors of all threat models and the geniuses who wrote this down.

156
00:12:43,980 --> 00:12:45,380
The truth is we're not.

157
00:12:45,700 --> 00:12:51,240
There are lots of very, very good threat models out there in the ether.

158
00:12:51,240 --> 00:12:54,640
And we borrowed heavily from them.

159
00:12:54,640 --> 00:13:12,840
And so we wanted to walk you through some of those traditional threat models so that you would have these resources available to you to go do your own research and hopefully take what we've done, take what these other people have done, and apply that into your own business,

160
00:13:12,840 --> 00:13:14,980
whether it's in healthcare or any other.

161
00:13:14,980 --> 00:13:18,920
So our starting point was this wonderful book here by Adam Shostak.

162
00:13:18,920 --> 00:13:24,680
I think he may be talking at BlackHat or DEF CON this week on threat modeling.

163
00:13:25,420 --> 00:13:27,140
It is fantastic.

164
00:13:27,140 --> 00:13:29,460
If you don't own it, I highly recommend it.

165
00:13:29,460 --> 00:13:31,320
He didn't pay me to say that.

166
00:13:32,200 --> 00:13:34,900
And we'll talk a little bit more about what's in that.

167
00:13:34,900 --> 00:13:37,340
But that's really on the software design standpoint.

168
00:13:37,340 --> 00:13:41,600
On the privacy design, there's this model called Linden.

169
00:13:41,600 --> 00:13:43,520
And again, it's excellent.

170
00:13:43,520 --> 00:13:49,280
So Adam's book largely focuses on the stride threat model.

171
00:13:49,280 --> 00:13:51,980
This is something that came out of Microsoft.

172
00:13:52,060 --> 00:14:01,980
And this was a way of getting software engineers to assess the major threats to applications.

173
00:14:01,980 --> 00:14:06,200
And they had narrowed down to really six areas.

174
00:14:06,200 --> 00:14:24,860
So spoofing, so somebody illegally accessing an application, tampering, somebody modifying the data, repudiation, somebody performing an act and we couldn't figure out who it was, elevation of privilege, somebody gaining credentials that they shouldn't have,

175
00:14:24,860 --> 00:14:33,560
denial of service, shutting it down, or information disclosure, which is what Patrick and I worry about a lot, which is breaching information.

176
00:14:33,600 --> 00:14:34,700
That's the stride model.

177
00:14:34,700 --> 00:14:35,840
It's excellent.

178
00:14:35,940 --> 00:14:37,360
Please go read about it.

179
00:14:37,360 --> 00:14:40,540
If you haven't already done so, get Adam's book.

180
00:14:40,540 --> 00:14:47,300
On the privacy side, the Linden model is also excellent.

181
00:14:47,620 --> 00:14:59,700
And when we started researching this, what became really apparent to us, and we'll talk more about this as well, is that sometimes privacy and security are polar opposites of each other.

182
00:14:59,700 --> 00:15:05,900
So in the stride model, we're worried about repudiation.

183
00:15:05,900 --> 00:15:08,880
Can somebody do something and then deny they did it?

184
00:15:08,880 --> 00:15:11,520
In privacy, we're worried about non-repudiation.

185
00:15:11,520 --> 00:15:13,160
Can I do something anonymously?

186
00:15:13,680 --> 00:15:17,100
And so we borrowed heavily from the Linden model as well.

187
00:15:17,100 --> 00:15:19,980
But there's some other models out there that are also good.

188
00:15:20,180 --> 00:15:24,500
Bruce Schneier wrote extensively about attack trees.

189
00:15:24,540 --> 00:15:34,900
Attack trees is one way of brainstorming where you start with an objective, like I want to open a safe, and then you walk down a tree of all the ways you would do that.

190
00:15:34,900 --> 00:15:36,680
So how could I open a safe?

191
00:15:36,680 --> 00:15:37,680
Well, I'd have to learn the combo.

192
00:15:37,680 --> 00:15:38,700
That would be one way.

193
00:15:39,240 --> 00:15:40,960
Or I could cut it open.

194
00:15:40,960 --> 00:15:43,600
And to learn the combo, how would I do that?

195
00:15:43,860 --> 00:15:50,500
And you walk down that, and then you start figuring out what is possible, what's not possible.

196
00:15:51,120 --> 00:15:57,840
And then once you've done that kind of a model, you can then insert controls in there to break up the attack tree.

197
00:15:57,840 --> 00:16:00,880
Kill chains came out of the military.

198
00:16:01,400 --> 00:16:08,300
And again, it's a way of modeling what needs to be done for somebody to execute an attack.

199
00:16:08,300 --> 00:16:15,520
And if you interrupt any step of the kill chain, you can impact or possibly prevent the attack.

200
00:16:15,520 --> 00:16:18,220
Both excellent models.

201
00:16:18,680 --> 00:16:19,800
Security scorecards.

202
00:16:19,800 --> 00:16:23,680
These came out of the University of Washington.

203
00:16:23,680 --> 00:16:27,240
This is a way of training threat modelers on how to do threat modeling.

204
00:16:27,240 --> 00:16:29,020
It's actually a deck of cards.

205
00:16:29,020 --> 00:16:33,060
And I have a deck that's at my office that's under lockdown from COVID.

206
00:16:33,120 --> 00:16:37,960
But it talks a lot about motivations and resources and methods.

207
00:16:37,960 --> 00:16:42,360
And it's really just a training mechanism, but they're worth checking out.

208
00:16:42,360 --> 00:16:44,800
And there are a ton of other models.

209
00:16:44,960 --> 00:16:49,120
I found this white paper from Carnegie Mellon on threat modeling.

210
00:16:49,480 --> 00:16:51,000
It's excellent.

211
00:16:51,000 --> 00:16:54,700
I highly recommend the POSTA model just because I like the name.

212
00:16:54,700 --> 00:16:58,160
But there's lots of models out there.

213
00:16:58,160 --> 00:17:02,720
But none of them really fit what Patrick and I wanted to do.

214
00:17:02,720 --> 00:17:11,880
Which was, we wanted a single approach that we could look at our software applications and our vendors and our business processes.

215
00:17:12,240 --> 00:17:21,440
And deal with all the intersections between compliance and security and privacy and ultimately reduce the risk of our organization.

216
00:17:23,440 --> 00:17:25,440
Lots of people do brainstorming.

217
00:17:25,640 --> 00:17:29,160
Brainstorming is the simplest form of threat modeling.

218
00:17:29,160 --> 00:17:30,560
It has its place.

219
00:17:30,560 --> 00:17:32,120
We do it too.

220
00:17:33,440 --> 00:17:36,080
But it also has its limitations.

221
00:17:36,380 --> 00:17:40,380
And we talked, I said earlier that we don't model everything.

222
00:17:40,380 --> 00:17:43,860
We model the things that are applicable to our system.

223
00:17:43,860 --> 00:17:48,380
And this is kind of a typical traditional threat model.

224
00:17:48,380 --> 00:17:50,620
We talked about SAM earlier.

225
00:17:50,620 --> 00:17:52,720
We're going to talk about SAM again later.

226
00:17:52,940 --> 00:18:04,060
But this is a situation, a diagram of how a continuous glucometer, a wearable glucometer might work, might interface with our company.

227
00:18:04,060 --> 00:18:08,120
And we draw this on a whiteboard and then say, okay, if we were going to attack this, how would we do it?

228
00:18:08,120 --> 00:18:12,380
And everybody starts drawing things and we say, well, I'd do a man in the middle of the application.

229
00:18:12,380 --> 00:18:14,960
Or I'd do a denial of service on the API.

230
00:18:15,140 --> 00:18:18,360
Or I'd do a breach of the partner.

231
00:18:18,360 --> 00:18:22,700
Or I'd figure out some way to hack the device to harm the participant.

232
00:18:23,460 --> 00:18:29,220
And that is one way of doing threat modeling, but it ignores lots of things.

233
00:18:29,220 --> 00:18:33,320
It ignores the motivations and capabilities of the attacker.

234
00:18:33,340 --> 00:18:40,600
It ignores the objectives of the system.

235
00:18:40,600 --> 00:18:44,580
It also ignores all of the controls we already have in place.

236
00:18:44,580 --> 00:18:49,340
Because we've already done things, like we've got TLS written up here.

237
00:18:49,340 --> 00:18:51,860
That's control that we encrypt the traffic.

238
00:18:52,220 --> 00:19:02,880
So we want something that doesn't ignore all that and is a little more structured than just a couple of smart people and a whiteboard.

239
00:19:03,900 --> 00:19:06,780
And threat models are done via brainstorming.

240
00:19:06,780 --> 00:19:08,600
They're limited by your imagination.

241
00:19:08,600 --> 00:19:11,680
And failures of imagination lead to blind spots.

242
00:19:11,680 --> 00:19:14,880
So this was the problem we were trying to solve.

243
00:19:15,200 --> 00:19:18,540
And now Patrick is going to talk about what we actually did.

244
00:19:18,560 --> 00:19:20,920
And specifically the includes-no-dirt model.

245
00:19:21,460 --> 00:19:22,140
Yeah, exactly.

246
00:19:22,140 --> 00:19:22,840
Thanks, Bill.

247
00:19:22,980 --> 00:19:25,400
So exactly that's what we were trying to solve for.

248
00:19:25,400 --> 00:19:27,360
There's a lot of dimensions to that.

249
00:19:27,440 --> 00:19:34,580
I think the one comment I would make on the brainstorming thing, and I think we've seen this before in prior practices.

250
00:19:34,960 --> 00:19:41,300
If your thoughts are limited or if you don't think of something, you don't actually expose that in your conversation.

251
00:19:41,300 --> 00:19:49,520
So what this process actually allows us to do is force us to think of things that may not be top of mind when we're actually doing the work.

252
00:19:49,520 --> 00:19:53,600
And that regimentation and that process actually drives us to that one.

253
00:19:53,600 --> 00:19:54,860
Okay, next slide.

254
00:19:55,200 --> 00:19:58,800
So what we were looking for in coming up with this process.

255
00:19:58,800 --> 00:20:02,520
Something that was easy for a non-SME to understand.

256
00:20:02,640 --> 00:20:07,380
Something that we could-and something that would be easy for someone to perform.

257
00:20:07,380 --> 00:20:22,640
So something that we could give to a non-expert, say someone on my team or on the privacy team, and have them not only understand what we were after and what we were trying to do, but actually something that they could deliver and run through in a fairly short amount of time.

258
00:20:22,720 --> 00:20:25,480
We wanted something that was flexible and repeatable.

259
00:20:25,480 --> 00:20:33,120
Something that we didn't have to shift every single time that we did the questions and something that we could do over and over and over again.

260
00:20:33,380 --> 00:20:36,260
We wanted something that was usable anywhere.

261
00:20:36,260 --> 00:20:43,280
We didn't want to have to design something that was great for business process, but really crappy for IT structures or vice versa on that.

262
00:20:43,620 --> 00:20:47,340
And of course, since we were putting a lot of effort into this, we wanted it to be memorable.

263
00:20:47,400 --> 00:20:49,740
Because why not when you're building it?

264
00:20:49,840 --> 00:20:54,060
And some creative uses of anagram generators actually got us where we are.

265
00:20:54,060 --> 00:20:55,120
So, next slide.

266
00:20:55,320 --> 00:20:57,480
So what we created with this process.

267
00:20:57,700 --> 00:21:00,960
It's a systematized approach to analyzing risks.

268
00:21:01,260 --> 00:21:03,500
That pays a couple of different dividends.

269
00:21:03,500 --> 00:21:08,100
One is it's systematized and it's easy to execute like we were just discussing.

270
00:21:08,100 --> 00:21:13,940
It's also interestingly started to be a key for us to explain how we think about risks.

271
00:21:13,940 --> 00:21:20,400
So it structures educational conversations when we have them with staff so they understand what we're trying to do.

272
00:21:20,880 --> 00:21:23,900
It's a repeatable process with objective scoring.

273
00:21:23,900 --> 00:21:25,660
So another huge win there.

274
00:21:25,660 --> 00:21:31,520
Something we can do over and over again, sometimes on the same system to see changes or see how things have evolved.

275
00:21:31,520 --> 00:21:36,660
And it gives us an objective score with some weights that we're going to see in the example we'll show you.

276
00:21:36,660 --> 00:21:42,200
That help us compare across risks or across even domains in what we're looking at.

277
00:21:42,200 --> 00:21:45,340
How we think about risks and what do we do first.

278
00:21:45,380 --> 00:21:49,160
There's never enough time, there's never enough resource, how do you focus your time?

279
00:21:49,380 --> 00:21:51,340
We wanted a system-centered approach.

280
00:21:51,340 --> 00:21:55,260
So something that isn't really focused on the thing that you're modeling.

281
00:21:55,260 --> 00:22:00,360
But something that actually is focused on the thing that you're modeling but not on the process itself.

282
00:22:01,700 --> 00:22:08,640
We tried to kind of bridge the gap between, say, having a Stride and a Linden for different things and create something consistent.

283
00:22:09,020 --> 00:22:13,220
Bill mentioned we focused on established controls and that's really important.

284
00:22:13,220 --> 00:22:19,460
If we've tested the control already and we're sure it works in our audit practice, we know it's actually running.

285
00:22:20,040 --> 00:22:22,400
Then we don't actually have to include it in the model.

286
00:22:22,400 --> 00:22:26,740
And in the example we'll show you, we've gone through a few things and eliminated it.

287
00:22:26,740 --> 00:22:29,060
Because they either don't apply or we know that it works.

288
00:22:29,060 --> 00:22:34,000
Lastly, we wanted to have a model that covers all of the domains we think are important.

289
00:22:34,000 --> 00:22:36,020
Privacy, security, and compliance.

290
00:22:36,020 --> 00:22:41,700
So not having three different models or three different versions and being able to include different regulatory regimens.

291
00:22:41,960 --> 00:22:42,880
Next slide.

292
00:22:44,760 --> 00:22:45,620
Alright.

293
00:22:46,000 --> 00:22:51,540
What we created with Includes No Dirt, the model that we have, your mileage may vary on this one.

294
00:22:51,540 --> 00:22:55,280
We designed it for our own uses at Omada Health.

295
00:22:55,280 --> 00:23:01,100
And if you're in the healthcare space, it may be directly applicable with the questions that we have.

296
00:23:01,100 --> 00:23:04,660
You may have to swap out some of the specific regulatory questions.

297
00:23:04,660 --> 00:23:08,740
If you're in an adjacent industry, it may need some questions adapted.

298
00:23:08,740 --> 00:23:14,600
Please, by all means, take the questions and modify them to your own use to target exactly what you're trying to get to.

299
00:23:14,880 --> 00:23:15,660
Next slide.

300
00:23:16,300 --> 00:23:16,720
Alright.

301
00:23:16,720 --> 00:23:17,980
And one last, the teaser.

302
00:23:17,980 --> 00:23:19,800
It is the Includes No Dirt model.

303
00:23:20,100 --> 00:23:23,740
And it has been arranged to actually be memorable.

304
00:23:23,740 --> 00:23:36,500
So identifiability, non-repudiation, clinical error, linkability, unlicensed activity, denial of service, elevation of privilege, spoofing, non-compliance to policy, overuse.

305
00:23:36,500 --> 00:23:42,720
Specifically, they were thinking of overuse of information and data as really pertains to the HIPAA space that we're in.

306
00:23:43,000 --> 00:23:48,720
Dirt, data error, information disclosure, repudiation, and tampering.

307
00:23:48,720 --> 00:23:51,860
So all those parts play together to make the model that we're using.

308
00:23:51,860 --> 00:23:52,580
Next slide.

309
00:23:53,740 --> 00:23:59,200
So for every risk, there's a property and a goal, and it comes from a specific place.

310
00:23:59,220 --> 00:24:00,680
So you skip down a couple.

311
00:24:00,680 --> 00:24:02,040
Clinical error.

312
00:24:02,420 --> 00:24:04,160
The risk is clinical error.

313
00:24:04,160 --> 00:24:07,340
A clinician making a mistake that may otherwise have been prevented.

314
00:24:07,520 --> 00:24:12,820
The property or the goal of that is the application of correct clinical standards.

315
00:24:12,820 --> 00:24:19,520
So making sure that the clinician both knows what they're doing and actually can do them at the moment in time where they actually need to do it.

316
00:24:19,520 --> 00:24:20,840
That's in the realm of compliance.

317
00:24:20,840 --> 00:24:27,120
And we've sorted on this slide the specific things as to what the goal of what we're trying to do is and where it comes from.

318
00:24:27,420 --> 00:24:28,360
Next slide.

319
00:24:32,000 --> 00:24:41,500
Now, you may have noticed that some of these things overlap, and that's where proper judgment by the risk assessors as you go through this is important.

320
00:24:41,640 --> 00:24:45,380
And I don't think I can say that enough strongly in the title slide.

321
00:24:45,580 --> 00:24:49,840
The risks that apply depend on the system being modeled.

322
00:24:49,840 --> 00:24:55,980
So some of these, you'll have to look at what you're trying to do and figure out, does this apply, does this not apply?

323
00:24:56,060 --> 00:24:57,580
How does it apply?

324
00:24:57,980 --> 00:25:00,680
And some things you may just factor out as you go through it.

325
00:25:00,700 --> 00:25:05,580
So these three in particular are complicated because they are very related.

326
00:25:05,580 --> 00:25:08,200
And Bill alluded to it at the beginning.

327
00:25:08,300 --> 00:25:13,940
Security and privacy sometimes are at opposite ends of what they're trying to do.

328
00:25:13,940 --> 00:25:16,060
And these tend to reflect it here.

329
00:25:16,060 --> 00:25:22,260
So identifiability, the property of a system that allows users to trace to a specific user.

330
00:25:22,300 --> 00:25:31,180
So there, the objective or the goal is anonymity, making sure that that's not actually possible.

331
00:25:31,360 --> 00:25:38,840
A risk of non-repudiation, non-repudiation, the process by which it's proven that a user took an action.

332
00:25:38,900 --> 00:25:41,460
The goal there is plausible deniability.

333
00:25:42,560 --> 00:25:45,800
It isn't clear if someone did something or not.

334
00:25:45,880 --> 00:25:48,020
The risk is repudiation.

335
00:25:48,640 --> 00:25:52,920
And here, what we're trying to get to is non-repudiation.

336
00:25:52,920 --> 00:25:58,420
So where someone can actually show that it actually hasn't happened yet.

337
00:25:58,420 --> 00:26:04,720
So these of note actually came from different parts, some from Stride, some from Lyndon.

338
00:26:04,720 --> 00:26:06,940
So privacy and security blended together.

339
00:26:07,120 --> 00:26:10,820
On the next slide and the next couple, we'll actually kind of unpack that a little bit.

340
00:26:10,820 --> 00:26:14,660
So de-conflicting these goals can be kind of complicated on this.

341
00:26:14,660 --> 00:26:18,380
Different stakeholders will have different needs for these things.

342
00:26:18,380 --> 00:26:27,800
So for example, with anonymity and identifiability, that risk goal, there are some times where you're building a system where that absolutely is required.

343
00:26:27,800 --> 00:26:30,780
We've got a whistle here for a whistleblower.

344
00:26:30,780 --> 00:26:43,660
If I'm designing, for example, a software application that holds anonymous reporting for whistleblowers, because that's required under healthcare compliance rules and other codes as well, anonymity is really important.

345
00:26:43,660 --> 00:26:49,660
But then for other goals and other people in the system, less important.

346
00:26:49,660 --> 00:27:01,380
So a hacker, for example, there in the middle, really relies on plausible deniability for what they're trying to do, either ethically or otherwise, making sure that there's that deniability as part of it.

347
00:27:01,460 --> 00:27:06,360
Repudiation and non-repudiation as well.

348
00:27:06,360 --> 00:27:09,700
Let's get into a little bit more of a specific example on the next slide, though.

349
00:27:09,700 --> 00:27:18,460
So let's say Human Resources wants to build or wants an employee complaint application that lets employees report sexual harassment.

350
00:27:19,280 --> 00:27:25,500
Lots of different goals, lots of different stakeholders, and figuring out how to balance between them gets really important.

351
00:27:25,500 --> 00:27:32,980
So employees want to be able to report and want, if they want to have anonymity, that their anonymity is protected.

352
00:27:32,980 --> 00:27:37,540
If they want to say something anonymous, they can't, and no one will know who it is.

353
00:27:37,960 --> 00:27:51,480
Well, HR wants to help ensure anonymity, but also wants to make sure that there's less of a possibility of abuse in the system, that you don't have one person anonymously reporting the same thing over and over again to drive a larger oppression.

354
00:27:52,020 --> 00:27:58,960
IT needs to provision and deprovision administrative access to this, but they have absolutely no need to see the complaints that are registered.

355
00:27:58,960 --> 00:28:03,900
Security runs DLP on every laptop, logs who has access to the application.

356
00:28:04,000 --> 00:28:18,040
Important from a security perspective, but then that becomes potentially challenging depending on the level of access and the fact that if they're provisioning it and they log who accesses, they have a proxy for who's actually reporting things.

357
00:28:18,180 --> 00:28:29,160
The legal department wants to be able to document complaints and collect evidence to take action, which is somewhat the opposite of anonymity.

358
00:28:29,160 --> 00:28:35,000
It's hard to take action and have a cause that comes out if we don't know actually who did something.

359
00:28:35,000 --> 00:28:44,720
So you have lots of different people running in the system with different needs, different roles, and those roles will conflict.

360
00:28:44,720 --> 00:28:50,620
So we can't completely make everything anonymous because then security and IT can't do their work.

361
00:28:51,200 --> 00:28:59,580
Legal will be able to document complaints and the harassment, if in fact it is actually occurring, will keep continuing because there's no way to investigate it.

362
00:28:59,580 --> 00:29:07,980
So all of these parts play together and need to be balanced in the work that you're doing when you do the modeling.

363
00:29:09,700 --> 00:29:11,260
All right, I think it's back to you.

364
00:29:11,340 --> 00:29:13,320
All right, so let's give it a try.

365
00:29:13,760 --> 00:29:15,420
Time to come back to Sam.

366
00:29:15,420 --> 00:29:34,620
So Sam is a typical patient with type 2 diabetes, and she's been using for years a blood glucometer, which means she's constantly pricking her finger, taking blood readings.

367
00:29:34,620 --> 00:29:50,900
We know that she would benefit from having a continuous glucometer, that she is a wearable, and that is automatically sending readings to her coach so that we get greater telemetry, so that we can respond quicker.

368
00:29:51,440 --> 00:29:59,300
So we want to introduce CGMs into our product set, but we want to do it safely.

369
00:29:59,300 --> 00:30:08,560
So what Patrick and I did is we filled out an Includes No Dirt threat model on the concept of a CGM to try to help us figure out where we need to pay attention.

370
00:30:09,120 --> 00:30:17,180
And again, you can download the one we've filled out at includesnodirt.com slash defcon.pdf.

371
00:30:17,180 --> 00:30:19,520
I highly encourage you to do so.

372
00:30:21,120 --> 00:30:23,260
We talked about brainstorming.

373
00:30:23,260 --> 00:30:39,320
The Includes No Dirt threat model, we've included a structured brainstorming worksheet that allows us to go through a system and kind of helps guide where we go.

374
00:30:39,320 --> 00:30:42,200
So again, I'm going to come back to this is our diagram.

375
00:30:42,200 --> 00:30:44,940
In our diagram, we have a wearable glucometer.

376
00:30:45,080 --> 00:30:54,420
That glucometer syncs to an application on the patient's cell phone, which then transmits the data to the partner.

377
00:30:54,420 --> 00:31:02,280
The partner then sends it to our endpoint, and it gets stored in our database.

378
00:31:02,280 --> 00:31:07,460
It then sends information back to our application.

379
00:31:07,460 --> 00:31:10,180
It also surfaces that information to the coach.

380
00:31:10,280 --> 00:31:15,720
And you'll see here that in addition to the CGM, the participant still has a BGM.

381
00:31:15,720 --> 00:31:24,260
So still does occasional finger sticks, and that information is also being sent to us.

382
00:31:24,260 --> 00:31:28,720
So we've got two sources now of blood sugar data.

383
00:31:28,720 --> 00:31:31,920
So this is the diagram we're going to be working off of.

384
00:31:32,280 --> 00:31:36,960
In our worksheet that we provided you, it's highly structured.

385
00:31:36,960 --> 00:31:40,980
One of the first things we do is we mark which threats we think apply.

386
00:31:40,980 --> 00:31:43,320
Who are the actors that are involved here?

387
00:31:44,000 --> 00:31:51,140
So certainly the participant is involved in this whole process, and the coach is involved, but we've got a vendor.

388
00:31:52,160 --> 00:31:55,120
We've got potentially other partners.

389
00:31:55,120 --> 00:31:58,320
We're going to be doing claims on this and billing.

390
00:31:58,320 --> 00:31:59,720
We're reporting.

391
00:31:59,760 --> 00:32:02,780
So there's business processes, there's people.

392
00:32:02,900 --> 00:32:05,580
For this one, we're not so worried about natural disasters.

393
00:32:05,580 --> 00:32:12,800
We're not so worried about geopolitical unrest, but other threat models, those might come into play.

394
00:32:13,980 --> 00:32:18,600
And we then do some brainstorming on vulnerabilities.

395
00:32:19,560 --> 00:32:22,800
So what are areas that could be vulnerable?

396
00:32:22,800 --> 00:32:29,500
They get an incorrect reading, or the service becomes unavailable, or the coach misinterprets the data.

397
00:32:29,500 --> 00:32:37,200
Now, up in the right-hand corner there, I've got a little diagram where I show the questionnaire and also the structured brainstorming.

398
00:32:37,200 --> 00:32:39,460
And this is an iterative process.

399
00:32:39,460 --> 00:32:44,480
We sometimes start with the questionnaire, and we sometimes start with the worksheet.

400
00:32:44,480 --> 00:32:50,920
But it's typical when we are doing one of these on a complex system, we are going back and forth.

401
00:32:50,920 --> 00:33:02,180
So we'll be going through the questionnaire, which is highly structured, and that will trigger us to go, Oh, wait, because we've said no on this question, we think that there's a vulnerability there.

402
00:33:02,180 --> 00:33:05,840
Let's go write that down on our worksheet on vulnerabilities.

403
00:33:05,840 --> 00:33:08,900
Let's go ask somebody to get more information.

404
00:33:08,900 --> 00:33:17,940
And we go through this process until we think we've got the questionnaire complete and the worksheet complete.

405
00:33:17,940 --> 00:33:19,980
And so we did that.

406
00:33:20,280 --> 00:33:26,680
And when we did that, we were able to take those vulnerabilities that I've listed here.

407
00:33:26,680 --> 00:33:28,920
There's five of them in our example.

408
00:33:28,920 --> 00:33:34,560
And we're mapping those to specific areas in the includes-no-dirt model.

409
00:33:35,620 --> 00:33:38,280
So you'll see, like, anonymity.

410
00:33:38,280 --> 00:33:39,380
We don't want anonymity.

411
00:33:39,380 --> 00:33:43,560
It doesn't apply in this one, but clinical error certainly does.

412
00:33:43,560 --> 00:33:47,190
And denial of service does, and spoofing does.

413
00:33:47,190 --> 00:34:02,770
So in the interest of time in our presentation, we're not going to go through all of our answers for every risk, but we're going to go through the answers we did for the risks that apply and talk about why they apply.

414
00:34:02,870 --> 00:34:07,050
And again, you can download our example and see our answers on all of them.

415
00:34:07,050 --> 00:34:18,770
So the factors that do apply are clinical error, unlicensed activity, denial of service, spoofing, noncompliance, data error, information disclosure, repudiation, and tampering.

416
00:34:18,890 --> 00:34:22,330
These are the things we're worried about in this particular threat model.

417
00:34:23,390 --> 00:34:26,050
So Patrick, let's start with clinical error.

418
00:34:26,170 --> 00:34:26,730
Sure.

419
00:34:26,730 --> 00:34:36,070
So what we did in this one, to make it a little clearer, is for the next few slides, on the left side of the slide is a snapshot of the answers.

420
00:34:36,070 --> 00:34:43,570
And all of these answers are in the materials that we put on the includes-no-dirt website under the DEFCON link.

421
00:34:43,570 --> 00:34:52,190
On the right side, we've clarified a little bit about what these actually mean in the context of the CGM work that we did for this specific example.

422
00:34:52,430 --> 00:34:57,370
It can be a little hard to read through those, so we've kind of pulled out what we think the important answers are.

423
00:34:57,490 --> 00:35:07,330
So here for clinical activities, what we're thinking about in the specific example of this continuous glucose monitor is, are we doing something that relates to the treatment of a patient?

424
00:35:07,330 --> 00:35:09,990
Well, of course we are in this particular example.

425
00:35:09,990 --> 00:35:26,650
So the specific question that we probe into here is, does this system or process, does this combination of things, have either inbuilt controls that prevent something from happening in the first place, or other review-based controls that can, if something does happen,

426
00:35:26,650 --> 00:35:29,290
we'd be able to find it and correct it as quickly as we can.

427
00:35:29,290 --> 00:35:31,230
So answer here, yes.

428
00:35:31,230 --> 00:35:42,430
And it's a little complicated because it's both CGM, it's both a device that is created by a partner of ours and software that we create for our coaches to be able to use that information.

429
00:35:42,850 --> 00:35:49,170
Each one of those has specific detective and preventive controls that operate in its own environment.

430
00:35:49,170 --> 00:35:54,830
And this is a great example of what Bill just said related to the iterative nature of this.

431
00:35:54,830 --> 00:36:00,630
When we hit this question, it's like, okay, wait, that's both the device and the software.

432
00:36:00,630 --> 00:36:01,450
How does that work?

433
00:36:01,450 --> 00:36:04,630
And we had to fork a little bit, came back, yep, that's exactly right.

434
00:36:05,150 --> 00:36:11,670
In questions 3.2 and 3.3, we delve down a little bit into some additional control work.

435
00:36:11,970 --> 00:36:16,390
And another thing I would say here is, not all controls are technical.

436
00:36:16,390 --> 00:36:24,990
In this particular case, with clinical error, part of preventing clinical errors is ensuring both the proper training of your clinicians.

437
00:36:24,990 --> 00:36:28,710
So being able to say, yeah, everybody that has access to this was properly trained.

438
00:36:28,810 --> 00:36:31,810
I almost said licensure, that's coming soon.

439
00:36:32,530 --> 00:36:40,170
And that the delivery and the quality of the deliveries is important and up to the standards we set in our clinical practice guidelines.

440
00:36:40,170 --> 00:36:49,510
So that becomes a review process and a quality check that our clinicians will do on the staff to make sure, by reviewing their output, that things are going the way we want it to.

441
00:36:49,550 --> 00:36:50,630
All right, next slide.

442
00:36:50,630 --> 00:37:01,430
So one thing I want to say before we move to the next slide, you'll see there on the left-hand side, on question 3.0, when we answered yes, it gets one point for that.

443
00:37:01,430 --> 00:37:08,390
If we'd answered no, we can skip the rest of the questions on clinical and move on to question 4.

444
00:37:08,730 --> 00:37:11,370
So those two things are really important.

445
00:37:11,370 --> 00:37:15,770
At the end of this, we're going to total up all the points, and that will drive a risk score.

446
00:37:15,770 --> 00:37:24,230
But being able to skip a whole bank of questions when they don't apply means you can go through the model much faster.

447
00:37:24,230 --> 00:37:36,270
So for simple systems that don't involve clinical, don't involve patient activities, we can maybe model them, as we said, very quickly, like 15 minutes.

448
00:37:36,270 --> 00:37:41,750
For something that's complicated, and this would be a fairly complicated one, it might take us several hours.

449
00:37:41,750 --> 00:37:48,850
But the model fits whichever size system, whichever level of complexity we're dealing with.

450
00:37:49,470 --> 00:37:51,630
Definitely, thanks for pointing that out.

451
00:37:51,990 --> 00:37:59,550
That weighting is really important because it helps to also create that apples-to-apples comparison that we talked about a little bit earlier.

452
00:37:59,550 --> 00:38:04,750
Second one, unlicensed activity, and I spilled it a little bit ago just talking about it.

453
00:38:04,750 --> 00:38:13,730
Does, in this case, the work that we do require licensure from either a site license or personnel licenses for the people that are delivering care?

454
00:38:13,970 --> 00:38:21,170
Just like the last question, yes, it does, and it's complicated because different parts of this thing require different licensure.

455
00:38:21,170 --> 00:38:39,480
The CGM manufacturer requires licensure by various federal and state authorities, and our clinicians internal to us require credentialing to make sure they're able to deliver the coaching that's appropriate for diabetes, so there are national standards for that.

456
00:38:40,760 --> 00:38:45,880
Also important here is the fact that we rely on other people in these things.

457
00:38:45,880 --> 00:38:52,800
Just like we talked about, if we've tested a control, we know it works, we don't have to bring that into the discussion here.

458
00:38:53,160 --> 00:39:03,820
We may, in diligence and checking, acknowledge that, yes, our business partners have the appropriate licensure, but we don't have to dig into that to make sure it's as robust as it is.

459
00:39:03,820 --> 00:39:13,580
Our contracting processes make sure that those exist, so we use that as effectively a control, and we focus on the things that are important to us, which is our own internal clinicians.

460
00:39:14,580 --> 00:39:15,960
I think you're next.

461
00:39:15,960 --> 00:39:17,060
Denial of service.

462
00:39:17,060 --> 00:39:22,640
So this is where we start looking about how mission critical the system is that we are modeling.

463
00:39:22,640 --> 00:39:45,140
For a connected glucometer, the availability of the entire system is very important, and if any piece of that system is having a problem, the connectivity between the device and the partner, the partner and us, us and the participant, isn't working, then it's going to have a significant impact on the effectiveness of getting that telemetry data to the coach,

464
00:39:45,140 --> 00:39:50,100
back to the participant, and being able to make decisions on that data.

465
00:39:50,100 --> 00:39:54,180
So when we go through our model, we ask, is it a mission critical system?

466
00:39:54,180 --> 00:39:57,260
If it is, that raises the point value.

467
00:39:57,400 --> 00:40:03,440
And then we look at, have we defined targets, and what are those targets, and how are they enforced?

468
00:40:03,760 --> 00:40:08,880
And again, Patrick said not all controls are technical.

469
00:40:08,900 --> 00:40:14,140
For the partner, they've got technical controls to ensure their availability.

470
00:40:14,140 --> 00:40:24,000
For us, we've got contractual controls, where we define an availability target with monitoring and penalties, and that's how we manage the risk on our side.

471
00:40:28,040 --> 00:40:38,400
Spoofing... we want to make sure that we are getting the right data, and we want to make sure that only the right people can access that data.

472
00:40:38,400 --> 00:40:52,740
And so spoofing as a threat is where we look and model in authentication, and this is a good example of where we can rely on existing controls.

473
00:40:52,740 --> 00:40:58,460
So we have defined authentication levels for our participants.

474
00:40:58,460 --> 00:41:06,380
We base it on NIST 800-63B, and they're defined as an AAL Level 1.

475
00:41:06,380 --> 00:41:13,120
Our coaches are defined as a Level 2, which means that they not only have to have a username and password, but a second factor.

476
00:41:13,120 --> 00:41:14,660
We test those.

477
00:41:14,660 --> 00:41:15,700
We know it works.

478
00:41:15,700 --> 00:41:23,880
So as long as the system is going to use those controls we've already defined, we can check those boxes and move on.

479
00:41:23,880 --> 00:41:35,940
We don't need to spend a lot of time detailing how authentication for this particular system is going to work, because it's a client of the greater system within our care delivery.

480
00:41:36,800 --> 00:41:38,340
All right.

481
00:41:38,820 --> 00:41:39,640
Noncompliance.

482
00:41:39,640 --> 00:41:51,680
So not surprisingly, when we have to address a particular business process or system, as a HIPAA covered entity, there's lots and lots of legal requirements that get attached to something.

483
00:41:51,680 --> 00:42:08,680
This is probably, let's call it the worst example of the complexity here, because for this combination of devices and software that we're building, it's everything from HIPAA, privacy policies, the terms of use both for the device and for our software application,

484
00:42:08,680 --> 00:42:11,060
there's a number of healthcare compliance issues.

485
00:42:11,060 --> 00:42:16,760
There would be FDA obligations for our business partners, the contracts that Bill just mentioned.

486
00:42:16,860 --> 00:42:21,240
So because this is clinical in nature, it relates to a device.

487
00:42:21,240 --> 00:42:22,820
There's patient data involved with it.

488
00:42:22,820 --> 00:42:24,840
This one's particularly complicated.

489
00:42:24,840 --> 00:42:38,240
As I mentioned kind of early on when we were talking about the problems that brainstorming can create, this question is specifically designed to bring up those non-obvious things that you may not have top of mind when you're actually doing it.

490
00:42:38,240 --> 00:42:55,000
If you have, if you're adapting this questionnaire, certain things that you want to target, definitely adding it to this list is important because, for example, here, terms of use may not have been something I would have thought about, but it has to include what we're trying to include in this specific example.

491
00:42:55,000 --> 00:42:58,060
So that was important to kind of drive through that.

492
00:42:58,060 --> 00:43:05,800
This also, you look down at the very bottom left of the screen, we can also check through the applicability of some of the credentials that we have.

493
00:43:05,800 --> 00:43:11,620
One of the things that I would stop to in a high trust certified organization is applying this particular case because of the nature of what we're trying to do.

494
00:43:11,760 --> 00:43:14,120
Okay, next one I think is mine as well.

495
00:43:14,140 --> 00:43:15,300
Data error.

496
00:43:15,300 --> 00:43:35,000
So here in this particular example, we're digging heavily into data integrity and for a medical process and a clinical record keeping process like this would create, so we're essentially creating a part of a medical record on glucose monitoring, glucose management for participants in the program.

497
00:43:35,000 --> 00:43:41,020
It's really important to make sure that this is ingested and maintained in an accurate and viable way.

498
00:43:41,660 --> 00:43:47,560
Again, here, in other includes no dirt models that we've actually done, we've tested some of that.

499
00:43:47,560 --> 00:43:51,580
We've tested, for example, the APIs that we do data ingestion with.

500
00:43:51,580 --> 00:44:00,380
So we can kind of check that off and go, yeah, it's acting as we intended it to and move on and focus the mitigation control work we're trying to do here for other things.

501
00:44:04,280 --> 00:44:06,600
So information disclosure.

502
00:44:06,820 --> 00:44:10,240
This is where we're worried about confidentiality of the system.

503
00:44:10,260 --> 00:44:23,360
We've got rules over within HIPAA, within our customer contracts on how we protect data to make sure that it isn't disclosed where it's not supposed to be.

504
00:44:23,360 --> 00:44:30,100
And again, here, we're largely consuming controls that we've already tested previously.

505
00:44:30,100 --> 00:44:35,740
So HIPAA requires us to encrypt PHI at rest and in transit.

506
00:44:35,740 --> 00:44:38,940
So we can ask, are we doing that?

507
00:44:38,940 --> 00:44:40,540
And if so, how?

508
00:44:40,620 --> 00:44:48,200
And since those are really well-known patterns for us, we can accept them and we can move on.

509
00:44:48,200 --> 00:44:51,520
It doesn't actually require a ton of discussion.

510
00:44:52,540 --> 00:44:55,360
Down at 12.6, data locality.

511
00:44:55,360 --> 00:44:57,240
This is a really good reminder for us.

512
00:44:57,360 --> 00:45:03,140
We have obligations to keep all of our data within the United States, processed, stored, and accessed.

513
00:45:03,320 --> 00:45:16,100
And so, especially when we're talking about a third-party vendor, this is a good reminder of, hey, let's make sure we know where their data centers are and where the data goes as it traverses its way to us.

514
00:45:18,360 --> 00:45:19,160
Repudiation.

515
00:45:19,160 --> 00:45:21,720
We've talked a lot about repudiation already.

516
00:45:22,860 --> 00:45:25,320
Does it require non-repudiation?

517
00:45:25,320 --> 00:45:25,740
Yes.

518
00:45:25,740 --> 00:45:27,500
What are those mechanisms?

519
00:45:27,720 --> 00:45:37,480
And again, in question 13.3, there's lots of mechanisms that we have in place, but we want to make sure we address them.

520
00:45:37,480 --> 00:45:39,780
How are user activities being logged?

521
00:45:39,880 --> 00:45:41,840
Do we have accurate timestamps?

522
00:45:41,840 --> 00:45:45,080
How long are logs retained?

523
00:45:45,080 --> 00:45:46,080
Things like that.

524
00:45:47,040 --> 00:45:55,480
That lets us know that this particular system is going to fit into our overall framework.

525
00:45:57,080 --> 00:45:58,180
And tampering.

526
00:45:58,760 --> 00:46:01,040
We don't want anyone to mess with the data.

527
00:46:01,380 --> 00:46:05,940
So, again, what are all the mechanisms in place to prevent tampering?

528
00:46:05,940 --> 00:46:21,160
Now, for this particular system, there's some interesting tampering things we need to deal with, like the chain of custody of the device between the manufacturer and the DME and the DME shipping it to the participant.

529
00:46:21,160 --> 00:46:32,460
And also, how do we make sure that the device that gets shipped gets assigned to the appropriate patient in our data model?

530
00:46:32,460 --> 00:46:41,380
And that's a fulfillment question, because we have to make sure that every device that gets shipped, that serial number comes to us assigned to the correct person.

531
00:46:41,380 --> 00:46:54,000
And if we don't, that then makes its way back up to not just tampering, but to data integrity and who has access to it.

532
00:46:54,000 --> 00:46:56,660
So, again, the model is iterative.

533
00:46:56,660 --> 00:46:58,000
It lets us go through it.

534
00:46:58,000 --> 00:47:03,180
And it reminds us to check, how are all these things being addressed for this?

535
00:47:03,180 --> 00:47:06,260
It is a very structured way of brainstorming.

536
00:47:07,020 --> 00:47:08,940
And we get to the end, we get a score.

537
00:47:10,240 --> 00:47:11,600
Patrick, you want to talk about this?

538
00:47:11,600 --> 00:47:12,280
Oh, sure.

539
00:47:12,360 --> 00:47:12,860
Yeah.

540
00:47:12,860 --> 00:47:15,240
So, as Bill said, we get to the end and we get a score.

541
00:47:15,240 --> 00:47:17,680
So, the product of all the numbers that you saw on the side.

542
00:47:17,680 --> 00:47:28,460
So, for example, when we've weighted the first element as one, when we're talking about clinical controls in place or not, all of those add up together.

543
00:47:28,460 --> 00:47:35,300
And in the particular governance risk and compliance system that we use, we can weight the scores, so some are stronger than others.

544
00:47:35,300 --> 00:47:39,400
But essentially, the product of that turns into a total score.

545
00:47:39,660 --> 00:47:50,180
We can rank that total score as a low, medium, or high, again, to be able to focus our efforts and make sure that we know, kind of, is this something we need to address immediately in the grand scheme of things?

546
00:47:50,180 --> 00:47:56,880
Is this something we can actually wait on for a while because it's not as critical as other things that we're looking at?

547
00:47:56,880 --> 00:48:00,000
On the right side, you actually see the list of action items.

548
00:48:00,000 --> 00:48:04,220
You saw that in a prior slide as far as how those work.

549
00:48:04,220 --> 00:48:06,400
Here's the specific action items for this one.

550
00:48:06,400 --> 00:48:08,880
So, for example, for this particular model.

551
00:48:08,880 --> 00:48:22,300
So, for example, creating clear instructions for participants on device calibration can help with data integrity issues because it's not clear if someone enters data incorrectly, the treatment would apply correctly.

552
00:48:22,300 --> 00:48:25,180
So, this addresses the clinical vulnerability issue.

553
00:48:25,340 --> 00:48:31,420
Backups to BGM and CGM also touches on some of the same issues.

554
00:48:31,460 --> 00:48:37,760
Sometimes that's required just because of the nature of the CGM and so forth with all of these.

555
00:48:37,760 --> 00:48:43,180
Each one of those action items is designed to address one or more vulnerabilities.

556
00:48:43,180 --> 00:48:51,380
And that's part of the process of this is everything that you've identified should have an action item at the end of it to make sure you're hitting everything you need to from a control perspective.

557
00:48:52,280 --> 00:48:54,760
And we've done a lot of these.

558
00:48:54,800 --> 00:48:59,260
I mentioned earlier that we launched a behavioral health application.

559
00:48:59,260 --> 00:49:02,540
And when we did that, Patrick and I did a threat model.

560
00:49:02,540 --> 00:49:05,520
And I think we came up with 19 action items.

561
00:49:05,520 --> 00:49:16,720
And those were specific things that we wanted to ingest into the system before we went live.

562
00:49:16,720 --> 00:49:35,060
So, we did that at the very early stages as we were just planning, which was six months before the launch, which meant that we had as risk assessors the ability to have a meaningful impact on the security and privacy and compliance of that application before it ever launched.

563
00:49:35,060 --> 00:49:41,360
And everybody involved also understood, because they went through the process with us, why.

564
00:49:41,360 --> 00:49:48,440
They knew why we had those action items, and what was the specific vulnerability we were trying to address.

565
00:49:48,780 --> 00:49:50,380
That latter is very important.

566
00:49:50,380 --> 00:50:00,220
You may have groups that, let's just say, are not necessarily as inclined to be helpful when working with the risk assessing organizations.

567
00:50:00,220 --> 00:50:10,600
We had, in this particular case, this behavioral health example, some of our developers come back to us and say, oh, we get it now, why this is important, after they've executed through the process.

568
00:50:10,600 --> 00:50:15,480
So, it becomes educational as well as helpful, just as a reminder as to why we're doing it.

569
00:50:17,040 --> 00:50:20,280
So, a couple of points to wrap this up.

570
00:50:20,380 --> 00:50:24,940
Vendor management, the threats you aren't seeing can also kill you.

571
00:50:25,640 --> 00:50:35,760
I use this example, this was a letter that Quest Diagnostics sent out about a year ago on a breach.

572
00:50:35,760 --> 00:50:45,040
And the important thing about this is not that Quest sent it out, but that they sent it out because one of their vendors had a problem.

573
00:50:45,060 --> 00:50:54,200
And that vendor was acting as Quest BAA, but Quest ultimately got sued for this breach.

574
00:50:55,200 --> 00:51:04,280
So, when you're doing threat modeling and risk assessments, it's important not only to look at your own systems, but your third parties as well.

575
00:51:04,280 --> 00:51:09,800
And we use the same methodology, the same checklist, to assess all of our vendors.

576
00:51:10,040 --> 00:51:15,060
Now, we have lots of vendors, we are a SaaS first company, we've got SaaS all over the place.

577
00:51:15,240 --> 00:51:23,740
And when somebody comes to us with a new vendor, and let's say it's a project management tool, we can go through this checklist pretty darn quickly, because it doesn't have clinical error.

578
00:51:23,740 --> 00:51:27,040
And it doesn't require licensure.

579
00:51:27,040 --> 00:51:35,360
But when somebody comes to us with a new device vendor, we're going to go through this same model very, very carefully.

580
00:51:35,980 --> 00:51:49,060
And so, when we use threat models to assess vendors, it's the same basic questionnaire, we're doing that checklist, we may or may not also do a brainstorming.

581
00:51:49,920 --> 00:51:54,660
But we then use that to influence our legal terms.

582
00:51:54,660 --> 00:52:06,420
So, if we define the vendor is going to be mission critical, well, that means we have to tell the legal department to make sure we have an SLA in the contract.

583
00:52:06,420 --> 00:52:19,400
And if we're worried about encryption of data at rest, then we have to include that term in the contract, and we have to assess that vendor to make sure that they are doing things we want.

584
00:52:19,400 --> 00:52:26,620
We put legal terms in to say they have to keep our data in the United States, but we then also verify where their data centers are.

585
00:52:26,620 --> 00:52:32,240
So, this model works for assessing vendors, and it works very, very well.

586
00:52:33,480 --> 00:52:36,240
All right, so when do you actually use this?

587
00:52:36,240 --> 00:52:41,900
We've talked a lot about different possibilities for it, and we've got a chart here that addresses a little bit of when to use it.

588
00:52:43,040 --> 00:52:46,680
As you can kind of tell from our examples, we use it all over the place.

589
00:52:47,580 --> 00:52:51,420
Initiations of significant projects, the behavioral health example that Bill just did.

590
00:52:51,420 --> 00:53:00,060
Vendor acquisition for the first time, and then annual assessments, both from a risk assessment perspective and from a vendor assessment perspective.

591
00:53:00,060 --> 00:53:07,620
Bill mentioned earlier that we did it for 26 material business processes on the risk assessment we just completed.

592
00:53:07,620 --> 00:53:19,880
I can't overstate how interesting and helpful that was this year, because traditionally from a compliance and a privacy perspective, risk assessments are really brainstorming in nature.

593
00:53:19,880 --> 00:53:26,020
This forced more rigor than I think we'd even seen last year when we did it a little bit closer to this way.

594
00:53:26,020 --> 00:53:35,140
And it took out the potential for missing things because you're not asking the questions in a regimented way, and that was a huge win.

595
00:53:35,680 --> 00:53:39,540
Resulted in a lot more action items for us to do, but that's a good thing in the grand scheme of things.

596
00:53:39,540 --> 00:53:42,700
There's a lot more because we're aware of it for us to look at.

597
00:53:43,020 --> 00:53:43,980
On demand, too.

598
00:53:43,980 --> 00:53:51,160
There are times when sometimes from an audit perspective, things just crop up and you think, maybe we should take a look at that more detail.

599
00:53:51,160 --> 00:53:53,640
There's the regimented way to actually look through it.

600
00:53:56,220 --> 00:53:56,860
All right.

601
00:53:57,160 --> 00:54:04,760
It does exist in a continuum of activity from a risk assessing perspective, and we've got a little bit of the dimensions that we think about it here.

602
00:54:04,760 --> 00:54:06,980
So threat model on the upper right.

603
00:54:06,980 --> 00:54:15,380
Really, its best practice seems to be when it's a new process or something that we're encountering for the first time, and we have no idea about the dimension of risk on it.

604
00:54:15,380 --> 00:54:17,460
So risk unknown in a new process.

605
00:54:17,780 --> 00:54:27,380
On the left side, there are things that we have an idea about, like processes that we're actually doing, and either how much we know about it or how much we don't know about it.

606
00:54:27,380 --> 00:54:34,580
So on an annual basis, the last few years, what our risks are as a company are pretty stable.

607
00:54:34,580 --> 00:54:37,300
We kind of know the general categories of risk.

608
00:54:37,620 --> 00:54:43,380
So we may not necessarily know with an existing product how it shifted over time.

609
00:54:43,380 --> 00:54:46,880
Take a look at that from an audit perspective, and these overlap.

610
00:54:46,880 --> 00:54:54,460
A threat model, in general, when you're talking about a threat model designs a control, you'll have to retest that control at some point.

611
00:54:54,460 --> 00:54:57,140
So that, in our world, still stays in my universe.

612
00:54:57,140 --> 00:55:01,480
That may get handed off to an internal audit group for them to be able to test that control eventually.

613
00:55:01,580 --> 00:55:02,920
But it's all related.

614
00:55:02,920 --> 00:55:09,200
It does create a completely virtuous circle, I guess you could say, from a control management perspective.

615
00:55:11,480 --> 00:55:15,280
So, final thoughts on all of this.

616
00:55:15,440 --> 00:55:22,860
When you are in security or compliance, your risk assessing organization, your job is actually to say yes.

617
00:55:22,940 --> 00:55:28,300
Security practitioners, we get a bad rap because people think we always say no.

618
00:55:28,300 --> 00:55:33,500
Our job is actually to figure out how to enable and empower the business.

619
00:55:33,580 --> 00:55:38,600
And so really, Patrick and I firmly believe that it's our job to say yes safely.

620
00:55:39,200 --> 00:55:51,140
And one of the ways we can say yes safely is to go through a regimented process of assessing risks and then coming up with action items and say, yes, it's fine to bring this new vendor on.

621
00:55:51,140 --> 00:55:53,400
It's fine to do this new process.

622
00:55:53,400 --> 00:56:03,440
But here are our recommendations for the ways to harden it, to improve the security and compliance and privacy of that system.

623
00:56:03,440 --> 00:56:07,100
And with that, thank you for listening to us.

624
00:56:07,100 --> 00:56:09,040
It's been our pleasure to talk to you.

625
00:56:09,040 --> 00:56:15,080
And we look forward to the Q&A portion here at DEF CON Biohacking Village.