Geoff Hill -- Rapid Threat Model Prototyping Process

0:02Chris RomeoHey folks, season 4, episode 26 of the AppSec Podcast. On this episode, we're joined by Joff Hill, who speaks to us about the rapid threat modeling prototyping process. And this is his unique approach to how he does threat modeling and teaches others to do threat modeling at the speed of Agile and DevOps both. And you know, we talk about threat modeling quite a bit on this podcast, but that's okay. We're back at it again because Joff provides a unique perspective, and we want you to be able to hear it. We hope you enjoy. The Application Security Podcast. Here we go. Hey folks, welcome to this episode of the Application Security Podcast, where we're going to talk again about our favorite topic, threat modeling, something that both Robert and I love and spend a lot of time focused on teaching other people how to do it and just trying to promote it across the industry. And so, we're joined by Jeff Hill, And Jeff is going to talk to us a little bit about his approach that's a little different than how everybody else is approaching this, which is why it's, it's so intriguing to us. But Jeff, first of all, we always start for our listeners with what is your security origin story, or how did you get into this crazy world that we call security?

1:47Geoff HillOkay, well, thank you for the introduction. Uh, basically my, my journey into the security world happened around 2002. I was working as a just a standard developer at Microsoft, and a close friend of mine who happened to be working in a security group, an infrastructure security group, said, hey, you know, you know a lot about hacking into things and everything like that. You know about screwing around with that stuff. Why don't you come over and work on our group? Because we don't have any app dev guys. And I thought it was a good idea. So I went over there, and then upon immediately getting in there, I got steeped in the wisdom, as it were, of the Microsoft SDL, the Security Development Lifecycle. And then I got introduced to threat modeling, and it all changed. Everything changed. Just like you guys, I was immediately enamored by the thought of threat modeling. Whoa, you can actually put some kind of architectural security into place. Fantastic.

2:34Chris RomeoHow long were you at Microsoft?

2:37Geoff HillAbout 8 years.

2:39Chris Romeo8 years. Okay. Wait, 2002. Does that mean you're there for the Gates memo when it came alive?

2:45Geoff HillI was there. I was there for the Gates memo, yeah, for the bitter end, basically.

2:49Chris RomeoJust quickly for those listeners that might not know exactly what that is, give me, give me just a quick sentence or two on what is the Gates Memo. I just refer to it as the Gates Memo, and a lot of people know what it is, but—

3:01Geoff HillYeah, I mean, you could sum it up by saying basically he got pissed off with Microsoft once again finding itself in the news with, with, uh, insecure products being delivered in an insecure fashion and without us thinking about— thinking ahead by putting security in. So he said, this is ridiculous, I'm getting sick and tired of this. and I want things to change. And so he basically put out this memo saying, you will create a security group, and you will sort it out, and you will get this done so that we're thinking ahead on security instead of, you know, security by design. So eventually, the Gates memo brought up 3 fundamental characteristics that Microsoft kind of built upon, which were the ideas of secure by design, secure by default, and secure in delivery. And those 3 ideas right there then basically begat the Microsoft Security Development Lifecycle.

3:52Chris RomeoYeah, and I think of that as the— that's the parent to all the other secure development lifecycles that exist in the industry. I know I was at Cisco as that SDL was being built, and we were having conversations with Microsoft and getting advice from them about, hey, these are things that work, these are things that didn't work, and in a very transparent manner. And something that I've always been been very fond of is the way that Microsoft shared that knowledge with other companies along the way.

4:21Geoff HillWell, I was one of those guys actually, because I was working then, I was already fully into the security group, and I was one of the guys who was espousing that. And I helped to build out the agile form of the SDL and deliver it out to customers who started using agile.

4:35Chris RomeoYeah, that's very cool. That's probably a whole other conversation for another day.

4:43Robert HurlbutIt'd be great to follow up.

4:44Chris RomeoYeah, I'd love to hear that story.

4:46Geoff HillYeah, sure. I've got no problem with following up on it. It's quite an interesting story of how you take a very heavyweight development lifecycle, the security development lifecycle, and you basically prune it to such a way that your customers can actually use it. Definitely an interesting path I did.

5:06Chris RomeoYeah. And so that'll be— folks, stay tuned for an upcoming episode where we unpack the agile form of SDL. But for today, we're here to talk about threat modeling, something like I said that we all know and love. And it's kind of interesting, I was talking to Adam Szostak maybe a couple weeks ago, and he mentioned you, Jeff, as somebody— he said, you got to check out what Jeff's doing in the world of threat modeling. He's doing stuff a little bit differently than we classically have approached it, which was intriguing to me. And so hence the reason I reached out and So tell us the story about how you got into this approach to threat modeling. There's got to be some pain somewhere in the background as to why you did something differently.

