Threat models

A threat model follows the data through a system on a data-flow diagram: where it travels, where it is stored, and who can change it. Each point has its own risk (read on the way, copied from storage, used by the wrong person) and its own defence (HTTPS, hashing and encryption, access control and MFA). One defence doesn't cover them all.

The club app has HTTPS: the padlock is showing. Is it secure?

Your mission: before the club app launches, map where members' data goes and name a defence for every point where it could go wrong.

Engage: Commit to a prediction before you test anything. A wrong guess is fine: it shows you what to look for.
Explore: Try it on the board and compare what happens with your prediction.
Explain: Put a name to what you saw, and why it works.
Elaborate: Use the idea in a new situation.
Evaluate: Look back at your first ideas and what changed.

EngageCommit to a prediction before you test anything. A wrong guess is fine: it shows you what to look for.

Engage: is the padlock enough?

The club app uses HTTPS (the padlock). Which data does that protect?Everything: the stored passwords and the admin page tooOnly data travelling between the browser and the appOnly the photosNothing: the padlock is decoration

ExploreTry it on the board and compare what happens with your prediction.

Explore: defend each point

Was your prediction right?

Try it yourselfYour edits are saved in this browser.

For each point in the diagram, choose what could go wrong and the defence that fits.

Use the board. This ticks when you get there.

ExplainPut a name to what you saw, and why it works.

Explain: follow the data

A threat model follows the data through a system and asks, at each point, what could go wrong and what stops it.

Worked exampleBefore each step, say what you think comes next.

$\text{draw the flow}$ Browser → app → database, plus anyone who can change things (the admin).
$\text{travelling}$ Data on the network can be read on the way: encrypt it (HTTPS).
$\text{stored}$ Data in a database can be copied: hash passwords, encrypt the rest.
$\text{who may act}$ A page that changes data can be used by the wrong person: access control and MFA.
$\text{check}$ Every point has a defence; no single defence covers every point.

Find the mistake

Sam secures the club app. Click the line where it first goes wrong.

ElaborateUse the idea in a new situation.

Elaborate: photos

Try it yourselfYour edits are saved in this browser.

Members can now upload photos. Defend all five points.

Use the board. This ticks when you get there.

ElaborateUse the idea in a new situation.

Elaborate: messages

Try it yourselfYour edits are saved in this browser.

Need a hint?

Is the message travelling, stored, or being opened by someone?

Another hint

Who should be allowed to read a conversation?

The committee wants members to message each other. Threat-model the new feature.

Use the board. This ticks when you get there.

EvaluateLook back at your first ideas and what changed.

Evaluate: look back

The school's canteen app lets parents top up lunch money. Which point needs access control most?Loading the logoShowing opening hoursShowing the menuChanging whose account the money goes to

I can follow data through a system and name a risk and a defence at each point.

For teachers

Students use a data-flow diagram of the club app to name a risk and a defence at each point where data travels, is stored or is changed, then threat-model two new features (AC9TDI10P13 node 1). Defensive and conceptual. A 5E mission lesson. About 45 minutes.

Open the teacher guide: answers, solutions, slides and a worksheet.

Students will be able to

I can follow data through a system on a data-flow diagram.
I can name what could go wrong where data travels, is stored or is changed.
I can match a defence to each point.

Before class

Try the board yourself. The club app is made up.

The one idea: follow the data; each point (travelling, stored, who may act) has its own risk and its own defence.

Typical width: have students draw the data-flow diagram for an app they know (the school canteen, a game) on paper first, then mark the points.

Running the lesson

Engage: ask what the padlock actually means.
Explore: ask which point they defended wrongly first, and why.
Explain: model the three questions on the admin page.
Elaborate: ask what the photos feature added to the diagram.
Evaluate: compare answers for the canteen app.

The hard part (on purpose)

Students pick HTTPS for everything. Ask: is this data travelling right now, or sitting in the database?

When students get stuck

A student thinks HTTPS covers everything (Sam's mistake). Ask: Where is the data at this point: on the network, or in the database? Fix: Each place needs its own defence.
A student confuses hashing with HTTPS. Ask: Is the password moving or stored? Fix: HTTPS on the way, hashing in storage.

Stretch and support

Stretch: Draw the diagram for the canteen app with three actors (parent, school, bank) and defend every arrow.

Support: A card with the three questions: travelling? stored? who may act?

Where it leads

Next: Kinds of weakness.

What each step is for

Engage: is the padlock enough?: Committing to whether HTTPS secures the whole app tests the new move: each point in a data flow needs its own defence.
Explore: defend each point: Students match a risk and a defence to each point of the diagram and find that one defence doesn't fit all.
Explain: follow the data: The teacher models the threat-model questions on one point. Sam trusts HTTPS for everything, the misconception planted after the method.
Elaborate: photos: One change: a new feature adds two points to the diagram, one travelling and one about who may see.
Elaborate: messages: Applying the model to a feature on their own: students place each point and its defence without the earlier diagram.

Now you can

Follow data through a system on a data-flow diagram.
Name what could go wrong where data travels, is stored or is changed.
Match a defence to each point.

Next lesson6. Kinds of weaknessSystems have three kinds of weakness. Software: a flaw in the app's own code (fix: update and test). User: what people do, like weak or shared passwords or being tricked (fix: training, strong passwords, MFA). Supply chain: something the app relies on, like an add-on or library, goes bad (fix: check and update what you rely on). Perfect code alone doesn't make a system safe.

Source: content/systems/cyber/threats/lesson.md