Threat modeling is a highly effective means of securing software and applications, yet very few organizations actually do it. In today's computing and security environment, however, threat modeling is more necessary than ever.

Cloud-based distributed systems and cross-functional, agile software development teams have replaced monolithic systems built and operated by siloed teams. Along the way, software has become much more complex — and so have the threats. Threat actors have changed tactics to get around traditional means of detection. Many attacks no longer deliver malware, for example, instead focusing on credential compromises. And attackers can sit inside company networks for months before acting. IBM's "Cost of a Data Breach Report" found that it takes an average of 287 days for organizations to identify and contain a breach.

Companies do recognize the need. A 2021 Security Compass study found that 79% of the midsize and large enterprises view threat modeling as a priority, but only 25% conduct modeling during the early design phases. And only 10% perform threat modeling on 90% of the applications they develop.

As an industry, we need to make threat modeling a standard practice in software development, introduced in a way that both development and security teams can work with, and implemented in a way that shows positive results and improvement over time. And it all starts with a word you might not hear a lot in IT ops and security circles: empathy.

A Cultural Change

There are a number of reasons for the disconnect between seeing the value in threat modeling and actually doing it, including a lack of communication between security and development teams, and a tendency to give up on threat modeling if initial efforts become muddled and don't produce the desired results.

Too often, security teams can look at applying security controls as a one-way street between them and development teams, as simply a matter of telling developers what to do. But that's starting off on the wrong foot. Organizations need to recognize that each team has skills that the other can learn from. After all, if you put a security pro in the developer space, they'd be lost.

Changing this mindset requires a cultural shift, and it starts with viewing empathy as a value proposition. The human side of this needs to come to the forefront, getting more people involved in enriching our knowledge. Security teams need to appreciate the environment developers work in, under pressure to develop and deliver software rapidly. Dev teams can help security teams understand frameworks such as containers and how to control access, knowledge which can be applied to security policies.

When teams get collaboration going back and forth, they're learning from each other. It will take time to get to that point. It might start in meetings or a process integration, perhaps working through a bit of trial-and-error, and eventually move into tool integration. When they get to the level of maturity where everybody has a basic understanding of each other's domains, they can then move to more advanced levels of threat modeling, such as modeling knowledge bases and creating graphs of concepts that map together.

But it needs a stable process, or it gets expensive and chaotic, resulting in messy people issues.

3 Steps to Better Threat Modeling

There are three key elements to creating a collaborative atmosphere.

Coaching: This helps developers understand the importance of threat modeling. It can start with onboarding new employees. Regardless of their background and certifications, don't assume they know how security is handled at your company. Make sure they understand the culture.

Collaboration: A culture of cooperation and collaboration begins with a company's leadership, with a CISO having the attitude of wanting to serve the teams. It can take time, but it should be modeled at the leadership level.

Integration: The elements of cooperation come together working on integrations, which is an ongoing process. The goal isn't perfection, but to improve and evolve over time.

A key to making this approach work is applying metrics, specifically by looking at outcomes, such as "reducing vulnerabilities" — as opposed to trying to grade the details of how individuals work. Outcomes are not a developer or security thing, it's everybody's thing.

I've found in my experience that it's useful to have clear 30-, 60-, and 90-day plans, describing the expected outcome at each stage. The plans should demonstrate incremental growth and be done collaboratively. If These outcomes should be measured, or you end up drifting aimlessly.

Empathy Is the Key

As a security community, it's our responsibility to help developers embrace threat modeling. It's not us versus them. We need to get them to think about security, and threat modeling, as part of an integrated approach that evolves over time.

Empathy as a management technique can help create that environment. Some people may think empathy means no accountability — that understanding someone's position and thoughts is somehow soft — but it actually produces the opposite result. It develops the collaboration that we so desperately need.