Comparison of Threat Modeling Methodologies
Microsoft Threat Modeling Methodology:
Microsoft’s Threat Modeling practice aligns with their Trustworthy Computing directive of January 2002. Microsoft took initiatives to ensure that secure software begun with secure design. In order for an application to meet the security properties of CIA along with Authorization, Authentication and Non-Repudiation, the STRIDE, an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege threat classification system at Microsoft is used.
Data Flow Diagrams (DFD) are used to graphically represent the system. DFDs use a standard set of symbols consisting of four elements: data flows, data stores, processes, and interactors, and for threat modeling one more—trust boundaries. An application is decomposed into individual components and the relevant threats from the STRIDE system can be applied to each component and thereafter mitigations for each can be sought out.
From a methodology point of view, this might not seem to scale with a software development process such as AGILE. The exercise based on Trustworthy Computing also applies specifically to Microsoft Windows specific development. Practitioners of the process require being subject matter experts in security in order to fully understand the threats, classification of threats and relevance of security properties to elements of the threat model.
P.A.S.T.A (Process for Attack Simulation and Threat Analysis):
This is a new application threat modeling methodology by Marco Morana and Tony UV. This is a seven step process that is applicable to most application development methodologies and is platform agnostic. It not only aligns business objectives with technical requirements but also takes into account compliance requirements, business impact analysis and a dynamic approach to threat management, enumeration and scoring.
The process begins with a clear definition of business objectives, security and compliance requirements and business impact analysis. Similar to the Microsoft process, the application is decomposed into components with Use Case diagrams and DFDs used to illustrate the threat model with which threat and vulnerability analysis can be performed. The next step involves use of threat trees, abuse cases, scoring systems and enumerations for further reference in analysis. Following this, viewing the threat model from an attacker perspective by Attack Modeling in attack trees and attack surface analysis. In the final step, risk and business impact can be qualified and quantified with necessary countermeasures identified.
This process combines the best of various threat modeling approaches with the attack trees serving an attacker centric means of viewing a threat as well as in combination with risk and impact analysis helps in an asset centric means of planning a mitigation strategy. The Threat Trees with mapping of threats to existing vulnerabilities works in favor of easy and scalable threat management.
Beyond the technical aspect, the risk and business impact analysis take threat modeling from beyond just a software development exercise but involves participation of key decision makers in the vulnerability management process. What differentiates this methodology from Trike is that it focuses on involving risk management steps in the final stage of the process. This ensures that it is not limited to a specific risk estimation formula.
Trike is a methodology to build threat models for security auditing from a risk management perspective. The creators of Trike also have a tool to accompany this methodology. The methodology begins with a requirements model that ensures acceptable risk to each asset by the system’s stakeholders. This is then followed by an implementation model which makes use of DFDs to illustrate data flow as well as takes into consideration the performable actions within a live environment and system state. Finally this implementation model is analyzed to result in a threat model. Once these threats are enumerated, appropriate risk values are assigned to them and attack graphs are created. Mitigations are assigned to the vulnerabilities that lead to these threats. Finally a Risk Model is created based on assets, roles, actions and threat exposure.
Trike has similarities to the Microsoft threat modeling processes. However, Trike differs because it uses a risk based approach with distinct implementation, threat, and risk models. The Trike methodology seems to be in an experimental stage and with lack of significant documentation and support, it probably would be difficult to implement. Systems with more than about a dozen actors and a dozen assets are difficult to model as one system using Trike v1. The current tool implementation suffers from performance issues right around this maximum human-comprehensible model size.