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.

Watch the webinar to learn more about application security

More from Application Security

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

Twitter is the New Poster Child for Failing at Compliance

All companies have to comply with privacy and security laws. They must also comply with any settlements or edicts imposed by regulatory agencies of the U.S. government. But Twitter now finds itself in a precarious position and appears to be failing to take its compliance obligations seriously. The case is a “teachable moment” for all organizations, public and private. The Musk Factor Technology visionary and Silicon Valley founder and CEO, Elon Musk, bought social network Twitter in October for $44…