5:53Geoff HillYeah, I mean, I was part of a group called the security— what were they called? It was a very specific security group that I was working with at Microsoft. We were a worldwide group. One of the things that I tried to do at one point was to implement threat modeling across a number of different internal customers and external customers. And I found out that a lot of them didn't adopt to it because they didn't have the time and they didn't have the wherewithal to do it. So a lot of times I found myself working, you know, in line with them to get the threat models out. And I found out that time and time again, the same issues came cropping up, that we didn't have the time to finish a threat model. By the time we finished the threat model, the project was finished or the first iteration is finished or the sprint storming is finished or whatever the case was, that we were throwing too much information into the model and that too little information was coming from the model back into the real world, which was development. The model was disconnected after our first few iterations because we built the model out and it would stop reflecting reality. And these, all these different issues right here really stressed me out because I was— I had probably about, at one point, about 150 customers I was covering that I was trying to do in a very agile fashion. And trying to get threat models completed and out to each one of them in a fashion that we, we were describing in a traditional way was next to impossible.

7:13Chris RomeoSo wait, 150? So you're working on 150 threat modeling projects simultaneously, trying to keep those all straight? And—

7:21Geoff HillYeah, a lot of them ended up just being your straight up what I call the CSV analysis, which is a comma-separated value analysis, which is you just basically say, look, just list down your assets and we'll try to figure out how to get access to the assets and move on.

7:36Chris RomeoOkay.

7:37Geoff HillYou know, if there were small projects, I ended up doing a lot of that. With the larger projects, so let's focus down to about a dozen projects that were larger projects. That's when I said, okay, look, I have to give you guys an actual threat model. I can't just kind of wing it. and put down how do we access your assets.

7:52Robert HurlbutYeah.

7:53Geoff HillAnd so, you know, in a way, like, the, the accessing the assets bit, the very bare-bones CSV method, that, that worked, but it wasn't great, uh, because it didn't, it didn't give me any kind of information beyond what was, you know, how you could access the assets. Uh, then with the larger threat models, it ended up being that we got way too much into the weeds, and you found— I found time and time again I was trying to boil the ocean. or at least the team was. And they're saying, why don't we do a threat model on this? And next thing you know, you're threat modeling TCP/IP for what reason, I don't know. And you sit there and you say like, whoa, stop, you're doing too much. And that's when I started coming up with the idea of, hang on, we should do this in iterations. We should go back. And that's when I started reading up on agile architecture and saying I should base this upon agile architecture principles before I go forward again. And that's when I started really building this out.

8:45Chris RomeoSo are you, when you're working through these 150, for the ones, the bigger ones that you're actually doing threat modeling for, are you following the classic Microsoft approach of data flow diagrams and STRIDE and all that type of good stuff?

8:58Geoff HillYeah. So, and DREAD. DREAD is dreadful. That's my personal—

9:03Chris RomeoI always dread DREAD whenever I see it.

9:06Geoff HillIt was, DREAD was always, well, DREAD was something that never really worked for the impact for me because If you say to somebody, I want you to tell me on a scale of 1 to 10 what this pain is, somebody would say, well, what does 6 mean? I have no idea. And so it started, you know, how do you describe a 6? So dread became to me a very difficult exercise to, you know, to get out, to predict from people.

9:29Chris RomeoYeah, it's like when you go to the doctor's office and they're like, hey, what's your pain level on a scale of 1 to 10? Like, I get 10 and I get 1. I don't know, like, what's a 5? Like, my stomach hurts at a 5 level.

9:40Geoff HillYeah, exactly. Or, or I'm a 7.5 and someone says, what? I don't get it. And so, so that ended up being STRIDE. And I've had my, my issues with STRIDE in the past, but I think that STRIDE works for, you know, what it is. And that's a very simple mnemonic that provides you with attack potential, you know, attack scenarios. And so You know, the traditional way was that you sat down there, you asked a lot of questions, you looked up the security requirements, you looked at the business requirements, you looked at the underlying architecture, and then you drew your own diagram, which is your own interpretation of everything you read. And your own diagram might not look even close to what the underlying, you know, architecture was, but it didn't matter because that's what you did. And then the second step you'd go through is you'd sit down with, again, a bunch of people, you take up their time, you take up your time, And then you start using elements of STRIDE, you try to figure out where the boundaries of trust lay. And again, that might cause some, you know, a bit of friction within the people because you never were able to describe it properly. And then you said, okay, well, once that's done, we're going to apply STRIDE to certain things. Once you take STRIDE, then we're gonna break that down into ATT&CK trees. And that's where I lost a lot of people, including myself, 'cause you sit down and you say like, okay, how much time are we gonna spend on building this ATT&CK tree out? And you'll say, well, maybe about an hour, maybe half an hour, we don't know, we'll see. And then if you start building out too many attack trees, then about a month later you find out that things have changed and you have to build a whole new set of attack trees. And then it becomes kind of— it becomes a counterproductive action. Uh, so the attack trees very quickly went to the wayside for me, and then I carried on with the rest of the stuff, which was still building up.

11:19Chris RomeoHow much time are you spending— I'm sorry to interrupt, but how much time are you spending total in one of these threat models?

11:25Geoff HillOh, I mean—

11:27Chris RomeoBetween DFDs, STRIDE, attack trees, roughly, roughly how much time?

