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:
- Attack vector
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.