Why Threat Free Threat Modeling Doesn’t Work

Threat Free Threat Modeling

Yes, this idea of threat free threat models makes no sense to me either, but nonetheless this is a growing misconception by some just coming into the practice of application threat modeling.

The fact is that threat modeling could be reworded to be a model of threats without distorting its meaning to even people outside of the field.

Common sense would lead anyone to believe that such a model would yield some representation of threats. In fact, this activity [of modeling threats] was very much the objective in much of the military uses that predates InfoSec’s use of threat modeling.

Ironically, in a mad rush to take part in threat modeling fanfare sweeping security and development circles, many are ignoring consideration of the blatantly obvious question: what threats could affect my application?

The same people seeking a “threat free” diet in their threat models will argue against the idea that attack centric threat models or those considering threats are overstated.

The fact is, in Application Security, these same views typically come from people in security that couldn’t red team their way to the treasure chest in a fishbowl. The camp of application breakers has attributes that are not innate to everyone.

It takes creativity, tenacity, knowledge [of code, use cases, frameworks, etc.], and most importantly practice – practice that simply builders of applications are not consumed with as part of their software development roles. (Read more about building in Application Security early into your SLDC here.)

The debate isn’t whether builders or breakers of applications should be charged with threat modeling activities but instead looking at the more inclusive option of collaborating among the two groups. In doing so, breakers exemplifying threats within a threat model can help builders understand the viability and kill chain of an exploit.

Blueprinting Better Security

The Process for Attack Simulation of Threat Analysis (P.A.S.T.A) threat modeling methodology was developed for several reasons.

#1: A new perspective – One key component behind the PASTA methodology is to look at your applications from the lens of an attacker.

#2. A collaborative process – PASTA was developed to be a collaborative threat modeling process. PASTA threat modeling is not meant to be solo activity performed unilaterally by one individual. Developers, security champions, SOC analysts, systems engineers, architects, pen testers, risk professionals can work collaboratively to consider threats against a target application.

Any team responsible for an application’s security posture should work together as a group to compile a list of threats, substantiated by industry sources as well as alert data within the application infrastructure, to help anchor any threat model.

The 7 Stages of PASTA Threat Modeling

PASTA has a linear methodology that begins with the following:

1. Business Use Cases: As a risk-centric approach, the context for risk is going to best be tied to what impact the application has to the business.

End goal of Step 1 of PASTA is to understand what role the application has in supporting front end and back end business processes and what inherent risks related to confidentiality, integrity, availability or regulatory compliance are at risk. One great value to risk-centric threat models is that they align to the reality that most organization do not have the means to reach a 0-risk threat model.

As a result, it is better to focus on the threats that are going to most greatly affect the business risk via the subject application.

2. Technology Scope: You can’t defend what you don’t know. This simple adage holds true and is blatantly missing in other pseudo approaches. Particularly as applications are becoming less monolithic and more decoupled, architects, system engineers and various developers responsible for front-end, back-end, client-side development would be good to partake in threat modeling activities within this stage.

As a blueprint, this stage helps to define the scope of what may be attacked. As such, it defines an initial outline of what would be good to test for subsequent stages as well as see what preventative hardening measures.

3. Application Decomposition: This step maps the interoperability among application components. Data-flow diagramming (DFDs) is a key output from this PASTA stage as it helps to contextualize data flows, call flows, between components identified in Stage 2.

This stage also helps to unravel what implicit trust may exist between application trust boundaries and among application components. As a blueprint, decomposing the application does help to test abuse case across trust boundaries during a pen test. Conversely, on the design side, data flows can reveal where improved security architecture measures could be applied.

4. Threat Analysis: Going back to the opening remarks, here is where an application threat model considers actual threats. PASTA makes threat modeling logical by incorporate two information threat sources: one is from threat intelligence sources that reflects threat patterns affecting industries that encompass applications and their respective environments (e.g. – mobile, web, Cloud, etc.)

The second source is threat data that comes from within the hosted application environment where SIEM products may be centralizing environment alerts that indicate various threat patterns around denial of service, authentication bypass, exfiltration attempts or even malicious file upload attempts.

Threats help to substantiate exploitation activities that should be attempted against the application.

5. Vulnerability Analysis: Vulnerability is a variable in the risk equation. We substantiate possible threats in the stage four and now [in this stage] we can correlate the vulnerabilities found in architecture, frameworks, systems, configurations, and code that can realize threat objectives. Again, collaboration is ripe for this stage as vulnerability data can be pulled via automated sources that are qualified by threat vulnerability management (TVM) teams.

The blueprint opportunity here is that instead of mining a sea of data vulnerabilities that comes from standard, isolated operations, a risk-centric threat model can contextualize vulnerability data to identify the most relevant ones that augment the feasibility of identified threat patterns.

6. Attack Modeling: Let the builders build and the breakers break. Breakers devoid of threat context are not equipped with the perspective of attack patterns that support a threat motive. CTFs are for practice and students. Criminally motivated attack patterns are well worth emulating if they support threat patterns that are likely to happen, based upon intelligence sources. A threat model provides a good scope of adversarial exercises to attempt and exemplify threat probability.

7. Residual Risk Analysis: A risk-centric approach centers on risks that will have the greatest impact and are the most likely to occur. Exploits that work against application components may help to substantiate risk levels simply by the fact that a PoC (proof of concept) was feasible and tied to a qualified vulnerability.

Addressing PoCs that work realize impact levels identified by Stage I is how threat models serve as an excellent blueprint for a multitude of security, development, and IT disciplines – all from a remediation point of view.

Preventative, Detective, and Reactive Security

In security, there is always a deficit of time. Blueprints help to focus or refine efforts for where to dedicate resources for preventative, detective, and reactive measures.

Mapping out what’s most important to what is likely, based upon a collaboration of threat analysis, application decomposition, and exploitation results are some of the key points that PASTA emphasizes as a threat modeling methodology.

If you are interested in learning more about risk-centric threat modeling, download our guide on the 7 stages of PASTA to understand how to leverage them for improved application risk assessments.