Managing Risk at Scale: Does the Modern Software Company Have Room for Threat Modeling (Part 2)

The new approach to threat modeling

After our previous blog on a new approach to threat modeling, we will discuss about the lightweight approach of using lists and taxonomies with traceable risk.

For instance, data sharing with lists that are provided by credible entities has proven to work. Many organizations use Common Weakness Enumeration (CWE), which is based on information from other lists. Similarly, we follow many regulations that are based on frameworks provided by NIST. These work together to help organizations establish a better security context.

Lists are generated from various standards and best practices, such as CWE and NIST 800-53.

Likewise, application taxonomies already exist within organizations. For example, we may have custom or off-the-shelf applications that are not tied to specific platforms. Here, we’re not specific about a single type of application, but rather generic categories of applications. This is useful for initial assessments of cost, risk, or impact to enterprise architecture. If our applications in the platform specific domain change too frequently, threat modeling activities can can start to feel the pressure.

Finally, as these activities are carried out, we can begin to accurately trace risk for the business. Through this process, we can generate audit reports and examine the application posture that gets injected into a risk register. The risk register, which is typically managed by a risk counsel, can then assess how threat modeling activities can support better resiliency, better compliance, and federal operations. These risk items can be fully traceable back to the threat modeling activities, which provides deeper insight into budget and risk.

Combining control lists with application taxonomies can create reports that categorize and rank risk in your organization and organize completion of work, as shown here from SD Elements.

When we take into account the regulations, frameworks, and audit practices that are required for your organization against application archetypes, we can figure out what controls we need to focus on for each application. This also helps us determine the coverage or risk against a given framework or practice. This is how the lightweight threat modeling approach works:

1. It minimizes the network effect because it reduces scope.

2. It provides a more consistent output in the form of textual lists, which can be understood and translated into downstream teams and phases as needed.

3. It has few exception policies, and those that do come up can be injected as part of the audit practice to create a more standardized map.

4. It provides the latest coverage for issues based on well-known industry lists, is systemic in its nature, and provides a more holistic perspective on managing security.

Final thoughts on the modern threat modeling process

So how valid is this approach? Here is how we’ve tested it.

Table 1: Real world validation for using this lightweight approach to threat modeling.

One area where this approach may not be well-suited is in trying to create a common artifact that can be used across the lifecycle. That being said, the output is generated in the form of a list that can translate between these lists and various lifecycle phases. For example, a list generated from NIST 800-53 can be translated into specific activities for developers, such as managing SQL injection.

Finally, it’s realistic. These activities help your organization address risk and scale rather than create processes for a perceived importance. This approach can actually reinforce product security in your organization — where once traditional threat modeling led to slowdown, new approaches like this can help you to speed up the development process and time to market.