The overwhelming number of new threats added daily to cyber ecosystems has moved threat modeling from a theoretically interesting concept into a current information security standard. As threat modeling methodologies evolve, security professionals are recognizing the importance of choosing the right threat modeling methodology for an organization’s specific challenges and the rise of new threats.
Threat Modeling Methodology Features
From a theoretical perspective, each threat modeling methodology provides security teams and organizations with the means to identify potential threats and may be seen on equal footing. However, on a practical level, threat modeling methodologies vary in quality, consistency, and value received for the resources invested.
Let’s dive a bit deeper into a few common threat modeling methodologies to better understand their strengths and weaknesses.
OCTAVE Threat Modeling
The Operationally Critical Threat, Asset, and Vulnerability Evaluation methodology[1] were one of the first created specifically for cybersecurity threat modeling. Developed at Carnegie Mellon University’s Software Engineering Institute (SEI) in collaboration with CERT, OCTAVE threat modeling methodology is heavy-weighted and focused on assessing organizational (non-technical) risks that may result from breached data assets.
Using this threat modeling methodology, an organization’s information assets are identified and the datasets they contain receive attributes based on the type of data stored. The intent is to both eliminate confusion about the scope of a threat model and to reduce excessive documentation for assets that are either poorly defined or are outside the purview of the project.
Though OCTAVE threat modeling provides a robust, asset-centric view, and organizational risk awareness, the documentation can become voluminous. This method is most useful when creating a risk-aware corporate culture. The method is highly customizable to an organization’s specific security objectives and risk environment.
Trike Threat Modeling
Trike threat modeling is an open source threat modeling methodology focused on satisfying the security auditing process from a cyber risk management perspective.[2] It provides a risk-based approach with unique implementation, and risk modeling process. The foundation of the Trike threat modeling methodology is a “requirements model.” The requirements model ensures the assigned level of risk for each asset is “acceptable” to the various stakeholders.
With the requirements model in place, the next step in Trike threat modeling is to create a data flow diagram (DFD). System engineers created data flow diagrams in the 1970s to communicate how a system moves, stores and manipulates data. Traditionally they contained only four elements: data stores, processes, data flows, and interactors. The concept of trust boundaries was added in the early 2000s to adopt data flow diagrams to threat modeling. In the Trike threat modeling methodology, DFDs are used to illustrate data flow in an implementation model and the actions users can perform in within a system state.
The implementation model is then analyzed to produce a Trike threat model. As threats are enumerated, appropriate risk values are assigned to them from which the user then creates attack graphs. Users then assign mitigating controls as required to address prioritized threats and the associated risks. Finally, users develop a risk model from the completed threat model based on assets, roles, actions and threat exposure.
P.A.S.T.A. Threat Modeling
The Process for Attack Simulation and Threat Analysis is a relatively new application threat modeling methodology.[3] PASTA threat modeling provides a seven-step process for risk analysis which is platform insensitive. The goal of the PASTA methodology is to align business objectives with technical requirements while taking into account business impact analysis and compliance requirements. The output provides threat management, enumeration, and scoring.
The PASTA threat modeling methodology combines an attacker-centric perspective on potential threats with risk and impact analysis. The outputs are asset-centric. Also, the risk and business impact analysis of the method elevates threat modeling from a “software development only” exercise to a strategic business exercise by involving key decision makers in the process.
STRIDE Threat Modeling
Microsoft’s threat modeling methodology – commonly referred to as STRIDE threat modeling – aligns with their Trustworthy Computing directive of January 2002.[4] The primary focus of that directive is to help ensure that Microsoft’s Windows software developers think about security during the design phase.
The STRIDE threat modeling goal is to get an application to meet the security properties of Confidentiality, Integrity, and Availability (CIA), along with Authorization, Authentication, and Non-Repudiation. Once the security subject matter experts construct the data flow diagram-based threat model, system engineers or other subject matter experts check the application against the STRIDE threat model classification scheme.
This methodology is both well documented and well known owing to Microsoft’s significant influence in the software industry and their offering of Microsoft TMT.
VAST Threat Modeling
The Visual, Agile, and Simple Threat modeling (VAST) methodology was conceived after reviewing the shortcomings and implementation challenges inherent in the other threat modeling methodologies. The founding principle is that, in order to be effective, threat modeling must scale across the infrastructure and entire DevOps portfolio, integrate seamlessly into an Agile environment and provide actionable, accurate, and consistent outputs for developers, security teams, and senior executives alike.
A fundamental difference of the VAST threat modeling methodology is its practical approach. Recognizing the security concerns of development teams are distinct from those of an infrastructure team, this methodology calls for two types of threat models.
VAST: Application Threat Models
Application threat models for development teams are created with process flow diagrams (PFD). Process flow diagrams map the features and communications of an application in much the same way as developers and architects think about the application during an SDLC design session.
VAST: Operational Threat Models
Operational threat models are designed for the infrastructure teams. Though more similar to traditional DFDs than application threat models, the data flow information is presented from an attacker – not a data packet – perspective. By relying on PFDs rather than DFDs, VAST threat models do not require extensive systems expertise.
Uniquely addressing both developer and infrastructure team concerns allows organizations to incorporate threat modeling as a part of their DevOps lifecycle with different outputs for various key stakeholders.
The most significant difference of the VAST threat modeling methodology, however, is its ability to allow organizations to scale across thousands of threat models. The pillars of a scalable threat modeling practice –automation, integration, and collaboration– are foundational to VAST threat modeling. As the organization matures and new threats arise, these pillars help to develop a sustainable self-service threat modeling practice driven by the DevOps teams rather than the security team.
Learn more: Threat Modeling Methodologies: What is VAST?
Choosing the Right Threat Modeling Methodology
Desired outputs should govern an organization’s choice of threat modeling methodology. While all threat modeling methodologies may be capable of identifying potential threats, the number and type of threats identified will vary significantly, as will the quality, consistency, and value received from those threat models. The challenge, however, is to purposefully choose a threat modeling methodology based on the desired outcomes rather than to simply settle for what everyone else is doing.
At the enterprise level, the ability to scale across hundreds or even thousands of threat models certainly should be considered. If an organization is to invest significant resources in an enterprise threat modeling initiative, then the capacity to generate relevant financial and productivity reports that sync with C-Suite financial reporting may be desirable. If reducing the organization’s overall threat profile, attack surface, and risk portfolio are important, then so too is the ability to measure and track the effectiveness of the threat modeling in achieving these goals.
ThreatModeler is a leading automated threat modeling platform and service provider dedicated to helping organizations gain holistic visibility into their attack surface to implement mitigation strategies and tackle unique security needs. Our platform is trusted by industry giants to expose weaknesses and vulnerabilities across operational infrastructure and software applications, resulting in stronger enterprise security.
Strengthen your security measures with a modern threat modeling system and dedicated support from security experts. To learn more about how ThreatModeler™ can help your organization build a scalable threat modeling process, book a demo to speak to a ThreatModeler expert today.
[1] Caralli , Richard A. etal. “Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process.” Software Engineering Institute: Pittsburg. May 2007.
[2] Eddington, Michael, etal. “Trike v1 Methodology Document.” OctoTrike.org. July 20, 2005.
[3] Ucedavélez , Tony and Marco M. Morana. “Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis.” 2015 John Wiley & Sons, Inc: Hoboken. May 15, 2015.
[4] JMeier, etal. “Threat Modeling Web Applications.” Microsoft, Inc: Redmond. 2005.