Bill Dougherty — INCLUDES NO DIRT, practical threat modeling for healthcare and beyond

0:00Chris RomeoBill Dougherty is the Vice President of IT and Security at Omada Health, where he leads a team responsible for all aspects of internal IT, including SaaS strategy, end-user support, vendor management, operational security, and compliance. Bill, along with Patrick Curry, created the Includes No Dirt approach to threat modeling, which takes threat modeling to the next level beyond STRIDE and goes head-on with a more modern set of real-world security considerations.

0:27Robert HurlbutWe hope you enjoy this conversation with Bill Dougherty.

0:31Chris RomeoI want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

1:16Robert HurlbutThe Application Security Podcast. Here we go.

1:40Bill DoughertyGo.

1:41Robert HurlbutHey folks, this is Chris Romeo and welcome to this episode of the Application Security Podcast. I am the CEO of Security Journey and Robert was unable to be with us today for this interview, but I am joined by Bill Dougherty, who's going to talk about something that many of you as our listeners have come to find as a regular topic here on the Application Security Podcast, and that is threat modeling. But Bill, we always start by jumping right in and capturing people's security origin story.

2:17Chris RomeoOur audience is dying to know, how did you get into this crazy world that we call security?

2:22Bill DoughertyChris, thanks for having me. It's great to be here. As you said, my name is Bill Dougherty. I currently run IT and security for a digital healthcare startup called Omada Health, but I've been doing security on and off now for 2+ decades, I guess. I was in IT for about a decade in the reseller channel and then went to work for one of my customers that was a, a large salvage auto auction company. I was running IT there and we started having a bunch of security issues. I recognized pretty quickly a couple of things. One, we didn't have anybody in the organization who was responsible for information security. This was back in 2004. 2, security people tend to make more money than IT people.

3:12Robert HurlbutRight.

3:13Bill Dougherty3, I kind of had always moused around the edges of security, and so I went to the powers that be and said, hey, I think we need a security department. And I want to run it and put a proposal together. And they said yes. And but they also said, okay, prove to us you know something about security. So I did what I always do. I picked up some books, I did some reading, I passed some tests, got my CISSP and my CISM, and then put together some plans for what security would mean at the company. And I was kind of off to the races and worked there for several years and then went and spent some time running site operations and security for StubHub, which is part of eBay, and then left there and was the CTO and CISO of a data center company for 5 years that we eventually sold to NTT Communications. So I've been in security really going back to early 2000, and I've done it in e-commerce, I've done it physical security in data center land, and now I'm doing it in healthcare.

4:21Robert HurlbutSo, the role that you have today, is that primarily AppSec or InfoSec or D, all of the above?

4:31Bill DoughertyLet's say it's all of the above. Today, I'm responsible for all of our internal IT systems. I'm responsible for AppSec and IT security. I also deal with end-user support and facilities. So, I touch all aspects of security.

4:50Robert HurlbutAnd so, did you see anything in regards to AppSec, you know, kind of in— is AppSec something that's kind of new as you've come into Omada Health, or is that something that you've kind of always been thinking about and always been responsible as long as you can remember?

5:04Bill DoughertyYeah, it's something I've been dealing with since the early days, and because the application is a prime source of entry into any organization. So I've been dealing with application security and not just web app, but, you know, back when I first got it started, we were running the core business on AS/400s and trying to deal with AS/400 security models and RPG code is, is an interesting treat. You know, I've got gray hair for a reason.

5:38Robert HurlbutI miss the AS/400. We should bring it back. Somebody was telling me that they have like web gateway software now for things like AS/400 where there's like a front-end web application and then it does some type of proxying to your AS/400 on the back end so you can still get some use out of it in the year 2019.

5:57Bill DoughertySo that is absolutely true. We were doing that back in 2004, 2005, and I'll tell you, one time we had a situation where we're in the web app interface, we were getting these weird error codes and no one could figure it out. We finally went to the guy who had been dealing with AS/400s for 30 years and he said, oh, I know what that means. It's not an ASCII code, it's an EBCDIC. If you translate it from EBCDIC to ASCII, it stands for 404.

6:29Robert HurlbutThat is great. Who knew an AS/400 could serve up a 404?

6:36Chris RomeoYes.

6:38Bill DoughertyExactly.

