Managing Risk at Scale: Does the Modern Software Company Have Room for Threat Modeling

Is threat modeling a roadblock to application development?

Is threat modeling a roadblock for security in your organization when it should be an enabler? If it is, you’re not the only one. Traditional threat modeling is no longer meeting the needs of the modern development team that relies on speed and automation. How do organizations keep pace with the industry while growing their numbers?

To explore this, we’ve worked with standards communities, regulatory bodies, academic research, and some of the biggest companies in the world to develop an alternative perspective of how threat modeling can help drive security forward without creating a barricade. So is threat modeling a blocker? Yes.

But it doesn’t have to be.

Traditional threat modeling processes have blockers

We need to begin by looking at traditional threat modeling and pinpointing where slowdown occurs. No single model can account for every business case, so we see a large variety of them. At the same time, they each aim to accomplish a specific goal by either addressing a development phase, working with various levels of security expertise or producing unique outputs. This kind of granularity works well when you need an assortment of tools to address a variety of factors — but when a company increases in size or doubles the projects that require threat modeling, it’s no longer a realistic strategy. At the end of the day, traditional threat modeling is slow.

Traditional threat modeling and why slowdown happens

Each threat modeling approach has its strengths and weaknesses. Imagine how these approaches transfer to tens, hundreds, or thousands of projects. Through our conversations with large companies using threat modeling, we discovered that they preferred using data flow diagrams, checklists, and misuse cases for threat modeling. See the following table for a breakdown of their challenges and a summary of the resulting slowdown.

Revamp your threat modeling approach

Organizations today are still using threat modeling, but they need a better way to do it as they grow. Where do they start?

Firstly, you need to seamlessly integrate threat modeling artifacts across the lifecycle. This means that threat modeling artifacts are well understood at each phase, and they don’t distract from the overall process flow or the work of other teams.

Secondly, the threat model should be simple to generate. It should be scalable across fast-paced development environments with thousands of applications without requiring the consistent use of a limited pool of resources.

Finally, it needs to be easily understood across the software lifecycle. Anyone should be able to look at a threat modeling artifact in any phase of the development life cycle and understand what it means.

To avoid a slowdown in the development process, threat modeling should:

1. Reduce the network effect
2. Produce consistent output
3. Include exception policies
4. Ensure the latest security coverage
5. Ensure that output reflects the entire system
6. Assess importance realistically
7. Reduce the discrepancy of threat modeling artifacts across the software lifecycle

How can we do this?

A new approach to threat modeling

We’ve outlined how traditional threat modeling processes can slow down large and growing businesses. We need a way to update threat modeling to address contemporary challenges that require the flexibility and speed we see in DevSecOps. This is the lightweight approach we’re looking for.

To scale threat modeling across people, systems, and data, we need a way to deliver common artifacts across the software lifecycle without becoming excessive and monolithic. Instead, we want a lightweight representation of these elements that we can easily reformat as needed. This common artifact should be able to produce:

• Data sharing with lists
• Application taxonomies
• 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.