SEC-101 Week 2: Threat Modeling I

STRIDE threat categories. Attack trees. The data flow diagram. DREAD as historical context. Lab 2: STRIDE sketch on the Week 1 system.

Reading (~30 min)

Read the OWASP Threat Modeling Cheat Sheet (owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet). Focus on the four-question model: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job? These four questions are the shape of every threat model you will write.

Lecture outline (~1.5 hr)

Part 1: Why threat modeling before tools (20 min)

The security industry has hundreds of tools, dozens of scanning frameworks, and a constant flow of new CVEs. Students who skip threat modeling go straight to "run the scanner and see what lights up." That approach finds known patterns but misses design-level failures, and it generates noise that drowns the signal.

Threat modeling inverts the question. Instead of "what does the scanner find?" the question is "what could go wrong, for whom, under what assumptions, and how bad would it be?" A threat model produces a prioritized list of things worth defending. The scanner (in PEN-101) tests whether the defenses worked.

The three artifacts of a threat model:

1. A data flow diagram showing what data moves where and under whose control.
2. A trust-boundary map showing which parts of the system you control versus which are outside your control.
3. A threat enumeration listing what could go wrong at each component and flow.

Part 2: STRIDE (40 min)

STRIDE is a mnemonic for six threat categories, created at Microsoft in the late 1990s and still in active use. Each category maps to a violated security property.

Walk through the mnemonic on the whiteboard (or in a slide). Then apply STRIDE to a simple example: a user-login flow.

The login flow as a data flow diagram: browser -> HTTPS -> web server -> session check -> database. Each arrow and each box is a potential threat surface. Walk through each STRIDE category against each element:

• Spoofing: can an attacker spoof the user's identity? What stops them? (Password. What if they stole it? Session token. What if they replayed it?)
• Tampering: can the session token be modified? What stops it? (Signature or server-side storage.)
• Repudiation: if the user claims they didn't log in, can the server prove they did? (Audit log with timestamp and IP.)
• Information disclosure: can an attacker read the session token in transit? (TLS. What if the TLS cert is untrusted?)
• Denial of service: can an attacker lock the account or exhaust the login server? (Rate limiting. What if there is none?)
• Elevation of privilege: can the user escalate from "user" to "admin"? (Authorization check on the server, not the client.)

Part 3: Attack trees (20 min)

An attack tree is a tree diagram where the root node is the attacker's goal and the child nodes are the means to reach it. AND nodes require all children to be satisfied; OR nodes require only one.

Example goal: "Compromise a user account." Top-level OR branches:

• Steal the password (OR: phishing / credential stuffing / keylogger)
• Steal the session token (OR: network interception / XSS that steals the cookie / server-side session store breach)
• Break the authentication logic (OR: bypass the check / exploit a logic bug in the password-reset flow)

Attack trees help identify paths the designer didn't think about. A system with strong passwords but no rate limiting on password-reset flows has a whole branch of the tree unmitigated.

Part 4: DREAD (historical) (10 min)

DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) is a scoring model Microsoft used alongside STRIDE in the early 2000s and later deprecated. It is worth knowing as historical context because you will encounter it in older papers, blog posts, and some organizations' internal processes.

The problem with DREAD: the five dimensions collapse to a single numeric score that implies false precision. Two analysts looking at the same vulnerability score it differently because the scale (1-10) has no ground truth. Modern alternatives (CVSS v3.1, which you will use in Week 11) break the problem down more carefully. DREAD is acknowledged for completeness; CVSS is the tool SEC-101 teaches.

Lab exercises (~1.5 hr)

Lab 2: STRIDE sketch (graded)

See labs/lab-2-stride-sketch.md for the full lab.

Take the system you chose for Lab 1 and apply the STRIDE mnemonic to it. This is a lighter version of Lab 6 (full threat model with diagram); the goal here is to practice the vocabulary before the full exercise.

Independent practice (~5 hr)

• Reading (1 hr): Read OWASP Juice Shop's "Hacking Instructor" introduction page (if available) OR the project README at github.com/juice-shop/juice-shop. You won't use Juice Shop until Week 6, but reading the README now shows you what a deliberately-vulnerable application looks like from the outside.
• picoCTF spine (3 hr): Continue in General Skills and begin Forensics. Aim for at least 3 challenges. A beginner Forensics challenge like file-type identification or simple steganography is a good target. Document your approach even when you don't solve.
• Reflection (1 hr): Write the prompts below.

Reflection prompts

1. Apply STRIDE to a system you actually use: a smart thermostat, a cloud storage service, a multiplayer game. Which of the six STRIDE categories produces the most threats for your chosen system? Why do you think that particular category dominates?

2. Attack trees map to goals, not vulnerabilities. Pick one node from your STRIDE analysis and expand it into a two-level attack tree: the top node is the attacker's goal; the child nodes are the means to reach it. What does the tree reveal that the STRIDE list alone didn't?

3. The DREAD model collapses to a single score; CVSS v3.1 does not. What is the advantage of keeping the dimensions separate rather than collapsing to one number? What information do you lose when you collapse?

Week 2 of 14. Next: Threat Modeling II (trust boundaries, enforcement vs. existence, workshop).