Written by Süleyman Yilmaz

Threat Composer

Exploring the parallels between risk descriptions and user stories.

Writing risk descriptions in your threat models is an intricate art that often leaves beginning threat modelers puzzled. In this article, we explore the parallels between risk descriptions and user stories, highlighting convenient templates that aid in accurately describing risks. Discover how a free and open-source tool can revolutionize your approach to threat modeling, including guidelines for self-hosting to ensure complete control.

During threat modeling courses and coaching-sessions, we often see a confusion around properly describing a risk by puzzling together the actor, the threat, the vulnerability, and the impact after materialization. Doing this properly is somewhat of an artform that comes with practice, making it hard for novice threat modelers to create an accurate description.

Analogous to this are (software) business analysts who learn to write user stories, often worded in the following format:

As a {USER_ROLE} I want to {FUNCTIONALITY} so that I can {BUSINESS_GOAL}.

This is of course not the only way to write a user story; more experienced business analysts don’t necessarily use it. It’s merely a convenient and safe template to use for people new to the field of user story writing.

The same technique can be applied to threat modeling, albeit with a different template.

In a search for good ways to teach this skill, we recently came across a free and open-source tool from AWS Labs called “Threat Composer”, which can be found here: https://awslabs.github.io/threat-composer/.

Two variations of risk-description templates exist in this tool to get you started:

A {THREAT_SOURCE} {PREREQUISITES} can {THREAT_ACTION}, which leads to {THREAT_IMPACT}, negatively impacting {IMPACTED_ASSETS}

An example of a completed description could be:

An insider having read-access to the unencrypted network traffic to the login page can observe authentication secrets, negatively impacting the application.

Depending on your threat modeling philosophy, the above attack can obviously be seen as a chain of two events:

Reading the plain text password (mitigation being transport encryption)
Abuse of that credential (mitigation being Multi-Factor Authentication).

When looking to incorporate the “holy trinity of cybersecurity”, being Confidentiality, Integrity, and Availability, a second variation can be expanded to:

A {THREAT_SOURCE} {PREREQUISITES} can {THREAT_ACTION}, which leads to {THREAT_IMPACT}, resulting in reduced {CONFIDENTIALITY_AND/OR_INTEGRITY_AND/OR_AVAILABILITY} of {IMPACTED_ASSETS}

The previous example would then look something like this:

An insider having read-access to the unencrypted network traffic to the login page can observe authentication secrets, which leads to account takeover resulting in reduced confidentiality, integrity and availability of the application server.

This tool runs purely in the browser, using its Local Storage mechanisms. This means the data you entered never leaves your computer unless you export it. Self-hosting this tool is obviously also an option if you want complete control over it. Instructions for doing so can be found here : https://github.com/awslabs/threat-composer