The Linux Foundation | 17 November 2017
A guest blog post by Mike Goodwin.
What is threat modeling?
Application threat modeling is a structured approach to identifying ways that an adversary might try to attack an application and then designing mitigations to prevent, detect or reduce the impact of those attacks. The description of an application’s threat model is identified as one of the criteria for the Linux CII Best Practises Silver badge.
Why threat modeling?
It is well established that defense-in-depth is a key principle for network security and the same is true for application security. But although most application developers will intuitively understand this as a concept, it can be hard to put it into practice. After many years and sleepless nights, worrying and fretting about application security, one thing I have learned is that threat modeling is an exceptionally powerful technique for building defense-in-depth into an application design. This is what first attracted me to threat modeling. It is also great for identifying security flaws at design time where they are cheap and easy to correct. These kinds of flaws are often subtle and hard to detect by traditional testing approaches, especially if they are buried in the innards of your application.
Three stages of threat modeling
There are several ways of doing threat modeling ranging from formal methodologies with nice acronyms (e.g. PASTA) through card games (e.g. OWASP Cornucopia) to informal whiteboard sessions. Generally though, the technique has three core stages:
Decompose your application – This is almost always done using some kind of diagram. I have seen successful threat modeling done using many types of diagrams from UML sequence diagrams to informal architecture sketches. Whatever format you choose, it is important that the diagram shows how different internal components of your application and external users/systems interact to deliver its functionality. My preferred type of diagram is a Data Flow Diagram with trust boundaries:
Identify threats – In this stage, the threat modeling team ask questions about the component parts of the application and (very importantly) the interactions or data flows between them to guess how someone might try to attack it. The answers to these questions are the threats. Typical questions and resulting threats are:
| Question | Threat |
| What assumptions is this process making about incoming data? What if they are wrong? | An attacker could send a request pretending to be another person and access that person’s data. |
| What could an attacker do to this message queue? | An attacker could place a poison message on the queue causing the receiving process to crash. |
| Where might an attacker tamper with the data in the application? | An attacker could modify an account number in the database to divert payment to their own account. |
Design mitigations – Once some threats have been identified the team designs ways to block, avoid or minimize the threats. Some threats may have more than one mitigation. Some mitigations might be preventative and some might be detective. The team could choose to accept some low-risk threats without mitigations. Of course, some mitigations imply design changes, so the threat model diagram might have to be revisited.
| Threat | Mitigation |
| An attacker could send a request pretending to be another person and access that person’s data. | Identify the requestor using a session cookie and apply authorization logic. |
| An attacker could place a poison message on the queue causing the receiving process to crash. | Digitally sign message on the queue and validate their signature before processing. |
| Maintain a retry count on message and discard them after three retries. | |
| An attacker could modify an account number in the database to divert payment to their own account. | Preventative: Restrict access to the database using a firewall. |
| Detective: Log all changes to bank account numbers and audit the changes. |
OWASP Threat Dragon
Threat modeling can be usefully done with a pen, whiteboard and one or more security-aware people who understand how their application is built, and this is MUCH better than not threat modeling at all. However, to do it effectively with multiple people and multiple project iterations you need a tool. Commercial tools are available, and Microsoft provides a free tool for Windows only, but established, free, open-source, cross-platform tools are non-existent. OWASP Threat Dragon aims to fill this gap. The aims of the project are:
- Great UX – Using Threat Dragon should be simple, engaging and fun
- A powerful threat/mitigation rule engine – This will lower the barrier to entry for teams and encourage non-specialists to contribute
- Integration with other development lifecycle tools – This will ensure that models slot easily into the developer workflows and remain relevant as the project evolves
- To always be free, open-source (like all OWASP projects) and cross-platform. The full source code is available on GitHub
The tool comes in two variants:
- An online web application – for the web variant the model files are stored in GitHub.
- An installable desktop application based on Electron – the desktop variant stores its model on the local file system.
End-user documentation is available for both variants and, most importantly, it has a cute logo called Cupcakes…
Threat Dragon is an OWASP Incubator Project – so it is still early stage but it can already support effective threat modeling. The near-term roadmap for the tool is to:
- Achieve a Linux CII Best Practices badge for the project
- Implement the threat/mitigation rule engine
- Continue to evolve the usability of the tool based on real-world feedback from users
- Establish a sustainable hosting model for the web application
If you want to harden your application designs you should definitely give threat modeling a try. If you want a tool to help you, try OWASP Threat Dragon! All feedback, comments, issue reports and pull requests are very welcome.
About the author: Mike Goodwin is a full-time security professional at the Sage Group where he leads the team responsible for product security. Most of his spare time is spent working on Threat Dragon or co-leading his local OWASP chapter.
This article originally appeared on the Core Infrastructure Initiative website.