Welcome
Hi there, welcome to our monthly 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 Stephen de Vries, Continuum Security “scaling threat modeling with risk patterns”
- How to use threat modeling as privacy by design technique?
- Curated resources covering threat modeling as code, and MITRE ATT&CK
- Tip of the month: “hi/5 newsletter”
- Updates on upcoming Toreon training sessions
Scaling threat modeling with risk patterns
Guest article by Stephen de Vries, Founder & CEO Continuum Security
One of the pain points of performing threat modeling is having to get a cross functional team of security and developers together. If you’re a startup working on a single product, then a fully manual threat modeling exercise every few weeks is probably practical and cost effective – but that approach can run into problems of scale when there are 500+ products all undergoing continuous modification. If threat modeling is to become an integral part of product development, then this challenge needs to be addressed.
A security champions programme and continuous threat modeling training is one route; another is to create a library of common templates or risk patterns that teams can draw on as a central resource. These two approaches are complementary and not mutually exclusive!
Accuracy vs Time Required
If you’ve been involved in some threat modeling sessions then you’ve probably had the experience that identifying the first batch of threats for any system is usually quick and easy and whoever is manning the white-board has their hands full keeping track of the threats identified by the team. Let’s call this the easy part, and at this stage a big picture view of the architecture is usually sufficient.
Then the torrent of threats inevitably slows down – and the discussion speeds up with more disagreement about what the architecture actually is – and which are real threats worth worrying about. This is the hard part, and to do it well we need to have a:
- clear and accurate view of the architecture
- understanding of the business goals and constraints
- the technical security know-how to identify threats in the architecture
It’s the last point that is usually the constraint in many organisations: a dearth of application security specialists means that security trained development teams often don’t have the experience needed to identify these more advanced threats against the system.
If we were to chart the accuracy of a threat model on the Y-Axis and the time spent on the X-Axis, we’d probably see substantial diminishing returns on accuracy as we spend more time in the threat model. But at the same time there’s an attractive ROI to be harvested in the first half of the curve, where we find many threats in relatively short time. Because they’re well known or even obvious threats against a known architecture.
And it’s this part of the threat modeling activity that we can optimise further by using templates and risk patterns.
Templates & Risk Patterns
Threat Model templates are easy to understand: You threat model a particular type of architecture, like a web payment system once – and then re-use that same template for similar systems in the future. Easy. One way to get started with a broad threat model template for web and mobile applications is to base it on the excellent OWASP ASVS project. This already contains a list of detailed controls that should be applied to different elements in a web/mobile application. Although it’s not a threat model as such, it is a good list of controls and it’s easy to derive the corresponding threats for each control by simply appending: “…because if we don’t…” to every control statement.
The challenge with using these blanket checklists that cast wide nets over broad architectures is that the time for generating the checklist for the specific system you’re modling is short (or near zero – copy and paste is quick and easy), but the time to find out whether the threats apply to your architecture is longer, because many may not be relevant. And if you (as a member of the security team) offload this extra work on your colleagues in the dev teams – you may start spending capital that’s in short supply.
A step up from this is to build smaller templates that apply to more specific parts of different architectures and that can be re-used in different threat models – Excel or copy and paste on a wiki could fill in the tooling here. Mini-templates that apply to specific architectural patterns and use-cases are called Risk Patterns. They are essentially building blocks that can be assembled into a coherent threat model. Where entire Templates are big building blocks, Risk Patterns are smaller and can therefore be matched more closely to the system you’re modeling. Below is an extract of an example Risk Pattern that describes the Threats and Controls for Single Factor Authentication against any Service:
- Scope: Single Factor Authentication against any Service
- Threat 1: Attackers gain access to the system through default passwords
- Control 1: Remove or change default authentication credentials
- Threat 2: Attackers gain access through the use of a brute force password attack
- Control 2.1: Require the use of strong passwords
- Control 2.2: Rate limit the number of authentication requests
- Threat 3: Attackers extract usernames by inspecting the response time of the application
- Control 3: Check that login response times for existing and non-existing usernames cannot be used to determine whether the username exists or not.
- Etc.
By comparing the architecture being modeled and the Scope section of the pre-defined Risk Patterns, we can quickly assemble the patterns into an initial threat model at a very low cost. Note that this is a conscious trade-off between accuracy and cost. Akin to using prefabricated wall units to build a house, instead of building them brick by brick. The resulting model could then determine whether we need to spend more time with manual modeling – or whether the risk profile is such that we don’t need any further architectural analysis.
You’ll notice that the Risk Pattern doesn’t only contain the Threats, but also the applicable Controls! This is a huge time saver and effectively means that you can standardise on the Controls throughout the organisation.
The tooling needed to implement a basic set of re-usable patterns does not have to be sophisticated. A shared spreadsheet or wiki could be a good starting point so that teams can start sharing common elements from the threat models they encounter every day.
Conclusion
Nobody likes doing boring repetitive work. The early stages of many threat modeling workshops are often not very exciting for the modelers, because the threats and controls are generally well-known. By offloading this activity to a set of patterns we can make better use of everyone’s time and spend that expensive human brain power on the really interesting threats that lurk behind custom business logic and architectural edge cases.
Stephen de Vries, Founder & CEO Continuum Security
Toreon – privacy threat modeling and privacy by design
With GDPR is becomes even more important that privacy is integrated in the software development lifecycle. Key takeaway from this Toreon presentation is to adopt a privacy-first best-practice framework: Privacy by Design. This can be achieved by performing threat modeling with privacy risk patterns in mind. Download the full presentation for more details.
Curated threat modeling content
Threat Model-as-Code, Abhay Bhargav, OWASP AppSecUSA 2018
In this talk (delivered at OWASP AppSec USA 2018), Abhay Bhargav explains how to threat model with playbooks, integrates into the Software Development Lifecycle (SDL).
He explains and demonstrates how to produce actionable outputs that can be acted up on with “Automaton” – An Open Source “Threat Modeling as Code” framework, that allows product teams to capture User Stories, Abuser Stories, Threat Models and Security Test Cases in YAML Files (like Ansible).This allows the product engineering team to not only capture Threat Models as code, but also trigger specific security test cases with tools like OWASP ZAP, BurpSuite, WFuzz, Sublist3r, Nmap and so on.
This approach leads to a convergence of Threat Modeling and Security Testing, allowing teams to improve both security testing and threat modeling based on results produced through this framework.
Slides and video are available, as well as (of course) code in GitHub.
Why stop at STRIDE, when you have MITRE ATT&CK™?
Never run out of threats and attack scenarios anymore, with this MITRE knowledge base of adversary tactics and techniques?
MITRE started ATT&CK five years ago as a way to categorize common adversary behavior for adversary emulation and intrusion detection research. The project has grown quite a bit since then.
ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge and is the go-to tool both for the adversary emulation team to plan events and for the detection team to verify their progress. ATT&CK is largely a knowledge base of adversarial techniques — a breakdown and classification of offensively oriented actions that can be used against particular platforms, such as Windows.
As such it is an excellent source of potential threats to evaluate when you do your threat modeling. Use the ATT&CK Matrix which visualises the tactics and techniques to identify if you have adequate defensive coverage in your threat model (where applicable).
Tip of the month: hi/5 newsletter
Get a weekly digest with five security articles that are worth your time.
This is the gist of hi/5 newsletter from Security Journey, which we look forward to every week.
Warning: this will not help you with your newsletter addiction 🙂
More information and registration here.
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)
- Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling at OWASP AppSec Day 2019, Melbourne, Australia (28-31 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