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 verify security efforts. The threat modeling process helps an organization document security threats to an application and make rational decisions about how to address them.

A well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system. Threat modeling is the most effective way to

• Detect problems early in the software development life cycle (SDLC)—even before coding begins
• Spot design flaws that traditional testing methods and code reviews can 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 after 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. Here is why these misconceptions should be dispelled.

• Automated testing in the SDLC can’t substitute for threat modeling. Automated testing in the SDLC can be efficient for finding vulnerabilities in code. However, manual security assessments (e.g., threat modeling) are better at uncovering design flaws.
• It is necessary to conduct threat modelling 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 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.

Threat modeling promotes 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.

• Define the scope and depth of analysis. Define the scope with stakeholders, then break down the depth of analysis for individual development teams so they can threat model the software.
• Create a visual interpretation of the collected data. Create a diagram of the major system components (e.g., application server, data warehouse, thick client, database) and the interactions among those components.
• Apply security context to the diagram created. Identify software assets, security controls, and threat agents, and diagram their locations to create a security model of the system. Once you’ve have modeled the system, you can identify what could go wrong.
• Identify threats. Refer to threat models such as STRIDE, capec, att&ck, etc. Document possibilities, produce a list of potential attacks, and ask questions such as
  • What can the attacker do?
  • What type of access do they have?
  • Where are they located?
  • 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?
  • What could be the different potential attack scenarios and vectors?
• Create a traceability matrix. Document a list of goals that the attacker might want to accomplish, along with how those goals could be achieved. Also add a list of security controls to prevent risk.

Figure 1: Security model of a system

Historically, threat modeling was a manual activity in which security experts and stakeholders drew diagrams on whiteboards. However, with the adoption of DevSecOps, security teams are under significant pressure to keep up with the fast and frequent releases of development and minimize security friction, leading to the adoption of automation practices.

Automated threat modeling practices should act as a supplement to the threat modeling engineers on staff. Human oversight is essential because designing a system model that a computer can analyze is complex. The most efficient way to scale threat modeling is to have an experienced human build the threat model and use AI to process and interpret relevant data, with human oversight throughout the process.

Types of data that AI can process and interpret include

• Types of threats
• Attack surface exposure
• Security controls
• Design flaws
• Vulnerabilities in code

Remember, AI can only interpret the data provided to it, and if the data going into the AI system is flawed, the results will reflect that.

Synopsys software security services include threat modeling, which can identify weaknesses including secure design violations, security control omissions, and control misconfiguration, weakness, and misuse. The Synopsys approach to threat modeling adheres to three steps.

Figure 2: Synopsys threat modeling approach

Model the system

System modeling consists of two parts.

• Create a component diagram with a control flow graph that shows all possible execution paths in a program
• Identify assets, security controls, trust boundaries, and threat agents

Conduct a threat analysis

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 an approach consisting of a checklist to drive the core analysis but that still leaves the opportunity for creative analysis. Synopsys uses a predefined 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.

Prioritize threats

After we model the system and conduct a threat analysis, we generate a list of threats and then prioritize them. At Synopsys, we use the NIST approach to prioritizing threats, using guidelines for quantifying the likelihood and impact of each threat to determine severity.

Threat modeling is applicable at any stage of the software development life cycle, but incorporating it early in the software development process will ensure that your organization is building security into your applications. At Synopsys, we recognize that organizations have different risk profiles and tolerances, so we customize our threat modeling services to meet your budget and needs.