14 DAY TRIAL // There are but five general steps to the threat modeling process applied to software development inhouse at Microsoft. Adam Shostack, a Program Manager in Microsoft's Security Engineering group, revealed that the threat modeling process has been streamlined in order to tailorfit even the most basic software development scenarios. But one thing that Shostack emphasized is the fact that threat modeling is a closed, circular process, and that any changes introduced to the software design following an initial finalization of the model, would impact its entire architecture.
Vision is the first step of threat modeling. "Consider your security requirements, scenarios and use cases to help frame your threat modeling. What are the security aspects of your scenarios? What do your personas expect or hope doesn't happen? What are the security goals of the system you're building, and how do those interact with the system as it stands?" Shostack explained.
Next, the developer has to build the model itself, by focusing on all the trust boundaries of the software. For this, essential elements such as external factors, processes, data stores and data flows, have to be enumerated with a focus on the way they interact with each other. The sensitive areas are intimately connected with scenarios in which more than one principal can access the same process or file. This is nothing else but the example of a trust boundary.
Shostack points to the STRIDE threat modeling system, explained here. And in this regard, STRIDE is more of a way of getting the general picture over the relation between past threats and software design elements than a classification system. And while threat identification is the third step, the next logical stage is mitigation.
And you have to understand that threats are not security vulnerabilities. While a vendor will be able to resolve a security flaw by issuing a patch, threats can only be mitigated. And there are four ways to mitigate a threat: "a. Redesign to eliminate threats. b. Use standard mitigations, such as those provided by OS features, to mitigate threats. c. Invent new mitigations, understanding that this is a subtle art. d. Accept risk, when allowed by the SDL", Shostack added.
On top of the phases exemplified above, there is also validation of the threat model. Validation has to happen at each stage of the model, but also at the end of the process. In addition, it is necessary for the re-validation to occur after all changes introduced to the threat model.