Software-Centric Threat Modeling

Engineering-led, developer-focused, or software-centric threat modeling: they all have software in common. Composing software into functions through the user story's lens is important. Farshad Abasi shares his journey from being a software engineer to forming a global AppSec team at HSBC Bank. Farshad expresses the importance of asset-based threat modeling and the need to keep things simple. He emphasizes the importance of focusing on the user story and considering the "comma, but" scenario to understand potential threats. He also suggests using pull request templates in source control to ask standard threat modeling requirements-specific questions.

Farshad recommends doing architectural threat modeling at the beginning of the development process and revisiting it periodically, perhaps quarterly or annually. He also highlights the importance of being part of the DevSecOps process to review user stories regularly. 

The key points are asset-based threat modeling, following the data, focusing on the user story, balancing high-level architecture threat modeling at the right time, and adopting pull request templates as reminders for threat modeling. 

Provide a solid process that makes sense to developers, as they don't mind threat modeling when presented in this way.

Transcript

Chris Romeo: 0:09

Engineering-led, developer-focused, or software-centric threat modeling. Each of these is threat modeling with a focus on those that write the software. No matter what we call it, the goal is to dig into the software and decompose it into functions by looking through the lens of the user story. Let's explore threat modeling. In the world of developers,

Farshad Abasi: 0:32

Hey, Farshad Abasi hailing from Vancouver, British Columbia up here in Canada. I started as a software engineer. Went, did the com slide thing, went built software, started building, web applications back in the.com era. A friend of worked at HSBC Bank and they recognized the value of doing application security and software security from inside the development organization rather than outside team. we ended up forming a global AppSec team.

Chris Romeo: 0:58

Large organizations must choose a specific process and methodology to succeed in threat modeling. Farshad landed on asset-based threat modeling at the core.

Farshad Abasi: 1:09

About a year we discussed this, and now a conclusion was that we were doing, a simplified version of OWASP, asset-based threat modeling. Keep things simple. Don't make it too complicated. So the asset is information. It's either that or the resources that cost you much. take an internet banking application, that internet banking application is assets. So the balances and the people's names and all that's one way they could lose money is that, that data is either deleted or. Compromised, you or exposed or modified in some way. The other way that bank could lose money is that the, compute that's running the, web application is misused so that the attackers run some crypto mining on there, and then they're just like costing a ton of money that's also gonna get charged. To that department who owns that particular application. So your application can cost you in two ways, Your, the cia, the confidentiality, integrity, availability, impact on the data, as well as some resource impact on the infrastructure that you're running in. That's where we draw the line. So we do asset based threat modeling. We say how can those assets be hurt in the way, like how can the data be hurt in terms of the cia and how can the compute and infrastructure be misused that it would cost us money?

Chris Romeo: 2:10

Threat modeling is only as repeatable as its process is robust. Here's Farshad's, take on the process.

Farshad Abasi: 2:19

It seems like the general way that everyone teaches this is says, you have something of interest, It's an asset. use the house example, right? You got an asset is sitting somewhere, someone's gotta get to it. What are the different entry points to this? So the different entry point is your window, your door, your chimney. Each of them may, some may be easier, some may be more difficult, depending on what's at stake. The attacker will go and, and leverage more resources to get to the asset. So if it's like a. A hundred million dollars in the house, he might try to go through the chimney if that's how, what he has to do, because it's a lot for him to gain. as the impact goes higher, then there's more to gain for the attacker and they're, more likely to take extreme measures. So you have to really focus your threat model. how theoretical do you get is based on what's there for them to gain. you of start with that conceptual model, but then that's the traditional threat modeling, Then you take an application system, let's decompose it into, its architectural components and the links, and then follow the data, So that's easy to understand

Chris Romeo: 3:10

Sometimes as a threat modeling teacher, you find illustrations that work to help people simplify the steps they must follow, like Farshad does using data from Star Trek: Next Generation.

Farshad Abasi: 3:21

I remember the presentations where we used to teach the teams at HSBC. We used put a picture of data from Star Trek and it'd be data. And everyone would remember that. if you're lost, just follow data. Where does it come in? Where does it go? Where does it get touched? Wherever it gets touched, it's an opportunity for an attacker. To do something bad to it. So that's easy for developers, for everyone to understand. Is it processed security? Is a stored security in those, points? where that stops short is that, within that component that you're making, so maybe that's processing the data in a secure way, but maybe there's a function in there that could be abused.

