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

X-Force Identifies Vulnerability in IoT Platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

4 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

4 min read - Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

4 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read