Threat Modeling

Threat modeling works by identifying the types of threat agents that cause harm to an application or computer system. It adopts the perspective of malicious hackers to see how much damage they could do. When conducting threat modeling, organizations perform a thorough analysis of the software architecture, business context, and other artifacts (e.g., functional specifications, user documentation). This process enables a deeper understanding and discovery of important aspects of the system. Typically, organizations conduct threat modeling during the design stage (but it can occur at other stages) of a new application to help developers find vulnerabilities and become aware of the security implications of their design, code, and configuration decisions. Generally, developers perform threat modeling in four steps:

• Diagram. What are we building?
• Identify threats. What could go wrong?
• Mitigate. What are we doing to defend against threats?
• Validate. Have we acted on each of the previous steps?

When performed correctly, threat modeling can provide a clear line of sight across a software project, helping to justify security efforts. The threat modeling process helps an organization document knowable security threats to an application and make rational decisions about how to address them. Otherwise, decision-makers could act rashly based on scant or no supporting evidence.

Overall, a well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system. And when the development organization is serious about security, threat modeling is the most effective way to do the following:

• Detect problems early in the software development life cycle (SDLC)—even before coding begins.
• Spot design flaws that traditional testing methods and code reviews may overlook.
• Evaluate new forms of attack that you might not otherwise consider.
• Maximize testing budgets by helping target testing and code review.
• Identify security requirements.
• Remediate problems before software release and prevent costly recoding post-deployment.
• Think about threats beyond standard attacks to the security issues unique to your application.
• Keep frameworks ahead of the internal and external attackers relevant to your applications.
• Highlight assets, threat agents, and controls to deduce components that attackers will target.
• Model the location of threat agents, motivations, skills, and capabilities to locate potential attackers in relation to the system architecture.

As a security process, threat modeling is subject to several misconceptions. Some people believe threat modeling is only a design-stage activity, some see it as an optional exercise for which penetration testing or code review can substitute, and some think the process is simply too complicated. The following should help dispel some of these misconceptions:

Penetration testing and code reviews can’t substitute for threat modeling. Penetration testing and secure code review are two activities that are effective for finding bugs in code. However, security assessments (e.g., threat modeling) are better at uncovering design flaws.

There’s a good reason to conduct a threat model after deployment. Understanding the issues in the current deployment influences future security architecture strategy, and monitoring weaknesses allows for faster and more effective remediation. Without understanding the potential threats an application faces, you can’t ensure that you’re addressing all risks.

Threat modeling isn’t that complicated. Many developers are intimidated by the idea of threat modeling. At first glance, it can seem daunting. However, if you break up the tasks into workable steps, performing a threat model on a simple web application—or even a complex architecture—becomes systematic. The key is to start with basic best practices.

The killer application of threat modeling is promoting security understanding across the whole team. It’s the first step toward making security everyone’s responsibility. Conceptually, threat modeling is a simple process. So consider these five basic best practices when creating or updating a threat model:

1. Define the scope and depth of analysis. Determine the scope with stakeholders, then break down the depth of analysis for individual development teams so they can threat model the software.

2. Gain a visual understanding of what you’re threat modeling. Create a diagram of the major system components (e.g., application server, data warehouse, thick client, database) and the interactions among those components.

3. Model the attack possibilities. Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system (see Figure 1). Once you’ve have modeled the system, you can identify what could go wrong (i.e., the threats) using methods like STRIDE.

4. Identify threats. To produce a list of potential attacks, ask questions such as the following:

                    Are there paths where a threat agent can reach an asset without going through a control?

                    Could a threat agent defeat this security control?

                    What must a threat agent do to defeat this control?

5. Create a traceability matrix of missing or weak security controls. Consider the threat agents and follow their control paths. If you reach the software asset without going through a security control, that’s a potential attack. If you go through a control, consider whether it would halt a threat agent or whether the agent would have methods to bypass it.

Figure 1: Security model of a system.

Synopsys software security services include threat modeling, which can identify potential weaknesses that may increase your system’s susceptibility to an attack, including secure design violations, security control omissions, or control misconfiguration, weakness, or misuse.

The Synopsys high-level approach

As Figure 2 shows, the Synopsys high-level approach to threat modeling adheres to the following steps:

• Model the system.
• Conduct a threat analysis.
• Prioritize the threats.

Figure 2: Synopsys threat modeling approach.

System modeling consists of two parts:

1. Creating a component diagram with a control flow graph (which shows all possible execution paths in a program)
2. Identifying assets, security controls, trust zones, and threat agents

Perhaps the most important activity in threat modeling is identifying threats. Most approaches fall into two categories:

• Checklist-based approaches. Many threat modeling approaches involve a checklist or a template. For example, STRIDE recommends you consider six types of threats—spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege—for all dataflows that cross a trust boundary.
• Non-checklist-based approaches. These approaches generally use creative methods (e.g., brainstorming) to identify attacks.

Synopsys threat analysis uses a quasi-checklist approach: It uses a template to drive the core analysis but still leaves the opportunity for creative analysis. Synopsys uses pre-baked application protocol threat analysis for commonly used application-level protocols, such as OAuth, SAML, OIDC, Kerberos, password-based authentication, and others. This list is not exhaustive, but it allows you to start thinking about areas of concern to analyze.

Once we model the system and conduct a threat analysis, we’ve generated a list of threats. Now it’s time to prioritize them. At Synopsys, we use the NIST approach to prioritize threats, using guidelines for quantifying the likelihood and impact of each threat to arrive at severity.