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

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Audio-jacking: Using generative AI to distort live audio transactions

7 min read - The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people. We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today