Stride Threat Model and other security threat modelling tools and techniques have fired the discussion this week: 'Threat modelling, as a technique has been awesome, 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'.
Security
Dave Anderson
When I first came across Security and Risk Management, several decades ago, I remember thinking this is so complicated. I made an effort to learn about it as much as I could. And as someone who’s spoken at security conferences, I still am a complete amateur at Security. It’s so complicated. I think you need to sit down with security people and talk to them to understand what they’re trying to do. I find huge value (when you’re hit with a process that’s difficult), in understanding what’s the control behind the process, because the process is just trying to put a control in force. And they understand what the control is.
So that’s the goal. Security people will tell you that the reason why this process exists is for this control eg. application security. And you ask what it means? Security doesn’t want the source code tampered with. Then you can partner with them to find the best way of doing that. But if you fight the process, it’s not going to work.
Mark McCann
Having a shared vocabulary and a common language is critical. We have had great success with stride security and threat modelling to help bridge that common language/vocabulary. Threat modelling/stride model, as a technique, has been awesome, 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.
And as you mentioned, there are these controls we want to meet in an automated fashion. We want to bake it into our CI/CD pipelines and our building block constructs that we used 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 next application, they’re building it from security approved building blocks that allow them to go fast, but go fast securely.
Threat Modelling
Dave Anderson
Threat models are brilliant and it’s worth talking about techniques that make Security easier. Mike, do you remember the first project you and I brought into threat modelling? We spoke to a Security guy called Bill Pellet who is a good friend of mine. And his reaction was: ‘No, you’re not doing this!’. So we went off, discovered threat modelling and worked out how to do it, and then come back to him with threat modelling. And I was expecting another tough 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 I think we should do it.’. You’re opening up the conversation.
Microsoft Stride Security Threat Model
Mike O’Reilly
I remember that. It was a long time ago, maybe 15 years? It’s the Microsoft threat model using 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 actually quite a fun activity as well. But it’s a really good way of designing security into your workload. At the end you can validate with a walkthrough with a cybersecurity architect or somebody who knows security and the process is actually really good. We’re taking responsibility for design and security into our system. And there’s never been a threat modelling exercise where we haven’t surfaced value or requirements that we’ve just got to address.
It’s a phenomenal approach to be proactive about security. Mark, you’ve mentioned other support like the OWASP Top 10 for Serverless. From a reactive side there’s tons of tools that we can look at.
Photo by Yiran Ding on Unsplash.com
Dave Anderson
I’ve a funny story about threat modelling. I was trying to convince a team to do threat modelling. I was talking to the security lead and he wasn’t sure if it worked or not. And it was quite a high profile project. I said ‘let’s just try it and see what happens.’. I knew the engineering team because they sat beside where I was sitting. So I said, ‘well, 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!’. I said ‘let’s threat model and see what happens’.
And I walked over to the engineers, and I asked if there were any security problems? And they said, there’s a loophole where you can log into the application, but it’s going to be fixed later. It was something to do with a token that had been implemented incorrectly. But the team thought it was going to be fixed later! So we threat modelled, and highlighted two or three issues. I realised there was a break in communication between the security requirement and implementation.
It was an easy fix. But the engineers had thought that someone else will fix it. And security guys thought this has all been implemented. There was a very minor misunderstanding, which was caught before anything went live.
The importance of a Security Stride Team Focus
Mark McCann
That is a key 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 haven’t thought about, like threat modelling or the way we do well architected reviews. It’s always team focused, it’s always collaborative and facilitated. And CSPs are able to surface: ‘Oh, you haven’t thought about this? Let’s think about that.’.
Dave Anderson
You always have a good tool set and good design, but the thing that will catch you out is probably a break in communication somewhere. And the best way to catch that is through a team event.
Mike O’Reilly
As an architect, I think it’s a really good exercise for making sure you understand how teams are going about certain things as well. So you’re constantly validating your thinking. When you are walking through the Microsoft threat model, you’re building DFDs (data flow diagrams), and you’re 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 eg. data privacy policies and what type of data you are moving, which is a big aspect of what application developers are doing – the movement of information and how we are protecting 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.
One last point on the threat modelling piece is when you get into the mitigations, and how you verify your mitigations, it leads you down the path for creative testing. You are arming your engineers with ways to test the system through a different perspective and you look at different techniques. Mark, you love talking about chaos engineering.
Mark McCann
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 constant evolution and the constant 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 processes. We have found it valuable to ask teams to do a threat model before they go into their well architected review.
By spending 5 to 10 minutes going over your threat model before the well architected review session gives context and value to the team. You find that the well architected review becomes very slick and fast, because they’ve thought about the boundary conditions and what way the data flows. And they can visualise 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.
Security Champion
Dave Anderson
Another great piece is identifying a developer to be a security champion. And it isn’t about always identifying the most senior developer. It’s just about identifying a developer who’s interested in security, stride security and expending extra effort to inform this person, so they learn all the controls and process etc., so they can then help out the team. So it’s a win win for everyone.
Mark McCann
One big enabler is baking in security guardrails into your environment as much as possible. There’s a fine balancing act of not stopping things going ahead. In every ecosystem we’ve worked in, we’ve had guardrails in place that give you baseline security: encryption, address encryption of transit and everything was tagged. There’s a whole foundational layer. Now you can use things like AWS config, or SCP to put that in place. But having those enabling constraints in place, allows you to have a higher order conversation about application security.
Mike O’Reilly
That’s a really good point. I think 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 could be tightened up, which is a really good way of being proactive by asking are we going out with the most secure settings or should we be looking at defaults or encryption? Is our resource policy a wild card? That can really help find things that may be slipping through the cracks in relation to the implementation. So there’s tonnes of good tools out there.
Mark McCann
In summary, Serverless is more secure. Do threat modelling, do well architected reviews, identify security champions, establish good guardrails and automate the hell out of everything!
Dave Anderson
And talk to your security department. They are not evil, they don’t have horns!
Mark McCann
Absolutely.
Dave Anderson
Alright folks. That’s the craic. There’s more on TheServerlessEdge.com). On Twitter, we’re @ServerlessEdge. So thanks very much!!
Transcribed by https://otter.ai
Top comments (0)