Recently on a Mobilise webinar for Building DevSecOps into your Pipelines I got asked the question ‘Can you still do threat modelling? (When using DevSecOps principals)’. Which was an interesting question where I could only give the quick answer. The answer was yes, but via the medium of blogging we can expand that further.
So here is a fuller explanation of how and why you can either add Threat modelling into your pipelines. Or move your current threat model into your new DevSecOps journey.
Threat what now?
Let’s start with a breakdown of what threat modelling is and how you normally use it. Threat modelling is a process where you identify where potential threats can come from. But also, crucially, how they could be accomplished against your system. From there you can provide developers and other teams with analysis of what defences you need to put in place and where. Now you can address these issues early on in the development lifecycle instead of coming across them much later on in development.
To start off, ask yourself three key questions:
- What are the most current relevant threats? (OWASP top ten can help you there)
- Where is the system/app most vulnerable to attack?
- What do I need to do to prevent these attacks and safeguard my system?
From here you would be in a good position to start threat modelling. However, before you jump feet first into writing them, it is worth nothing that there are several methodologies out there you can follow to help you. It’s best to have a look at them and choose one that fits with your overall strategy. The two I have used before are STRIDE, created by Microsoft and PASTA (not the Italian food) which is a risk-centric methodology. Both have there pro’s and con’s which I won’t address here, as I previously stated, you have to find and use the methodology that fits your companies/projects goals. Not what everyone else is using.
How does it fit into those CI/CD pipelines?
It does and does not. Threat modelling is not truly part of the automated pipeline process. It’s the step that happens before the CI/CD comes together. It begins towards the start, in the design and plan stage. Which is all part of the Secure development practises.
Once you have completed a set of threat models you then would develop your app or system to defend against these threats you have identified. Further to that you can design and then build security tests for your DAST tools. With those tests in place if you have a DAST tool capable of automated testing (recommend Gauntlt for that) then your CI/CD pipeline will run the tests and pass or fail the build.
While Threat modelling isn’t automated it can help you in adding those automated steps into your pipeline. Eventually you and the developers will get used doing the threat modelling process and you will find that writing each one up won’t take more than 30 – 45 minutes. Also have the added benefit of having this process in place that each time you add a new feature then you will threat model it and hopefully not miss potential vulnerabilities.
Open Source Threat Modelling is a thing.
You now know what Threat Modelling is and how to use it. It’s time to make your own, but how would you create a document to contain this information? Well, in comes OWASP and Mozilla to the rescue. Both of these host and support open-source free-licensed Threat Model templates to be used in an agile DevSecOps world.
OWASP offer two great resources to help:
Both are worth a read. I normally talk about OWASP projects (we often use OWASP ZAP as part of our DAST tooling in our pipelines.) but for a change I’m going to go over another open-source foundation offering.
Rapid Risk Assessment is great for when the system is still in current development. Even if you are fully DevOps enabled doing multiple releases a week. This would still work for you.
The idea of this is to do quick analysis repeatedly and doing this over and over again will fully bring out a threat model over time. Even better, it is easy to update and can be done at any point and continuously updated (just like that CI/CD pipeline). Mozilla have provided the steps you need to start using RRA and do it continuously, they have also provided a template to get you started, it may be fully Mozilla branded but it is okay to change it to your own internal marking and protective markings.
Hopefully you now have a good enough understanding to start exploring adding Threat modelling to your DevSecOps journey.