Skip to main content

Threat Model and Security Clinic

This is a hands-on session on the capstone repo. No reading substitutes for actually running STRIDE against your own diagram, scanning your own code, and diffing your own IAM.

Retrieval Prompts​

  1. State each letter of STRIDE and what it covers, in your own words.
  2. Why does STRIDE yield more per hour spent on trust-boundary flows than on internal flows?
  3. What three sub-problems does the "secrets, dependencies, supply chain" policy cover?
  4. Define RPO and RTO and give one sentence that distinguishes them.
  5. What is the experiment that proves a role is least-privilege rather than just narrow-looking?

Compare and Distinguish​

  • STRIDE vs a security audit
  • pinned dependency vs scanned dependency
  • secret in .env vs secret in a secrets manager
  • managed policy vs narrow inline policy
  • "same-account snapshot" vs "cross-account copy"

Common Mistake Check​

  1. "We ran STRIDE but couldn't find gaps, so we're fine."
  2. "Our .env has all the secrets; Git won't commit it by accident."
  3. "AmazonS3FullAccess is easier; we'll tighten it later."
  4. "We enabled RDS backups, so we're backup-ready."
  5. "CI uses Action: *, Resource: * because it deploys a lot of services."

Mini Application​

Part A -- STRIDE Pass (60 min)​

  1. Draw your capstone's data-flow diagram. Mark trust boundaries.
  2. Pick the one flow crossing the highest-value boundary.
  3. Fill a six-row STRIDE table: mitigated / gap / accepted -- with evidence.
  4. Pick one real gap. Walk it end-to-end:
    • threat -> evidence -> mitigation -> detection -> residual -> deployed
  5. Commit the worksheet and the walk to library/raw/threat-model.md.

Part B -- Secrets, Dependencies, Supply Chain (60 min)​

  1. Run gitleaks detect and trufflehog filesystem . on your repo. Remediate every finding.
  2. Move at least one secret from .env to your secrets manager. Verify the runtime fetches it via role.
  3. Add pip-audit / npm audit / cargo audit to CI with a HIGH/CRITICAL fail threshold.
  4. Enable signed build provenance (GitHub Attestations or cosign attest) for one artifact.
  5. Commit library/raw/security-policy.md as a one-page policy.

Part C -- Least-Privilege Diff (60 min)​

  1. Pick one runtime identity with a suspect policy.
  2. Record its current effective permissions.
  3. Replace with a narrow inline policy of only the actions and resources you think it uses.
  4. Deploy to staging. Record what breaks.
  5. Widen one permission at a time, each scoped as narrowly as possible.
  6. Commit the before/after diff to library/raw/iam.md.

Part D -- Backup Restore Drill (60-90 min)​

  1. Document RPO and RTO in library/raw/recovery.md.
  2. Restore yesterday's snapshot into a new DB instance.
  3. Run a canary query on both prod and the restored instance; diff.
  4. Record total elapsed time. If it exceeds RTO, either invest in faster restore or loosen RTO with rationale.
  5. Log issues found and convert each into a runbook update.

Evidence Check​

  • STRIDE worksheet with at least one letter walked to a deployed mitigation
  • no secrets found in the repo; at least one secret now loaded from a manager
  • CI scans dependencies and fails on HIGH/CRITICAL
  • at least one artifact carries signed build provenance
  • one IAM role was tightened, something broke, and widening is committed with a diff
  • library/raw/recovery.md contains a dated restore drill log with timings and issues found