ARCHIVE FILE
Threat modelling for developers
Threat modelling for developers
Sven Anders Robbestad
20 December 2019
Threat modelling for developers
What is threat modelling?
A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses. [...] It enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.
— Wikipedia (Dec 2019)
In short, threat modelling is a process for capturing, organizing, and analyzing the vulnerability of an application.
A threat is an undesirable, potential malicious event, or an incidental event. Malicious events can for instance be coordinated denial attacks (DDOS) or crypto hijacking. Incidental events can be things such as storage failures.
Who should threat model?
Developers!
Security audits don't cut it. Developers need to be able to apply threat models and create secure software on their own.
Before the hacks. Before the eventual audit.
But you can't expect developers to do classic threat modelling. Here's how that works.
"Old school" threat modelling
The classic way to do threat modelling is go through a process where you perform an analysis by applying a specific methodology, which ends up in a report with a list of prioritized risks.
It's a four step process (with a zeroth step) where you:
- Decide the scope the model
- Decompose the application, visualize data flows and attack surfaces
- Decompose the application and create trust boundaries
- Determine counter measures
- Implement fixes, and then go back to step 1 to see if we fixed the threats, and see if we have introduced new ones
There are a number of different methodologies, such as the STRIDE model ("the Microsoft model"), attack tree, asset-focused, software-centric, attacker-focused, risk-based (P.A.S.T.A) and so on.
The risk based PASTA (Process for Attack Simulation and Threat Analysis) model is interesting, because it takes the four steps describe above and breaks it down into a comprehensive seven step process that gives you a really good, formal analysis of your applications vulnerabilities.
This is the pinnacle of high assurance security analysis. It's a fantastic methodology for a dedicated security team.
But it's less than great for the developer. In fact, it's pretty terrible. No developer on earth would ever want go through this extremely laborious methodology every time they write a piece of code.
All this methods have a few things in common. They take too much time. We develop functionality, not security. Oh, and often the functionality has changed between the time the work on the threat model started and by the time it was completed, because these comprehensive security reviews can take weeks, if not months, to wrap up.
And when you get the report back, ... then what? I'd like to see the team that just throw away their backlog to work on vulnerabilities for a while. I'm sure it happens, but I'd wager it's a rare occurrence.
"Think like an attacker"
In the mean time, you're often told to "think like an attacker", when developing software. Great, but how do you do that? Security professionals will often come up with platitudes like that, or "Security is everyone's responsibilities".
But "think like an attacker"? How do you do that? If everyone knew, all software would be forever safe. And when you go to the kitchen in the evening to make yourself dinner, all you have to do is "think like a chef", and you'll be able to make a five star meal like the best of them.
The new threat methodology for developers
Threat models use complicated words and concepts, such as repudiation, trust and application boundaries, data flow diagramming and expect us to derive attack tree for threats and targets-assets in scope.
But basically, here's what you should think about when you develop software:
- Why am I building this?
- How should it work?
- How do I make sure nothing goes wrong?
First of all, you should always know the end result of what you're building. It's easy to start on something without having an end result in sight, but it helps immensely to know what you're building before you're building it.
Second, when you know how it should work, making it is easier. It sounds like a platitude, but try making something without knowing the end results of how the user should operate it. Just stop and imagine it for a few seconds.
Third, and this is an important step, how do you stop the thing you're building from crashing, or letting the user do something "impossible"?
You don't need to know everything. But imagine you're building an API to fetch, update and delete users from database. Here's how you apply the steps:
- Why are you building this? Who's going to access it? Who is allowed to do what, and should there be some restrictions?
- Know all the actions that should be allowed
- Make sure any disallowed actions can't be performed.
Finally, try to make a habit of getting the team together to discuss these issues in light of what you're building. A good discussion is probably more useful than a detailed security report made by an external party.
If you're a business developer, you can use the same methodology, except you'll obviously have different answers. For instance, to "why are you building this?", you might answer that the feature adds users, increase revenue, or that it provides more insight to eventually increase your revenue. Also, these questions may also lead you to narrow down the feature so that you'll get the answers you want, and not a huge trove of data that you can't analyze. And finally, you want to make sure this data can't be abused, and that you don't run afoul of data privacy laws.
The begs the question, "am I responsible for this"? And, "where does threat modelling belong"?
The answer is, put the threat modelling, the 3 questions and the discussion, as part of the story for each feature you're developing (depending on which development model you're using, it could be part of the sprint planning, part of the agile process and so on).
Resources
OWASP Threat Modeling Resource
For further information about threat modeling, and a summary of generic steps:
https://www.owasp.org/index.php/Category:Threat_Modeling
Value Driven Threat Modeling by Avi Douglen (AppSecUSA 2018)
Summary: Offering software developers a different way to threat model
https://www.youtube.com/watch?v=3Fl_7FrM_gI
OWASP Juice Shop
https://www2.owasp.org/www-project-juice-shop/#div-screenshots