6:38Robert HurlbutThat is great. Well, let's transition and start to talk about this thing called the No Dirt Approach to Threat Modeling, which I love the name, first of all. But let's— before we can get into where the name came from, let's introduce for us what is this thing you call the No Dirt Approach to Threat Modeling?

7:01Bill DoughertySo we Have a requirement in health, in all of healthcare, but especially in digital health, to do annual risk assessments. And lots of companies kind of just do a check the box, but we choose not to do that. We choose to actually assess our risk on an annual and really on a continuous basis. And one of the things we started about 2 years ago is we realized it wasn't just enough to do an annual risk assessment. or a vendor assessment. We really needed to start doing some threat modeling. We needed to quantify the things we were worried about and then really dig down. Quickly, we discovered a couple of problems. One of the problems is nobody knows how to do threat modeling in digital healthcare because digital healthcare is relatively new. And the second one is unlike Some organizations have this problem, some don't, but we see significant tension in healthcare between security, privacy, and compliance. And we have threats in all 3 of those realms. And in some cases, the goals are mutually exclusive. And I have a partner in the organization named Patrick Curry. He was my director of compliance, and he and I are the 2 people who do our risk assessments and our threat models. And we quick— we kind of realized that there was no good model that we could steal from to say, this is how we go do it. And so over the course of a couple months, we started writing one and said, okay, what are all of the realms we want to go assess a system for? And Because we, we've been doing this for a while, we knew that there were some patterns we could follow. So we started looking at different patterns like the STRIDE framework that came out of Microsoft for security. We looked at the Linden model that was really a privacy model. We looked at a bunch of different models, and then we kind of put them all in a blender and shook them up and then came up with what are the things we care about. And we really wanted to make sure that for all the areas we care about, we're asking the right questions and we're looking at the right things, but we also aren't including a bunch of stuff that we don't care about because we just don't have that kind of time. And so we, we put together this model, and as we put it together, we figured out we needed to document it so that we could train other people to use it too in the organization. And then once we did that, we We decided, you know, this is something that we think will be useful to other people. So let's write it up as a white paper and get the company to let us publish it and give it away because ultimately we want to make everybody stronger. Report just came out: healthcare is the number one most breached industry in existence, and that has to change. And so we need to do better, but we also need to. Get our partners and our competitors to do better too. So that's how we came up with the model.

10:20Robert HurlbutAnd so the name No Dirt, does that have something to do with like the categories?

10:26Bill DoughertyYeah, so the full name is Includes No Dirt, and it's an acronym. And I give Patrick full credit for the acronym. He took all of the risks that we were looking at and Tried to create— put them into an acronym generator and tried a bunch of different things and came up with INCLUDES NO DIRT. And it just happened, and that was actually one of the principles we, we had for when we put the model together, is it had to be easy to understand and easy to remember. And, and, um, I instantly liked it because I don't, you know, I want my systems to be clean. I want them to not be dirty. So If my system includes no dirt, then it should be clean.

11:09Robert HurlbutOkay, and so those— so that doesn't specifically break down into like individual categories?

11:15Bill DoughertyIt breaks down into individual risks. So, um, so again, it's an acronym. So we're looking at identifiability, non-repudiation, clinical error, linkability, unlicensed activity, denial of service, elevation of privilege, spoofing, noncompliance to policy or obligations, overuse, data error, information disclosure, repudiation, and tampering. And I want to quickly point out to you that I said non-repudiation as a risk, and I said repudiation as a risk.

11:47Robert HurlbutI did catch that as well.

11:48Chris RomeoI was—

11:50Bill Doughertyand that's a good example of where they're in conflict. So in security realm, our goal is non-repudiation, so the risk is repudiation. The risk is that we can't prove who did what.

12:01Robert HurlbutMm-hmm.

12:02Bill DoughertyHowever, in privacy land, there are times we want anonymity and there's times we want plausible deniability. Those are goals in privacy land, and they conflict quite clearly with non-repudiation as a goal in, in the security realm. And so we include both in the model so that we then go through and say, what type of system are we dealing with? Is this one where we want people to be anonymous, or is this one where we want people to be identified?

12:33Robert HurlbutSo that— and so that's something that's healthcare-specific though?

