Threat modelling

Before an attacker does

Shard Garden now has chat, player-made levels and a shop. Each one is a new way in for someone who wants to cause harm.

A threat model is the team thinking like an attacker before an attacker does. OWASP's guide builds it on four questions.

Four questions

Every threat model answers:

• What are we working on?Draw the system: its parts and where data goes.
• What can go wrong?List the threats, part by part.
• What are we going to do about it?Pick an answer for each threat.
• Did we do a good enough job?Check the model against what actually shipped.

Draw the flows

OWASP: "DFDs visually model a system, its data flows, and interactions with external entities." A data flow diagram shows "trust boundaries, data flows, data stores, processes, and the external entities", which "often represent possible attack points."

A trust boundary is where data from someone the studio doesn't control comes in, like a player's phone talking to the server.

STRIDE

Microsoft sorts threats into six kinds, one per letter:

• SpoofingUsing "another user's authentication information".
• Tampering"The malicious modification of data."
• RepudiationUsers who "deny performing an action" with no way to prove otherwise.
• Information disclosureData seen by people "not supposed to have access to it".
• Denial of serviceAttacks that "deny service to valid users".
• Elevation of privilege"An unprivileged user gains privileged access".

Four answers

For each threat, OWASP's guide lists four answers:

• Mitigate"Reduce the likelihood that the threat will materialize."
• Eliminate"Simply remove the feature or component that is causing the threat."
• TransferGive the responsibility to another party, by contract.
• AcceptLive with the risk, as a decision the team writes down.

Every feature, every time

Remy's design docs have a threat model section, updated when a feature changes. After launch, Priya asks the fourth question again.

Bolt says: Next: passkeys for every player.