Chris Romeo: 3:52

Now we hone in on one of the most important parts of Farshad's process, focusing on the user story. As my friend, Izar Tarandach, is fond of saying,"Threat model, every user story." The plot thickens as Farshad adds the"comma, but."

Farshad Abasi: 4:11

Take a user story. I'm making a function or a feature here, that as a user I should be able to view the list of my transactions. As a user, I should, I should be able to view. The list of my transactions for my checking account. If you want to figure out the threat scenario, you put a comma, you put a, but you say comma, but I should not be able to view other people's transactions there. You just came up with a threat scenario that as a user you shouldn't be able to view other people's transactions. when you're building this user story, have you thought of a control that prevents that person from being able to view other people's transactions with the feature that you've built? We of practice these things where it gets them to not just think of the good user because the good user just wants to see their banking transactions, their account balance, but the bad user wants to use that function to see other people's data. in any of the user stories, if they put that"comma, but...," and then think of what the bad user would wanna do, and that's a really easy way for them to understand. And then that's how we get them started. And we, mentor that. we do a but of that stuff together. And then hopefully once they get a hang of it, we get them to start, coming up with. those evil stories,

Chris Romeo: 5:10

Here's another tip I want to highlight so you don't miss it. Farshad recommends using pull request templates in source control to ask some standard threat modeling requirements-specific questions.

Farshad Abasi: 5:22

If the development team is using, Git for example, if they have a pull request set up so that there's a manual review required, we get the person that's doing the manual review in the template for the poll request, to add a few of those common things that they need to remember. Like, in this user story? Have you remembered to consider access control and input validation, et cetera, et cetera, all those application security controls that I would call cross-cutting concerns or common controls that apply to most stories. We would put them in a poll request template as a reminder. So when they're considering the threat model, have those controls been considered or as part of the solution

Chris Romeo: 5:54

As we think about the user story-based threat modeling, it does open a challenge that at the user story level, we miss out on threats that exist at the 50,000 foot view or the architecture. Farshad has an answer.

Farshad Abasi: 6:09

If someone was to say, Hey, fresh, I'd wear DevOps team. When should I do threat modeling? I say, you should do that architectural threat modeling at the beginning when your architecture is forming, and you get into sprints and you build and you build, and maybe once a year when you do your tabletop, you also do a full threat model at the architecture level or maybe every quarter. So you see, have you added any architectural like interfaces or are you talking to any new third parties or data stores? If you are a security AppSec guy and you come to me and say, test my application and do that functional threat modeling, You've spent hundreds of sprints doing all those user stories. For me to retroactively go through all of those and do it, it doesn't work. So that really works well when you're actually a part of the, the DevOps process if you're part of the DevSecOps, if you will, and you're able to regularly review those user stories. Otherwise, when we do it retroactively, I just go, give me the high level functions. Like I know I'm not gonna be able to dig into every user story you've developed. Just tell me at a high level, what are the key functions of your application, and then I'll just try to figure out if there's possibilities to abuse those business functions and functional threat modeling in regard. The architecture diagram is the stuff that should only be done once or twice. Remember I was saying that that's not the stuff that developers should do every day. That's like, Hey, in the beginning, let's take a ideal world scenario. You're building an application, you're gonna follow DevOps, right? Or Agile. There's always gonna be that initial inception product inception stage, where you create that initial architecture and your first backlog of user stories at that stage before you go into Sprint one. You define the high level architecture. You're like, yeah, we're gonna build a microservices application. AWS is gonna look like this, right? You haven't started building anything yet. That's where you do that initial threat modeling. At that point, often it's probably a good idea to get a security SME involved of some sort. If not, you know, you get your solution architect, you know that. Then they do that traditional architecture level threat modeling,

Chris Romeo: 7:50

Asset-based threat modeling, follow the data, focus on the user story, balance the high-level architecture threat model at the right time, and adopt poll request templates as reminders for threat modeling. Developers don't mind threat modeling when you provide a solid process that makes sense. Learn from what Farshad has achieved with threat modeling and focus on modeling every user story.