11:33Geoff HillIt would take me roughly, we'll say for one of the bigger projects, it would take me roughly a day to accumulate all the information from the security requirements, from the architectural diagrams, asking questions and all that right there. So about 8 hours equivalent. And then maybe take me between 8 to 10 hours to actually get a DFD without people saying this is wrong or that's wrong and getting feedback from the team and everything like that. In the meantime, I have to get all that done and then some in order to get it ready while we're still in sprint zero. Then I'd add all the information to it, and then inevitably we'd go back on the information and we start not arguing with disagreeing because it wouldn't just be saying spoofing here, it would be saying, okay, let's break down every possible spoofing attack we can do.

12:15Robert HurlbutYep.

12:15Geoff HillAnd let's describe every possible spoofing attack we can do. And so you do that and it ends up being a couple of days worth of work at the very least.

12:24Robert HurlbutYeah.

12:25Geoff HillMaybe you're talking 3 days worth of work that you're talking, you get it done. And by then, if you're in a purely agile environment, well, the sprint team's already taken off. They've spent like a day doing model storming and in sprint zero and they're off to the races and you're already behind the times because you're already telling them, well, guys, you have to put in the mitigation that we described here.

12:46Chris RomeoIt's like trying to change the engine on the airplane, right? After the plane is mid-flight, you're out there saying, well, we gotta swap out that engine.

12:53Geoff HillExactly, exactly. We gotta do rewiring on all the internal systems here. They're saying, but we're, you know, we just started, like, we're mid-sprint. We've already finished with a couple of the things. You're way behind. Like, oh God, this is, you know, this is frustrating. And so, and then after doing this, you know, We'll say the 12 that happened during that period of time were the frustrating bang your head against a wall until your head stops hurting because either you banged it too many times, you knocked yourself out, or you stopped banging your head and you've created a hole in the wall or something like that.

13:24Chris RomeoYeah. I can certainly see how this doesn't scale, right? This is not an equation where I'm like, wow, if we just had 10 more Jeffs, we could do an additional 3,000 threat models per year. This isn't a model that scales. Because the end result is, like you're describing here, has a lot of problems, and it's just taking a lot of hours per day to be able to get something, and it's questionable what the total— how good that actual information is.

13:55Geoff HillWell, and the information always stays frosty for a while. I mean, it goes stale very quickly, especially in a highly agile environment. You put all this information, you know, you take all this information, you create a bunch of documents. Generally, the documents get put in someplace. I love— someone referred to Confluence as a place where data goes to die, and I love that comment because I totally agree with that. It's like you dump a bunch of documents up there and you forget about them because you're off and you're doing something else. And then somebody comes back and says, hey, did you do a threat model on X? And you say, no problem. You dig it up and you find out that your threat model has no bearing to reality, you know, 2 or 3 iterations later.

14:30Robert HurlbutYeah.

14:30Geoff HillBecause you haven't kept the threat model up and no one else has because either they don't have the time or they don't have the experience you do. And you're basically back to square one. You're like, okay, this isn't very helpful because the threat model isn't responding to the current actions. The threat model is providing old advice. The threat model is putting into a dead-end area such as confluence. And the threat model hasn't got any outputs that the team can actually digest, can readily digest. So all of this led to serious frustrations. And that's when I decided, I mean, I have to look at it a different way, and that's when I have to actually start looking at it from an agile architecture point of view, and then also implementing the idea of rapid prototyping and kind of combine the two so I could get inside. And actually, this works very well with the DevOps environment.

15:15Chris RomeoSo let's explore a little bit now. I feel like we've got a good handle on the problem space, and I wouldn't say I would argue with you about any of those things. I totally agree with You know, and I've lived that life as well. I helped to roll out threat modeling at Cisco to 25,000 developers. So I know that scale problem and that pain. So when you talk about rapid prototyping or rapid threat modeling here, what does that actually mean? Give me a definition first for that.

15:45Geoff HillSure. So the rapid threat model prototyping philosophy is kind of a just-in-time philosophy, an 80/20 philosophy if you think. you know, that way. It's basically you want to do 20% of the effort to get 80% of the way there. And you want to do— you want to put in just enough information so that you can understand the model, so you can understand how to fix the issues or how to mitigate the issues, and so you can move to the next step and you can provide it back. And you also want it in such a way that it's simplified, in such a way that it might take a little bit of time of the security professional, but the actual development team can take over and can maintain and curate the threat model, the following threat model. So there are a number of different design ideas behind this, and one of them is to get rid of— and this might be controversial to you guys, I don't know— but to get rid of the idea of doing data flow diagrams. Immediately I thought, if I can actually piggyback on top of the actual diagrams that the architects and the designers make, like for example, the designers within a team, then I'm right close to the heart. So if the designers do a change, then if I base it upon his or her design, then the threat model will change too.

16:54Chris RomeoSo you're not saying do away with— you're saying do away— rapid threat modeling prototyping does away with creating a DFD for the sole purpose of the threat model?

17:06Geoff HillCorrect. Correct. What the rapid threat modeling prototyping philosophy is, is use the current tools we have. So if the team has created a design, team creates a design, piggyback on top of that. The team owns the design, the team changes the design, and then we will use the changed design instead of creating our own design, which forks off of that and then goes off to die somewhere.

