A bunch of WASPs trying to penetrate a laptop's screen because they are after the web application
What some call a penetration test, others call a bug scrub…

If you are landing here after reading earlier posts, you might be thinking “this is great, but what I REALLY need is to avoid being the next <insert bad breach company here>. Well, our friends at OWASP (Open Web Application Security Project) are an organization that focuses on improving the security of software. Like any good David Letterman fan, they are famous for their Top 10 list of web application threats, and have followed that up with an API version! Threat modeling for software applications are essential not only to the end customers, but with the sheer complexity of today’s typical environments, the legal ramifications of a breach or attack can spell disaster for the hosting company, the software vendor, business partners, ecosystem partners, and the end users alike. It should be no surprise then that OWASP has its own approach to application threat modeling.

Like other approaches we’ve discussed, OWASP’s Application Threat Modeling approach helps you systematically identify and analyze potential security risks and threats to your application. OWASP’s encourages developers and security teams to consider security from the very beginning. You’ll find it more cost-effective and less disruptive to assess security early than to fix security issues after the application is already built. While networks or physical security architectures are built before performing a threat modeling exercise, we tend to forget that applications (web, mobile, embedded) are by their very nature accessible and exposed to some degree from day 1. It is essential to perform threat modeling and even risk mitigation before any accessible deployment.

The Process

Their process is actually pretty straightforward:

Data Flow Diagram from OWASP's Threat Modeling examples, showing how data moves throughout a notional library application.
A great DFD used in an OWASP Threat Modeling exercise? Pure madness!
  1. Decompose the Application – in this ‘step’ we actually have a few things to check off the list. A lot of it is about situational awareness for the application. What are the inputs, outputs, and involved assets? How do the pieces all relate from a trust-level perspective? How does data flow (time to use some DFDs!)?
  2. Determine and Rank Threats – a lot of threat-focused frameworks could be leveraged here, but given the generalized nature of web threats, STRIDE is perfect. Are there specific APTs that tackle Web Apps? SURE! But at the end of the day, they are all leveraging similar techniques, so it isn’t typically a massive, complex alert chain, but rather a recipe shared amongst a lot of other threat actors. Maybe that is better depicted using Attack Trees? And while we’re at it, lets rank them with DREAD, just to bring it all home. We’re riffing here!
  3. Determine Countermeasures and Mitigation – This part is the payoff. STRIDE itself can give us some awesome insights into how to defend against these threats, or reduce the impact should they occur. Others, like the Center for Internet Security (CIS) and NIST offer some slick guidance, hardened images, best practices, and the like. Here, it is all about picking the Application Security Framework (ASF) that best fits your way of doing business. It is very much like picking a new diet. The best diet or fitness plan is the one you can stick to. Beer and ice cream are part of my plan, but it doesn’t mean it will be for you.
A hierarchical diagram showing how to characterize risks from a syber perspective.
Use whatever risk process you want, but bonus points if it meshes with your corporate RM program!

What makes OWASP’s approach stand out?

OWASP’s approach explicitly recognizes not all threats and vulnerabilities are equally critical. Unlike DREAD’s alone, OWASP gives you the flexibility to borrow from more traditional risk management programs and prioritize the identified risks based on their potential impact and likelihood of occurrence. Their framework facilitates communication and collaboration between the application developers, you and your security team, and any other stakeholders. Once you identify and prioritize your threats, OWASP ties it to actionable outputs: how do we mitigate these threats? OWASP offers complimentary resources that recommend security controls and best practices to reduce the risk of exploitation.

Many regulatory standards and industry best practices require organizations to perform threat modeling as part of their security efforts. Following OWASP’s approach can help organizations meet these compliance requirements. As with other approaches listed before,  OWASP’s approach encourages a continuous and iterative process, allowing you to adapt to changing threats and evolving application features. Make it your own, folks!