WEBVTT 00:00.000 --> 00:02.540 Hello, my name is Bill Daugherty. 00:02.580 --> 00:05.440 I'm the CISO of Omada Health. 00:05.440 --> 00:09.160 Joining me today is Patrick Curry, our Senior Director of Compliance. 00:09.160 --> 00:13.400 And today we're going to talk about threat modeling in digital health care. 00:13.520 --> 00:20.200 Patrick and I are the co-authors of the Includes No Dirt threat model, which we'll be discussing today. 00:20.620 --> 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. 00:26.700 --> 00:30.820 We've also got some specific exhibits that we've created just for this discussion. 00:31.120 --> 00:35.900 That's at includesnodirt.com slash defcon.pdf. 00:36.020 --> 00:40.840 And thank you for paying attention and watching our talk here today. 00:40.840 --> 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. 00:53.880 --> 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. 01:07.140 --> 01:09.760 Now, if that's out of the way, we can dive into it. 01:10.480 --> 01:12.400 A little bit of background on us. 01:12.400 --> 01:14.920 Omada Health is a digital health care company. 01:14.920 --> 01:17.200 And what is digital health care really? 01:17.200 --> 01:26.720 It is the combination of technology and clinical expertise and humans to deliver better health outcomes. 01:26.720 --> 01:31.440 And we've been doing this for about nine years now, I think. 01:31.440 --> 01:35.100 And we really focus on digital care made human. 01:35.100 --> 01:39.160 So it's not just the machine that you're interacting with. 01:39.520 --> 01:42.020 We do it a little bit differently. 01:43.020 --> 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. 02:01.640 --> 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, 02:24.900 --> 02:25.980 billing and reporting. 02:25.980 --> 02:29.520 That's all of the messy stuff behind the scenes. 02:29.520 --> 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. 02:40.420 --> 02:45.500 And last year, we added behavioral health, so treating anxiety and depression. 02:45.500 --> 02:56.710 Recently, we just bought a company called Physera that does digital physical therapy, so for muscular, skeletal, or pain treatment. 02:57.080 --> 02:58.660 So that's us. 02:58.660 --> 03:01.400 We're going to talk today a little bit about Sam. 03:01.400 --> 03:07.500 Sam is representative of a real participant in our program. 03:07.500 --> 03:08.740 She is not real. 03:09.280 --> 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. 03:18.180 --> 03:21.840 And she does that through tracking her blood values. 03:21.840 --> 03:24.400 That information gets shared with her coach. 03:24.400 --> 03:37.200 Her coach is then giving her advice on meals and exercise and potentially talking about her insulin levels, things like that. 03:37.360 --> 03:40.860 And ultimately, what we're driving towards is behavior change. 03:40.860 --> 03:49.000 We're trying to give our participants lifestyle improvements that will help them better manage their chronic diseases. 03:49.000 --> 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. 03:57.940 --> 03:59.400 But this is what OMADA does. 03:59.400 --> 04:01.160 We do whole person health care. 04:01.680 --> 04:10.960 And we do this with connected devices and lesson plans and coaching and all kinds of stuff. 04:10.960 --> 04:12.780 And we do a lot of it. 04:12.980 --> 04:18.360 We have, since our inception, served more than 350,000 participants. 04:18.360 --> 04:22.560 We have over 1,000 satisfied customers. 04:22.560 --> 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. 04:31.820 --> 04:35.660 And our participants really seem to like our program. 04:35.660 --> 04:37.780 We have a 92% CSAT. 04:38.220 --> 04:39.680 So that's enough about OMADA. 04:39.680 --> 04:46.060 We shared that with you because we want you to understand who we are and why we came to do this. 04:46.060 --> 04:48.160 So why should we do threat models? 04:49.720 --> 04:53.900 Patrick and I started this about two years ago. 04:55.160 --> 04:58.360 In health care, we are required to do annual risk assessments. 04:58.360 --> 05:01.340 The problem with that is nobody ever tells you how. 05:01.340 --> 05:03.040 And we've been doing them for a couple of years. 05:03.040 --> 05:07.020 And we decided that we needed to up our game. 05:07.020 --> 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. 05:20.940 --> 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. 05:29.300 --> 05:30.560 And then your plans go to hell. 05:30.560 --> 05:32.680 And we knew we had blind spots. 05:32.980 --> 05:34.980 And we wanted to get rid of those blind spots. 05:34.980 --> 05:37.520 I love this cartoon, by the way. 05:38.360 --> 05:41.920 On the left side, this is typically how we would deal with things in health care. 05:41.920 --> 05:47.140 We're going to encrypt the laptop because HIPAA says that all the data has to be encrypted at rest. 05:47.220 --> 05:54.200 And then what would actually happen is somebody would force us to reveal our password anyway. 05:56.100 --> 06:00.080 Every time we give a talk on this, we update this slide. 06:00.080 --> 06:07.360 And sadly, I'm never out of companies that have had major breaches in the last six months to update. 06:08.080 --> 06:12.340 But these are examples of really bad things that have happened. 06:12.340 --> 06:17.220 Health care is by far the number one most breached industry, but everybody gets breached. 06:17.220 --> 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. 06:37.100 --> 06:38.960 And yet they still had problems. 06:38.960 --> 06:41.940 And the reason they had problems is because they had blind spots. 06:41.940 --> 06:48.520 So threat modeling is a way to try to eliminate some of those blind spots. 06:50.500 --> 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. 06:58.100 --> 07:03.460 So there's no A for effort here. 07:03.480 --> 07:12.320 But doing threat modeling and doing them consistently will, over time, improve your security and your compliance and your privacy. 07:12.860 --> 07:15.900 And it is by far the right thing to do. 07:16.120 --> 07:17.900 So let's define it a little bit. 07:17.920 --> 07:21.840 In order to really talk about this, we have to have a taxonomy. 07:21.840 --> 07:23.420 We have to all be using the same language. 07:23.420 --> 07:26.260 Lots of people interchange the word threat with risk. 07:26.260 --> 07:28.080 We do that, too, accidentally. 07:28.080 --> 07:30.340 But we had to come to a common language. 07:30.340 --> 07:36.380 And when Patrick and I were working on this model, we were using the same word to mean different things. 07:36.380 --> 07:38.340 So we eventually wrote it down. 07:38.900 --> 07:40.380 This is our taxonomy. 07:40.460 --> 07:41.980 First thing is a system. 07:41.980 --> 07:45.520 And a system is anything you want to model. 07:45.780 --> 07:50.320 Lots of threat modeling focuses on applications, on software. 07:50.320 --> 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. 07:56.900 --> 08:04.140 And the defining characteristic of it is we want to protect it from specific threats. 08:04.500 --> 08:09.140 We just did our annual risk assessment and just completed it. 08:09.140 --> 08:13.740 And this time around, we modeled 26 business processes end-to-end. 08:13.740 --> 08:17.460 So systems typically have defined borders. 08:17.460 --> 08:20.160 You know what the entry point into the system is. 08:20.160 --> 08:21.400 You know what the exit is. 08:21.760 --> 08:24.660 And you can then model it for threats. 08:25.040 --> 08:31.140 Those borders are sometimes called trust boundaries, which are areas where principles can interact. 08:31.480 --> 08:34.520 Sometimes they're called attack surfaces. 08:36.500 --> 08:44.380 The key point is understanding all of the areas that an attack or a risk or a threat can come from. 08:45.020 --> 08:47.520 Vulnerability is a weakness in your system. 08:47.520 --> 08:49.720 Vulnerabilities are things that can be exploited. 08:49.720 --> 08:53.200 So if you have a weak password policy, that is a vulnerability. 08:53.200 --> 08:54.340 It can be exploited. 08:54.340 --> 08:57.700 If you leave your front door unlocked, that is a vulnerability. 08:57.900 --> 09:04.300 That doesn't actually mean that someone will breach your password or open your door, but it is vulnerable for exploitation. 09:04.820 --> 09:07.380 A threat is an actor. 09:07.640 --> 09:09.940 A threat can be a person. 09:09.940 --> 09:13.220 It can be an employee of a third party. 09:13.220 --> 09:15.460 It could be its own business process. 09:15.460 --> 09:17.020 It could be a piece of code. 09:18.720 --> 09:22.460 And threats exploit vulnerabilities. 09:22.460 --> 09:27.360 And we call that an attack vector in our taxonomy. 09:27.800 --> 09:35.300 Risk in this world, then, is the bad outcome that results when a threat exploits a vulnerability. 09:35.300 --> 09:39.700 And we can then measure risks by measuring the likelihood of it happening. 09:39.700 --> 09:41.260 That's the probability. 09:41.380 --> 09:46.280 And the impact, or the cost, if it does happen, that's the impact. 09:47.300 --> 09:49.960 And that's typically how people think about risks. 09:50.440 --> 09:52.260 You'll see this often. 09:52.400 --> 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. 09:59.480 --> 10:03.340 And then we talk about inherent risks and residual risks. 10:03.340 --> 10:06.380 And that's often how risk assessments are done. 10:06.700 --> 10:13.320 In our taxonomy, controls are things we do to reduce the probability or the impact of a risk. 10:13.320 --> 10:17.360 So, if your door is unlocked, that is a vulnerability. 10:17.740 --> 10:21.880 The key and lock is a control. 10:21.880 --> 10:23.220 And you can lock your door. 10:23.220 --> 10:29.300 That doesn't necessarily mean that nobody will open your front door. 10:29.300 --> 10:32.960 It just has lessened the probability of it. 10:33.300 --> 10:35.480 It might have increased the impact, by the way. 10:35.600 --> 10:40.660 So, controls have... there's no panacea to them. 10:40.660 --> 10:46.900 But we do need to model what are the risks and then what are the controls. 10:46.900 --> 10:51.500 And when we do that, we can then figure out what are the residual risks. 10:51.740 --> 10:53.700 Threat modeling is just an analysis. 10:53.700 --> 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. 11:00.540 --> 11:04.440 And defined list of risks is really important. 11:06.320 --> 11:11.360 Because we can sit around and talk about every bad outcome under the sun. 11:11.820 --> 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. 11:20.620 --> 11:22.160 And then lastly, action items. 11:22.160 --> 11:23.420 This is the result. 11:23.420 --> 11:26.080 This is what we're trying to get out of a threat model. 11:26.560 --> 11:29.500 We've looked at all the bad things that could happen. 11:29.500 --> 11:31.720 We've measured the probability of impact. 11:31.720 --> 11:33.860 We've assessed the controls we have. 11:33.860 --> 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. 11:39.720 --> 11:45.820 And we're going to reduce the risk by creating new controls that either reduce the probability or the impact. 11:46.060 --> 11:47.600 So that's our taxonomy. 11:47.600 --> 11:50.500 If I can add to that while you change slides on that. 11:50.500 --> 11:56.020 One thing that was super critical for us is just exactly that taxonomy. 11:56.020 --> 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. 12:05.380 --> 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. 12:14.940 --> 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. 12:27.080 --> 12:30.280 Getting on the same page is really important. 12:31.120 --> 12:31.740 Absolutely. 12:31.740 --> 12:32.880 I could not agree more. 12:32.880 --> 12:34.800 And thank you for jumping in so I can take a drink. 12:37.500 --> 12:43.980 We would love to think that we were the inventors of all threat models and the geniuses who wrote this down. 12:43.980 --> 12:45.380 The truth is we're not. 12:45.700 --> 12:51.240 There are lots of very, very good threat models out there in the ether. 12:51.240 --> 12:54.640 And we borrowed heavily from them. 12:54.640 --> 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, 13:12.840 --> 13:14.980 whether it's in healthcare or any other. 13:14.980 --> 13:18.920 So our starting point was this wonderful book here by Adam Shostak. 13:18.920 --> 13:24.680 I think he may be talking at BlackHat or DEF CON this week on threat modeling. 13:25.420 --> 13:27.140 It is fantastic. 13:27.140 --> 13:29.460 If you don't own it, I highly recommend it. 13:29.460 --> 13:31.320 He didn't pay me to say that. 13:32.200 --> 13:34.900 And we'll talk a little bit more about what's in that. 13:34.900 --> 13:37.340 But that's really on the software design standpoint. 13:37.340 --> 13:41.600 On the privacy design, there's this model called Linden. 13:41.600 --> 13:43.520 And again, it's excellent. 13:43.520 --> 13:49.280 So Adam's book largely focuses on the stride threat model. 13:49.280 --> 13:51.980 This is something that came out of Microsoft. 13:52.060 --> 14:01.980 And this was a way of getting software engineers to assess the major threats to applications. 14:01.980 --> 14:06.200 And they had narrowed down to really six areas. 14:06.200 --> 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, 14:24.860 --> 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. 14:33.600 --> 14:34.700 That's the stride model. 14:34.700 --> 14:35.840 It's excellent. 14:35.940 --> 14:37.360 Please go read about it. 14:37.360 --> 14:40.540 If you haven't already done so, get Adam's book. 14:40.540 --> 14:47.300 On the privacy side, the Linden model is also excellent. 14:47.620 --> 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. 14:59.700 --> 15:05.900 So in the stride model, we're worried about repudiation. 15:05.900 --> 15:08.880 Can somebody do something and then deny they did it? 15:08.880 --> 15:11.520 In privacy, we're worried about non-repudiation. 15:11.520 --> 15:13.160 Can I do something anonymously? 15:13.680 --> 15:17.100 And so we borrowed heavily from the Linden model as well. 15:17.100 --> 15:19.980 But there's some other models out there that are also good. 15:20.180 --> 15:24.500 Bruce Schneier wrote extensively about attack trees. 15:24.540 --> 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. 15:34.900 --> 15:36.680 So how could I open a safe? 15:36.680 --> 15:37.680 Well, I'd have to learn the combo. 15:37.680 --> 15:38.700 That would be one way. 15:39.240 --> 15:40.960 Or I could cut it open. 15:40.960 --> 15:43.600 And to learn the combo, how would I do that? 15:43.860 --> 15:50.500 And you walk down that, and then you start figuring out what is possible, what's not possible. 15:51.120 --> 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. 15:57.840 --> 16:00.880 Kill chains came out of the military. 16:01.400 --> 16:08.300 And again, it's a way of modeling what needs to be done for somebody to execute an attack. 16:08.300 --> 16:15.520 And if you interrupt any step of the kill chain, you can impact or possibly prevent the attack. 16:15.520 --> 16:18.220 Both excellent models. 16:18.680 --> 16:19.800 Security scorecards. 16:19.800 --> 16:23.680 These came out of the University of Washington. 16:23.680 --> 16:27.240 This is a way of training threat modelers on how to do threat modeling. 16:27.240 --> 16:29.020 It's actually a deck of cards. 16:29.020 --> 16:33.060 And I have a deck that's at my office that's under lockdown from COVID. 16:33.120 --> 16:37.960 But it talks a lot about motivations and resources and methods. 16:37.960 --> 16:42.360 And it's really just a training mechanism, but they're worth checking out. 16:42.360 --> 16:44.800 And there are a ton of other models. 16:44.960 --> 16:49.120 I found this white paper from Carnegie Mellon on threat modeling. 16:49.480 --> 16:51.000 It's excellent. 16:51.000 --> 16:54.700 I highly recommend the POSTA model just because I like the name. 16:54.700 --> 16:58.160 But there's lots of models out there. 16:58.160 --> 17:02.720 But none of them really fit what Patrick and I wanted to do. 17:02.720 --> 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. 17:12.240 --> 17:21.440 And deal with all the intersections between compliance and security and privacy and ultimately reduce the risk of our organization. 17:23.440 --> 17:25.440 Lots of people do brainstorming. 17:25.640 --> 17:29.160 Brainstorming is the simplest form of threat modeling. 17:29.160 --> 17:30.560 It has its place. 17:30.560 --> 17:32.120 We do it too. 17:33.440 --> 17:36.080 But it also has its limitations. 17:36.380 --> 17:40.380 And we talked, I said earlier that we don't model everything. 17:40.380 --> 17:43.860 We model the things that are applicable to our system. 17:43.860 --> 17:48.380 And this is kind of a typical traditional threat model. 17:48.380 --> 17:50.620 We talked about SAM earlier. 17:50.620 --> 17:52.720 We're going to talk about SAM again later. 17:52.940 --> 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. 18:04.060 --> 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? 18:08.120 --> 18:12.380 And everybody starts drawing things and we say, well, I'd do a man in the middle of the application. 18:12.380 --> 18:14.960 Or I'd do a denial of service on the API. 18:15.140 --> 18:18.360 Or I'd do a breach of the partner. 18:18.360 --> 18:22.700 Or I'd figure out some way to hack the device to harm the participant. 18:23.460 --> 18:29.220 And that is one way of doing threat modeling, but it ignores lots of things. 18:29.220 --> 18:33.320 It ignores the motivations and capabilities of the attacker. 18:33.340 --> 18:40.600 It ignores the objectives of the system. 18:40.600 --> 18:44.580 It also ignores all of the controls we already have in place. 18:44.580 --> 18:49.340 Because we've already done things, like we've got TLS written up here. 18:49.340 --> 18:51.860 That's control that we encrypt the traffic. 18:52.220 --> 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. 19:03.900 --> 19:06.780 And threat models are done via brainstorming. 19:06.780 --> 19:08.600 They're limited by your imagination. 19:08.600 --> 19:11.680 And failures of imagination lead to blind spots. 19:11.680 --> 19:14.880 So this was the problem we were trying to solve. 19:15.200 --> 19:18.540 And now Patrick is going to talk about what we actually did. 19:18.560 --> 19:20.920 And specifically the includes-no-dirt model. 19:21.460 --> 19:22.140 Yeah, exactly. 19:22.140 --> 19:22.840 Thanks, Bill. 19:22.980 --> 19:25.400 So exactly that's what we were trying to solve for. 19:25.400 --> 19:27.360 There's a lot of dimensions to that. 19:27.440 --> 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. 19:34.960 --> 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. 19:41.300 --> 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. 19:49.520 --> 19:53.600 And that regimentation and that process actually drives us to that one. 19:53.600 --> 19:54.860 Okay, next slide. 19:55.200 --> 19:58.800 So what we were looking for in coming up with this process. 19:58.800 --> 20:02.520 Something that was easy for a non-SME to understand. 20:02.640 --> 20:07.380 Something that we could-and something that would be easy for someone to perform. 20:07.380 --> 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. 20:22.720 --> 20:25.480 We wanted something that was flexible and repeatable. 20:25.480 --> 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. 20:33.380 --> 20:36.260 We wanted something that was usable anywhere. 20:36.260 --> 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. 20:43.620 --> 20:47.340 And of course, since we were putting a lot of effort into this, we wanted it to be memorable. 20:47.400 --> 20:49.740 Because why not when you're building it? 20:49.840 --> 20:54.060 And some creative uses of anagram generators actually got us where we are. 20:54.060 --> 20:55.120 So, next slide. 20:55.320 --> 20:57.480 So what we created with this process. 20:57.700 --> 21:00.960 It's a systematized approach to analyzing risks. 21:01.260 --> 21:03.500 That pays a couple of different dividends. 21:03.500 --> 21:08.100 One is it's systematized and it's easy to execute like we were just discussing. 21:08.100 --> 21:13.940 It's also interestingly started to be a key for us to explain how we think about risks. 21:13.940 --> 21:20.400 So it structures educational conversations when we have them with staff so they understand what we're trying to do. 21:20.880 --> 21:23.900 It's a repeatable process with objective scoring. 21:23.900 --> 21:25.660 So another huge win there. 21:25.660 --> 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. 21:31.520 --> 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. 21:36.660 --> 21:42.200 That help us compare across risks or across even domains in what we're looking at. 21:42.200 --> 21:45.340 How we think about risks and what do we do first. 21:45.380 --> 21:49.160 There's never enough time, there's never enough resource, how do you focus your time? 21:49.380 --> 21:51.340 We wanted a system-centered approach. 21:51.340 --> 21:55.260 So something that isn't really focused on the thing that you're modeling. 21:55.260 --> 22:00.360 But something that actually is focused on the thing that you're modeling but not on the process itself. 22:01.700 --> 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. 22:09.020 --> 22:13.220 Bill mentioned we focused on established controls and that's really important. 22:13.220 --> 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. 22:20.040 --> 22:22.400 Then we don't actually have to include it in the model. 22:22.400 --> 22:26.740 And in the example we'll show you, we've gone through a few things and eliminated it. 22:26.740 --> 22:29.060 Because they either don't apply or we know that it works. 22:29.060 --> 22:34.000 Lastly, we wanted to have a model that covers all of the domains we think are important. 22:34.000 --> 22:36.020 Privacy, security, and compliance. 22:36.020 --> 22:41.700 So not having three different models or three different versions and being able to include different regulatory regimens. 22:41.960 --> 22:42.880 Next slide. 22:44.760 --> 22:45.620 Alright. 22:46.000 --> 22:51.540 What we created with Includes No Dirt, the model that we have, your mileage may vary on this one. 22:51.540 --> 22:55.280 We designed it for our own uses at Omada Health. 22:55.280 --> 23:01.100 And if you're in the healthcare space, it may be directly applicable with the questions that we have. 23:01.100 --> 23:04.660 You may have to swap out some of the specific regulatory questions. 23:04.660 --> 23:08.740 If you're in an adjacent industry, it may need some questions adapted. 23:08.740 --> 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. 23:14.880 --> 23:15.660 Next slide. 23:16.300 --> 23:16.720 Alright. 23:16.720 --> 23:17.980 And one last, the teaser. 23:17.980 --> 23:19.800 It is the Includes No Dirt model. 23:20.100 --> 23:23.740 And it has been arranged to actually be memorable. 23:23.740 --> 23:36.500 So identifiability, non-repudiation, clinical error, linkability, unlicensed activity, denial of service, elevation of privilege, spoofing, non-compliance to policy, overuse. 23:36.500 --> 23:42.720 Specifically, they were thinking of overuse of information and data as really pertains to the HIPAA space that we're in. 23:43.000 --> 23:48.720 Dirt, data error, information disclosure, repudiation, and tampering. 23:48.720 --> 23:51.860 So all those parts play together to make the model that we're using. 23:51.860 --> 23:52.580 Next slide. 23:53.740 --> 23:59.200 So for every risk, there's a property and a goal, and it comes from a specific place. 23:59.220 --> 24:00.680 So you skip down a couple. 24:00.680 --> 24:02.040 Clinical error. 24:02.420 --> 24:04.160 The risk is clinical error. 24:04.160 --> 24:07.340 A clinician making a mistake that may otherwise have been prevented. 24:07.520 --> 24:12.820 The property or the goal of that is the application of correct clinical standards. 24:12.820 --> 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. 24:19.520 --> 24:20.840 That's in the realm of compliance. 24:20.840 --> 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. 24:27.420 --> 24:28.360 Next slide. 24:32.000 --> 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. 24:41.640 --> 24:45.380 And I don't think I can say that enough strongly in the title slide. 24:45.580 --> 24:49.840 The risks that apply depend on the system being modeled. 24:49.840 --> 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? 24:56.060 --> 24:57.580 How does it apply? 24:57.980 --> 25:00.680 And some things you may just factor out as you go through it. 25:00.700 --> 25:05.580 So these three in particular are complicated because they are very related. 25:05.580 --> 25:08.200 And Bill alluded to it at the beginning. 25:08.300 --> 25:13.940 Security and privacy sometimes are at opposite ends of what they're trying to do. 25:13.940 --> 25:16.060 And these tend to reflect it here. 25:16.060 --> 25:22.260 So identifiability, the property of a system that allows users to trace to a specific user. 25:22.300 --> 25:31.180 So there, the objective or the goal is anonymity, making sure that that's not actually possible. 25:31.360 --> 25:38.840 A risk of non-repudiation, non-repudiation, the process by which it's proven that a user took an action. 25:38.900 --> 25:41.460 The goal there is plausible deniability. 25:42.560 --> 25:45.800 It isn't clear if someone did something or not. 25:45.880 --> 25:48.020 The risk is repudiation. 25:48.640 --> 25:52.920 And here, what we're trying to get to is non-repudiation. 25:52.920 --> 25:58.420 So where someone can actually show that it actually hasn't happened yet. 25:58.420 --> 26:04.720 So these of note actually came from different parts, some from Stride, some from Lyndon. 26:04.720 --> 26:06.940 So privacy and security blended together. 26:07.120 --> 26:10.820 On the next slide and the next couple, we'll actually kind of unpack that a little bit. 26:10.820 --> 26:14.660 So de-conflicting these goals can be kind of complicated on this. 26:14.660 --> 26:18.380 Different stakeholders will have different needs for these things. 26:18.380 --> 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. 26:27.800 --> 26:30.780 We've got a whistle here for a whistleblower. 26:30.780 --> 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. 26:43.660 --> 26:49.660 But then for other goals and other people in the system, less important. 26:49.660 --> 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. 27:01.460 --> 27:06.360 Repudiation and non-repudiation as well. 27:06.360 --> 27:09.700 Let's get into a little bit more of a specific example on the next slide, though. 27:09.700 --> 27:18.460 So let's say Human Resources wants to build or wants an employee complaint application that lets employees report sexual harassment. 27:19.280 --> 27:25.500 Lots of different goals, lots of different stakeholders, and figuring out how to balance between them gets really important. 27:25.500 --> 27:32.980 So employees want to be able to report and want, if they want to have anonymity, that their anonymity is protected. 27:32.980 --> 27:37.540 If they want to say something anonymous, they can't, and no one will know who it is. 27:37.960 --> 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. 27:52.020 --> 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. 27:58.960 --> 28:03.900 Security runs DLP on every laptop, logs who has access to the application. 28:04.000 --> 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. 28:18.180 --> 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. 28:29.160 --> 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. 28:35.000 --> 28:44.720 So you have lots of different people running in the system with different needs, different roles, and those roles will conflict. 28:44.720 --> 28:50.620 So we can't completely make everything anonymous because then security and IT can't do their work. 28:51.200 --> 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. 28:59.580 --> 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. 29:09.700 --> 29:11.260 All right, I think it's back to you. 29:11.340 --> 29:13.320 All right, so let's give it a try. 29:13.760 --> 29:15.420 Time to come back to Sam. 29:15.420 --> 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. 29:34.620 --> 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. 29:51.440 --> 29:59.300 So we want to introduce CGMs into our product set, but we want to do it safely. 29:59.300 --> 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. 30:09.120 --> 30:17.180 And again, you can download the one we've filled out at includesnodirt.com slash defcon.pdf. 30:17.180 --> 30:19.520 I highly encourage you to do so. 30:21.120 --> 30:23.260 We talked about brainstorming. 30:23.260 --> 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. 30:39.320 --> 30:42.200 So again, I'm going to come back to this is our diagram. 30:42.200 --> 30:44.940 In our diagram, we have a wearable glucometer. 30:45.080 --> 30:54.420 That glucometer syncs to an application on the patient's cell phone, which then transmits the data to the partner. 30:54.420 --> 31:02.280 The partner then sends it to our endpoint, and it gets stored in our database. 31:02.280 --> 31:07.460 It then sends information back to our application. 31:07.460 --> 31:10.180 It also surfaces that information to the coach. 31:10.280 --> 31:15.720 And you'll see here that in addition to the CGM, the participant still has a BGM. 31:15.720 --> 31:24.260 So still does occasional finger sticks, and that information is also being sent to us. 31:24.260 --> 31:28.720 So we've got two sources now of blood sugar data. 31:28.720 --> 31:31.920 So this is the diagram we're going to be working off of. 31:32.280 --> 31:36.960 In our worksheet that we provided you, it's highly structured. 31:36.960 --> 31:40.980 One of the first things we do is we mark which threats we think apply. 31:40.980 --> 31:43.320 Who are the actors that are involved here? 31:44.000 --> 31:51.140 So certainly the participant is involved in this whole process, and the coach is involved, but we've got a vendor. 31:52.160 --> 31:55.120 We've got potentially other partners. 31:55.120 --> 31:58.320 We're going to be doing claims on this and billing. 31:58.320 --> 31:59.720 We're reporting. 31:59.760 --> 32:02.780 So there's business processes, there's people. 32:02.900 --> 32:05.580 For this one, we're not so worried about natural disasters. 32:05.580 --> 32:12.800 We're not so worried about geopolitical unrest, but other threat models, those might come into play. 32:13.980 --> 32:18.600 And we then do some brainstorming on vulnerabilities. 32:19.560 --> 32:22.800 So what are areas that could be vulnerable? 32:22.800 --> 32:29.500 They get an incorrect reading, or the service becomes unavailable, or the coach misinterprets the data. 32:29.500 --> 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. 32:37.200 --> 32:39.460 And this is an iterative process. 32:39.460 --> 32:44.480 We sometimes start with the questionnaire, and we sometimes start with the worksheet. 32:44.480 --> 32:50.920 But it's typical when we are doing one of these on a complex system, we are going back and forth. 32:50.920 --> 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. 33:02.180 --> 33:05.840 Let's go write that down on our worksheet on vulnerabilities. 33:05.840 --> 33:08.900 Let's go ask somebody to get more information. 33:08.900 --> 33:17.940 And we go through this process until we think we've got the questionnaire complete and the worksheet complete. 33:17.940 --> 33:19.980 And so we did that. 33:20.280 --> 33:26.680 And when we did that, we were able to take those vulnerabilities that I've listed here. 33:26.680 --> 33:28.920 There's five of them in our example. 33:28.920 --> 33:34.560 And we're mapping those to specific areas in the includes-no-dirt model. 33:35.620 --> 33:38.280 So you'll see, like, anonymity. 33:38.280 --> 33:39.380 We don't want anonymity. 33:39.380 --> 33:43.560 It doesn't apply in this one, but clinical error certainly does. 33:43.560 --> 33:47.190 And denial of service does, and spoofing does. 33:47.190 --> 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. 34:02.870 --> 34:07.050 And again, you can download our example and see our answers on all of them. 34:07.050 --> 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. 34:18.890 --> 34:22.330 These are the things we're worried about in this particular threat model. 34:23.390 --> 34:26.050 So Patrick, let's start with clinical error. 34:26.170 --> 34:26.730 Sure. 34:26.730 --> 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. 34:36.070 --> 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. 34:43.570 --> 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. 34:52.430 --> 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. 34:57.490 --> 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? 35:07.330 --> 35:09.990 Well, of course we are in this particular example. 35:09.990 --> 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, 35:26.650 --> 35:29.290 we'd be able to find it and correct it as quickly as we can. 35:29.290 --> 35:31.230 So answer here, yes. 35:31.230 --> 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. 35:42.850 --> 35:49.170 Each one of those has specific detective and preventive controls that operate in its own environment. 35:49.170 --> 35:54.830 And this is a great example of what Bill just said related to the iterative nature of this. 35:54.830 --> 36:00.630 When we hit this question, it's like, okay, wait, that's both the device and the software. 36:00.630 --> 36:01.450 How does that work? 36:01.450 --> 36:04.630 And we had to fork a little bit, came back, yep, that's exactly right. 36:05.150 --> 36:11.670 In questions 3.2 and 3.3, we delve down a little bit into some additional control work. 36:11.970 --> 36:16.390 And another thing I would say here is, not all controls are technical. 36:16.390 --> 36:24.990 In this particular case, with clinical error, part of preventing clinical errors is ensuring both the proper training of your clinicians. 36:24.990 --> 36:28.710 So being able to say, yeah, everybody that has access to this was properly trained. 36:28.810 --> 36:31.810 I almost said licensure, that's coming soon. 36:32.530 --> 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. 36:40.170 --> 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. 36:49.550 --> 36:50.630 All right, next slide. 36:50.630 --> 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. 37:01.430 --> 37:08.390 If we'd answered no, we can skip the rest of the questions on clinical and move on to question 4. 37:08.730 --> 37:11.370 So those two things are really important. 37:11.370 --> 37:15.770 At the end of this, we're going to total up all the points, and that will drive a risk score. 37:15.770 --> 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. 37:24.230 --> 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. 37:36.270 --> 37:41.750 For something that's complicated, and this would be a fairly complicated one, it might take us several hours. 37:41.750 --> 37:48.850 But the model fits whichever size system, whichever level of complexity we're dealing with. 37:49.470 --> 37:51.630 Definitely, thanks for pointing that out. 37:51.990 --> 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. 37:59.550 --> 38:04.750 Second one, unlicensed activity, and I spilled it a little bit ago just talking about it. 38:04.750 --> 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? 38:13.970 --> 38:21.170 Just like the last question, yes, it does, and it's complicated because different parts of this thing require different licensure. 38:21.170 --> 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. 38:40.760 --> 38:45.880 Also important here is the fact that we rely on other people in these things. 38:45.880 --> 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. 38:53.160 --> 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. 39:03.820 --> 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. 39:14.580 --> 39:15.960 I think you're next. 39:15.960 --> 39:17.060 Denial of service. 39:17.060 --> 39:22.640 So this is where we start looking about how mission critical the system is that we are modeling. 39:22.640 --> 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, 39:45.140 --> 39:50.100 back to the participant, and being able to make decisions on that data. 39:50.100 --> 39:54.180 So when we go through our model, we ask, is it a mission critical system? 39:54.180 --> 39:57.260 If it is, that raises the point value. 39:57.400 --> 40:03.440 And then we look at, have we defined targets, and what are those targets, and how are they enforced? 40:03.760 --> 40:08.880 And again, Patrick said not all controls are technical. 40:08.900 --> 40:14.140 For the partner, they've got technical controls to ensure their availability. 40:14.140 --> 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. 40:28.040 --> 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. 40:38.400 --> 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. 40:52.740 --> 40:58.460 So we have defined authentication levels for our participants. 40:58.460 --> 41:06.380 We base it on NIST 800-63B, and they're defined as an AAL Level 1. 41:06.380 --> 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. 41:13.120 --> 41:14.660 We test those. 41:14.660 --> 41:15.700 We know it works. 41:15.700 --> 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. 41:23.880 --> 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. 41:36.800 --> 41:38.340 All right. 41:38.820 --> 41:39.640 Noncompliance. 41:39.640 --> 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. 41:51.680 --> 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, 42:08.680 --> 42:11.060 there's a number of healthcare compliance issues. 42:11.060 --> 42:16.760 There would be FDA obligations for our business partners, the contracts that Bill just mentioned. 42:16.860 --> 42:21.240 So because this is clinical in nature, it relates to a device. 42:21.240 --> 42:22.820 There's patient data involved with it. 42:22.820 --> 42:24.840 This one's particularly complicated. 42:24.840 --> 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. 42:38.240 --> 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. 42:55.000 --> 42:58.060 So that was important to kind of drive through that. 42:58.060 --> 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. 43:05.800 --> 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. 43:11.760 --> 43:14.120 Okay, next one I think is mine as well. 43:14.140 --> 43:15.300 Data error. 43:15.300 --> 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. 43:35.000 --> 43:41.020 It's really important to make sure that this is ingested and maintained in an accurate and viable way. 43:41.660 --> 43:47.560 Again, here, in other includes no dirt models that we've actually done, we've tested some of that. 43:47.560 --> 43:51.580 We've tested, for example, the APIs that we do data ingestion with. 43:51.580 --> 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. 44:04.280 --> 44:06.600 So information disclosure. 44:06.820 --> 44:10.240 This is where we're worried about confidentiality of the system. 44:10.260 --> 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. 44:23.360 --> 44:30.100 And again, here, we're largely consuming controls that we've already tested previously. 44:30.100 --> 44:35.740 So HIPAA requires us to encrypt PHI at rest and in transit. 44:35.740 --> 44:38.940 So we can ask, are we doing that? 44:38.940 --> 44:40.540 And if so, how? 44:40.620 --> 44:48.200 And since those are really well-known patterns for us, we can accept them and we can move on. 44:48.200 --> 44:51.520 It doesn't actually require a ton of discussion. 44:52.540 --> 44:55.360 Down at 12.6, data locality. 44:55.360 --> 44:57.240 This is a really good reminder for us. 44:57.360 --> 45:03.140 We have obligations to keep all of our data within the United States, processed, stored, and accessed. 45:03.320 --> 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. 45:18.360 --> 45:19.160 Repudiation. 45:19.160 --> 45:21.720 We've talked a lot about repudiation already. 45:22.860 --> 45:25.320 Does it require non-repudiation? 45:25.320 --> 45:25.740 Yes. 45:25.740 --> 45:27.500 What are those mechanisms? 45:27.720 --> 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. 45:37.480 --> 45:39.780 How are user activities being logged? 45:39.880 --> 45:41.840 Do we have accurate timestamps? 45:41.840 --> 45:45.080 How long are logs retained? 45:45.080 --> 45:46.080 Things like that. 45:47.040 --> 45:55.480 That lets us know that this particular system is going to fit into our overall framework. 45:57.080 --> 45:58.180 And tampering. 45:58.760 --> 46:01.040 We don't want anyone to mess with the data. 46:01.380 --> 46:05.940 So, again, what are all the mechanisms in place to prevent tampering? 46:05.940 --> 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. 46:21.160 --> 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? 46:32.460 --> 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. 46:41.380 --> 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. 46:54.000 --> 46:56.660 So, again, the model is iterative. 46:56.660 --> 46:58.000 It lets us go through it. 46:58.000 --> 47:03.180 And it reminds us to check, how are all these things being addressed for this? 47:03.180 --> 47:06.260 It is a very structured way of brainstorming. 47:07.020 --> 47:08.940 And we get to the end, we get a score. 47:10.240 --> 47:11.600 Patrick, you want to talk about this? 47:11.600 --> 47:12.280 Oh, sure. 47:12.360 --> 47:12.860 Yeah. 47:12.860 --> 47:15.240 So, as Bill said, we get to the end and we get a score. 47:15.240 --> 47:17.680 So, the product of all the numbers that you saw on the side. 47:17.680 --> 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. 47:28.460 --> 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. 47:35.300 --> 47:39.400 But essentially, the product of that turns into a total score. 47:39.660 --> 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? 47:50.180 --> 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? 47:56.880 --> 48:00.000 On the right side, you actually see the list of action items. 48:00.000 --> 48:04.220 You saw that in a prior slide as far as how those work. 48:04.220 --> 48:06.400 Here's the specific action items for this one. 48:06.400 --> 48:08.880 So, for example, for this particular model. 48:08.880 --> 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. 48:22.300 --> 48:25.180 So, this addresses the clinical vulnerability issue. 48:25.340 --> 48:31.420 Backups to BGM and CGM also touches on some of the same issues. 48:31.460 --> 48:37.760 Sometimes that's required just because of the nature of the CGM and so forth with all of these. 48:37.760 --> 48:43.180 Each one of those action items is designed to address one or more vulnerabilities. 48:43.180 --> 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. 48:52.280 --> 48:54.760 And we've done a lot of these. 48:54.800 --> 48:59.260 I mentioned earlier that we launched a behavioral health application. 48:59.260 --> 49:02.540 And when we did that, Patrick and I did a threat model. 49:02.540 --> 49:05.520 And I think we came up with 19 action items. 49:05.520 --> 49:16.720 And those were specific things that we wanted to ingest into the system before we went live. 49:16.720 --> 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. 49:35.060 --> 49:41.360 And everybody involved also understood, because they went through the process with us, why. 49:41.360 --> 49:48.440 They knew why we had those action items, and what was the specific vulnerability we were trying to address. 49:48.780 --> 49:50.380 That latter is very important. 49:50.380 --> 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. 50:00.220 --> 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. 50:10.600 --> 50:15.480 So, it becomes educational as well as helpful, just as a reminder as to why we're doing it. 50:17.040 --> 50:20.280 So, a couple of points to wrap this up. 50:20.380 --> 50:24.940 Vendor management, the threats you aren't seeing can also kill you. 50:25.640 --> 50:35.760 I use this example, this was a letter that Quest Diagnostics sent out about a year ago on a breach. 50:35.760 --> 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. 50:45.060 --> 50:54.200 And that vendor was acting as Quest BAA, but Quest ultimately got sued for this breach. 50:55.200 --> 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. 51:04.280 --> 51:09.800 And we use the same methodology, the same checklist, to assess all of our vendors. 51:10.040 --> 51:15.060 Now, we have lots of vendors, we are a SaaS first company, we've got SaaS all over the place. 51:15.240 --> 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. 51:23.740 --> 51:27.040 And it doesn't require licensure. 51:27.040 --> 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. 51:35.980 --> 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. 51:49.920 --> 51:54.660 But we then use that to influence our legal terms. 51:54.660 --> 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. 52:06.420 --> 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. 52:19.400 --> 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. 52:26.620 --> 52:32.240 So, this model works for assessing vendors, and it works very, very well. 52:33.480 --> 52:36.240 All right, so when do you actually use this? 52:36.240 --> 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. 52:43.040 --> 52:46.680 As you can kind of tell from our examples, we use it all over the place. 52:47.580 --> 52:51.420 Initiations of significant projects, the behavioral health example that Bill just did. 52:51.420 --> 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. 53:00.060 --> 53:07.620 Bill mentioned earlier that we did it for 26 material business processes on the risk assessment we just completed. 53:07.620 --> 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. 53:19.880 --> 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. 53:26.020 --> 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. 53:35.680 --> 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. 53:39.540 --> 53:42.700 There's a lot more because we're aware of it for us to look at. 53:43.020 --> 53:43.980 On demand, too. 53:43.980 --> 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. 53:51.160 --> 53:53.640 There's the regimented way to actually look through it. 53:56.220 --> 53:56.860 All right. 53:57.160 --> 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. 54:04.760 --> 54:06.980 So threat model on the upper right. 54:06.980 --> 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. 54:15.380 --> 54:17.460 So risk unknown in a new process. 54:17.780 --> 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. 54:27.380 --> 54:34.580 So on an annual basis, the last few years, what our risks are as a company are pretty stable. 54:34.580 --> 54:37.300 We kind of know the general categories of risk. 54:37.620 --> 54:43.380 So we may not necessarily know with an existing product how it shifted over time. 54:43.380 --> 54:46.880 Take a look at that from an audit perspective, and these overlap. 54:46.880 --> 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. 54:54.460 --> 54:57.140 So that, in our world, still stays in my universe. 54:57.140 --> 55:01.480 That may get handed off to an internal audit group for them to be able to test that control eventually. 55:01.580 --> 55:02.920 But it's all related. 55:02.920 --> 55:09.200 It does create a completely virtuous circle, I guess you could say, from a control management perspective. 55:11.480 --> 55:15.280 So, final thoughts on all of this. 55:15.440 --> 55:22.860 When you are in security or compliance, your risk assessing organization, your job is actually to say yes. 55:22.940 --> 55:28.300 Security practitioners, we get a bad rap because people think we always say no. 55:28.300 --> 55:33.500 Our job is actually to figure out how to enable and empower the business. 55:33.580 --> 55:38.600 And so really, Patrick and I firmly believe that it's our job to say yes safely. 55:39.200 --> 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. 55:51.140 --> 55:53.400 It's fine to do this new process. 55:53.400 --> 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. 56:03.440 --> 56:07.100 And with that, thank you for listening to us. 56:07.100 --> 56:09.040 It's been our pleasure to talk to you. 56:09.040 --> 56:15.080 And we look forward to the Q&A portion here at DEF CON Biohacking Village.