Threat Modeling

    Threat is a potential or actual adverse event that may be malicious (such as a denial of service attack) or incidental (such as the failure of a storage device), and that can compromise the assets of an enterprise.

Threats can come from outside or within organizations, and they can have devastating consequences. Attacks can disable systems entirely or lead to the leaking of sensitive information, which would diminish consumer trust in the system provider. To prevent threats from taking advantage of system flaws, administrators can use threat-modeling methods to inform defensive measures.

Threat modeling is an iterative process that consists of defining enterprise assets, identifying what each application does with respect to these assets, creating a security profile for each application, identifying potential threats, prioritizing potential threats, and documenting adverse events and the actions taken in each case.

A threat model is essentially a structured representation of all the information that affects the security of an application. Threat modeling enables informed decision-making about application security risk.

Threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.

How To Do Threat Modeling

Many people think only security engineers can do threat modeling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, I would suggest they should also know a little bit of threat modeling as part of their work.

Let’s look at the elements of threat modeling:

Assets: What valuable data and equipment should be secured?

Threats: What the attacker can do to the system?

Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?

combined likelihood and impact are important enough to do something about.

 Threat modeling is a procedure for optimizing network security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.

·      Assessment Scope - The first step is always to understand what's on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy. Understanding the capabilities provided by the application and valuing them is more difficult. Less concrete things, such as reputation and goodwill are the most difficult to measure, but are often the most critical.

·      Identify Threat Agents and possible Attacks - A key part of the threat model is a characterization of the different groups of people who might be able to attack your application. These groups should include insiders and outsiders, performing both inadvertent mistakes and malicious attacks.

·      Understand existing Countermeasures - The model must include the existing countermeasures

·      Identify exploitable Vulnerabilities - Once you have an understanding of the security in the application, you can then analyze for new vulnerabilities. The search is for vulnerabilities that connect the possible attacks you've identified to the negative consequences you've identified.

·      Prioritized identified risks - Prioritization is everything in threat modeling, as there are always lots of risks that simply don't rate any attention. For each threat, you estimate a number of likelihood and impact factors to determine an overall risk or severity level.

·      Identify Countermeasures to reduce threat - The last step is to identify countermeasures to reduce the risk to acceptable levels.

Threat-modeling methods are used to create

• an abstraction of the system
• profiles of potential attackers, including their goals and methods
• a catalog of potential threats that may arise

STRIDE

Invented in 1999 and adopted by Microsoft in 2002, STRIDE is currently the most mature threat-modeling method. STRIDE has evolved over time to include new threat-specific tables and the variants STRIDE-per-Element and STRIDE per instance.

STRIDE evaluates the system detail design. It models the in-place system. By building data flow diagrams (DFDs), STRIDE is used to identify system entities, events, and the boundaries of the system. STRIDE applies a general set of known threats based on its name, which is a mnemonic, as shown in the following table:

PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat-modeling framework developed in 2012. It contains seven stages, each with multiple activities,

Process for Attack Simulation and Threat Analysis

PASTA aims to bring business objectives and technical requirements together. It uses a variety of design and elicitation tools in different stages. This method elevates the threat-modeling process to a strategic level by involving key decision makers and requiring security input from operations, governance, architecture, and development. Widely regarded as a risk-centric framework, PASTA employs an attacker-centric perspective to produce an asset-centric output in the form of threat enumeration and scoring.

CVSS

The Common Vulnerability Scoring System (CVSS) captures the principal characteristics of a vulnerability and produces a numerical severity score. CVSS was developed by NIST and is maintained by the Forum of Incident Response and Security Teams (FIRST) with support and contributions from the CVSS special interest group. The CVSS provides users a common and standardized scoring system within different cyber and cyber-physical platforms. A CVSS score can be computed by a calculator that is available online.

The CVSS consists of three metric groups (Base, Temporal, and Environmental) with a set of metrics in each.

A CVSS score is derived from values assigned by an analyst for each metric. The metrics are explained extensively in the documentation. The CVSS method is often used in combination with other threat-modeling methods.

OCTAVE

The Operationally Critical Threat Asset Vulnerability Evaluation method is a risk-based strategic assessment and planning method for cybersecurity. It was created by the CERT of the SEI in 2003 and refined in 2005. OCTAVE focuses on assessing organizational risks and does not address technological risks. Its main aspects are operational risk, security practices, and technology.

OCTAVE has three phases.

Build asset-based threat profiles. (This is an organizational evaluation.)

Identify infrastructure vulnerability. (This is an evaluation of the information infrastructure.)

Develop a security strategy and plans. (This is an identification of risks to the organization's critical assets and decision making.)