Welcome

Hi there, welcome to our latest 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.

This months “TMI” line-up features:

• A guest article by Fraser Scott on “threat modeling as code” with the threatspec tool.
• Curated resources covering “The Evolution of Threat Modeling” by Phil Zimmermann, and Adam Shostack’s talk at AppSecCali 2019 earlier this year.
• Toreon article: “Setting up efficient threat model meetings.”
• Tip of the month: New community edition released by IriusRisk.
• Updates on upcoming Toreon training sessions.

Guest article by Fraser Scott

In a fantastic talk at AWS re:Inforce this year, Eric Brandwine and Neha Rungta shared an interesting perspective. About 7 minutes into their talk, Eric states that “every security problem is caused by an assumption that was broken”. In other words, security problems violate assumptions. I’d be interested in understanding this better in terms of systems theory, but for now, let’s assume it’s a valid point of view.

If you accept that, then the first job of threat modeling is to make those assumptions visible. Typically we dot that by asking probing questions such as “what if…?” and “what could go wrong?” But merely making those assumptions visible isn’t sufficient. Not even close. It has to keep them visible, throughout the development process, and as the applications and services being threat modeled change and evolve. And it needs to do this as early, quickly and cheaply as possible, without getting in the way. And keeping those assumptions visible still isn’t sufficient. Making them visible has to drive positive change. Typically in threat modeling, this involves identifying and implementing mitigating controls.

There are many approaches to threat modeling, and we see more and more organisations adopt agile threat modeling methods. Complex, fluid organisations that often exist on the edge of chaos, continually evolving and adapting. Yet our approaches to documenting threat models, and architecture in general, hasn’t kept up. Ageing architecture diagrams, out of date within hours of creation, are still very common. Threat modeling an epic during an agile planning session once a month is excellent, but that’s a long time for engineers to carry those assumptions around in their heads.

Consider an alternative approach:

// @connects MyApp:Web to MyApp:FileSystem with Wiki pages written as files to disk
func (p *Page) save() error {
filename := p.Title + ".txt" // @review MyApp:FileSystem Is this safe? Couldn't this potentially expose us to arbitrary file writes?
// @mitigates MyApp:FileSystem against Malicious OS user modifies the Wiki content with Strict file permissions 
return ioutil.WriteFile(filename, p.Body, 0600)
}

This example uses threatspec code annotations. Threatspec is an open-source tool that helps developers capture these assumptions, as well as any other security concerns, decisions and threats. Right at the moment when it matters. In the context that matters. Namely, in the source code. The developer doesn’t have to leave their IDE. The developer doesn’t have to leave the code that they’re thinking about and writing, because threatspec captures the relevant information as comments annotating the source code, rather than as separate JSON or YAML files. Then, when the developer wants to take a step back and see the forest despite the trees, they’re able to generate a threat model report for their source code repository. Or even across multiple repositories written in different languages. This way, we enable a new view that stays in sync with the code. And finally, because threatspec allows you to not only capture threats and mitigations, but also describe the relationships between components in the model, it can be used to generate architecture and data flow diagrams dynamically.

Threatspec is under active development and has gone through a significant rewrite recently, so if you’re interested in learning more or even contributing, check out the website at https://threatspec.org. (Also, don’t tell anyone yet, but threatspec has also just been approved to become an OWASP project, so stay tuned.. shh….)

Fraser Scott

Toreon article by Thomas Heyman, Application Security Consultant at Toreon

In our previous instalment of setting up threat modeling in practice, we discussed the stakeholders involved in a typical threat modeling exercise. We concluded with the observation that the time of most parties involved is precious. Inviting everyone for a bunch of threat modeling workshops is therefore far from ideal. Not only is it not cost-effective, but it will also quickly label being invited to a threat model workshop as a “time-waster” and “not relevant”.

So how do we proceed, then? Excellent question! The answer comes in three parts:

1. limit the number of threat modeling sessions,
2. ensure that they are well-scoped,
3. and only invite the relevant stakeholders for each session.

First, the number of threat modeling sessions should be kept to a minimum. At the least, there needs to be one kick-off session, one modeling session, a threat analysis session, and a closing event.

There is a new release of the Community Edition of IriusRisk v2, available for signup at https://community.iriusrisk.com The Community edition allows small teams to create one threat model, at no cost. This means that you can now experiment with a  threat modeling tool that auto-generates a substantial part of your threat model using open standards like the OWASP ASVS and Mobile ASVS.

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