17:30Chris RomeoSo does this— I'm sorry, go ahead, Robert.

17:33Robert HurlbutNo, I was going to ask, how is that design represented? So when you say design, is that by scanning code, or how is that design represented?

17:43Geoff HillThere are any number of different ways. So one of the ways that the design is obviously represented is just by people drawing up on a drawboard, on a whiteboard or something like that, taking a photo and then putting the photo in, you know, and creating an actual graphic design out of it, perhaps in Lucidchart or Draw.io or something similar. Another way is to look at the code and to work backwards from the code if you already have code there. If you have, for example, brownfields design. Brownfields design is more adaptable to code, whereas a greenfield design is probably best done with some kind of a diagram. The diagrams are usually the best because we're graphical at the very heart, human beings are. Usually, I think it's best to start with some kind of a diagram to show people. I'll give you an example. When I was working over in Klarna this last week, and I was teaching, there was a Swedish startup a bank startup. And so I was teaching a number of different groups how to do the rapid threat model prototyping, and part of the whole thing was to get out there and to get them to do the design. Now, some of the guys who had gone in here hadn't actually done a design, and so when they did the design, one of the first things they said was, wow, we never actually visualized it like this. But we helped them to go through that and to help them develop out. So that was actually, by doing the design, helped them in other ways functionally in addition to non-functionally.

19:03Chris RomeoSo I'm going to put on my ex-Cisco hat here as somebody who had to do threat modeling at a large-scale capacity. And so I guess my concern when we're saying we're going to use the existing designs and things that are there, I could imagine a lot of inconsistency in the design. And I say this based on experience. I saw some designs where people did a really nice job and had great diagrams and very well documented. And I saw other things that were— there was really no design behind them at all. So how do you deal with that? I could see it's obvious how you would deal with it with the people that are doing a good job on their architecture diagrams. How do you— how does rapid threat modeling prototyping fit into the case where somebody isn't doing what they should be doing from a, just a general system architecture design?

19:58Geoff HillSo basically, again, we view it as being a just-in-time kind of philosophy. So if they give us a very rough overview of what their system looks like, let's say it's a brownfield system, for example, and then we work on that right there, we can actually work with it. You know, again, the philosophy is we want to get— the whole philosophy behind rapid threat model prototyping is to get the conversation started, not to finish the conversation. So if you can, if you consider that, you say, you know, just-in-time philosophy, get the conversation started, get some kind of a design up there, doesn't have to be perfect. The minute you start trying to make it perfect, well, we're gonna wait for a long while. Some teams may get it, but then other teams which don't get it and don't get it perfectly, we can still work with that and say, look, we can work with that design, we can work with what you guys have. Let's move forward and let's work with what you have.

20:49Chris RomeoSo they may draw you a picture on the whiteboard. What you're saying is in that case, you're not constraining them to the DFD language that we've— the classic threat modeling DFD. They can draw the picture any way they want. You're going to operate on top of their picture.

21:04Geoff HillSorry, apologies. Yeah, I didn't mean to talk over you. Yeah, so it ends up either being a context diagram or process flow diagram, which to me are probably a lot more meaningful to the teams than a data flow diagram.

21:16Chris RomeoYeah. And now when you say, um, context diagram, do you mean like You're not talking about like state, like a state diagram or anything, or is that included as one of the things that you look at?

21:27Geoff HillYou could, you could look at a state diagram, but what I mean context diagram is I mean very high-level view of things. Because a lot of times these different teams, when, you know, when you give them an hour, for example, Klarna again, I gave them an hour to work with something. And in the hour we got a fairly high-level diagram. We were able to get some good threats out of that. And so the hour was useful to them. that they, that they did. So what we want to do is we want to get some kind of a representation diagram for them, uh, and it doesn't have to be great, it just has to have just enough information to start the conversation.

21:58Chris RomeoAfter the break, Joff explains where we go next. This episode of the Application Security Podcast is brought to you by Security Journey. Security Journey has a new weekly publication called High Five. 5 security articles that are worth your time. We scour the internet looking for the best articles on application and product security. We add in just a touch of sarcasm and snark in our descriptions. Just what security people and developers love. To sign up, visit www.securityjourney.com/highfive. That's /hi, the number 5. Welcome back. Joff dives back and explains, now that we have a diagram, where do we go from here?

22:50Geoff HillSo the next thing we want to take a look at is we want to get an idea, because this— and you guys will probably agree with me— is to me the most important step is getting the access control correct. In order to get the access control issues out there, at least identify them first, because I think that most problems can be pointed back to poor access control or lack of access control, such as injection issues, such as obviously elevating privilege, potentially other issues too. So in order to do that, we wanted to— we wanted— I wanted to get some way of identifying those quickly. And I looked at trust boundaries and I thought trust boundaries don't really do it for me because first of all, you're drawing lines around things. And second of all, you're not really— you can't ultimately— you can't automate this. So I went back and I said, well, what if I enumerated trust zones onto the various objects that existed in the diagrams, the various elements of the diagram? So trust zones are basically, I would say, how I said, as I said, one rule to the trust zones were that the number 0 means it's outside of your trust, means you have no control over whatever that element is. So generally, you know, if you're talking about a website, then obviously that's the human beings who interact with the website or the other services. If you're talking about internally, it could be other internal processes that interact with your, your system that you don't control. Because it's whatever, because, because whatever you want to do, you want to make it relative to your system, whatever the threats are.

