The step-by-step guide to threat modeling

Your organization relies on software to innovate and deliver value to your customers, as well as to work faster and more efficiently. However, if that software is not developed and deployed securely, it can put your business at risk. When software risk is business risk, you must both prioritize it and manage it proactively. Threat modeling promotes the idea of thinking like an attacker and enables organizations to build security considerations into software from the start, rather than addressing security as an afterthought.

What is threat modeling?

Threat modeling is a structured process that

• Identifies security requirements
• Locates security threats and potential vulnerabilities
• Quantifies threat and vulnerability criticality
• Prioritizes remediation methods

Threat modeling analyzes software design by comparing design views against threat agents to identify security weaknesses. Working with the software design means that the analysis can be conducted without having to delve into the code.

By identifying key structural elements and system assets—and documenting their related risk—threat modeling gives you enough detail to allow your business to make informed decisions about risk.

Securing your architecture

When performed during the architecture design phase, threat modeling enables organizations to avoid or mitigate security issues early by adding security controls or changing to a more secure design. Addressing these issues during architecture design saves the escalating expenses of addressing them later in the development process.

In addition to its use during the architecture design phase, threat modeling is also very useful during other stages of the software development life cycle (SDLC), including secure requirements identification, security test planning, secure code review, and penetration testing. Threat modeling informs these activities and offers invaluable insight into the methods attackers could use to harm your systems.

The six steps of threat modeling

A thorough analysis of system architecture, business context, and artifacts like functional specifications and user documentation helps threat analysts discover important aspects of your system—security-related or not—and synthesize an understanding that may not yet exist within your organization. There are six primary activities that constitute a threat model.
 

1. Define scope and depth of analysis

The first step is to define the scope and depth. The key stakeholders within the organization should work with the threat modeling expert to set the parameters and boundaries for which components should be included in the review. This phase will provide an understanding of the overall effort and expected delivery timeline of the assessment.
 

2. Gather data

The second step requires a threat modeling team to read and review the artifacts provided by the development team. The documents include but are not limited to architectural descriptions, software design documents, API specifications, end user documentation, source code, and related artifacts. This preliminary analysis is used to identify the high-risk areas in the platform that will form the basis for all future activities in the threat model. As part of this phase, the team will interview key members of the application and business teams. These interviews provide threat analysts with key knowledge about the application’s design and implementation details.
 

3. Model the system

After the gathering phase, threat analysts will build a simplified diagram of all the in-scope, adjacent, or connecting components (some which may be out of scope), as well as the connections and their protocols. Creating a diagram of the system’s structure provides a solid visual understanding of the system.
 

4. Perform threat analysis

Once the component diagram is completed, the fourth step requires threat analysts to add assets, controls, threat agents, and trust zones to create the full threat model diagram. This diagram should list all the realistic threats to the system, focusing on data, dataflow, platform, and operational security. It should also identify weak or missing controls that may lead to a successful compromise. Once identified, the threat analysts should mark the location of each threat.
 

5. Perform risk analysis

When the model is completed, step five requires threat analysts to review the dataflow and connections, component by component, to list all the realistic threat scenarios. Creating a traceability matrix is a way to record missing or weak controls so that you can define a plan to rank and mitigate them.

To create a traceability matrix, you need to consider the threat agents and follow the control path. If an asset can be reached without going through a control, for example, there may be a potential risk or design flaw. If an asset can be reached through a control, you might want to consider whether the control would halt a threat agent or whether that threat agent may have methods to bypass the security control. This is where a knowledge of actual attacks is essential.

Although the threat modeling process is simple, it takes time and repetition to become proficient at it. Creating and completing a thorough traceability matrix requires you to think not like a developer but like an attacker. One way to do this is to break threats into categories like these:

• Skill
• Motivation
• Attack vector
• Discoverability
• Probability

By thinking through each of these threat agent categories, then tracing them through your design to see where they might slip through a control, you can build a traceability matrix to properly track threat information through the requirements, design, and testing phases of the SDLC.
 

6. Create reporting

The final stage in threat modeling is to document all your models, system descriptions, potential risks, actual risks, and their associated likelihood and impact. A consulting service like the one Synopsys offers will provide this information in a PDF report.