When I join projects as a security consultant and ask about the threat model, the answer is often: “We’ve got that covered! We’ll carry out the penetration test just before go-live.” Whilst penetration tests are carried out shortly before a project goes live, a threat model is conducted right at the start, during the design phase. The advantage of this is that conceptual weaknesses are identified right from the start. A security vulnerability that would otherwise require an enormous amount of effort to rectify can be addressed. This article explains what a threat model is and how it can significantly reduce the risks associated with your applications.
What is threat modelling?
Threat modelling addresses the question: what could actually go wrong? As a rule, developers and product owners tend to focus on how a feature works in the best-case scenario. Traditionally, acceptance criteria in user stories are specified by describing what users expect. For example, if I can upload an avatar image in a user story, then one acceptance criterion is that my new avatar image is subsequently displayed in my profile. But what if a malicious attacker uploads not an image as an avatar, but malware – such as a web shell? How would the system react in that case? A threat model is therefore about considering in advance everything that could go wrong and then devising appropriate countermeasures. As Adam Shostack, one of the founders of threat modelling, once said: “What can possibly go wrong?”
The major advantage of this approach is that potential IT security risks can be identified and factored in as early as the design phase of a software project. At this stage, these issues are usually much easier and more cost-effective to resolve.
How do I go about creating a threat model for my project?
When considering a new feature and asking yourself “What could actually go wrong?”, it’s important to set aside the thought “Why would users do something so absurd?” You have to realise one thing: If an IT system can be used incorrectly or in a faulty manner, then sooner or later someone will do just that. That’s Murphy’s Law. It doesn’t even have to involve criminal intent; it can simply happen by accident – a so-called ‘fat-finger’ error.
However, for larger software projects, it makes sense to approach threat modelling in a more structured and organised way. There are various elaborate and, in some cases, academic approaches to this, such as PASTA or OCTAVE. However, these frameworks involve a relatively significant amount of effort. This makes sense when developing software for, say, an aeroplane or an X-ray machine. For an online shop, however, this approach feels rather like using a sledgehammer to crack a nut. On top of that, such threat models are often produced externally. This means there is a group of security experts who review the design documents and, as a result, hand over a document containing the threat model. An example that illustrates this very well comes from ETH Zurich. There, security researchers analysed the Threema messaging app: ‘Three Lessons From Threema: Analysis of a Secure Messenger’. The problem with such a document is that, whilst security experts understand it perfectly, developers – let alone product owners – can only grasp it to a limited extent. A document like this often ends up in a drawer with the lofty aim of working through it if there’s any time left at the end of the project. We all know that there’s never any time left at the end of a project.
How do we carry out threat modelling?
Here at iteratec, we’ve had very positive experiences over many years with conducting threat modelling in a workshop. We place great importance on ensuring the group of participants is as diverse as possible. Often, the initial instinct is to send only developers to such a workshop, as they are, after all, the ones responsible for writing secure software. But when it comes to considering everything that could go wrong and how the software might be circumvented, the different perspectives of all stakeholders are particularly helpful. For example, business users often know best how to creatively circumvent processes. We therefore always recommend that, alongside developers, people from operations, specialist departments, project management and so on are also present.
To begin with, we go through the system’s key use cases on a whiteboard. In doing so, we focus primarily on who communicates with whom, which actors interact with the system, and which assets – the ‘crown jewels’ – are processed where. Simply sketching out the big picture offers significant added value, because afterwards it is clear to everyone involved how the system is intended to function as a whole and how the individual components interact with one another. It is not uncommon for us to hear comments such as “Now I understand why you want it this way and why it can’t be done any more simply.”
We then step into the role of a malicious attacker. We consider how we could cause damage from the perspective of a specific actor and formulate what are known as ‘Evil User Stories’. An example of such an ‘Evil User Story’ is: As a database administrator, I extract a copy of the customer database to sell it on the dark web. So either the so-called ‘insider’ or, as is much more often the case, a database administrator has been compromised, and the attacker is operating in that role. When writing the Evil User Stories together, we follow the STRIDE model. The Evil User Stories are then assessed for criticality using the DREAD model.
In the final step, we then define and discuss suitable countermeasures for each Evil User Story developed. This enables the teams to incorporate the countermeasures directly into their backlog, already prioritised.
We usually run these workshops as half-day or full-day sessions with two security experts. In our experience, this approach offers significant added value, as attack scenarios are discussed collaboratively within the team. We also provide explanations to address more in-depth queries. This massively increases awareness and understanding of security risks, in contrast to an abstract document. It is also extremely helpful for the teams to discuss the practical implementation of countermeasures directly with us, the security experts. This ensures that project-specific constraints are taken into account, and countermeasures do not simply end up being shelved as unfeasible.
Curious and keen to develop a threat model for your software project? Please feel free to get in touch.
Do you have any questions or need support?
You can find out more about the possibilities of threat modelling for your business on our website.
Please feel free to contact us or arrange an appointment.
