Operations and Security
Threat Model and Incident Project
Complete an advanced release review by mapping trust boundaries, abuse cases, detection, containment, and recovery.
Lesson 6 of 6 in the recommended order · About 25 min (estimate)
On this page
Outcome
Produce a concise threat model and an incident runbook with tested decision points.
Why it matters
At this level, code is judged by how safely it changes under load, failure, and team ownership. The technique in this lesson makes an important boundary visible enough to test and review.
Concept
A useful threat model names assets, actors, entry points, trust boundaries, and mitigations. A useful runbook starts with signals, limits authority, preserves evidence, and separates reversible containment from destructive recovery.
Read the code
def classify(signal):
if signal["auth_failures"] > 100 and signal["accounts"] > 20:
return "credential-attack"
if signal["errors_5xx"] > 25:
return "service-regression"
return "observe"
cases = [
{"auth_failures": 150, "accounts": 30, "errors_5xx": 0},
{"auth_failures": 2, "accounts": 1, "errors_5xx": 40},
]
print([classify(case) for case in cases])
Read from the public behavior inward: identify the input boundary, the decision, and the observable result before studying syntax.
Predict the output
Predict the exact output before running the example.
Check your prediction
It prints ['credential-attack', 'service-regression']. The classifier produces a decision label, not an irreversible action.
Modify the code
Change one valid input into the nearest invalid or overloaded case. Write down which layer should reject it and what the caller should observe.
Review the change
Keep the failure at the narrowest boundary that owns the rule. Preserve a stable return value or exception contract so callers do not need to inspect implementation details.
Debug the bug
An incident script that deletes or restores automatically collapses detection and owner approval into one step. Keep destructive recovery behind an explicit decision.
Try it yourself
Complete the focused implementation and run its deterministic checks.
Loading this exercise…
Practical challenge (optional)
Write a threat model for the course platform and rehearse one credential-abuse and one bad-deploy scenario using synthetic evidence only.
Sign in to track your progress on this exercise.
AI collaboration
Checkpoint
- Which five elements make the threat model concrete enough to review?
- Why should initial containment be reversible and limited in authority?
- Why must destructive recovery remain separate from automatic detection?
Answers
- Assets, actors, entry points, trust boundaries, and specific mitigations.
- Early incident evidence can be incomplete; reversible containment limits harm while responders preserve evidence and test the hypothesis.
- Detection can be wrong. Deletion or restoration changes evidence and availability, so an authorized owner must make that decision explicitly.
Sign in to track your progress on this exercise.
Summary and next step
You made the boundary explicit, predicted its behavior, tested a deterministic implementation, and examined its failure mode. Continue to the next lesson to combine this technique with a wider application or production constraint.