Is next-gen threat modeling even about threats?

The threat landscape evolves with technology, and as threats grow in sophistication, there are concerns about major events like the Colonial Pipeline ransomware attack or the Equifax breach repeating themselves elsewhere. While mainstream media focuses on operational cybersecurity, intelligent application firewalls, and other defensive and reactive solutions, the 2021 Verizon Data Breach Investigation Report suggests that insecure code and configuration in software is the root cause that needs to be addressed.

To address the challenges of insecure software development and deployment, the industry is moving to bake security into the software development life cycle (SDLC). Many experts attempt to use traditional threat modeling as their first line of business to address security in the SDLC.

But what if everyone is doing threat modeling wrong?

The industry standard for how we conduct threat modeling today evolved from past meetings where security professionals piled into a conference room and brainstormed potential threats that might affect their software. This labor-intensive process often caused communication issues between security professionals and developers. The major flaw in this approach is that only the threats security professionals thought about during the development of their modeling platforms are being addressed by their technology.

Threat modeling has changed throughout the years

With the development of DevSecOps, modern threat modeling is less focused on detailed analysis of complex threat scenarios. This might seem counterintuitive, and you might think that a threat model without threats is not going to give any information at all. But modern threat modeling through DevSecOps provides superior results because threat prevention starts from the ground up. DevSecOps and the philosophy of building secure code from the beginning deemphasizes individual threats and how they manifested in the form of vulnerabilities and focuses on baking in prevention early in the software development process. In a sense, you eliminate the vulnerabilities by leveraging secure design and programming good code from the start.

Additionally, DevSecOps makes the process less stressful for everyone. During the early days of threat modeling, the time-consuming and waterfall-style of threat modeling meant that it was performed at a limited scale and rarely kept current. That often resulted in developers skipping security planning and instead submitting code to the application security (AppSec) team to determine if it was secure enough. Then, the security team would provide a long list of changes that needed to be made. Given their tight deadlines, few developers had time to implement the AppSec team’s robust list of recommendations. Some companies did not have the resources to provide retroactive fixes while also working on new code. In that case, the best defense was to employ traditional threat modeling to try and stop attackers who were seeking to exploit those known vulnerabilities.

DevSecOps has become the gold standard for new threat modeling by proactively preventing threats from occurring in the first place. By making development teams own security, it supports a much stronger security framework than if security was the exclusive responsibility of understaffed AppSec teams. By proactively developing more secure code, normalizing language and modernizing the philosophy of threats, organizations can greatly improve their security posture.

Which raises the question: If modern threat modeling is not the same as classical threat modeling, why call it threat modeling at all?

Adopting a modern threat modeling framework is critical

While the methods have changed, the reason we need to model threats remains the same. Modern modeling still involves identifying and preventing threats, just more proactively. By focusing on DevSecOps, threat modeling aims to prevent problems across the board instead of whichever threat or vulnerability is trending at the time. It is not feasible to predict every new type of malware delivery scheme, but it is possible to eliminate the pathways and vulnerabilities that malware could follow.

This situation is only going to get more precarious. With the development of sophisticated IoT device hacks, cryptocurrency and blockchain scams, plus phishing attacks, companies have more threats to worry about than ever before. To think that a handful of people could predict every method of attack is naive. And while it seems counterintuitive, the best way to protect against modern threats is not to focus directly on the threats at all.

We must also consider that there are other topics pertaining to risk management in software that don’t fit traditional application security models. Modern threat modeling needs to provide developers a prioritized list of mitigations that need to be implemented.

Utilizing a modern, comprehensive, and automated threat modeling framework enables companies to deploy their often limited resources so they can have the biggest impact. Building strong and secure code from the start can even prevent productivity loss by not forcing developers or AppSec teams to retroactively correct vulnerabilities. It will also prevent threat actors from establishing a beachhead to work from, regardless of their methods or attack techniques they employ.

I believe this modern threat modeling framework needs to become the new standard — quickly. No company wants to be known as “the next Equifax” or “the new Colonial Pipeline,” and no shareholder or stakeholder wants to be blindsided by the knowledge that a major systems breach occurred due to poor modeling practices. Companies instead need to focus on DevSecOps, building secure code from the start, and using that platform to create a stronger, more modern foundation and approach to threat modeling.