24:19Chris RomeoMm-hmm.

24:20Geoff HillAnd therefore you want to, you want to take that. And people had said to me, well, should we take a look, you know, take a look in terms of the whole company? I said, it's not helpful for you guys. If you want to practice defense in depth, which is a very strong kind of architectural principle, then you want to make your system resilient. In order to make your system resilient, you have to take into account that every inbound from other systems, whether they're inside the company or not, are potentially inbound attack vectors, and therefore they're outside of your control. So the primary rule right here with doing zones of trust is you put 0 on any of the outside interlocutors who come into your system. And then inside your system, you rank the different elements by numbers, you order them by numbers based upon the criticality of the system. And it's kind of a difficult way to explain it, but either the system directly requires more permission sets— sorry, not the system, but the element in the system, requires more permission sets than you know it should, or it has a more critical function. So something that would answer both those questions would be a database, for example. We know that databases require a pretty high set of permissions to get access to, or should. We know also that they're usually pretty critical to the system involved because they carry data at rest and are then potentially the primary attack vector for an attacker. So if you're looking at any kind of system, then you're then looking at all the elements with having a trust boundary number— sorry, trust zone number associated with that element, starting from 0, which are elements outside of your, you know, out of your control, all the way up to wherever the data ends up. Now, the general rule for this is if the data ends up syncing somewhere, if it ends up hitting the disk somewhere, in your system, whether it's in the cloud or local, then that is usually your highest number. So you start getting a ranking of all the different elements.

26:17Robert HurlbutSo do you keep— I was just curious. I mean, that makes sense, I guess. Do you have some kind of a key to know, like you just mentioned, certain items outside of your control inside your system that you're trying to manage? I mean, do you have sort of a key to help you decide or somebody else decide when they're trying to build one of these from scratch?

26:44Geoff HillYeah, I mean, I have general rules of thumb on what should be outside and stuff like that. Obviously, anything, you know, the easiest one is if you're building an internet-facing system, then anything that's outside of the, you know, your boundary devices, whatever they are, your DMZ or your website, you know, your server-side website, then those are considered to be outside your control. people's devices, people interacting with your system, other services interacting with your service endpoints, that kind of thing. If you're inside and you have a system that only operates on the inside and you're developing it, then if you're personally developing everything and you have control over that, fine. If you have things that are shared, then you have some control over it. But if you have things that interact with you that are other systems inside the company that you don't control at all, they're just either interacting with you or pulling data from you, then they're zeros. They're zone zero.

27:40Chris RomeoOkay. And so, and then I'm guessing that this ranking system that we use, we're going to pay the most attention to the one at the top of the list, one being the most critical. That's where we're going to focus our efforts at a future stage. Is that the reason behind numbering them?

27:57Geoff HillUh, there's, there's that. But there's also the fact that you can now start easily implementing all elements of STRIDE on all of the, on all the elements inside of the system. So I created a bunch of really fast rules. Like I said, it's rapid threat model prototyping.

28:13Robert HurlbutYep.

28:13Geoff HillSo in order to, in order to implement this, what I did was I said, okay, the very first thing we wanna do is we wanna get the ranking. The ranking will allow us to quickly identify potential access control points and access control issues. which to me are the most important. Then going down in line, then I implement other rules for spoofing, for tampering, for all the elements of STRIDE, and we allocate those to each of the data flows and to the elements inside of the system. We do that quickly using the rules that I developed, which are also based upon the difference and the values that you've created with the trust zones. Eventually, what you can do then afterwards is you can figure out criticality of data flows by looking at the numbers. So if you look at the cumulative value of all the numbers in a data flow, and if that's a higher value, then you probably want to concentrate more time on that because it's more critical value to you. You'd want to look at jumps between elements. If elements have a jump of more than 1 in terms of their trust zones, Then you should probably focus more on those 2. So it allows you to focus on areas and allows the team to kind of get around and start realizing where they really need to put their efforts to.

29:28Chris RomeoOkay, so then what are some of the other, other examples of the rules that you've described here? I mean, we talked about the ranking, and then we talked about how you're throwing spoofing and then getting going all the way down through the the STRIDE and then potentially even adding some of those values. I mean, what, gimme another example. I guess I'm a little fuzzy on what, what you mean by the rules. If you can gimme another one, that'd be great.

29:53Geoff HillSo I've, I, so I've created a number of rules. I've created 6 rules, 6 basic rules for, uh, the Rapid Threat Model, RTMP. And rule, rule number 1 is always to get the authorization or get the elevation of privilege issues out there, the E on STRIDE. And so what you do is you assign E to any element that is the origin between 2 elements connecting. It's the origin element and where there's a difference, a positive difference in the zone. So to give you an example, if an outside person were coming into you, and they were calling your website and calling to your web server. So they make a connection to your web server. The outside person would be a 0. Web server would probably be a 1 because you'd have low trust in it because you probably put it in a DMZ. And so therefore you would have a difference of 1, a positive difference of 1. Therefore, that outside person potentially would be an elevation of privilege threat.

