Threat modeling is an exercise in understanding the threats facing your systems and applications. By using a structured approach you will gain a clear blueprint of these threats, and be able to reasonably assess them. The threat modeling process allows you to more logically build security into your systems and applications, instead of trying to implement security without clearly knowing the threats you’re trying to address.
The end result of a threat modeling exercise should be a living document for members of the project team. This document should provide clear understanding around the architecture of a system/application, and the threats facing it. The Threat Model can be useful in several ways:
1. so executives can judge business threats, which ones are higher priority, and what resources would be required to mitigate the threat
2. so designers can make intelligent design choices about functionality
3. so developers can write code to mitigate the threats
4. so testers can validate if the threat is real, theoretical but likely, or theoretical but unlikely
The Methodology
Three core steps comprise the threat modeling process: 1) Collect all relevant background information; 2) model the system/application; 3) identify threats and known mitigations. Each step has logical sub-steps, and the process is not usually linear. For example, it’s common for changes to be made to the model of a system as threats are identified and the system is better understood. The value of this process is largely in the information and analysis. Threat modeling does not have to be a one-time exercise, and should in fact be regularly revisited as the systems and applications evolve.
Threat Modeling Outline
The following outline illustrates the basic parts of the threat modeling process. These parts do not necessarily need to be addressed in order.
Collect Background Information
Prerequisites: Specification documents including PM, dev, and test. Specification documents should be as clear and up to date as possible.
Figure out what the system or application was designed to do. Document the different use scenarios.
Technologies should be inventoried per system or application, and can include things like the host operating system version, database or web server versions, as well as application technologies such as Java, .NET, COM/ActiveX, Web Services, ADO.NET, etc.
Developer assumptions, administrator assumptions, business assumptions should all be identified. These will give more understanding into reasoning behind the systems design, and open up discussions for weaknesses that will lead to threats.
Model the System/Application
Prerequisites: Data-flow diagrams - 1) architectural overviews and 2) details of specific components. DFD's should depict several key concepts including, Data flow, Data stores, Processes, Multi-process, Interactors, and Trust boundaries.
Identify all exposed interfaces to the system or application. These could be remotely accessible TCP services such as mail or web, or local services such as a process or object. Think through all points of entry into the application, including administrative interfaces, anonymous, and authenticated.
Assets include definite protected resources such as data and processing resources, or more abstract ideas such as integrity of log files.
Define how external entities are characterized in the system, which typically maps back to roles based on credentials. Examples of such roles include Administrator, Regular User, Editor, Anonymous etc. Roles could be as generic as "authenticated and unauthenticated."
Data-flow diagrams or process models illustrate actions a system performs at a given entry point, and the steps taken thereafter.
At what point does data, credential handoffs, and processing switch to privileged execution paths. Boundaries exist between these paths where processes might execute in the low-privileged context of the user (e.g. impersonation) versus executing in a highly privileged context of the system or administrative-level user.
Threats
Threats should focus around the core business. Threats to the application don't mean much if they don't hurt the business model.
Using each entry point and protected resource, determine the threats to the application and business objectives or rules. Drill down into how an adversary, attacker, or worm would realize those threats through specific attacks. The attacks will become the basis of a security test plan.
Think-through and model the threat to determine if it is mitigated. Is a sufficient form of authentication in place to mitigate brute-force attacks? Are compiler options such as /GS, /NXCOMPAT, /DYNAMICBASE and safe exception handling in place to mitigate buffer overruns?
