Creating a threat model can take several weeks. The way in which the team conducting the threat model looks for flaws may require adjustment based on the SDLC methodology in use within your firm. No matter what methodology you utilize, you can't neglect identifying and resolving design flaws.
In order to identify and resolve those flaws, you must understand that there are five primary activities that make up a threat model:
- Defining the scope and depth of the analysis.
- Gaining an understanding of what you're threat modeling.
- Modeling the attack possibilities.
- Interpreting the threat model.
- Creating a traceability matrix to record missing or weak controls.
RELATED: The 5 pillars of a successful threat model
In an ideal scenario, threat modeling should take place as soon as the architecture is in place. However, not all scenarios are ideal. No matter when you end up performing the threat model, understand that the cost of resolving issues generally increases further along in the SDLC.
The earlier you're able to identify potential attacks and squash those vulnerabilities, the more time and cost efficient those resolutions will be. Remember, it's better to build security in than it is to bolt security on. But, again, not all scenarios are ideal and not all applications undergo a threat modeling assessment during their development. Don't worry, not all hope is lost.
While threat modeling should take place as early as possible, it's still a very useful activity no matter how close an application is to deployment or has been in production. While an app may have reached the end of its development cycle, you can still pick up threat modeling within the support cycle.
Threat modeling offers perspective into potential flaws in the system. A thorough assessment informs your organization about the current design-level security stance of an application. Therefore, through threat modeling, you're able to make an informed decision about investing further in that system.