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

With this newsletter, we deliver guest articles, white papers, curated articles and tips on threat modeling that help you bootstrap or elevate your security knowledge and skills.

Our “TMI” line-up:

• A guest article by Koen Yskout covering “Threat modeling: what are we modeling, exactly?” ;
• Curated resources covering a panel discussion on agile threat modeling and a blog post on how GitHub does threat modeling;
• A Toreon blog post covering 7 key learning principles to create our future threat modeling training;
• Tip of the month: a new threat modeling book by Izar (with 30 days trial access)
• Updates on upcoming Toreon training sessions.

Guest article by Koen Yskout, Research Manager Secure Software Engineering, DistriNet, University Leuven

In this article, I share some thoughts on the use of the word ‘model’ in the context of threat modeling, based on recent research and discussions within our team at DistriNet. I do not have all the answers to the questions I pose, yet I hope that this article triggers some reflection and sets the scene for developing further improvements to threat modeling in practice.

Models

“Essentially, all models are wrong, but some are useful.” While George Box was primarily thinking about statistical models when he wrote this, the idea can be transferred without much problems to other kinds of models, such as models of software and security.

A model is an abstraction, a simplification of reality that allows one to (systematically) reason about the essentials of that which is modeled, while omitting any unnecessary detail. To paraphrase Einstein: a model should be as simple as it can be, but no simpler. To determine if a model is useful and has the right level of simplicity, we thus need to know what it will be used for. That is, the purpose of creating the model must be explicit. This purpose can be described as the reasoning enabled by the model, or more concretely, as the set of questions that can be answered from it.

Threat modeling

Applying this line of thinking to the notion of ’threat modeling’, I begin with a curious observation. Strictly speaking, the name ’threat modeling’ itself implies that we make a model (or an abstraction) of threats that exist in the context of a particular software system. A useful and well-known abstraction in this context are the STRIDE threat types (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege): they describe a set of threat types in a generic manner, focusing on their (undesired) effect, without going into detail of how they could materialize. For example, a spoofing threat could be realized by guessing a password, tampering with session identifiers, or forging IP packets, while the effect remains the same, namely confusing one entity for another. By itself, the set of STRIDE threat types is already an abstraction (or a model?) of the attacker’s capabilities. A threat model (in the literal sense) then boils down to a set of these threats, instantiated in the context of a particular system. But what would be the purpose of such a threat model? Which questions does it enable us to answer?

