This process can be very costly and time-consuming as it takes a security expert (or a number of experts) to identify high-value assets, analyze applications, assess the risk, and prioritize the threats and vulnerabilities. After going through all these steps, they deliver the security requirements to the development team.
This must be done for each application, and should also be revisited for each new feature as and when those are added, in order to maintain security after the initial release.
Understanding the threat modeling process
To understand the process of threat modeling, we must first distinguish between the two disparate classes of security weaknesses that exist.
Some articulate the difference as “business logic” vs. “technical” or “semantic” vs. “syntactic.” To build on a term familiar to developers, we classify threats into two different “domains.” Each kind of software weakness is domain-specific or domain-agnostic (or both). Making this distinction is critical.
- Domain-agnostic threats are software weaknesses that are the result of the type of application, the choices of technologies/protocols, the type of data being handled, the relevant compliance regulations, and so on. For example, XSS is a common weakness for all web applications and SQL inject applies to all applications that use SQL-based backend databases. They are commonly repeated and can be easily cataloged.
- Domain-based threats are business logic threats that are usually identified by domain experts when assessing the risks associated with the functionality of the application. An example is the need for a second approval when sending more than $1,000 in wire transfers.
Distinguishing between domain-agnostic and domain-based threats is critical.
Now that we have distinguished these two distinct types of weaknesses, you might notice that domain-agnostic threats, given their characteristic consistency, can be compiled into a knowledge base of the common threats. This library effectively serves as best practice guidelines for application security within the organization.
Furthermore, the domain-agnostic threats can be scaled to numerous projects and releases in an efficient, repeatable manner by employing automation tools and processes.
When you must scale and automate your threat modeling process
- In large enterprises with a limited number of security experts, threat modeling must be scaled to meet the security requirements of a large portfolio of applications.
- When organizations transition to Agile, DevOps, or Continuous Delivery methodologies, and there is a need to repeat the threat modeling process more often due to the greater number of releases potentially being built each year.
Streamlining the domain-agnostic portion of the threat modeling process through automation will allow application security experts to focus their manual efforts toward identifying domain-based threats, which are unique for every application and require more attention and due-diligence.
Additionally, it saves the precious time of scarce security experts, which prevents the threat modeling process from becoming a bottleneck, allowing it to harmonize with the rapid release cycles of Agile development. On an organizational level, automation of threat modeling processes can improve the overall product security and ensure fast development.
If you want to learn about the best threat modeling approach for your organization, download our threat modeling whitepaper now.