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

Critically close to zero(day): Exploiting Microsoft Kernel streaming service

10 min read - Last month Microsoft patched a vulnerability in the Microsoft Kernel Streaming Server, a Windows kernel component used in the virtualization and sharing of camera devices. The vulnerability, CVE-2023-36802, allows a local attacker to escalate privileges to SYSTEM. This blog post details my process of exploring a new attack surface in the Windows kernel, finding a 0-day vulnerability, exploring an interesting bug class, and building a stable exploit. This post doesn’t require any specialized Windows kernel knowledge to follow along, though…

Gozi strikes again, targeting banks, cryptocurrency and more

3 min read - In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest. Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms,…

Vulnerability management, its impact and threat modeling methodologies

7 min read - Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem. Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

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