Throughout my career in software development and application security, I have worked on many development and operations teams and have often seen issues when it comes to implementing security into applications and products. Security in application development is often an afterthought and seen as an impediment to developers. As such, it is given less priority or totally ignored for the sake of hitting production deadlines.

This leads to more critical vulnerabilities in production, an increased risk to the business and remediation costs exponentially greater than those of implementing security by design in the early stages of the software development life cycle (SDLC). Threat modeling is an easy and cost-effective way to implement security in the design phase of the SDLC, before any code ever gets written.

What Is Threat Modeling?

Threat modeling is the practice of identifying and prioritizing potential threats and security mitigations to protect something of value, such as confidential data or intellectual property. By continuously threat modeling applications, security teams can better protect apps while educating the development team and building a culture of security throughout the enterprise.

Threat modeling can be a great way to start building a DevSecOps culture. One of my biggest pet peeves is hearing an organization’s upper leadership say they have implemented DevOps processes through tooling and moved the operations team right next to the development team. Sorry, but DevOps is neither a tool nor a process nor a combination of both. DevOps is the culture. DevOps is the idea that the operations team and development team should be one unit, share skill sets and establish a common goal.

When you are threat modeling, you bring the security architect, the operations/infrastructure team and lead developers together. A living document known as a threat model includes inputs from the whole team. In other words, threat modeling, by its very nature, fosters a culture of communication and collaboration. More importantly, it helps the team members build an understanding of each other’s roles, objectives and pain points. Is this all you need to implement DevSecOps? No,  but it will have a great impact on the software development culture.

Threat Modeling Can Lead to Teachable Moments

Perhaps the most overlooked benefit of threat modeling is education. In software development, threat modeling is a great way to bring awareness to the development team on current threats to applications. I often get pushback from architects and developers  wondering why threat hunting matters. This offers a great opportunity for me to explain why a threat is real and proven and the risk it poses to the enterprise.

Someone may ask, for example, “Why does encrypting our internal communication in the application matter?” I would reply, “Because you are transferring highly confidential information throughout the application, and if a malicious insider or rogue internal device sniffed the information, that could lead to information disclosure, which could damage the company’s reputation.” More often than not, the response is something along the times of, “Oh, I’d never thought of that.” Now that this person is privy to the reasoning behind this security control, they will base future decisions on the idea that communication should be encrypted by default to reduce risk to the business.

The bottom line is that threat modeling leads to a discussion, discussions lead to the exchange of knowledge and knowledge leads to better execution.

Proactively Improve Your Security Posture

The most obvious benefit of threat modeling is an improved application security posture. The primary goal of threat modeling, after all, is to identify threat actors and the ways in which they can influence an application. Once identified, these threats are resolved through security controls and mitigations, thus forcing security to be implemented in the design phase of the SDLC. This injects security by design principles into the application architecture, reduces threats and vulnerabilities before code has even been written, and minimizes defect and remediation costs.

Many security leaders and personnel are caught in a reactive security cycle, in which they respond only after a security incident has occurred to isolate and patch the issue. Threat modeling, on the other hand, is a way to proactively defend against future security incidents. Even application security testing is reactive: Code is developed and/or deployed in a test environment before security testing is conducted to find application vulnerabilities. This method requires significant development and operational time to fix and patch these vulnerabilities. Threat modeling can resolve vulnerabilities before they even occur, reducing testing and development time and saving costs.

Threat Modeling as a Foundation for DevSecOps Culture

Threat modeling delivers more value as it is executed consistently and repeatedly. Often, when threat modeling is conducted on a consistent basis throughout an organization’s application portfolio, secure design patterns begin to emerge that can be documented and leveraged by application development teams. This, again, contributes to the establishment of a proactive DevSecOps culture.

Design patterns can also serve as the basis for standard, repeatable application security requirements for the enterprise. For example, all data in transit should be encrypted via HTTPS, and all internal applications should leverage single sign-on (SSO) for authentication. Standard design patterns and requirements developed from threat modeling can go a long way toward reducing risk to the organization and remove a lot of the variety and complexity in security architectures that often lead to breaches.