Jimm Wayans

What Is Threat Modeling?

Threat modeling is a proactive approach to identifying entry points to enumerate threats and building security measures to prevent security breaches in applications and computer and network systems. It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application and systems. You can use threat modeling to shape your application’s and system’s design and improve security.

Threat modeling provides a good foundation for the specification of security requirements during application development. When applied during the early phases of software development, threat modeling empowers developers in several ways. These range from verifying application architecture, identifying and evaluating threats, designing countermeasures, to penetration testing based on a threat model. There is however paucity of established techniques and tools for threat modeling and analysis.

What Most Threat Models Include

Due to the uniqueness in nature, most threat models do not look the same but generally include the following basics:

• A description of the threat
• A list of assumptions regarding the function of the software or organization that can be reviewed in the future
  Vulnerabilities
• Actions for each vulnerability
• How to review and verify the vulnerabilities are being watched and are secure

Why is threat modeling necessary?

As organizations become more digital and cloud-based, IT systems face increased risk and vulnerability. Growing use of mobile and Internet of Things (IoT) devices also expands the threat landscape. And while hacking and distributed-denial-of-service (DDoS) attacks repeatedly make headlines, threats can also come from within–from employees trying to steal or manipulate data, for example.

Smaller enterprises are not immune to attacks either–in fact they may be more at risk because they don’t have adequate cybersecurity measures in place. Malicious hackers and other bad actors make risk assessments of their own and look for easy targets.

Threat Modeling Methodologies

OCTAVE (Practice Focused)
The Operationally Critical Threat, Asset, and Vulnerability Evaluation methodology[1] was 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 eliminate confusion about the scope of a threat model and 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. OCTAVE lacks scalability – as technological systems add users, applications, and functionality, a manual process can quickly become unmanageable.

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 (Acceptable Risk Focused)
Trike threat modeling is a unique, open source threat modeling process 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.

However, because Trike threat modeling requires a person to hold a view of the entire system to conduct an attack surface analysis, it can be challenging to scale to larger systems.

P.A.S.T.A. Threat Modeling (Attacker Focused)
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.

PASTA threat modeling works best for organizations that wish to align threat modeling with strategic objectives because it incorporates business impact analysis as an integral part of the process and expands cybersecurity responsibilities beyond the IT department.

This alignment can sometimes be a weakness of the PASTA threat modeling methodologies. Depending on the technological literacy of key stakeholders throughout the organization, adopting the PASTA methodology can require many additional hours of training and education.

STRIDE Threat Modeling (Developer Focused)
STRIDE stands for Spoofing Tampering Repudiation Information Message Disclosure Denial of Service and Elevation of Privilege. Microsoft’s threat modeling methodology – commonly referred to as STRIDE – 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 (Enterprise Focused)
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.

Why you should Threat Model?

Threat Modeling gives a complete picture of the threats and possible attack paths. These attack paths can subsequently be used for instance to create efficient test scenarios, design adjustments or to define additional mitigating measures. Next to the result, the threat modeling workshop is a great way to raise security awareness and collaboration.

This allows you to execute concrete next steps in improving security.