12:35Bill DoughertyIt is definitely healthcare-specific, but it's also— many organizations have this issue. So think about the news today. If you were writing a whistleblower application, and that could be an internal whistleblower application for your HR or your legal department, Do you want the, the employee— do you want the whistleblower to be anonymous or not? And even if they're anonymous, does that also mean you have plausible deniability? Those are not the same thing. So if I can post something without putting my name to it, it's anonymous. But if you log my IP address or my machine ID, That doesn't mean I have plausible deniability. And we certainly see this in our organization. We run a DLP solution on our laptops. We record what people do. We can replay sometimes what they do on a movie. Well, we also have requirements to allow people to do anonymous reporting if they— like for Medicare fraud, things like that. So how do you deconflict those things within your organization? The point of the model is to, when you're analyzing some system, to surface that, hey, this might be an issue, and then to go create an action item for how we're going to deal with it.

14:07Robert HurlbutOkay, so just to summarize kind of where we've been so far, you've got these different threat categories that are tied to the first letter of INCLUDES NO DIRT. For those that have done threat modeling in the days of old that if you mentioned STRIDE already, I mean, STRIDE is a version of that and has some of the same things even that you've included here, but just to make the connection for folks. And so, we've got this threat base now that includes all of these things like identifiability, clinical error, all the way down to overuse state error, tampering. What's the process for how you actually use this Great, great question.

14:51Bill DoughertyOne of our goals for the system, for the model, was that we needed to be able to analyze a system quickly and we needed to be able to do it consistently. And so we took these risks that we are trying to model and we put together a questionnaire, and that questionnaire then lives in our GRC system and it assigns points based on how you answer the question, and your point total then lets the person who's doing the model know, do we think this is a low-risk or a high-risk system? And which then allows us to triage where we need to spend more time. So taking the very first one, which is identifiability, that's the risk. The question is, does the tool or process or system require anonymity for compliance? That's a yes/no question. And if it's required, then we go deeper. If it's not required, you don't assign a point to it, you just move on to the next question.

15:54Robert HurlbutOkay.

15:54Bill DoughertySo, so we can quickly go through, you know, non-repudiation. Does the system require plausible deniability for compliance? Yes or no? If no, move on. If yes, then Tell me, does it have controls in place? If so, what are those controls? Describe how you're enforcing it. And that then, as you start digging into, yes, we need this, and yes, we have controls, you can then as a modeler say, I'm not sure those controls are sufficient. Let's create an action item to— and then continue on with the model. So for a small system that isn't terribly important, You should be able to go through and complete the entire questionnaire and score it in about 5 minutes. For something that's really complicated, Patrick and I just did one of these on Monday, and we spent 3 hours analyzing a system with the system owner. And it'll— we'll have another 3 or 4 hours of write-up of our results with diagrams and things. And we probably walked out of there with 10 or 12 action items. But, and I've used the term system several times. I should take a step back and say, and kind of define that term. For us, a system is just the thing you're modeling. So a system can be an application, or it can be a network, or it could be a business process, or it can be a vendor. It's whatever it is you're modeling. And so we wanted one, one model framework that would scale to any of those things.

17:26Chris RomeoHmm.

17:26Bill DoughertySo somebody comes to me and says, Hey, I wanna bring on a new chat application, Skype, as a vendor. Well, we can do that, and we can analyze it, and it's probably gonna be pretty quick because we're not putting sensitive data in there. We're not worried about a lot of things. Move on. The next day, somebody can come to me and say, hey, we've got a brand new application we wanna give to our participants that we're writing that is going to deal with some new medical condition, and it's going to have lots of protected health information. It's going to require interaction with coaches, and oh yeah, we want to share that information with somebody else.

18:05Chris RomeoWow.

18:06Bill DoughertyI mean, I intuitively know this is going to be a high-risk thing, but I now need to go through all of these risks to figure out, have they thought— have they designed it correctly? Are they thinking about it the right way? Do we have the correct controls in place?

18:21Robert HurlbutA couple of questions that kind of came out of that explanation. The first one is you mentioned that you did this exercise with Patrick where you spent, you know, 3 hours or whatever looking at this, at this kind of bigger, bigger system. And you mentioned diagrams. Now, when you say diagrams in the context of Includes No Dirt, is that part of kind of the approach, or was that just system diagrams as you were trying to understand what you were actually modeling?

18:49Bill DoughertyIt's also part of the approach. So most people who do threat modeling, they start with brainstorming. And brainstorming can be very unstructured, and that's not always a good— that's sometimes a good thing, sometimes it's not. We also have a brainstorming worksheet that we go through. And as part of that, you know, whatever the system is we are modeling, we wanna make sure we understand it. And so we start doing—

