For pre-seed companies, threat modeling is the most underestimated and underutilized security technique. With limited budgets at the pre-seed level, access to additional resources and commercial tools is likely unavailable. Threat modeling is the most economic activity to bake security into the SDLC early on in the process. Additionally, many design decisions are made at the pre-seed stage. Since these decisions can be difficult to change in later stages, it's important that they are considered for security through threat modeling. Understanding what threat modeling is early on will help companies build a secure application from the ground up.
Threat modeling is the ultimate shift left approach. It can be used to identify and eliminate potential vulnerabilities before a single line of code is ever written. Employing threat modeling methodologies should be your first step toward building networks, systems, and applications that will be secure by design.
“Threat modeling is a structured approach of identifying and prioritizing potential threats to a system, and determining the value that potential mitigations would have in reducing or neutralizing those threats.” - OWASP Cheat Sheets
Threat modeling helps you to visualize any risks in your prospective design, which will allow for brainstorming of possible mitigations before you’re actually required to implement them.
There are three steps of an effective Threat Modeling exercise:
An asset is anything of value that an attacker would be interested in including sensitive data, servers, files, users, etc. For example, simple modern architecture would include:
Enumerating your assets is part of defining them. To do so, you need to consider at least these four areas:
While there are many other areas to cover, these four areas are a good starting point. At this stage, you are just enumerating all possible assets without looking whether there is a realistic threat to these assets. Most often, development teams focus on the house front door (the obvious threat) and ignore the house backdoor (the easier threat).
Your attack surface is any input point in the application that can lead an attacker to your assets. For example, APIs that retrieve users data.
Let’s take a stab at enumerating your attack surface, which may include:
Again, at this point you are just enumerating all potential attack surfaces without any regards to whether it is realistic or not.
At this step, you can begin to enumerate all the possible attacks (or bad things) that could happen against the assets through the attack surface which were both identified in the previous step.
Let’s enumerate some attacks here. For example:
Now, the next step is to identify mitigations for each of the attack scenarios. Some are going to be easier than others. In this step, sometimes you will have multiple controls. So for example, to mitigate SQL injection attacks, you can use an ORM (assuming you are in a place to change your technology stack) or you can use a prepared statement. In this case, try to choose controls that can tackle multiple attacks at the same time. Also, try to choose controls that are more automatic and do not suffer the human-error effect. So an ORM would automatically mitigate SQL injections and does not allow for a human-error as much as forcing prepared statements, where it is easier to forget.
Threat modeling is one of the most underappreciated techniques in your security toolbox. Additionally, it is the ultimate shift left approach as you can integrate it in the SDLC before writing the first line of code. The process described above is a very simplified process to illustrate the concept. There are some industry approved methodologies such as DREAD, STRIDE, PASTA, VAST, Trike, OCTAVE, and NIST if you wish to go deeper into the topic.