Week 2, Lecture 1 — Threat Modelling

Cybersecurity & Secure Programming

Slot: W2 L1 Content budget: 35 min Embedded interlude: live Optus 2022 unauth API (~5 min) Anchors: Optus 2022, Capital One 2019, Heartbleed Book chapter: 4

Before the lecture

Read Chapter 4 — Week 2, Lecture 1: Threat Modelling in the book PDF (approximately 14 pages, 30 minutes reading time). The chapter opens on the Optus 2022 breach — an unauthenticated public API that returned 9.8 million customer records to an attacker who simply iterated a numeric ID — and uses that single missing access-control check as the anchor for everything that follows: Shostack’s Four Question Frame, DFDs, STRIDE, and the methodology zoo around them.

If you can also find ten minutes for one further read, the Threat Modeling Manifesto (https://www.threatmodelingmanifesto.org/) is 800 words and worth the time — it is the closest thing the discipline has to a shared statement of values.

Slides

Lecture timing

This is a 50-minute nominal slot — realistically 45–50 min of room time. The chapter content runs to about 35 minutes, plus a 5-minute embedded interlude on the Optus 2022 hook, plus 5–10 minutes of slack. Resist the temptation to expand the methodology comparison; the room loses energy fast on a LINDDUN-vs-PASTA tour. The live STRIDE walkthrough on the Moodle DFD is the centrepiece — that is what students remember.

Block Time Notes
Embedded interlude — Optus 2022 unauth API 0–5 min Everyone-on-keyboards on Troy Hunt’s analysis; the rest of the lecture is downstream of this image
The Four Question Frame 5–12 min Project the cycle diagram. Stress that Question 4 is the one teams skip; do not over-explain Q1–Q3
DFDs — four shapes plus trust boundaries 12–20 min Four-minute teach of the shapes; four-minute live build of the Moodle DFD on the board
STRIDE walkthrough on the Moodle DFD 20–35 min Walk all six letters live on Flow 1 exactly as the chapter does. Take threats from the floor for at least two letters
Other lenses — LINDDUN, attack trees, PASTA 35–38 min One slide each. Use the “which lens when” decision aid as the closer. Mention DREAD only to warn against it
Where it fails + the Try This 38–40 min Heartbleed in one sentence (design TM ≠ implementation bug); set the Try This as homework for the W2 practical

Embedded interlude

The interlude is the live Optus 2022 unauth API (~5 min, everyone on keyboards).

URL. Troy Hunt’s analysis: https://www.troyhunt.com/the-optus-data-breach/

Setup. “Open this URL on your laptop. We’ll spend five minutes here — the rest of the lecture turns on what you find.”

Activity.

  1. Have students locate the section describing the unauthenticated, internet-facing API endpoint.
  2. Ask: “What did the Optus engineers fail to ask at design time?”
  3. Take answers. The intended answer is Question 2 of the Four Question Frame — “What can go wrong?” — and specifically the Spoofing / Information-Disclosure question of “who can call this and what do they get?”

Talking points.

  • Roughly 9.8 million Australian customer records exposed.
  • The attacker did not need novel skill — they iterated a numeric customer ID against an unauthenticated endpoint.
  • An access-control check had existed in earlier code, was silently weakened by a 2018 refactor, was rediscovered on the public website in August 2021, and was never propagated to the API.
  • A 30-minute STRIDE pass on the API’s DFD at design time would have surfaced this and forced a decision: authenticate, rate-limit, or accept the risk.
  • This is the lecture’s anchor: TM is not paperwork — it is the conversation that catches news-grade bugs.

Wrap. “Now we’re going to do this systematically — STRIDE on a real data-flow diagram. The Optus engineers had no framework for asking the question. By the end of the hour, you will.”

Common student questions (and short answers)

These come up reliably; have answers ready in case they surface mid-lecture.

  • “Isn’t this just a more formal name for code review?” — No. Code review catches implementation bugs (a missing if, a buffer overflow, a hard-coded password). Threat modelling catches design bugs (an entire endpoint shipped without auth; a trust boundary nobody noticed). Heartbleed is the canonical example — the design was sound; the implementation had a missing length check.
  • “Which letter of STRIDE is hardest to find threats for in a typical web app?” — Usually Repudiation. Useful question because it forces students to articulate why audit logging is a security control, not just an ops control.
  • “Optus had an authentication check in earlier code, and a 2018 refactor silently removed it. Which Shostack question catches that?” — Q4: did we do a good enough job? This is the place to introduce the idea that threat models need to be re-run after refactors.
  • “Could a threat model have caught Heartbleed?” — Trick question. Protocol-level TM did the right thing — RFC 6520 §4 says the malformed heartbeat MUST be discarded silently. Implementation-level memory-safety bugs require fuzzing, static analysis and memory-safe languages, not TM.
  • “How long should a threat-modelling session take?” — For a sprint feature, thirty minutes is plenty. For a full system or a regulated context, half a day. The complaint that “TM takes too long” is almost always a complaint about doing STRIDE-per-interaction on a system that does not warrant it.

End-of-lecture self-check

Optional, formative — not graded. A 2-minute self-check on what the lecture covered. Click an option to see immediate feedback.

Going Further

Annotated reading for students who want to go deeper after the lecture. Every item below is cited in the chapter or is a canonical primary source.

  • Shostack, Adam. Threat Modeling: Designing for Security (Wiley, 2014). The standard reference. Thirty pages will give you the working method; the rest gives you the depth.
  • OWASP. Threat Modeling Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html. One A4 page that maps onto the Four Questions.
  • Shostack, Adam. Elevation of Privilege card game. https://shostack.org/games/elevation-of-privilege. Free, Creative-Commons-licensed, and the fastest way to teach STRIDE to a room. We use it in the Week 2 practical.
  • Threat Modeling Manifesto Working Group. Threat Modeling Manifesto (2020). https://www.threatmodelingmanifesto.org/. Eight hundred words; co-signed by fifteen of the field’s leading practitioners; the closest thing the discipline has to a shared statement of values.
  • OWASP Threat Dragon. https://owasp.org/www-project-threat-dragon/. The cross-platform open-source tool we use for the Week 2 practical.
  • Tarandach, Izar. pytm — A Pythonic framework for threat modeling. https://github.com/izar/pytm. For the threat-modelling-as-code section of the chapter.

← Schedule Next: Week 2, Lecture 2 (coming soon) →