The threat model is an effective way to turn hidden security threats and mechanisms into obvious threats and mechanisms, so that security personnel can write security requirements and architecture and test security tools. At the beginning, I want to use STRIDE's revised version, which can clearly map threats to the mechanism for processing. In this way, when starting a new project (such as SOA Web Services), we can determine which criteria can help the project.
Threat models are often misunderstood. They are not about constructing threats. As a defensive programmer, we have almost no control over threats. Our job is to go beyond the vulnerabilities and fix them. A vulnerability is basically a passive system defect, and a threat is a variety of operations that take advantage of the vulnerability, so we can identify the threat; 2) handle the threat. The final result of Threat modeling is not a list of threats, but a list of solutions. In addition to a general list, positive threats can also help us identify countermeasures in the architecture.
In addition, if we compare the methods in the early stages of building a Software Architecture/design, the threat model is actually a structured method of comparison/comparison. For example, if we are building a set of Web services and choosing between the SOA style (WS-*) and the rest style, we may look at the current standards supported by each software security stack.
Threat modeling helps us describe very abstract objects (such as software security functions in Analysis Services) in a concrete structure, but as you can see, Threat modeling is not about threats, it is about security architecture elements. This is just an example. It is not a complete threat model, but it can provide an effective way to find problems in the security architecture.