Threat modeling is typically attack-centric; threat modeling most often is used to identify vulnerabilities that can be exploited by an attacker in software applications.
Threat modeling is most effective when performed at the design phase of an information system or application. When threats and their mitigation are identified at the design phase, much effort is saved through the avoidance of design changes and fixes in an existing system.
While there are different approaches to threat modeling, the typical steps are
- Identifying threats
- Determining and diagramming potential attacks
- Performing reduction analysis
- Remediation of threats
Identifying threats
Threat identification is the first step that is performed in threat modeling. Threats are those actions that an attacker may be able to successfully perform if there are corresponding vulnerabilities present in the application or system.For software applications, there are two mnemonics used as a memory aid during threat modeling. They are
- STRIDE, a list of basic threats (developed by Microsoft):
- Spoofing of user identity
- Tampering
- Repudiation
- Information disclosure
- Denial of service
- Elevation of privilege
- DREAD, an older technique used for assessing threats:
- Damage
- Reproducibility
- Exploitability
- Affected users
- Discoverability
Appendices D and E in NIST SP800-30, Guide for Conducting Risk Assessments, are a good general-purpose source for threats.
Determining and diagramming potential attacks
After threats have been identified, threat modeling continues through the creation of diagrams that illustrate attacks on an application or system. An attack tree can be developed. It outlines the steps required to attack a system. The following figure illustrates an attack tree of a mobile banking application.
An attack tree illustrates the steps used to attack a target system.
Performing reduction analysis
When performing a threat analysis on a complex application or a system, it is likely that there will be many similar elements that represent duplications of technology. Reduction analysis is an optional step in threat modeling to avoid duplication of effort. It doesn’t make sense to spend a lot of time analyzing different components in an environment if they are all using the same technology and configuration.Here are typical examples:
- An application contains several form fields (which are derived from the same source code) that request bank account number. Because all of the field input modules use the same code, detailed analysis only needs to be done once.
- An application sends several different types of messages over the same TLS connection. Because the same certificate and connection are being used, detailed analysis of the TLS connection only needs to be done once.
Technologies and processes to remediate threats
Just as in routine risk analysis, the next step in threat analysis is the enumeration of potential measures to mitigate the identified threat. Because the nature of threats varies widely, remediation may consist of one or more of the following for each risk:- Change source code (for example, add functions to closely examine input fields and filter out injection attacks).
- Change configuration (for example, switch to a more secure encryption algorithm, or expire passwords more frequently).
- Change business process (for example, add or change steps in a process or procedure to record or examine key data).
- Change personnel (for example, provide training, move responsibility for a task to another person)
Recall that the four options for risk treatment are mitigation, transfer, avoidance, and acceptance. In the case of threat modeling, some threats may be accepted as-is.