Soatok’s Informal Guide to Threat Models - Dhole Moments

Skip to the content

Search

Search for:

Close search

Close Menu

After a long day of exhausting conversations about Hybrid Post-Quantum Cryptography, random jackasses trying to play gotcha with endpoint attacks against end-to-end encrypted messaging apps, and message board discussions in the wake of dumb politicians pushing more "age verification" bullshit on us all, it’s become abundantly clear to me that the phrase "threat model" is a foreign concept to most people.

Except, y’know, as a buzzword.

Art by Embyr.

For context, this was commissioned during the era of anti-vaccine losers claiming to "do their own research" briefly co-opting the word "threat model" as a buzz word.

I just still find it kind of funny even without this context.

To be up front: If you’re here looking for an academic resource with over 100 citations on how to write a formal threat model document for your new startup which involves multiple blockchains, this probably isn’t the gay furry blog for you. Maybe start with STRIDE and system theory.

But if you’re looking to build an intuition for what questions a good threat model should answer, and you’re starting from zero, you’re probably in the right place.

So let’s talk about threat modeling.

Threat Modeling For Neophytes

Their name is Neophyte, if you didn’t get the joke.

Art: Harubaki

At a high level, don’t overthink this too much.

While a threat model is a formal cybersecurity process that some infosec folks actually specialize in, you can run informal threat models in the design and architecture phases of developing a new product or service and no one can stop you. You might just end up with a better result.

A threat model should, at minimum, answer these basic questions:

What are we even protecting to begin with?

If you can’t answer this, you have a lot of ground work to do.

Who/what wants to harm what we’re protecting?

Hackers, activists, cyber-stalkers, social media harassment networks

Natural disasters / bad karma

Underpaid and overworked employees who get fed up

Idiotic legislatures paid by large corporate lobbyists to pass stupid laws that hurt everyone

Nation State Adversaries!!!!1oneon

How might (2) attack (1)?

Attack scenarios go here

Murphy’s Law goes here

What will we do to prevent (3) from happening?

Murphy’s Law also goes here!

And, like, okay. If you can check those off, you can call your document a threat model in some sense.

However, this is often useless in practice because some crucial details are omitted.

How are the assets (1) related / connected?

Think in graphs, not lists.

Not all targets are equal value.

What assumptions are we making, especially with (4) and (5)?

I’ll say more about this below.

What threats are we deliberately not addressing?

You literally cannot address every possible attack that any person will ever imagine in the unforeseeable future, so don’t pretend to.

Too many people take assumptions (6) for granted, ironically, but it’s incredibly important to be as clear about what your assumptions are.

If one of your assumptions is wrong, then your model is incomplete (at best), or your list of accepted risks (7) needs to be reconsidered.

For example: The Invisible Salamanders attack breaks abuse reporting in some end-to-end encrypted messaging designs, but only if you introduce abuse reporting.

The attack is possible because one of the assumptions that went into the AEAD schemes in question (AES-GCM, ChaCha20-Poly1305) is that there is only one valid key for a given message. The second you introduce multiple valid keys for a given message (or confused deputies for that matter), you’ve gone outside the security guarantees of your algorithm–which, as an attacker, makes for a fun trick.

Being clear about your assumptions allows you to identify your own unknown unknowns. You don’t have to be perfect.

In fact: Threat models are supposed to be living documents, not point-in-time snapshots. Update them whenever you deem appropriate.

High Paw (high five) sticker<br>" data-large-file="https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?fit=512%2C512&ssl=1" src="https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?resize=512%2C512&ssl=1" alt="High Paw (high five) sticker" class="wp-image-1333" style="width:auto;height:256px"/>Art: CMYKat

Example: My Own Work

You may or may not already be aware that I’m working on delivering key transparency to the Fediverse. The work is being tracked on publickey.directory if you’re curious about the state of it after this blog post goes live.

This work began with a specification, which includes a prominently featured threat model.

The threat model is organized into the following sections:

Assumptions (stated up front)

Assets

Actors (both attackers and people we want to protect), given role names

The risks, which have one of four statuses...