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

by Security Compass
 | December 12, 2019
Managing Risk at Scale: Does the Modern Software Company Have Room for Threat Modeling (Part 1)

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.

Approach

Characteristic

Structure

Developed formally or through collaboration

Agile integration

Easily integrates with Agile, DevOps, or Waterfall

Age

Well-established or relatively new

Separation of concerns

Focus on software independent of either computation or platform

Traceability and testing

May focus more on testing and requirements

Security expertise

Some require extensive security knowledge

Output and reporting

Technical and nontechnical artifacts reach different audiences

Depth of security taxonomy

Extensive detail about required controls, or a high level assessment

Security posture

Offensive or defensive about security

Table 1: Threat modeling approaches and their defining characteristics.

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.

Popular approach

Challenge

Slowdown

Data flow diagrams

(Phase: Design)
  • Maintain accuracy when updating all data flow and block diagrams
  • API node complexity
  • Level of quality of diagrams is based on the skill of the creator

Data flow and block diagrams may become inconsistent with each other over time, and diagrams can become exponentially complex with each additional API node causing a network effect.

Checklists

(Phase: Requirements)
  • Exceptions
  • Updating lists

Not all parts of an application can be addressed by one list, and it’s difficult to know if an application conforms to a list. Keeping lists updated is time-consuming and requires expertise.

Misuse cases

(Phase: Testing)
  • May miss non use-cases or other ways to compromise a system
  • May exaggerate the importance of some cases

Misuse cases can become unreliable due to bias or exaggeration.

Table 2: Popular approaches to threat modeling create challenges in growing organizations that slow down development.

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

If these sound familiar to you, it’s because we have already started doing this. To learn more about this new approach to threat modeling, read the second part of this blog.