19:15Chris RomeoYeah.

19:16Bill DoughertyDiagrams. How does data flow through it? Where are the trust boundaries? Those diagrams can be pretty simple. It can be something we draw on a whiteboard and then take a photograph of and we're done. Or we could spend— if it's something that is really complicated, we may spend a lot of time on it and then go back and create a real diagram of it. But we want to fully understand what type of data we're dealing with, how it enters the system, how it leaves the system, what the, what the main use cases are. So how complicated that gets is dependent on how complicated the system is and how important the system is. And then we start mapping that to different threats and different risks and trying to understand how all of this is going to work. So, you know, go back to my example of a whistleblower application. I'd create a diagram that shows a user with a browser on their laptop and they're connecting to a web interface with a backend, and then there's an administrative interface for the, you know, the legal person to go evaluate it, and there's trust boundaries, there's firewalls and things, and then I'd start looking at, okay, you want it to be anonymous, what's on the laptop that prevents it from being anonymous?

20:33Robert HurlbutAnd that's the question that you're asking kind of midstream as you're trying to figure out, hey, is this an actual threat that I need to consider for this system that I'm modeling, or is it something that I think we already have handled?

20:47Bill DoughertyRight. So the questionnaire, you can go through it really fast, but we're actually trying for important and complicated systems, we're trying to go through it slowly. And the questionnaire then becomes just a tool by which I, in a structured way, I make sure I'm asking probing questions And I don't forget to ask about something.

21:08Robert HurlbutLet me just kind of summarize how I'm hearing the process going, and then maybe you can just confirm that I'm in the right direction, as well as maybe correct me here if I'm missing this. But I'm envisioning you're going through the DFD process for whatever the system, whatever it is, the thing that you're threat modeling, and then you are maybe creating a couple different diagrams on the whiteboard at different levels. And then you're picking up your Includes No Dirt checklist and you're using that checklist, you're checking things off and confirming against the diagrams as well as your understanding of the system. Am I, am I tracking?

21:45Bill DoughertyYeah. And I would say it's a very interactive process. So we've got a diagram and then we start, you know, tell me what it is, we're— what's the system look like? And then we start going through the checklist and then as we hit areas of importance, we maybe go back up and modify the diagram. Like, okay, show me it. So the one we were looking at on Monday, it was pretty complicated, but as we're going through it, we hit the questions on denial of service. And when we hit that, they told us how they are preventing against denial of service, and it was another box that needed to be added to the diagram. And then we hit a question— we hit the questions on unlicensed activity, which in healthcare is important. You don't want unlicensed clinicians performing care if it requires a license. And it turns out there's another web interface where they deal with matching people to licenses. Okay, that goes back on the diagram, and then we probe our way through it again. So you still have brainstorming. It's still very interactive. But by the end of the process, we have to have asked the questions on all of these areas, and the end result becomes a lot of notes. And as we're going, it's really typical, as we're going along, we ask, how do you do something? What's the controls? We figure out, oh, maybe there's a gap there. We kind of write a note to ourselves that there's a gap there. We move, we get all the way to the end. And then we start saying, okay, what are those action items? And that's based on all of those exceptions we found. And we, we then brainstorm on what are the controls we want to see put in place, what are the modifications we want in order to readdress— to address those problems.

23:35Robert HurlbutIs this something that you're trying to teach to your development staff, or is this something that Omada Health is going to send out security people such as yourself and Patrick that are going to do this with development teams?

23:49Bill DoughertyI'd say both. Ideally, I want to get to where all of my development teams or all of my product teams are just— have— are filling out these questionnaires on their own and it's getting scored. And then the scoring becomes a triage point that tells my security team where should they go spend more time. Initially, we are performing that as a service for those teams. So they have something new that they want modeled, they bring us in, we go through it. You know, we put the model together at the beginning of the year, we published the white paper in September. We've done a bunch of these, but I'd still say that the process— we're still refining our process for how we take this model. and apply it. And as we do that, we're then training people on how to use it. But we do, we absolutely want the teams to ultimately become self-sufficient. And just like with Stride, the goal for Stride was never for security people to come in and analyze their application. The goal was always for that analysis to be part of the SDLC process.

25:06Robert HurlbutYeah.

25:06Bill DoughertyAnd teams should be able to do it themselves. Teams should be able to do this themselves too.

