Threat Modeling — A simplified approach

As application security focuses more on shift left, where we start aligning security towards the earlier stages of the Software Development Lifecycle, understanding the application design and identifying key threats has become a crucial stage which informs the other security activities in the lifecycle. This activity is termed as Threat Modeling. In this article, I will outline the approach I follow to conduct Threat Modeling for any applications. The approach has been generalized so that it can apply to any organization’s application security process, whether automated or manual, to ensure that it can be adopted by security consultants to conduct Threat Modeling effectively.

Need for Threat Modeling

Let’s visit the need for Threat Modeling quickly. It is deemed as an essential activity in today’s application security context because it helps identify potential risks early. By anticipating and assessing possible threats from an attacker’s perspective, teams can design countermeasures before vulnerabilities are built into the system. This proactive analysis improves the resilience of applications and aligns with the shift-left approach for more robust security planning.

How to Conduct Threat Modeling

Threat Modeling, although sounding complicated, is actually quite a straight-forward activity to perform, provided there is a robust framework to be followed. Now, there are semi-automated tools which can assist an organization to perform Threat modeling quicker, but it is imperative that the organization understands the fundamental approach to Threat Modeling so that it can be rapidly scaled and automated to meet the organization’s application security goals.

As I believe strongly in standardizing Application Security activities to simplify adoption and incorporate feedback, I would like to share my approach to Threat Modeling, which would be useful for organizations to develop and enhance their own Threat modeling processes.

The approach is as follows:

Let me elaborate the steps a little more:

1. Develop a Threat Modeling library outlining design components and map key threats, data types, security requirements and security controls for each component. This step creates a library of threats, security requirements, controls & other custom data such as Data Types & User privileges which serves as the foundation of the entire Threat modeling process. Data types & User privileges can be created from the organization’s data & authorization frameworks and must be mapped to the security requirements and security controls. In case of manual threat modeling, it may seem as a tedious activity, but it is absolutely essential to create to create this library in an effort to keep threat modeling consistent across any organization. Automated tools also work on the same principle.
2. Obtain architecture diagrams from the development teams. Now, architecture diagrams refers to a group of design representations of the application, which can be termed differently in each organizations. The terms I have usually encountered in my experience are High-level Design, Low-level Design, Network diagram, Logical view and Physical View. It does not matter which term is used. We should obtain the design representations which will help us identify the design components, their interactions, and the data being processed/stored in it.
3. Once the design components and its associated information is identified, list the key threats, security requirements and security controls using the Threat Modeling library. A per-requisite for this analysis is that the Threat Modeling library should be fairly up to date, which means that it has to be reviewed regularly for any changes to be incorporated based on organization’s evolving infrastructure.
4. Armed with the list of threats, security requirements and security controls, the next step is to perform Threat analysis to identify its current status. This involves a collaborative approach where the Threat Modeling professional interacts with Application architects and developers to understand whether the security requirements and security controls are being incorporated in the application design or not.
5. The next step is for the Threat Modeling professional to create a detailed report using the outcome of Threat analysis. This report is then socialized with the Application teams so that they can add the required action items to the development board for fulfillment. The Threat Modeling report should contain, at minimum, the following information:
   - Application Design diagrams
   - Approach used for Threat Modeling
   - Identified security threats and their current status (Open, Partially mitigated, Fully Mitigated)
   - List of security requirements and their current status (Fulfilled, Not fulfilled)
6. Re-validation is the final step in the approach, where the Threat Modeling professional revisits the Threat Model once the application team fulfills the security requirements to address the security threats. The applied remediation/control is analyzed thoroughly and the Threat Model is updated accordingly.

Considerations

This approach encompasses my understanding of Threat Modeling and its execution. However, like any other process, it is important to understand the advantages and disadvantages that this approach brings, so that an organization is well-informed to tackle any present or future challenges.

• This approach is scalable with the organization’s growth. However, it requires regular reviews to identify and incorporate changes which happens as a result of that growth.
• This approach makes it easy to onboard new security professionals onto Threat Modeling due to its standardization. However, establishing this approach takes a lot of effort for an organization due to the aspect of research on threats and components.
• It aligns well with the concept of Shift-left, as having a standardized Threat Modeling approach means that with enough automation, the onus of execution can be shifted onto the application teams.

Conclusion

In conclusion, Threat Modeling is an essential activity in today’s application security landscape, which informs organizations of security threats quite early in their development lifecycle. The aforementioned approach works well to create a standard Threat Modeling process which can then be used across the organization’s assets. It also allows organizations to automate Threat Modeling once they understand the approach’s building blocks and obtain information on any challenges as they adopt it across their ecosystem.

Like what you read? Do consider following Cyber Security Advocacy where I publish weekly articles to share my knowledge and experience from over a decade in Cybersecurity.