30:57Chris RomeoSo the criticality is not— is a higher number of Criticality better, or does that mean something's more critical, or is it a lower number?

31:05Geoff HillIt means— so you're going up in value from zero, so you're not going to go down in value. Uh, you may, but I'm— we're not going to discuss that right now for the simple— yeah. So you start off with a zero, and zero is always out of your trust, and then everything goes up in value, and it's always relative to the model you're making. It's not— I, I've never been able to try to put it company-wide, for example. Yeah. So, a 6 on your model might be an 8 on someone else's model, for example, or the equivalent of an 8. But essentially, what you do is you take and you assign every element inside of that model a zone of trust, and that'll be a positive number that's greater than 0.

31:43Chris RomeoDoes it have to be unique though, or can you reuse the same number?

31:47Geoff HillOh, yeah, you can reuse the same number. So, ones with similar numbers mean that they have a similar level of trust. Basically.

31:55Chris RomeoOkay. And whoever's the modeler is able to set that for that given model, which allows them to move faster because they're not using— they're not having to look up some criticality value in a document somewhere.

32:09Geoff HillNo, they just find— no, and they shouldn't be doing that. So basically, to make it fast, they sit down with some of the team members. And they basically say, okay, is this less or more critical to your system? Yes, it's more critical. Okay, then we'll put this number on. And then you go back and you readjust it, and it takes maybe 10, 15 minutes in my experience that you do this. And when you go down and you assign the numbers to each of the elements, then they— then immediately the team can look in and go, oh wow, they notice the differences, they can see the numbers, and it's a lot easier to point out than drawing trust boundaries around different elements and stuff like that. And so similar elements, for example, anything with a number 1 potentially would be in your DMZ.

32:48Chris RomeoDMZ.

32:48Geoff HillThat would be an example. So you'd have a lot of different, like you might have a file server there, you might have, I hope not, but you might have a web server there, stuff like that. They're all in that one zone and then they call into interior applications or interior, sorry, elements, which would then have higher levels of higher zones of trust.

33:07Chris RomeoGot it. Okay. Yeah, that makes sense.

33:09Geoff HillOkay.

33:10Chris RomeoSo we've talked about kind of the first rule is the authorization. And I'm with you. I'm tracking with you now about the criticality levels, and, and that's all making sense to me. And, and I will say this, I like the idea that this— that it appears to be relying on the gut kind of feel of the developers, the people that are in the code and in the designs and everything.

33:32Geoff HillYeah.

33:32Chris RomeoWhich is something I like because they— I, and, and I would— I probably said this a thousand times in my career when I'll, when I'll talk developers. It's like, listen, I know threat modeling, but you know your code and your product 100 times better than I ever will. So I'll let their gut drive the direction that we're going because they do know better. They live and breathe this thing and I don't.

33:53Geoff HillWell, and you know, it's interesting you say that because, again, it's fresh in my memory, but I've also spent quite a bit of time teaching BBC this and they're taking up my methodology too. But in all the sessions, what happened was, Generally, you have them down there, and I'd say, look, write down the numbers as fast as you possibly can, and then go back and revise them. And it's interesting, they get together, and they look back and say, oh, actually, this is more critical, this is less critical. And they do some adjustments right there. And I just sit back and I give them a bit of advice and guidance. But I say, look, it's up to you guys to figure out the criticality. You know the systems. And they finish up with that, and then they end up being very happy with it. And then it's very easy to start implementing the rules. And the rules are out of the box. Like I said, the very first rule you figure out is the elevation of privilege. If it goes a positive difference, then it's an elevation, potential elevation of privilege issue. If there's a jump, then that means you really should be, as, as a person who's either a threat modeler or developer, you really should be looking at that and be concerned about that particular jump.

34:52Chris RomeoIs that rule number 2, the jump?

34:55Geoff HillWell, it's a sub of rule number 1. Any of the differences So a difference of, you know, a difference of more than 1, for example, would be more concerning than a difference of 1, but there's still, there's still an elevation of privilege issue.

35:06Chris RomeoI got it. Okay. Difference of more than 1. Got it. Maybe that there's a fundamental flaw in your, in your architecture.

35:13Geoff HillExactly. All right.

35:15Chris RomeoSo now this, what's another rule?

35:17Geoff HillSo the next rule is spoofing. So spoofing means basically anything coming from outside of your system into your system. And so any of the paths you have going from zero or less than zero, but we won't get into that, but zero into your system, you're gonna have potential spoofing issues. Now, again, think of these rules as being quick rules to set up stuff and to sort stuff out. They're not meant to be comprehensive. Again, they're gonna cover the 80/20 part.

35:42Chris RomeoYep.

