Threat Modeling as the Only Secure Development Activity

Purpose

This article discusses why it is important for threat modeling to be supported by a full secure development process within an organization. If threat modeling is the only secure development activity performed, it will be difficult to identify threats, mitigate risks, and leverage knowledge gained during threat modeling efforts in future projects.

This article does NOT describe how to perform threat modeling, however it does provide a brief introduction to ensure it is clear what the author means by the term "threat modeling."

Introduction to Threat Modeling

At its core, threat modeling is a secure development activity in which developers, architects, designers, security personnel, and sometimes managers consider possible attack scenarios or threats against an application. This process typically occurs during a planning or design phase of development before any code is written.

One threat modeling strategy may include the following steps:

1. Resource <- 2. Capability <- 3. Use Case <- User
1. Resource <- 2. Capability <- 4. Threats <- Attacker

1. Identify resources within the application, such as database tables, file systems, and application servers.
2. Determine the capabilities or actions that can be performed on each item. One example for a database table may be to read checking account transaction data.
3. Consider the proper way in which a valid user may invoke a capability. Following with the previous example, a customer may login to Online Banking and access their checking account details.
4. Consider the threats to a particular resource based on the associated capabilities. Threat modeling participants can base threats on defined use cases or by brainstorming in a free form manner. Example: An attacker may wish to access another user's checking account data.
5. Assign a risk level to each threat, such as high, medium, and low.
6. Define countermeasures based on the analysis of the risk level vs. the cost of implementing the solution

There are many ways threat modeling can be performed. For more information, please visit the OWASP Threat Modeling page.


Threat Modeling as the Only Secure Development Activity

Threat modeling is a necessary component within a secure development process. However, if threat modeling is the only security activity your organization has implemented, you may not be realizing its full value or potential.

During the threat modeling process, threats and countermeasures must be defined. Typically, it is difficult for threat modeling participants to think from an attacker's perspective without basic application security awareness training. Often, the end result will be an incomplete threat model that does not include enough of the relevant application attack scenarios or threats.

Once threats have been enumerated, participants must identify viable and effective countermeasures. The most effective countermeasures are those based on application security best practices. Often, developers are not familiar with these best practices leading to the creation of countermeasures that only partial protect resources. Security training is necessary to provide application security knowledge and these essential best practices.

Once appropriate countermeasures have been designed, implemented, and tested to ensure they are complete and effective solutions for eliminating risks, this knowledge should be captured to be reused in future projects. If this knowledge is not captured, the organization will be forced to start from scratch each and every time threat modeling is performed. This can be an unnecessary allocation of time or money.

To effectively capture and reuse this knowledge, an organization should wrap security best practices and solutions into the organization's security policies and secure coding standards. In future projects, the designer or requirements specifier can create security requirements based on this documentation. During the threat modeling process, threats can be matched up with defined security requirements allowing participants to focus on threats that have not been mitigated in past efforts.

Conclusion

Threat modeling should not be the only secure development activity used within an organization. It must be supported by a full process including security training, security policies, secure coding standards, and many more activities. The OWASP Comprehensive, Lightweight Application Security Process is one fully featured secure development process that should be considered.