I began writing this post hoping it will help you see all those shades of threats and risks to your code.
What is Threat Modeling:
If you want to build good software (and hopefully, you re aiming to build great software), you must invest time to build in security considerations in the software architecture. Threat modeling is here to help. What is it exactly?
Threat model is an expression used by security experts for security analysis and resolving threats (risks) that emerged in the process.
Why learn to Threat Model:
It is hard to find software that is not open to the world wide web these days. This gives way to hackers to “hack in”, to your system which may lead to loss of important data (payments, passwords, etc.), consequently causing loss of reputation.
This is not to say that apps not open to outside don t need security review too. They most definitely do. If you re in security, you should always go by the words “trust no one” and “defense in depth”. Lots of things can happen, even when we talk about software that s not open to outside; your coworker can turn to the “dark side” and try to steal information, or accidentally break things down. Even worse, they may have good intentions but they “spin up core way over its limits” in a nuclear plant while they are cleaning the dashboard in the control room.
How to Threat Model:
At first, when we think about the threat model, it looks easy. You learn the usual threats that occur and check if they apply to your software. Easy! But an ad hoc approach is not a way to go in this case and there s much more to threat modeling.
There are lots of questions to answer early on: Where do I start? Are all threats iterated through? Am I really done, even though I ve finished everything? One must have some degree of certainty that the job is done well.
The right way includes finding a methodology, a proven process to discover threats and to handle them right.
The good news is that security experts have already done this for us, we just need to use their knowledge and experience and apply it. You will not be as good as them in threat modeling, sure, but you do get a good start, and practice will make you better.
There s a lot of practices and methodologies we can use to threat model, but in this blog, our focus is to show, in short, how one simple threat model looks.
We will pick some methodologies, without going into much details about others. At the end of the blog, you will find references to continue investigating the topic and other methodologies.
Time to Practice:
Our threat model will be done on a sample login data flow.
Scenario: Users use the browser to open a login web page, the web page contacts our web server for authentication.
We will use 4 steps shown in figure below:
1) Try to model your current system, put it on a diagram. When changed – update.
2) There are several models we can use to find threats, in this sample we will use STRIDE (explanation below)
3) Handle the threats
4) Validate (if the model is changed repeat steps)
Diagram your system :
When finished with drawing a model of software (or part of it), we want to analyze and draw trust boundaries. Trust boundaries are simple lines on our diagram that show who has control over a specific part of the software. Usually, trust boundaries are points where you can expect threats.
STRIDE your software
STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
STRIDE is one of many methodologies used to threat model your system, and we will use it in this example. In the real world, you will have a list of spoofing (or others) threats where you need to iterate through and check if any threat applies to your system. In our example, we ll only mention some of the possible threats, but not all.
Spoofing (pretending that you are someone you are not)
- Someone can get in the middle between Visitor and Web server and send fake login page to the visitor
- Someone can log in with a stolen username and password
- Someone can resend sniffed data back to the server
Tampering (modifying something you are not supposed to modify)
- Logged in user can change someone else s users data
- Logged user can delete all data in the database
- Users can send fake data to the web server.
Repudiation (rejecting responsibility)
- User claims they haven t received an email
- User claims they didn t click the button
- User claims they didn t order something
- Database query failing down (how to know if there are no logs)
Information Disclosure
- Error message: You failed to login to the database MyDatabase with username xxx. (Now the attacker knows database name)
- You can t log in from an external IP address (design leak – now the user knows that it needs an inner IP address).
- File names – (ex Employee salaries )
Denial of service (consume all resources)
- Send 10.000 request every second (can our system handle this situation)
- Send 1GB big video
Elevation of Privilege (users are able to do things that they are not supposed to do)
- SQL injection
- Users should be able to access Business Logic only through a web page but they can access endpoints directly.
- Database admin can modify web server config, or web server user can alter database configuration
Handle the threats
We can do four types of actions on each threat:
- Mitigate threats (make it harder to exploit by using passwords and 2FA)
- Eliminating threats (but this can eliminate features, too)
- Transfering threats (save files on AWS instead of on your server)
- Accepting the risk (some risks are OK to accept, for example, if NASA attacks our web site)
Now we will define respond to each threat :
Spoofing
- Use SSL and single domain for all pages (mitigate)
- Enable 2-factor authorization (mitigate)
- Implement some protection mechanism (mitigate)
Tampering
- Implement authorization (mitigate, but if we decided to use third party solution, then we will be transferring threat )
- Set database permissions (mitigate)
- Validate input (mitigate)
Repudiation
- Save all actions in LOGs (mitigate)
Information Disclosure
- Use best practices in naming and watch on API design (mitigate)
- Implement ACL (access control lists) (mitigate)
Denial of service
- Implement auto scaling (if we would be using AWS then it would be transferred threat)
- Reserve resources for higher demand (mitigate)
- Limit user usage (only videos to 10 MB can be sent – threat eliminated, but our software lost great feature )
Elevation of Privilege
- Use prepared statements and SQL procedures (mitigate)
- Expose only HTTP port on the web server (mitigate)
- Separate web server and database in different servers/trust boundaries (mitigate)
Validate
Update your diagram:
While validating the diagram we found out that our business logic is using a proprietary pdf library to generate pdf documents. After we ve updated the diagram, we need to check:
- Does everyone on the team agree that the diagram represents our data flow
- Is every actor presented in the diagram
- Can we explain everything without using words like sometimes and also (if no then we need to expand our diagram and put more details in it)
- Is every threat resolved
- Did we watch at every element and every data flow in the diagram while searching for threats
In this example, the diagram is changed so we need to check it again.
Spoofing
- Can a logged-in user query database directly somehow (if yes, implement mitigation)
- Can pdf library present itself as a logged-in user and send requests to the business library (do security check on pdf library or review code on pdf library, if available)
Tampering
- What if pdf lib modify given data and show you false information (replace pdf lib with better one)
- Can a user create a non-specified request that will pass through our validation (example: instead 3 days of vacation it will send -3 days of vacation, this will increase their available vacation days from 6 to 9. Solution: implement better validation, DON T try to sanitize input, if not good REJECT it)
Repudiation
- If pdf library send a request to business logic will it be logged in (if not, implement logging)
Information Disclosure
- Can proprietary pdf lib secretly send our data out of our system or to other users (if possible then maybe sandbox lib)
Denial of service
- What if 100 users generate 10MB pdf report at the same time (if needed add RAM to the server)
Elevation of Privilege
- What if pdf lib can be exploited (example: user sends some code as a parameter to pdf that will trigger that code. Solution: validate input, sandbox pdf library)
Summary
To start a threat model, first try modeling your system in a diagram. If it is too complex, it s ok to break them up in more diagrams. You can use any type of diagram, although most people use data flow diagrams. If you don’t know where to start, then go from users, actors in the system and expand, or go with the data flow (watch how data moves through your system).
When getting the first diagram that represents a system, draw trust boundaries. Usually, intersections of trust boundaries are places where threats will appear. Pick one of threat modeling methodologies and iterate through threats with your parts of the diagram. Afterward, go through each threat and try to handle them.
Some threats will appear as impossible or ridiculous, but there s no need to worry. Write them down, and you can always accept that risk, transfer it, or remove it altogether later on.
The threat model is done when you have all threats on paper, and when those threats are obtained from a diagram everybody in your team agrees represents your system/software.