Why do we Threat Model?
The purpose of threat modeling is to identify potential threats and attack vectors of an application. The attack surface is all the attack vectors an attacker can access. The more vectors, the greater the attack surface. Once identified, development teams can prioritize and work on remediating those threats earlier in the development cycle.
When conducting a threat model, the goal is to define and map the entry points of the attack surface by identifying and assessing any potential vulnerabilities. The work is to diagram/map out how an attacker can enter an application and close that vector off. Diagraming gives you a visual understanding of what you are working on and allows you to see the interactions with all the components in your application.
An example to make this easier to understand is to think about building a house. We don’t move into the house until there are walls, windows, and doors on the building. To reduce our risk, we install locks and bolts on the entry points. In some cases, depending on other factors such as location to certain areas or value of the belongings, or family safety in general, we may further install cameras or security monitoring, in some cases even paid guards.
To help model the attack possibilities, you can use “Shostack’s Four Question Framework for Threat Modeling.”
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
When should I do a threat model?
There is also a lot of conversation about when is the right or best time to do a threat model. I think anytime is the best time if one hasn’t already been done. But having said that, if we think about our house, designing in our ideas at the beginning keeps cost vastly lowered as opposed to going back and saying that we really need a secret panic room which will require a teardown of one of the other existing rooms, rewiring for security and pulling plumbing for emergencies if it takes a while to be rescued! So clearly, earlier can reduce some of those costs. This can also reduce cost and potential impact on our developers, as well as maintain application integrity rather than bolting things on in the end.
While we want to do a threat model early on, we don’t want to limit our thinking to just planning. If anything changes – design or requirements, deployment environment, you will want to think about updating your existing threat model. Even for applications already in production, it isn’t too late to do a threat model.
Once we have identified threats, we will want to analyze and assess the risks as well as rank and prioritize them. There are different models to do this, such as STRIDE.
STRIDE
Spoofing Authentication
Tampering with data Integrity
Repudiation Non-repudiation
Information Disclosure Confidentiality
Denial of Service Availability
Elevation of privilege Authorization
The risks you identify are potentials. We can look at what is meant by risk from the likelihood that something might happen as well as what the impact and cost may be if it does happen. This is where you want to understand how the attack can happen and what the root cause of that threat is so you can determine the next steps.
Now what do I do about the findings?
Once potential risks are identified, and you look at what the potential impact, likelihood, and exploitability are, you must decide what to do next. You will also want to consider and evaluate the threats in terms of what the exposure is, or you may look at it from a business impact perspective. So now you have some options to decide from, such as deciding to accept the risk, remove vulnerable components, or add a control to mitigate the risk (a countermeasure).
Remember to document what the findings are, what the risk and priority are, and what you will do about them. You will also want to share and store that documentation where others can access it each time you do a new threat model. In addition, this could be an artifact to share with your penetration testers to provide more information for their planning and testing.
What threat modeling isn’t
It isn’t a code review or a penetration test, but it should be a part of your SSDLC or review process. Penetration testing and code reviews find bugs or vulnerabilities in your code. But a threat model, which is a security assessment, can help to uncover design flaws that you may not otherwise find.
Final thought
As stated in the Threat Modeling Manifesto, conducting a threat model adds value to stakeholders by improving the security and privacy of a system through early and frequent analysis. The key takeaway is wherever you are at now, whether that’s in the design phase or already in production if you haven’t done a threat model yet, start now and go from there.