TMI newsletter 3 (25-Apr-2019)

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

Threat Models as a Blueprint for Attack

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

Toreon – threat modeling in your agile software development?

How can you integrate threat modeling in your agile software development? This Toreon presentation explains a practical approach based on the SCRUM methodology.

Threat modeling activities are mapped on the SCRUM process steps, organised by the 4 main questions answered as part of every threat model. Key takeaways are start early, reassess during sprints and validate continuously.

Curated threat modeling content

OAuth 2.0 threat model and security considerations

Threat models come in all shapes and sizes; in the end, the format doesn’t matter, as long as they serve their purpose. One great example is RFC 6819, covering the OAuth 2.0 Threat Model and Security Considerations.

When threat modeling an OAuth 2.0 implementation, there are a lot of things to consider that make it harder  to have a secure implementation. It was only in December last year that we saw Microsoft leaking tokens after a subdomain take over and loosely configured redirect URI. Recommendations are still evolving, as shown by the recently submitted internet draft discussing OAuth 2.0 with PKCE for browser based applications.

So where do you start when trying to map out all the threats after clarifying the used OAuth flow (use the correct one!), processes and dataflows? A great resource to check is RFC 6819 which provides a comprehensive threat model for OAuth 2.0. It goes into much more detail than the security considerations of the OAuth 2.0 RFC 6749. The document starts by listing the assumptions and security features of OAuth and then it describes the threats and mitigations (security considerations). Threats are grouped by protocol structure to help development teams.

A resource that is also a must when discussing OAuth is the book “OAuth 2 in Action” by Justin Richer and Antonio Sanso. The book has an entire section dedicated to OAuth 2 implementation vulnerabilities clearly described and illustrated.

APPSEC Cali 2018 video – threat modeling toolkit

Our key takeaways from this video that might not be apparent upon the first view:
  • Threat modeling is a supporting technique in a secure development lifecycle; it helps security people be more efficient
  • Jonathan is great at the ‘keep what works, throw out everything else’ methodology, a somewhat lean way of thinking about threat modeling
  • Labelling your diagrams is really important to keep things simple but still usable
  • Listen carefully to all the Q&A since there are some really useful tips there
  • Remember, all the content is actually in use now, this is not just some theory
Personal note on diagrams (e.g. data flow diagrams) and arrow directions: the direction of the arrows rarely matters for the security, which becomes clear during the threat discovery (e.g. STRIDE analysis). There is no need to spend a huge amount of time on this. It is better to spend it on analysing and mitigating threats.

Tip of the month: How to overcome “diagramming writers block”?

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!

Upcoming public Toreon trainings

  • 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

Book your seat in our Hands-on Threat modeling course

Do you want to discover everything you need to know about threat modeling? And get concrete tools to implement threat modeling in your organisation? Book your seat in our Hands-on Threat modeling course.

Start typing and press Enter to search

Shopping Cart