25:11Robert HurlbutNow, do you have a separate security requirements document, or does this become your set of security requirements as you're interacting with dev?

25:23Bill DoughertyI would say we have separate documents that are, 'cause we have lots of policies that for how they should be doing things in general. When they start doing something new, this becomes the framework we use to create specific action items. And those action items are really gonna— are gonna be system-specific, but generally it's gonna be the— when they're trying to do something that doesn't follow a pattern we've already established.

26:02Chris RomeoOkay.

26:02Bill DoughertyOkay. So let's take something simple. HIPAA requires us to encrypt data at rest. We do that, we encrypt it at rest a couple of different ways. If somebody's putting in a new system and that system doesn't encrypt data at rest, that's a new pattern. We're going to look at it and say, okay, does HIPAA require that specific data to be encrypted or not? If it does, then here's your action item, go do it. If not, we may have a compensating control we want to go look at.

26:35Robert HurlbutIn the way that you're using the Includes No Dirt model, you have a series of different requirements that are going to be compliance-focused, things like HIPAA you mentioned. They're going to drive the things that you have to do. And then Includes No Dirt is not a direct mapping or correlation to HIPAA, but it's going to support a lot of the things that HIPAA is calling for.

26:59Bill DoughertyCorrect.

27:00Robert HurlbutWhat, uh, what advice would you have for somebody who is listening to this podcast, they've never heard of the Includes No Dirt methodology here, maybe they're even in a healthcare-related kind of digital healthcare startup or something? What would be your advice to that person as to how they could get started with the Includes No Dirt approach?

27:19Bill DoughertyYeah, so we've published it, um, and It's a fairly simple read. It's on— it's at includesnodirt.com. And the format of the white paper is we have kind of the background and the logic behind it, and then we have samples of our questionnaires that are filled out, so you get an idea of what it looks like to fill one out. But at the end, we have just in plain text all of the blank questionnaires. There's 3 of them. There's the, the main assessment questionnaire, there's a brainstorming worksheet, and then there's also a specific questionnaire that we send out to vendors. And my advice is go read it, see if this looks like something you want to consume in your organization. If it does, take it and then modify the questions and modify the areas So that it matches your security model. So this one matches ours, and we think it will match a lot of them. But I'm highly encouraging people to go make this your own and create derivative works from it so that it becomes useful in your organization. The other thing I would say is if you have a GRC system and that GRC system will support it, try to bake this into your GRC system. So we we do these questionnaires within the system. It gets attached. attached to records, and so we can go back in time and see what our thinking was. It does automatic scoring. All that's done in our GRC system. If you have one, put this in there.

28:59Robert HurlbutThis is, uh, it's been very, very helpful, Bill, just to understand kind of a different approach to threat modeling, because I'm somebody who comes from the world of big engineering companies, big tech companies, where we did threat modeling Using Stride as a basis, but we never had really requirements that kind of drifted outside of what Stride was able to handle. You know, we did stuff from a brainstorming perspective as well, but Stride was kind of the foundation. So, this is pretty exciting for, for me as a practitioner to be able to see how this is kind of the next generation of Stride in that it has some of these other categories that are specific to healthcare like Clinical errors, the one that jumps out at me is that I don't think I'm going to experience in a tech company. But yet, it is definitely good that you have something that is specific to your approach as a company, as Omada Health. And, I'm also excited with the idea that you have as far as, hey, this is something that other people can pick up and can adapt and make it their own. And so, thank you for your efforts in putting this together and sharing it with the community.

30:06Chris RomeoThank you.

30:07Robert HurlbutAnd I'll say, any last thoughts you want to leave our audience with about Includes No Dirt threat modeling or anything?

30:14Bill DoughertyWell, first of all, thank you for having me here and for covering this. You know, when we started this, we did it because there's lots of good books out there on the theory, but there aren't a lot of good guides that are very practical. It just says, If you're trying to get started, go do this. And I want to see more of that. And so I'm really happy that we're starting to get some traction. I think you found us because Adam Szostak, who's kind of the godfather of threat modeling, he was very kind to actually read it and give me some feedback and also cover it on his blog. His book is excellent. It's one of the foundations for this. But I highly encourage practitioners who are doing this and are— if you're using my model or using someone else's model, whatever it is you're doing, publish and get it out into the community so that people who are just getting started have a guide to help them because we all get stronger together.

31:26Chris RomeoThanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.