35:43Geoff HillAnd so what you do is you get, in general, you'll get, you usually get like some of the outside systems, you can't control them. then in general, you get the first layer of systems that are inside of your system— sorry, the first layer of elements inside of your system— and they'll generally have spoofing issues on them because they're the first ones being hit. And therefore you're saying, okay, now we need to be sure that we have some form of identity that is being passed into the system from these different elements.

36:11Chris RomeoOkay, so that definitely makes sense, and I see how that's I'm starting to get on board here with the idea because what I'm seeing is you've figured out a rule, a simple rule-based system to quickly let somebody deduce if they're spoofing, for example.

36:31Geoff HillYes.

36:31Chris RomeoWhereas I would have to sit there and explain spoofing as far as here's what it is, here's how it works, and then I'd have to say, okay, look at this DFD and tell me if you see the opportunity for spoofing. And you're just giving me a little calculation that says, okay, if there's a 0 on this side and it's talking to something that's higher than a 0 on this side, then there's a chance of spoofing.

36:51Geoff HillYes. And then of course the difference in between the 0 and the higher than 0 come into play because obviously a higher number means that again, you've got a more critical component, you've got a critical difference here and you might have to go back and rethink your design. But again, what it does is it starts a conversation. So tampering, again, tampering is from lower to higher anywhere in the system, but it's on the data flows or on the connection flows, not on the elements.

37:18Robert HurlbutOkay.

37:20Geoff HillBecause the elements are an abstract way of pointing, saying we're passing data of some kind, either a command or passing some kind of packet or something like that. Repudiation. Now repudiation is an interesting one. And Robert, I think I got into a bit of a discussion with you on LinkedIn a while back. repudiation.

37:36Robert HurlbutRight, I remember.

37:37Geoff HillYeah, and, and I'll, I'll, I'll stick my neck out again. I'll say, look, I don't really like explaining to people who aren't in security what non-repudiation means to repudiation. They don't get it. And so I sat back and I said, what the hell does it mean actually? I mean, to me, repudiation means that either there's a lack of authentication or poor authentication, or somewhere, somehow, somehow, somewhere we've tampered with the integrity of the logging or some kind of system like that. So to me, repudiation is the previous 2 elements astride, either a lack of authentication or a lack of integrity, which means either spoofing and/or tampering has happened on the system to allow you to repudiate against it. So with repudiation, what you're going to find with the rules is you're going to find general repudiation will happen around the spoofing, obviously. And in some cases, what happened was some of the tampering along the links on the interior.

38:33Chris RomeoSo, so you're saying it only applies to the links on the interior?

38:37Geoff HillNo, no, repudiation will happen. Well, repudiation will happen where spoofing happens for the most part.

38:43Chris RomeoOkay.

38:43Geoff HillI, I don't know any exception where it hasn't in any of the cases I've done.

38:46Robert HurlbutYeah.

38:47Geoff HillAnd then it'll also, repudiation will happen and then you'll look at contextually, but it'll happen on, on the interior connections where you can do tampering. Then this is again where the team comes in and you say, look, does repudiation mean anything in this right here? I can tamper with this data. And they'll say, oh yeah, we're doing logging here. Yeah, you can probably repudiate that if you can get in and trash the logs, that kind of thing. So again, it's your experience, but I'm driving the conversation to that area as opposed to in general, in the old days, I'd say, ah, you know, repudiation means non-repudiation. And then everyone looked at me really funny.

39:20Chris RomeoSo I gotta throw this out though. So the way that I explain When I talk about non-repudiation is this is the Bart Simpson principle. I didn't do it. Nobody saw me do it. Can't prove anything. That's non-repudiation. And if you've ever watched The Simpsons, you kind of, you get, you know, what all the things Bart gets away with and whatnot.

39:40Robert HurlbutSo.

39:41Geoff HillEspecially when stuff breaks right next to him when he's broken it. I didn't do it.

39:44Chris RomeoYeah. So that makes sense. Okay. So repudiation, information disclosure has a rule, I'm guessing?

39:53Geoff HillIt does, from higher to lower zones. So the thinking here is if you're passing information from a more privileged zone or more critical zone to a less critical zone, then you're probably— then that information probably has some kind of more privileged, I don't know, capability around it or something like that. And so you might want to check it, or you should check it.

40:12Chris RomeoAnd then denial of service.

40:13Geoff HillDenial of service happens on the connections that are connecting from the outside in because, again, we're talking about rapid prototyping rules here. If you're looking at the most probable attacks that are going to happen from denial of service, they aren't going to be happening internally. They're going to be happening from external factors happening into your system.

40:36Chris RomeoYep. And then we already talked about elevation of privilege. We kind of started there.

40:41Geoff HillYeah. And elevation of privilege to me is the most important. That's why you want to do that one first.

40:45Chris RomeoYep, that makes sense.

40:47Geoff HillYeah, and that's why we do the boundary. Now, the reason— again, the reason I did this is I can now— and I've— and we've actually started to work on this, uh, in, in BBC— but you can do a simple methodology, or you can do a simple, um, which I'd say simple second-step methodology right here, where you can quickly add and add the numbers together and quickly subtract them. Now what I've done is I've also taken and you know, on my own, I've created a system. I've created a software as a service which does all this just and adds other things too, because that's ultimately what I want to do is I want to make a system for people that they could use and they could put into a DevOps system they could automate.

