2 min lesson
Threat-model a system live
Explain the order in "Threat-model a system live", then say how you would verify the result.
Step 1 of 3
The onsite threat-modeling round hands you a prompt and a whiteboard and watches how you reason about trust. The two prompts most aligned to this role: design just-in-time cloud access or design a safe agent-execution sandbox. Pick one, set a 30-minute timer and produce trust boundaries, attacker goals and systemic mitigations.
There's no diagram tool in your head, so work the structure explicitly. A threat model is four questions in order: what are we building, what can go wrong, what do we do about it and did the mitigations hold. Most candidates jump to mitigations and skip the boundaries - the boundaries are where the score is.
Learn more
Advanced table
Worked example: just-in-time cloud access
Worked example: just-in-time cloud accessTrust boundaries and the controls that fit
- Trust boundary
- Engineer → cloud IAM
- Attacker goal
- Use standing admin creds found on a laptop
- Systemic mitigation
- No standing access; JIT grant, scoped role, auto-expires in hours
- Trust boundary
- Approval flow → grant issuance
- Attacker goal
- Self-approve or replay an old approval
- Systemic mitigation
- Approver ≠ requester; grants are single-use and time-boxed
- Trust boundary
- Granted session → cloud APIs
- Attacker goal
- Pivot from one service to the whole account
- Systemic mitigation
- Role scoped to the one resource/action; deny by default
- Trust boundary
- Audit → detection
- Attacker goal
- Act without leaving a trace
- Systemic mitigation
- Every grant + API call logged immutably, alert on anomalies
| Trust boundary | Attacker goal | Systemic mitigation |
|---|---|---|
| Engineer → cloud IAM | Use standing admin creds found on a laptop | No standing access; JIT grant, scoped role, auto-expires in hours |
| Approval flow → grant issuance | Self-approve or replay an old approval | Approver ≠ requester; grants are single-use and time-boxed |
| Granted session → cloud APIs | Pivot from one service to the whole account | Role scoped to the one resource/action; deny by default |
| Audit → detection | Act without leaving a trace | Every grant + API call logged immutably, alert on anomalies |
Each row pairs a boundary with the control that shrinks blast radius there.
The least-privilege story is the spine of this answer. Standing permissions are a constant liability - every credential that exists is a credential that can leak. JIT flips the default: zero standing access, a scoped grant when you prove you need it, automatic revocation when the window closes. The blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. of a stolen laptop drops from “the whole account, forever” to “one resource, for two hours, fully logged.”