Welcome

Hi there, welcome to our third edition of the Threat Modeling Insider.

With this newsletter, we deliver valuable information and curated content about threat modeling that will help you bootstrap or elevate your security knowledge and skills.

The line up of this “TMI” features:

• A guest article by Tony UV, VerSprite “Threat Models as a Blueprint for Attack”
• Toreon presentation: How can you integrate threat modeling in your agile software development?
• Curated resources covering OAuth 2.0, and the threat modeling toolkit
• Tip of the month: “How to overcome diagramming writer’s block”
• Updates on upcoming Toreon training sessions

Guest article by Tony UcedaVelez, CEO & Founder at VerSprite

The previous phrase makes no sense to me either. However, this is a growing misconception among those just coming into the practice of application threat modeling. The fact is that threat modeling could be reworded as 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, modeling threats was very much the objective in many of the military uses that predate AppSec / 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 the blatantly obvious question: ‘what threats could | do affect my application?’

Builders as Breakers vs. Breakers with Builders

The same people seeking a Threat Free diet in their threat models will argue against the idea that attack-centric threat models are overstated.” The fact is, in AppSec, 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 builders of applications are not consumed with as part of their software development roles. 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 the two groups collaborating. In doing so, breakers can illustrate threats within a threat model that 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 – to look at applications through the lens of an attacker and to promote a collaborative threat modeling process amongst developers, security champions, SOC analysts, systems engineers, architects, pen testers, and risk professionals.

The idea behind PASTA is that a team responsible for an application’s security posture can work collaboratively to consider threats against a target application. As such, a list of threats, substantiated by industry sources as well as alert data within the application infrastructure, can help anchor any threat model. 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 be tied to what impact the application has to the business. The 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 the inherent risks related to confidentiality, integrity, availability, or regulatory compliance are. One great value to of risk-centric threat models is that they align to the reality that most organisations do not have the means to reach a 0-risk threat model. As a result, it’s better to focus on the threats that are going to most greatly affect the business via the subject application.
2. Technology Scope: You can’t defend what you don’t know. This simple adage holds true and is obviously 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 define the scope of what may be attacked. It defines an initial outline of what would be good to test for in subsequent stages as well as what preventative hardening measures to take.
3. Application Decomposition: This step maps the interoperability amongst application components. Data flow diagramming (DFDs) is a key output from this PASTA stage as it helps contextualize data flows and call flows between components identified in Stage 2. This stage also helps unravel what implicit trust may exist between application trust boundaries and amongst application components. As a blueprint, decomposing the application helps test abuse cases across trust boundaries during a pen test. Conversely, on the design side, data flows can reveal where to apply improved security architecture measures.
4. Threat Analysis: Going back to the opening remarks, here is where an application threat model can actually consider threats. PASTA makes threat modeling logical by incorporating two information threat sources.Threat intelligence sources reflect threat patterns affecting industries/ sub-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 substantiate exploitation activities that could be attempted against the application.
5. Vulnerability Analysis: Vulnerability is a variable in the risk equation. We substantiate possible threats in stage four and now 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 teams. The blueprint opportunity here is that instead of mining a sea of vulnerable data that comes from standard, isolated operations, a risk centric threat model can contextualize this data to identify the most relevant operations 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 are most impactful and most likely. Exploits that work against application components may help 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 1 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.

In security, there is always a deficit of time. Blueprints help 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.

Tony UcedaVelez, CEO & Founder at VerSprite

OAuth 2.0 threat model and security considerations

Stuck while creating a model of a system? Need some inspiration? Remember that a good model is all about efficient communication!

Find someone who has detailed knowledge on the usage scenarios that the system supports (such as a functional analyst or product owner), and have them walk you through them. While they are stepping through the scenarios, highlight the relevant elements on your model. If you can illustrate their story with your model, the model has a good level of abstraction.

On the other hand, if they are talking about payment transactions, order confirmations, and shipping notifications, while your model only has VPNs, firewalls, and REST requests, you might want to rethink your model’s abstraction level. Use the scenarios as inspiration!

Bonus tip: You can also use the previous approach to validate the completeness of your model!

• Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling at OWASP Global AppSec, Tel Aviv, Israel (27-28 May 2019)
• Hands-on Threat Modeling and tooling for DevSecOps at O’Reilly Velocity, San Jose, USA (10-11 June 2019)
• Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling at Black Hat, Las Vegas, USA (3-8 August 2019)
• Offensive Whiteboard Hacking for Pentesters training at HITB, Singapore, (26-30 August 2019)
• Offensive Whiteboard Hacking for Pentesters training at HITB, Dubai, UAE (12-17 October 2019)
• Hands-on Threat Modeling and tooling for DevSecOps at DevSecCon, London, UK (12-13 November 2019)

Want to learn more about Threat Modeling training? Contact us, so we can organize one in your neck of the woods.

We aim to make this a community driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.

Kind regards,
Sebastien Deleersnyder
CEO, Toreon