41:26Robert HurlbutYeah, that's something I'm really interested in because I know you've stated before, like, for example, you could use a drawing from draw.io, push that into to what you're doing and then it would evaluate based on all these rules that you're talking about. Is that essentially just querying, let's say Draw.io, querying the diagram and how it's put together, and then from there you can determine and apply all the things that you're talking about?

41:54Geoff HillYes. By the way, Draw.io, they're impossible to work with because they don't provide templates. Or they don't provide templates of what they do. And so when they change their underlying XML, it's infuriating.

42:08Robert HurlbutYeah.

42:09Geoff HillBut I'm working with them now, so they're helping me. But for example, with Draw.io or Lucidchart, for example, you can store data inside of each of the objects, inside of each of the elements as name-value pairs. So you can actually store the zone value and you can store stride inside of there, for example. Now, once you do that, you can then save that diagram as an XML reference diagram, and then you just parse through the XML and you pull the data out as necessary.

42:38Chris RomeoSo is your tool actually— so are you extending threats anywhere beyond STRIDE, or is this—

42:46Geoff HillOh yeah.

42:46Chris RomeoOkay, so the tool that you have and the methodology, obviously the methodology, the STRIDE or the threats all come from the conversations. Does the tool have an additional database of threats that are then deduced?

43:00Geoff HillIt does, it does. So the RTMP is meant for doing with Teams, as you rightfully deduced right there, and it's meant to introduce people to the concept. The tool then takes all that right there and then adds to it. And it adds, it looks back and it takes the CWE, it uses CWE and CAPEC as basis, Okay. Um, for, for, uh, building out library of threats right there. It actually builds out a, an, an enriches a language that builds upon STRIDE that then enumerates upon. Are you guys familiar with the Security Frame by any chance?

43:33Chris RomeoYou said the security— well, say the name again.

43:36Geoff HillSecurity Frame. No, it's a—

43:39Chris Romeono, I'm not.

43:39Geoff HillOriginally, a gentleman named JD Meyer at Microsoft created it, and he said it was 10 elements that basically when they, they did a whole bunch of, uh, interviews with people and developers inside of Microsoft and continuously these elements came up. And so they said, okay, we're going to make something called the Security Frame. So it's kind of like making the OWASP Top 10 static, but then generalizing some of the issues in the OWASP Top 10 and adding STRIDE to it, I guess is the best way I can, I can manage to say it. But the Security Frame, it basically expands the 6 elements of STRIDE out into 10 elements. So it takes into account logging, takes into account cryptography, sessions, That kind of thing. And so then what my software does, my software actually takes and uses that as a basis, as a communication basis. It maps it to STRIDE, it maps it to the OSTAP 10 if you want to, and then as a background uses CWE currently and CAPEC for its data to mine to actually create out the threats. So that's the addition you would get by using the tool over Okay, cool.

44:44Chris RomeoSo that's, I think, something for our listeners to take a look at. And so, Jeff, where would you recommend people go to get more information about what you're doing? Potentially, is there a talk you've done recently somewhere public where people could look up slides and dive deeper into this topic?

45:01Geoff HillOkay, so I'm pretty active on Twitter. And I continue to maintain that active state right there. But then also GitHub, I have a GitHub repo which if you look up Two-Tamantic Threat Modeling or Rapid Threat Modeling, you'll find the GitHub repo. And then I'm putting basically right now as I'm putting my current presentations up there, I'm adding a white paper to it. You can go to my website for more information, although the website is geared towards the tool obviously. and not towards the methodology. In addition, if you want to find out more of where I'm going to be teaching next or talking next, I will be posting that up on Twitter and on LinkedIn.

45:40Robert HurlbutOkay.

45:42Chris RomeoAnd we'll definitely post these links in the show notes for folks to be able to access. And so, Jeff, thank you for taking the time today to share this rapid threat modeling prototype type of thing. I think there's a lot A lot of really cool stuff that you're doing here. And sounds like you've really listened to the developers that you've worked with over the years, which I think is half the battle in trying to do threat modeling at scale. And I look forward to diving into this deeper, and we're definitely going to schedule you again to come back and talk about Agile SDL and the journey that you went on there. So thanks for being with us today.

46:19Robert HurlbutYeah, thank you.

46:20Geoff HillThanks very much. I guess one more thing I'd like to say is just that With the RTMP, when you finish up, then obviously people go through, like there's a second wave of people when they talk after they've initially put out the elements of Stride, and they'll say, no, it doesn't apply here, that kind of thing. So that has to be said. That's another iteration that they do.

46:41Chris RomeoOkay, so kind of weeding out the false positives.

46:44Geoff HillYeah, exactly.

46:45Chris RomeoOkay, very cool. All right, we'll get that in. Okay. All right, well, thank you very much, Jeff.

46:50Geoff HillThanks very much.

46:51Robert HurlbutThank you.

46:52Geoff HillBye, guys. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.