STRIDE Threat Modeling: What You Need to Know

Your teams need STRIDE threat modeling to identify and eliminate potential vulnerabilities before writing a single code line. They can do this by mapping out their application based on unique use cases and business logic. 

You can return to the STRIDE framework anytime, even when developing or in production with your application. And every time you release new code, see how it will affect your application’s overall attack vector. Employing threat modeling should be your first step toward building networks, systems, and applications that will be secure by design. STRIDE is a model of threats that you can use to ensure secure application design.

Threat modeling, as a technique, has been remarkable, not only for good application design but also for having conversations with security partners/teams on the threats we have identified and what we’re doing to mitigate them. 

Shared vocabulary with Security

When we first came across Security and Risk Management several decades ago, we remember thinking this was complicated. We made an effort to learn about it as much as we could. And even though we have spoken at security conferences, we are still entirely amateur at Security. It’s so complicated.

You need to sit down with security people and talk to them to understand what they’re trying to do. I find tremendous value in understanding the control behind the process because the process is just trying to put control in force. So that’s the goal. Security people will tell you that the reason why this process exists is for this control, e.g., application security. Security doesn’t want the source code tampered with. You need to partner with them to find the best way. But if you fight the process, it’s going to fail.

Having a shared vocabulary and a common language is critical. We have succeeded with stride security and threat modeling to help bridge that common language/vocabulary. Threat modeling/stride model, as a technique, has been superb for good application design and conversing with security partners/teams on the threats we have identified and what we’re doing to mitigate them. And there are controls we need to meet in an automated fashion. We must bake them into our CI/CD pipelines and the building block constructs we use to deliver the services. Ideally, we then get these reviewed/approved by the security team upstream. So that whenever a developer comes along and composes the following application, they’re building it from security-approved building blocks that allow them to go fast but go fast securely.

Threat Modelling and opening up the conversation

Threat models are brilliant, and techniques that make Security easier are worth discussing.  We remember the first project we brought into threat modeling. We spoke to a Security guy called Bill Pellet, a good friend. And his reaction was: ‘No, you’re not doing this!’. So we went off, discovered threat modeling and worked out how to do it, and then came back to him with threat modeling. And I was expecting another challenging time, but his response was: ‘This is amazing. I love what you’ve done, but you’ve missed something…. We felt brilliant.  I couldn’t believe how warm his reception was. And I’ve experienced that ever since. When you come to the Security Team and say: ‘This is what I think you want to do. And this is how we should do it.’. You’re opening up the conversation. 

Microsoft Stride Security Threat Model

I remember that. It was a long time ago, maybe 15 years? It’s the Microsoft threat model using the STRIDE model, so it’s very application-centric. A manager, engineer, and product owner can be in one room together, working through that process and following that STRIDE exercise. It’s a fun activity as well. But it’s an excellent way of designing security into your workload.  Ultimately, you can validate with a walkthrough with a cybersecurity architect or somebody who knows security, and the process is excellent.  We’re taking responsibility for the design and security of our system. And there’s never been a threat modeling exercise where we haven’t surfaced value or requirements that we’ve just got to address.

The risk of communication breakdowns

We would like to share a funny story about threat modeling. We started with threat modeling by talking to the security lead, who wanted to know if it worked. It was quite a high-profile project. We convinced the team to ‘try it and see what happens.’ I knew the engineering team because we sat beside them. So we said, ‘Let’s run a quick pilot.’ The security lead said: ‘We’ve been all over this, we spent months on this, and this thing is bulletproof!’. We said, ‘Let’s threat model and see what happens.’And I walked over to the engineers and asked about any security problems. And they said there’s a loophole where you can log into the application, but we will fix it later. It was something to do with a token the team had implemented incorrectly. But the team thought they were going to fix it later!

So we threat modeled and highlighted two or three issues. I realized there was a risky communication breakdown between the security requirement and implementation.It was an easy fix. But the engineers had thought that someone else would fix it. And security guys thought the team had all implemented it. There was a very minor misunderstanding, which we caught before anything went live. 

The Importance of a Security Stride Team Focus

That is a crucial point. These collaborative, facilitated team-based activities surface so much value. You get a diverse group of people in a room/zoom call, and there’s a great discovery of ideas and things that you have yet to think about, like threat modeling or the way we do well-architected reviews. It’s always team-focused; it’s always collaborative and facilitated. And CSPs can surface: ‘Oh, you haven’t thought about this? Let’s think about that.’.You always have a good tool set and sound design, but the thing that will catch you is a break in communication somewhere. And the best way to capture that is through a team event.

As an architect, it’s an excellent exercise for ensuring you understand how teams are going about certain things. So you’re constantly validating your thinking. When you are walking through the Microsoft threat model, you’re building DFDs (data flow diagrams) and constantly reaffirming what it is talking to here, what are we doing, what are we passing across? You can use it to weave in the organization’s information, e.g., data privacy policies and what type of data you are moving. A significant aspect of what application developers are doing is the movement of information and how we protect it. Even looking at post-production, people say they have static analysis in place. But you can still design insecure systems that static code analysis will pick up on. You’ve got to take that stuff quite seriously.

SCORP Methods

One last point on the threat modeling piece is when you get into the mitigations and how you verify your mitigations, it leads you down the path of creative testing. You are arming your engineers with ways to test the system through a different perspective, and you look at other techniques. How do you then meet those controls in an automated fashion? Here’s our test. Can we bake it into the pipeline? Can we run it every single time we make a change? It’s a constant evolution and security improvements that we can go to.

The other technique that we love is the well-architected review process. I’ve written about this and SCORP methods. We have found it valuable to ask teams to do a threat model before they go into their well-architected review.You spend 5 to 10 minutes reviewing your threat model before the well-architected review session gives context and value to the team. The well-architected review becomes very slick and fast because they’ve thought about the boundary conditions and how the data flows. And they can visualize it very clearly. That’s a tip/technique to do a threat model first, so when you do a well-architected review, it adds so much value.

Identify a Developer to be a Security Champion

Another great piece is identifying a developer to be a security champion. And it is about more than identifying the most senior developer. It’s just about placing a developer interested in security, stride security, and expending extra effort to inform this person. Hence, they learn all the controls and processes to help the team. So it’s a win-win for everyone.

One significant enabler is baking security guardrails into your environment as much as possible. There’s a delicate balancing act of not stopping things going ahead. In every ecosystem we’ve worked in, we’ve had guardrails that give you baseline security: encryption, address encryption of transit, and everything tagged. There’s a whole foundational layer. Now you can use things like AWS config or SCP to implement that. But those enabling constraints allow you to have a higher-order conversation about application security. It complements security design.

We were introducing a team to serverless, and one of the things we did was to introduce cfn-lint and cfn-nag. CFN is a very opinionated validator that will go through your CloudFormation and highlight things that the team could tighten up, which is an excellent way of being proactive by asking are going out with the most secure settings or if we should be looking at defaults or encryption? Is our resource policy a wild card? That can help find things that may be slipping through the cracks concerning the implementation. So there are tonnes of good tools out there. 

In summary, Serverless is more secure. Do threat modeling, do well-architected reviews, identify security champions, establish suitable guardrails and automate the hell out of everything! And talk to your security department. They are not evil; they don’t have horns!That’s the craic. There’s more on TheServerlessEdge.com. On Twitter, we’re @ServerlessEdge.