start	end	text
0	9160	Hello, my name is Bill Daugherty. I'm the CISO of Omada Health. Joining me today is Patrick Curry, our Senior Director of Compliance.
9160	13400	And today we're going to talk about threat modeling in digital health care.
13520	20200	Patrick and I are the co-authors of the Includes No Dirt threat model, which we'll be discussing today.
20620	26700	If you'd like to follow along with us, you can go to includesnodirt.com and download our white paper on that threat model.
26700	30820	We've also got some specific exhibits that we've created just for this discussion.
31120	35900	That's at includesnodirt.com slash defcon.pdf.
36020	40840	And thank you for paying attention and watching our talk here today.
40840	53880	Standard disclaimer, we have put together a discussion that is based on some real-world concepts, but this is not a real-world situation.
53880	67100	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.
67140	69760	Now, if that's out of the way, we can dive into it.
70480	74920	A little bit of background on us. Omada Health is a digital health care company.
74920	86720	And what is digital health care really? It is the combination of technology and clinical expertise and humans to deliver better health outcomes.
86720	91440	And we've been doing this for about nine years now, I think.
91440	95100	And we really focus on digital care made human.
95100	99160	So it's not just the machine that you're interacting with.
99520	102020	We do it a little bit differently.
103020	121640	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.
121640	145980	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, billing and reporting.
145980	149520	That's all of the messy stuff behind the scenes.
149520	159850	We have four diseases that have been kind of our core, which is type 2 diabetes prevention, type 2 diabetes treatment, hypertension.
160420	165500	And last year, we added behavioral health, so treating anxiety and depression.
165500	176710	Recently, we just bought a company called Physera that does digital physical therapy, so for muscular, skeletal, or pain treatment.
177080	178660	So that's us.
178660	181400	We're going to talk today a little bit about Sam.
181400	187500	Sam is representative of a real participant in our program.
187500	188740	She is not real.
189280	198180	But Sam would be a participant who has type 2 diabetes and is using our program to try to better manage her disease state.
198180	201840	And she does that through tracking her blood values.
201840	204400	That information gets shared with her coach.
204400	217200	Her coach is then giving her advice on meals and exercise and potentially talking about her insulin levels, things like that.
217360	220860	And ultimately, what we're driving towards is behavior change.
220860	229000	We're trying to give our participants lifestyle improvements that will help them better manage their chronic diseases.
229000	237680	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.
237940	239400	But this is what OMADA does.
239400	241160	We do whole person health care.
241680	250960	And we do this with connected devices and lesson plans and coaching and all kinds of stuff.
250960	252780	And we do a lot of it.
252980	258360	We have, since our inception, served more than 350,000 participants.
258360	262560	We have over 1,000 satisfied customers.
262560	271820	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.
271820	275660	And our participants really seem to like our program.
275660	277780	We have a 92% CSAT.
278220	279680	So that's enough about OMADA.
279680	286060	We shared that with you because we want you to understand who we are and why we came to do this.
286060	288160	So why should we do threat models?
289720	293900	Patrick and I started this about two years ago.
295160	298360	In health care, we are required to do annual risk assessments.
298360	301340	The problem with that is nobody ever tells you how.
301340	303040	And we've been doing them for a couple of years.
303040	307020	And we decided that we needed to up our game.
307020	319900	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.
320940	329240	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.
329300	330560	And then your plans go to hell.
330560	332680	And we knew we had blind spots.
332980	334980	And we wanted to get rid of those blind spots.
334980	337520	I love this cartoon, by the way.
338360	341920	On the left side, this is typically how we would deal with things in health care.
341920	347140	We're going to encrypt the laptop because HIPAA says that all the data has to be encrypted at rest.
347220	354200	And then what would actually happen is somebody would force us to reveal our password anyway.
356100	360080	Every time we give a talk on this, we update this slide.
360080	367360	And sadly, I'm never out of companies that have had major breaches in the last six months to update.
368080	372340	But these are examples of really bad things that have happened.
372340	377220	Health care is by far the number one most breached industry, but everybody gets breached.
377220	397100	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.
397100	398960	And yet they still had problems.
398960	401940	And the reason they had problems is because they had blind spots.
401940	408520	So threat modeling is a way to try to eliminate some of those blind spots.
410500	418100	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.
418100	423460	So there's no A for effort here.
423480	432320	But doing threat modeling and doing them consistently will, over time, improve your security and your compliance and your privacy.
432860	435900	And it is by far the right thing to do.
436120	437900	So let's define it a little bit.
437920	441840	In order to really talk about this, we have to have a taxonomy.
441840	443420	We have to all be using the same language.
443420	446260	Lots of people interchange the word threat with risk.
446260	448080	We do that, too, accidentally.
448080	450340	But we had to come to a common language.
450340	456380	And when Patrick and I were working on this model, we were using the same word to mean different things.
456380	458340	So we eventually wrote it down.
458900	460380	This is our taxonomy.
460460	461980	First thing is a system.
461980	465520	And a system is anything you want to model.
465780	470320	Lots of threat modeling focuses on applications, on software.
470320	476340	And that is certainly a system that can be modeled, but so can a business process or a network or a vendor.
476900	484140	And the defining characteristic of it is we want to protect it from specific threats.
484500	489140	We just did our annual risk assessment and just completed it.
489140	493740	And this time around, we modeled 26 business processes end-to-end.
493740	497460	So systems typically have defined borders.
497460	500160	You know what the entry point into the system is.
500160	501400	You know what the exit is.
501760	504660	And you can then model it for threats.
505040	511140	Those borders are sometimes called trust boundaries, which are areas where principles can interact.
511480	514520	Sometimes they're called attack surfaces.
516500	524380	The key point is understanding all of the areas that an attack or a risk or a threat can come from.
525020	527520	Vulnerability is a weakness in your system.
527520	529720	Vulnerabilities are things that can be exploited.
529720	533200	So if you have a weak password policy, that is a vulnerability.
533200	534340	It can be exploited.
534340	537700	If you leave your front door unlocked, that is a vulnerability.
537900	544300	That doesn't actually mean that someone will breach your password or open your door, but it is vulnerable for exploitation.
544820	547380	A threat is an actor.
547640	549940	A threat can be a person.
549940	553220	It can be an employee of a third party.
553220	555460	It could be its own business process.
555460	557020	It could be a piece of code.
558720	562460	And threats exploit vulnerabilities.
562460	567360	And we call that an attack vector in our taxonomy.
567800	575300	Risk in this world, then, is the bad outcome that results when a threat exploits a vulnerability.
575300	579700	And we can then measure risks by measuring the likelihood of it happening.
579700	581260	That's the probability.
581380	586280	And the impact, or the cost, if it does happen, that's the impact.
587300	589960	And that's typically how people think about risks.
590440	592260	You'll see this often.
592400	599480	People trying to measure the impact by putting a dollar amount on it, a probability, and that gets you to an adjusted risk score.
599480	603340	And then we talk about inherent risks and residual risks.
603340	606380	And that's often how risk assessments are done.
606700	613320	In our taxonomy, controls are things we do to reduce the probability or the impact of a risk.
613320	617360	So, if your door is unlocked, that is a vulnerability.
617740	621880	The key and lock is a control.
621880	623220	And you can lock your door.
623220	629300	That doesn't necessarily mean that nobody will open your front door.
629300	632960	It just has lessened the probability of it.
633300	635480	It might have increased the impact, by the way.
635600	640660	So, controls have... there's no panacea to them.
640660	646900	But we do need to model what are the risks and then what are the controls.
646900	651500	And when we do that, we can then figure out what are the residual risks.
651740	653700	Threat modeling is just an analysis.
653700	660540	It's a way of systematically going through and looking at vulnerabilities and controls and threats against a defined list of risks.
660540	664440	And defined list of risks is really important.
666320	671360	Because we can sit around and talk about every bad outcome under the sun.
671820	679900	A meteor may strike the planet, but that really isn't a risk we're going to try to go model as threat modelers.
680620	682160	And then lastly, action items.
682160	683420	This is the result.
683420	686080	This is what we're trying to get out of a threat model.
686560	689500	We've looked at all the bad things that could happen.
689500	691720	We've measured the probability of impact.
691720	693860	We've assessed the controls we have.
693860	699720	And then now we've got a whole bunch of work that we want someone to go do to reduce the risk.
699720	705820	And we're going to reduce the risk by creating new controls that either reduce the probability or the impact.
706060	707600	So that's our taxonomy.
707600	710500	If I can add to that while you change slides on that.
710500	716020	One thing that was super critical for us is just exactly that taxonomy.
716020	720660	Coming from different disciplines, from IT security and from healthcare compliance,
720660	725380	we spoke very different languages when it came to risk and threats.
725380	734940	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.
734940	739000	So if you decide to adopt this model and go forward with it,
739000	744120	don't underestimate how important it is to create that taxonomy when you're speaking to your risk organization
744120	747080	or your compliance team or your privacy office.
747080	750280	Getting on the same page is really important.
751120	754800	Absolutely. I could not agree more. And thank you for jumping in so I can take a drink.
757500	763980	We would love to think that we were the inventors of all threat models and the geniuses who wrote this down.
763980	765380	The truth is we're not.
765700	771240	There are lots of very, very good threat models out there in the ether.
771240	774640	And we borrowed heavily from them.
774640	784220	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
784220	788980	and hopefully take what we've done, take what these other people have done,
788980	794980	and apply that into your own business, whether it's in healthcare or any other.
794980	798920	So our starting point was this wonderful book here by Adam Shostak.
798920	804680	I think he may be talking at BlackHat or DEF CON this week on threat modeling.
805420	809460	It is fantastic. If you don't own it, I highly recommend it.
809460	811320	He didn't pay me to say that.
812200	814900	And we'll talk a little bit more about what's in that.
814900	817340	But that's really on the software design standpoint.
817340	821600	On the privacy design, there's this model called Linden.
821600	823520	And again, it's excellent.
823520	829280	So Adam's book largely focuses on the stride threat model.
829280	831980	This is something that came out of Microsoft.
832060	841980	And this was a way of getting software engineers to assess the major threats to applications.
841980	846200	And they had narrowed down to really six areas.
846200	852340	So spoofing, so somebody illegally accessing an application, tampering, somebody modifying the data,
852340	859060	repudiation, somebody performing an act and we couldn't figure out who it was,
859060	864860	elevation of privilege, somebody gaining credentials that they shouldn't have,
864860	869040	denial of service, shutting it down, or information disclosure,
869040	873560	which is what Patrick and I worry about a lot, which is breaching information.
873600	875840	That's the stride model. It's excellent.
875940	880540	Please go read about it. If you haven't already done so, get Adam's book.
880540	887300	On the privacy side, the Linden model is also excellent.
887620	892460	And when we started researching this, what became really apparent to us,
892460	899700	and we'll talk more about this as well, is that sometimes privacy and security are polar opposites of each other.
899700	905900	So in the stride model, we're worried about repudiation.
905900	908880	Can somebody do something and then deny they did it?
908880	913160	In privacy, we're worried about non-repudiation. Can I do something anonymously?
913680	917100	And so we borrowed heavily from the Linden model as well.
917100	919980	But there's some other models out there that are also good.
920180	924500	Bruce Schneier wrote extensively about attack trees.
924540	929080	Attack trees is one way of brainstorming where you start with an objective,
929080	934900	like I want to open a safe, and then you walk down a tree of all the ways you would do that.
934900	938700	So how could I open a safe? Well, I'd have to learn the combo. That would be one way.
939240	943600	Or I could cut it open. And to learn the combo, how would I do that?
943860	950500	And you walk down that, and then you start figuring out what is possible, what's not possible.
951120	957840	And then once you've done that kind of a model, you can then insert controls in there to break up the attack tree.
957840	960880	Kill chains came out of the military.
961400	968300	And again, it's a way of modeling what needs to be done for somebody to execute an attack.
968300	975520	And if you interrupt any step of the kill chain, you can impact or possibly prevent the attack.
975520	978220	Both excellent models.
978680	983680	Security scorecards. These came out of the University of Washington.
983680	987240	This is a way of training threat modelers on how to do threat modeling.
987240	993060	It's actually a deck of cards. And I have a deck that's at my office that's under lockdown from COVID.
993120	997960	But it talks a lot about motivations and resources and methods.
997960	1002360	And it's really just a training mechanism, but they're worth checking out.
1002360	1004800	And there are a ton of other models.
1004960	1009120	I found this white paper from Carnegie Mellon on threat modeling.
1009480	1014700	It's excellent. I highly recommend the POSTA model just because I like the name.
1014700	1018160	But there's lots of models out there.
1018160	1022720	But none of them really fit what Patrick and I wanted to do.
1022720	1031880	Which was, we wanted a single approach that we could look at our software applications and our vendors and our business processes.
1032240	1041440	And deal with all the intersections between compliance and security and privacy and ultimately reduce the risk of our organization.
1043440	1049160	Lots of people do brainstorming. Brainstorming is the simplest form of threat modeling.
1049160	1052120	It has its place. We do it too.
1053440	1056080	But it also has its limitations.
1056380	1060380	And we talked, I said earlier that we don't model everything.
1060380	1063860	We model the things that are applicable to our system.
1063860	1068380	And this is kind of a typical traditional threat model.
1068380	1072720	We talked about SAM earlier. We're going to talk about SAM again later.
1072940	1084060	But this is a situation, a diagram of how a continuous glucometer, a wearable glucometer might work, might interface with our company.
1084060	1088120	And we draw this on a whiteboard and then say, okay, if we were going to attack this, how would we do it?
1088120	1092380	And everybody starts drawing things and we say, well, I'd do a man in the middle of the application.
1092380	1094960	Or I'd do a denial of service on the API.
1095140	1098360	Or I'd do a breach of the partner.
1098360	1102700	Or I'd figure out some way to hack the device to harm the participant.
1103460	1109220	And that is one way of doing threat modeling, but it ignores lots of things.
1109220	1113320	It ignores the motivations and capabilities of the attacker.
1113340	1120600	It ignores the objectives of the system.
1120600	1124580	It also ignores all of the controls we already have in place.
1124580	1129340	Because we've already done things, like we've got TLS written up here.
1129340	1131860	That's control that we encrypt the traffic.
1132220	1142880	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.
1143900	1146780	And threat models are done via brainstorming.
1146780	1148600	They're limited by your imagination.
1148600	1151680	And failures of imagination lead to blind spots.
1151680	1154880	So this was the problem we were trying to solve.
1155200	1158540	And now Patrick is going to talk about what we actually did.
1158560	1160920	And specifically the includes-no-dirt model.
1161460	1162840	Yeah, exactly. Thanks, Bill.
1162980	1165400	So exactly that's what we were trying to solve for.
1165400	1167360	There's a lot of dimensions to that.
1167440	1174580	I think the one comment I would make on the brainstorming thing, and I think we've seen this before in prior practices.
1174960	1181300	If your thoughts are limited or if you don't think of something, you don't actually expose that in your conversation.
1181300	1189520	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.
1189520	1193600	And that regimentation and that process actually drives us to that one.
1193600	1194860	Okay, next slide.
1195200	1198800	So what we were looking for in coming up with this process.
1198800	1202520	Something that was easy for a non-SME to understand.
1202640	1207380	Something that we could-and something that would be easy for someone to perform.
1207380	1222640	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.
1222720	1225480	We wanted something that was flexible and repeatable.
1225480	1233120	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.
1233380	1236260	We wanted something that was usable anywhere.
1236260	1243280	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.
1243620	1247340	And of course, since we were putting a lot of effort into this, we wanted it to be memorable.
1247400	1249740	Because why not when you're building it?
1249840	1254060	And some creative uses of anagram generators actually got us where we are.
1254060	1255120	So, next slide.
1255320	1257480	So what we created with this process.
1257700	1260960	It's a systematized approach to analyzing risks.
1261260	1263500	That pays a couple of different dividends.
1263500	1268100	One is it's systematized and it's easy to execute like we were just discussing.
1268100	1273940	It's also interestingly started to be a key for us to explain how we think about risks.
1273940	1280400	So it structures educational conversations when we have them with staff so they understand what we're trying to do.
1280880	1283900	It's a repeatable process with objective scoring.
1283900	1285660	So another huge win there.
1285660	1291520	Something we can do over and over again, sometimes on the same system to see changes or see how things have evolved.
1291520	1296660	And it gives us an objective score with some weights that we're going to see in the example we'll show you.
1296660	1302200	That help us compare across risks or across even domains in what we're looking at.
1302200	1305340	How we think about risks and what do we do first.
1305380	1309160	There's never enough time, there's never enough resource, how do you focus your time?
1309380	1311340	We wanted a system-centered approach.
1311340	1315260	So something that isn't really focused on the thing that you're modeling.
1315260	1320360	But something that actually is focused on the thing that you're modeling but not on the process itself.
1321700	1328640	We tried to kind of bridge the gap between, say, having a Stride and a Linden for different things and create something consistent.
1329020	1333220	Bill mentioned we focused on established controls and that's really important.
1333220	1339460	If we've tested the control already and we're sure it works in our audit practice, we know it's actually running.
1340040	1342400	Then we don't actually have to include it in the model.
1342400	1346740	And in the example we'll show you, we've gone through a few things and eliminated it.
1346740	1349060	Because they either don't apply or we know that it works.
1349060	1354000	Lastly, we wanted to have a model that covers all of the domains we think are important.
1354000	1356020	Privacy, security, and compliance.
1356020	1361700	So not having three different models or three different versions and being able to include different regulatory regimens.
1361960	1362880	Next slide.
1364760	1365620	Alright.
1366000	1371540	What we created with Includes No Dirt, the model that we have, your mileage may vary on this one.
1371540	1375280	We designed it for our own uses at Omada Health.
1375280	1381100	And if you're in the healthcare space, it may be directly applicable with the questions that we have.
1381100	1384660	You may have to swap out some of the specific regulatory questions.
1384660	1388740	If you're in an adjacent industry, it may need some questions adapted.
1388740	1394600	Please, by all means, take the questions and modify them to your own use to target exactly what you're trying to get to.
1394880	1395660	Next slide.
1396300	1396720	Alright.
1396720	1397980	And one last, the teaser.
1397980	1399800	It is the Includes No Dirt model.
1400100	1403740	And it has been arranged to actually be memorable.
1403740	1416500	So identifiability, non-repudiation, clinical error, linkability, unlicensed activity, denial of service, elevation of privilege, spoofing, non-compliance to policy, overuse.
1416500	1422720	Specifically, they were thinking of overuse of information and data as really pertains to the HIPAA space that we're in.
1423000	1428720	Dirt, data error, information disclosure, repudiation, and tampering.
1428720	1431860	So all those parts play together to make the model that we're using.
1431860	1432580	Next slide.
1433740	1439200	So for every risk, there's a property and a goal, and it comes from a specific place.
1439220	1440680	So you skip down a couple.
1440680	1442040	Clinical error.
1442420	1444160	The risk is clinical error.
1444160	1447340	A clinician making a mistake that may otherwise have been prevented.
1447520	1452820	The property or the goal of that is the application of correct clinical standards.
1452820	1459520	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.
1459520	1460840	That's in the realm of compliance.
1460840	1467120	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.
1467420	1468360	Next slide.
1472000	1481500	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.
1481640	1485380	And I don't think I can say that enough strongly in the title slide.
1485580	1489840	The risks that apply depend on the system being modeled.
1489840	1495980	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?
1496060	1497580	How does it apply?
1497980	1500680	And some things you may just factor out as you go through it.
1500700	1505580	So these three in particular are complicated because they are very related.
1505580	1508200	And Bill alluded to it at the beginning.
1508300	1513940	Security and privacy sometimes are at opposite ends of what they're trying to do.
1513940	1516060	And these tend to reflect it here.
1516060	1522260	So identifiability, the property of a system that allows users to trace to a specific user.
1522300	1531180	So there, the objective or the goal is anonymity, making sure that that's not actually possible.
1531360	1538840	A risk of non-repudiation, non-repudiation, the process by which it's proven that a user took an action.
1538900	1541460	The goal there is plausible deniability.
1542560	1545800	It isn't clear if someone did something or not.
1545880	1548020	The risk is repudiation.
1548640	1552920	And here, what we're trying to get to is non-repudiation.
1552920	1558420	So where someone can actually show that it actually hasn't happened yet.
1558420	1564720	So these of note actually came from different parts, some from Stride, some from Lyndon.
1564720	1566940	So privacy and security blended together.
1567120	1570820	On the next slide and the next couple, we'll actually kind of unpack that a little bit.
1570820	1574660	So de-conflicting these goals can be kind of complicated on this.
1574660	1578380	Different stakeholders will have different needs for these things.
1578380	1587800	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.
1587800	1590780	We've got a whistle here for a whistleblower.
1590780	1596740	If I'm designing, for example, a software application that holds anonymous reporting for whistleblowers,
1596740	1603660	because that's required under healthcare compliance rules and other codes as well, anonymity is really important.
1603660	1609660	But then for other goals and other people in the system, less important.
1609660	1615320	So a hacker, for example, there in the middle, really relies on plausible deniability for what they're trying to do,
1615320	1621380	either ethically or otherwise, making sure that there's that deniability as part of it.
1621460	1626360	Repudiation and non-repudiation as well.
1626360	1629700	Let's get into a little bit more of a specific example on the next slide, though.
1629700	1638460	So let's say Human Resources wants to build or wants an employee complaint application that lets employees report sexual harassment.
1639280	1645500	Lots of different goals, lots of different stakeholders, and figuring out how to balance between them gets really important.
1645500	1652980	So employees want to be able to report and want, if they want to have anonymity, that their anonymity is protected.
1652980	1657540	If they want to say something anonymous, they can't, and no one will know who it is.
1657960	1663940	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,
1663940	1671480	that you don't have one person anonymously reporting the same thing over and over again to drive a larger oppression.
1672020	1678960	IT needs to provision and deprovision administrative access to this, but they have absolutely no need to see the complaints that are registered.
1678960	1683900	Security runs DLP on every laptop, logs who has access to the application.
1684000	1691000	Important from a security perspective, but then that becomes potentially challenging depending on the level of access
1691000	1698040	and the fact that if they're provisioning it and they log who accesses, they have a proxy for who's actually reporting things.
1698180	1703880	The legal department wants to be able to document complaints and collect evidence to take action,
1703880	1715000	which is somewhat the opposite of anonymity. It's hard to take action and have a cause that comes out if we don't know actually who did something.
1715000	1724720	So you have lots of different people running in the system with different needs, different roles, and those roles will conflict.
1724720	1730620	So we can't completely make everything anonymous because then security and IT can't do their work.
1731200	1739580	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.
1739580	1747980	So all of these parts play together and need to be balanced in the work that you're doing when you do the modeling.
1749700	1751260	All right, I think it's back to you.
1751340	1753320	All right, so let's give it a try.
1753760	1755420	Time to come back to Sam.
1755420	1774620	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.
1774620	1790900	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.
1791440	1799300	So we want to introduce CGMs into our product set, but we want to do it safely.
1799300	1808560	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.
1809120	1819520	And again, you can download the one we've filled out at includesnodirt.com slash defcon.pdf. I highly encourage you to do so.
1821120	1839320	We talked about brainstorming. 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.
1839320	1854420	So again, I'm going to come back to this is our diagram. In our diagram, we have a wearable glucometer. That glucometer syncs to an application on the patient's cell phone, which then transmits the data to the partner.
1854420	1870180	The partner then sends it to our endpoint, and it gets stored in our database. It then sends information back to our application. It also surfaces that information to the coach.
1870280	1875720	And you'll see here that in addition to the CGM, the participant still has a BGM.
1875720	1888720	So still does occasional finger sticks, and that information is also being sent to us. So we've got two sources now of blood sugar data.
1888720	1903320	So this is the diagram we're going to be working off of. In our worksheet that we provided you, it's highly structured. One of the first things we do is we mark which threats we think apply. Who are the actors that are involved here?
1904000	1911140	So certainly the participant is involved in this whole process, and the coach is involved, but we've got a vendor.
1912160	1922780	We've got potentially other partners. We're going to be doing claims on this and billing. We're reporting. So there's business processes, there's people.
1922900	1932800	For this one, we're not so worried about natural disasters. We're not so worried about geopolitical unrest, but other threat models, those might come into play.
1933980	1949500	And we then do some brainstorming on vulnerabilities. So what are areas that could be vulnerable? They get an incorrect reading, or the service becomes unavailable, or the coach misinterprets the data.
1949500	1957200	Now, up in the right-hand corner there, I've got a little diagram where I show the questionnaire and also the structured brainstorming.
1957200	1964480	And this is an iterative process. We sometimes start with the questionnaire, and we sometimes start with the worksheet.
1964480	1970920	But it's typical when we are doing one of these on a complex system, we are going back and forth.
1970920	1976900	So we'll be going through the questionnaire, which is highly structured, and that will trigger us to go,
1976900	1985840	Oh, wait, because we've said no on this question, we think that there's a vulnerability there. Let's go write that down on our worksheet on vulnerabilities.
1985840	1997940	Let's go ask somebody to get more information. And we go through this process until we think we've got the questionnaire complete and the worksheet complete.
1997940	2008920	And so we did that. And when we did that, we were able to take those vulnerabilities that I've listed here. There's five of them in our example.
2008920	2014560	And we're mapping those to specific areas in the includes-no-dirt model.
2015620	2023560	So you'll see, like, anonymity. We don't want anonymity. It doesn't apply in this one, but clinical error certainly does.
2023560	2027190	And denial of service does, and spoofing does.
2027190	2033810	So in the interest of time in our presentation, we're not going to go through all of our answers for every risk,
2033810	2042770	but we're going to go through the answers we did for the risks that apply and talk about why they apply.
2042870	2047050	And again, you can download our example and see our answers on all of them.
2047050	2055030	So the factors that do apply are clinical error, unlicensed activity, denial of service, spoofing, noncompliance,
2055030	2058770	data error, information disclosure, repudiation, and tampering.
2058890	2062330	These are the things we're worried about in this particular threat model.
2063390	2066050	So Patrick, let's start with clinical error.
2066170	2072130	Sure. So what we did in this one, to make it a little clearer, is for the next few slides,
2072130	2076070	on the left side of the slide is a snapshot of the answers.
2076070	2083570	And all of these answers are in the materials that we put on the includes-no-dirt website under the DEFCON link.
2083570	2092190	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.
2092430	2097370	It can be a little hard to read through those, so we've kind of pulled out what we think the important answers are.
2097490	2103670	So here for clinical activities, what we're thinking about in the specific example of this continuous glucose monitor is,
2103670	2107330	are we doing something that relates to the treatment of a patient?
2107330	2109990	Well, of course we are in this particular example.
2109990	2118010	So the specific question that we probe into here is, does this system or process, does this combination of things,
2118010	2122510	have either inbuilt controls that prevent something from happening in the first place,
2122510	2129290	or other review-based controls that can, if something does happen, we'd be able to find it and correct it as quickly as we can.
2129290	2134630	So answer here, yes. And it's a little complicated because it's both CGM,
2134630	2142430	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.
2142850	2149170	Each one of those has specific detective and preventive controls that operate in its own environment.
2149170	2154830	And this is a great example of what Bill just said related to the iterative nature of this.
2154830	2160630	When we hit this question, it's like, okay, wait, that's both the device and the software.
2160630	2164630	How does that work? And we had to fork a little bit, came back, yep, that's exactly right.
2165150	2171670	In questions 3.2 and 3.3, we delve down a little bit into some additional control work.
2171970	2176390	And another thing I would say here is, not all controls are technical.
2176390	2184990	In this particular case, with clinical error, part of preventing clinical errors is ensuring both the proper training of your clinicians.
2184990	2188710	So being able to say, yeah, everybody that has access to this was properly trained.
2188810	2191810	I almost said licensure, that's coming soon.
2192530	2200170	And that the delivery and the quality of the deliveries is important and up to the standards we set in our clinical practice guidelines.
2200170	2209510	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.
2209550	2210630	All right, next slide.
2210630	2221430	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.
2221430	2228390	If we'd answered no, we can skip the rest of the questions on clinical and move on to question 4.
2228730	2231370	So those two things are really important.
2231370	2235770	At the end of this, we're going to total up all the points, and that will drive a risk score.
2235770	2244230	But being able to skip a whole bank of questions when they don't apply means you can go through the model much faster.
2244230	2256270	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.
2256270	2261750	For something that's complicated, and this would be a fairly complicated one, it might take us several hours.
2261750	2268850	But the model fits whichever size system, whichever level of complexity we're dealing with.
2269470	2271630	Definitely, thanks for pointing that out.
2271990	2279550	That weighting is really important because it helps to also create that apples-to-apples comparison that we talked about a little bit earlier.
2279550	2284750	Second one, unlicensed activity, and I spilled it a little bit ago just talking about it.
2284750	2293730	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?
2293970	2301170	Just like the last question, yes, it does, and it's complicated because different parts of this thing require different licensure.
2301170	2319480	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.
2320760	2325880	Also important here is the fact that we rely on other people in these things.
2325880	2332800	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.
2333160	2343820	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.
2343820	2353580	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.
2354580	2355960	I think you're next.
2355960	2362640	Denial of service. So this is where we start looking about how mission critical the system is that we are modeling.
2362640	2378840	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,
2378840	2390100	then it's going to have a significant impact on the effectiveness of getting that telemetry data to the coach, back to the participant, and being able to make decisions on that data.
2390100	2397260	So when we go through our model, we ask, is it a mission critical system? If it is, that raises the point value.
2397400	2403440	And then we look at, have we defined targets, and what are those targets, and how are they enforced?
2403760	2414140	And again, Patrick said not all controls are technical. For the partner, they've got technical controls to ensure their availability.
2414140	2424000	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.
2428040	2438400	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.
2438400	2452740	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.
2452740	2466380	So we have defined authentication levels for our participants. We base it on NIST 800-63B, and they're defined as an AAL Level 1.
2466380	2473120	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.
2473120	2483880	We test those. We know it works. So as long as the system is going to use those controls we've already defined, we can check those boxes and move on.
2483880	2495940	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.
2496800	2511680	All right. Noncompliance. 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.
2511680	2525660	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
2525660	2536760	and for our software application, there's a number of healthcare compliance issues. There would be FDA obligations for our business partners, the contracts that Bill just mentioned.
2536860	2544840	So because this is clinical in nature, it relates to a device. There's patient data involved with it. This one's particularly complicated.
2544840	2558240	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.
2558240	2575000	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.
2575000	2585800	So that was important to kind of drive through that. 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.
2585800	2591620	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.
2591760	2615000	Okay, next one I think is mine as well. Data error. 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.
2615000	2631580	It's really important to make sure that this is ingested and maintained in an accurate and viable way. Again, here, in other includes no dirt models that we've actually done, we've tested some of that. We've tested, for example, the APIs that we do data ingestion with.
2631580	2640380	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.
2644280	2663360	So information disclosure. This is where we're worried about confidentiality of the system. 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.
2663360	2691520	And again, here, we're largely consuming controls that we've already tested previously. So HIPAA requires us to encrypt PHI at rest and in transit. So we can ask, are we doing that? And if so, how? And since those are really well-known patterns for us, we can accept them and we can move on. It doesn't actually require a ton of discussion.
2692540	2716100	Down at 12.6, data locality. This is a really good reminder for us. We have obligations to keep all of our data within the United States, processed, stored, and accessed. 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.
2718360	2746080	Repudiation. We've talked a lot about repudiation already. Does it require non-repudiation? Yes. What are those mechanisms? 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. How are user activities being logged? Do we have accurate timestamps? How long are logs retained? Things like that.
2747040	2755480	That lets us know that this particular system is going to fit into our overall framework.
2757080	2781160	And tampering. We don't want anyone to mess with the data. So, again, what are all the mechanisms in place to prevent tampering? 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.
2781160	2792460	And also, how do we make sure that the device that gets shipped gets assigned to the appropriate patient in our data model?
2792460	2814000	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. 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.
2814000	2831600	So, again, the model is iterative. It lets us go through it. And it reminds us to check, how are all these things being addressed for this? It is a very structured way of brainstorming. And we get to the end, we get a score. Patrick, you want to talk about this?
2831600	2855300	Oh, sure. Yeah. So, as Bill said, we get to the end and we get a score. So, the product of all the numbers that you saw on the side. 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. And in the particular governance risk and compliance system that we use, we can weight the scores, so some are stronger than others.
2855300	2876880	But essentially, the product of that turns into a total score. 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? 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?
2876880	2895580	On the right side, you actually see the list of action items. You saw that in a prior slide as far as how those work. Here's the specific action items for this one. So, for example, for this particular model. So, for example, creating clear instructions for participants on device calibration can help with data integrity issues because
2895580	2917760	it's not clear if someone enters data incorrectly, the treatment would apply correctly. So, this addresses the clinical vulnerability issue. Backups to BGM and CGM also touches on some of the same issues. Sometimes that's required just because of the nature of the CGM and so forth with all of these.
2917760	2931380	Each one of those action items is designed to address one or more vulnerabilities. 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.
2932280	2956720	And we've done a lot of these. I mentioned earlier that we launched a behavioral health application. And when we did that, Patrick and I did a threat model. And I think we came up with 19 action items. And those were specific things that we wanted to ingest into the system before we went live.
2956720	2975060	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.
2975060	2988440	And everybody involved also understood, because they went through the process with us, why. They knew why we had those action items, and what was the specific vulnerability we were trying to address.
2988780	3000220	That latter is very important. You may have groups that, let's just say, are not necessarily as inclined to be helpful when working with the risk assessing organizations.
3000220	3015480	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. So, it becomes educational as well as helpful, just as a reminder as to why we're doing it.
3017040	3024940	So, a couple of points to wrap this up. Vendor management, the threats you aren't seeing can also kill you.
3025640	3035760	I use this example, this was a letter that Quest Diagnostics sent out about a year ago on a breach.
3035760	3045040	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.
3045060	3054200	And that vendor was acting as Quest BAA, but Quest ultimately got sued for this breach.
3055200	3069800	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. And we use the same methodology, the same checklist, to assess all of our vendors.
3070040	3075060	Now, we have lots of vendors, we are a SaaS first company, we've got SaaS all over the place.
3075240	3083740	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.
3083740	3095360	And it doesn't require licensure. But when somebody comes to us with a new device vendor, we're going to go through this same model very, very carefully.
3095980	3109060	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.
3109920	3126420	But we then use that to influence our legal terms. 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.
3126420	3139400	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.
3139400	3152240	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. So, this model works for assessing vendors, and it works very, very well.
3153480	3161900	All right, so when do you actually use this? 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.
3163040	3171420	As you can kind of tell from our examples, we use it all over the place. Initiations of significant projects, the behavioral health example that Bill just did.
3171420	3180060	Vendor acquisition for the first time, and then annual assessments, both from a risk assessment perspective and from a vendor assessment perspective.
3180060	3187620	Bill mentioned earlier that we did it for 26 material business processes on the risk assessment we just completed.
3187620	3199880	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.
3199880	3206020	This forced more rigor than I think we'd even seen last year when we did it a little bit closer to this way.
3206020	3215140	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.
3215680	3222700	Resulted in a lot more action items for us to do, but that's a good thing in the grand scheme of things. There's a lot more because we're aware of it for us to look at.
3223020	3233640	On demand, too. 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. There's the regimented way to actually look through it.
3236220	3244760	All right. 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.
3244760	3257460	So threat model on the upper right. 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. So risk unknown in a new process.
3257780	3267380	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.
3267380	3277300	So on an annual basis, the last few years, what our risks are as a company are pretty stable. We kind of know the general categories of risk.
3277620	3286880	So we may not necessarily know with an existing product how it shifted over time. Take a look at that from an audit perspective, and these overlap.
3286880	3301480	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. So that, in our world, still stays in my universe. That may get handed off to an internal audit group for them to be able to test that control eventually.
3301580	3309200	But it's all related. It does create a completely virtuous circle, I guess you could say, from a control management perspective.
3311480	3328300	So, final thoughts on all of this. When you are in security or compliance, your risk assessing organization, your job is actually to say yes. Security practitioners, we get a bad rap because people think we always say no.
3328300	3338600	Our job is actually to figure out how to enable and empower the business. And so really, Patrick and I firmly believe that it's our job to say yes safely.
3339200	3353400	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. It's fine to do this new process.
3353400	3363440	But here are our recommendations for the ways to harden it, to improve the security and compliance and privacy of that system.
3363440	3375080	And with that, thank you for listening to us. It's been our pleasure to talk to you. And we look forward to the Q&A portion here at DEF CON Biohacking Village.