Skip to main content
Learning Center
Python Programming

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

  1. Which five elements make the threat model concrete enough to review?
  2. Why should initial containment be reversible and limited in authority?
  3. Why must destructive recovery remain separate from automatic detection?
Answers
  1. Assets, actors, entry points, trust boundaries, and specific mitigations.
  2. Early incident evidence can be incomplete; reversible containment limits harm while responders preserve evidence and test the hypothesis.
  3. 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.

learning.goultergroup.com

The interactive parts of this page have not loaded. Reading and links still work; reload the page to try again.