An obvious question that can be answered is `which threats exist for this system?’. While that is indeed an essential question for any system, it is not the threat model itself that is used to answer this question. Rather, this question must already be answered during the construction of the threat model: because the threat model contains threats, they must already be identified while the model is being built; they are not found by reasoning on the threat model itself.

System modeling

So, what would be a model that does allow us to answer the question which threats exist for a system? A natural candidate is a model of the system that, through some reasoning procedure, yields threat instances. Models of a software system are commonly known as the software’s architecture or design. In a practical threat modeling context, the system architecture is often modeled as a Data Flow Diagram (DFD), which uses a simple language to describe the system at a very abstract level. A systematic reasoning procedure to create a threat model based on this system model consists of iterating over the various elements of the system model and investigate possible (STRIDE) threats related to each element.

Because of the high abstraction level of DFD’s, however, such a system model omits many details of the system — including security-relevant information. It can thus be expected that actual threats will be missed and irrelevant threats will pop up. We more extensively discuss several benefits and drawbacks of data flow diagrams for threat modeling in one of our recent papers[^1]. Here, we zoom in on two options for addressing this problem.

In the first option, the resulting threat model is manually improved by means of expert knowledge, experience and judgment. However, doing so admits defeat with respect to Einstein’s criterium for the system model’s simplicity. Indeed, it embraces the fact that the system model is too simple and that additional knowledge (outside of the system model) is necessary. The limits of the system model have been reached, and it becomes very hard to make progress towards better (systematic and reproducible) threat elicitation approaches, assuming that such an approach should only be grounded in reasoning about a model of the system, of course.

The second option is to change the system model by adding more information (but not too much, either). The required information is dictated by the threats that need to be found through reasoning on the system model. Consider spoofing, for example. It can be defined as a mismatch between the actual and perceived identity of some entity. To find spoofing threats, the system model must somehow include information about the identity of the entities, both the actual and perceived ones, as well as the contact surface between entities. For elevation of privilege threats, identities are less important, but the notion of privileges (as well as privilege boundaries) needs to be part of the system model.

It is not required that a single system model incorporates all these aspects simultaneously (nor that such a model should resemble a DFD). It would be perfectly acceptable to have a system model that has exactly the right level of simplicity for detecting potential spoofing threats, yet that is totally inadequate for detecting elevation of privilege threats. Every model must be useful for something, but not for everything. A small nuisance, though, is that we do not yet know the best way to express these models, nor how to extract the relevant information from a software system. These are still areas of active research, which our research group is strongly interested in.

The purpose of a threat model

I would like to revisit one point, namely: we’ve seen that the purpose of a threat model is not to answer the question which threats exist. But then what is the question that it should answer? Given a set of threats for a system, it makes sense to start reasoning about which threats should be mitigated, and how. Hence, the threat model will be used to answer questions such as ‘which are the most important threats to address first?’, and ‘which threat(s) would a certain migitating control defend against?’. Note that each of these questions requires more information than just the set of threats, for example their associated impact or risk, and their relation to mitigating controls. Hence, just like system models, threat models should include the right information for answering the questions that are asked about them. Again, we unfortunately do not yet have a common, structured language that enables us to describe and exchange such threat models.

In conclusion, the term ’threat modeling’ is often used as an aggregate term for all involved models and processes. By simply focusing on the term ‘model’, and the purpose associated to each model, we were able to untangle different aspects of threat modeling. Eventually, the union of all involved models should enable systematic reasoning about the four threat modeling questions[^2]: (1) what are you building? (2) what can go wrong? (3) what should you do about that? and (4) did you do a decent job? Hence, threat modeling inherently deals with multiple models, and it’s important to keep in mind that each of these models is an abstraction that must be carefully vetted in terms of its purpose and simplicity. Because we currently do not have the languages to express threat models, the first research challenge in our recent paper[^3] is therefore aimed specifically at developing a reference model for threat modeling. If you are interested in following up or collaborating on this, or have particular ideas, insights or concerns to share, feel free to drop us a line!

[^1]: Sion, Laurens; Yskout, Koen; Van Landuyt, Dimitri; van den Berghe, Alexander; Joosen, Wouter. (2020). Security Threat Modeling: Are Data Flow Diagrams Enough? IEEE/ACM 42nd International Conference on Software Engineering Workshops (ICSEW’20).

[^2]: Shostack, Adam. (2014). Threat modeling: designing for security. Wiley.

[^3]: Yskout, Koen; Heyman, Thomas; Van Landuyt, Dimitri; Sion, Laurens; Wuyts, Kim; Joosen, Wouter. (2020). Threat modeling: From infancy to maturity. International Conference on Software Engineering – New Ideas and Emerging Results (ICSE-NIER’20).

Koen Yskout, Research Manager Secure Software Engineering, DistriNet, University Leuven

Panel Agile Threat Modeling

How GitHub threat models

What will surprise absolutely no one, is that COVID-19 had a major impact on physical training courses throughout the world, including ours. We are currently taking stock of our existing training content and will migrate it to an online learning and collaboration platform. Read our latest threat modeling blog post on how we apply 7 key learning principles to create our future threat modeling training.

Izar Tarandach and Matthew Coles recently published a new book called “Threat modeling, a practical guide for development teams”.
Here is a quote from Brook Shoenfield describing it: “This is the only book that compares well-known threat modeling techniques for the purpose of delivering secure design. It aligns threat modeling with the way modern software is actually produced.”
O’Reilly provided us with a promotion code for you to get 30 days trail access through this link. You can then directly read the book here.

• Whiteboard Hacking a.k.a. Hands-on Threat Modeling hosted by Toreon  (2 x 4h on 23-24 March, 2021)
• Hands-on threat modeling and tooling for DevSecOps hosted by Toreon  (2 x 4h on 21-22 April, 2021)
• Whiteboard Hacking a.k.a. Hands-on Threat Modeling hosted by Toreon  (2 x 4h on 19-20 May, 2021)

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