Threat modeling interview questions

Questions and answers

5 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   Walk me through how you would threat model a new feature.

   I start with what we are building and what matters: the assets, the actors, and the data flowing between components, sketched as a simple data flow diagram. Then I mark trust boundaries — every point where data crosses from a less trusted context to a more trusted one, such as browser to API, service to database, or tenant to shared infrastructure. I enumerate threats systematically per element using STRIDE so the coverage is repeatable rather than dependent on what I happened to think of. Each threat gets a rough likelihood and impact, and only the ones above the bar get mitigations, which I write as specific engineering work with an owner. I close by recording what we consciously accepted and what would change that decision, because an unrecorded acceptance is indistinguishable from an oversight.

2. Question 2

   What is STRIDE, and how does each category map to a control?

   STRIDE enumerates six threat categories, each the inverse of a security property: spoofing against authenticity, tampering against integrity, repudiation against non-repudiation, information disclosure against confidentiality, denial of service against availability, and elevation of privilege against authorization. The value is the mapping to control families — spoofing points to authentication, tampering to integrity protection such as signing or validation, repudiation to audit logging, disclosure to encryption and access control, denial of service to quotas and rate limits, and elevation to authorization checks and privilege separation. Applying it per element of the diagram, rather than to the system as a whole, is what keeps it from becoming a vague checklist. It is a prompt for coverage, not a guarantee, and I would say so.

3. Question 3

   What is a trust boundary? Give an example people get wrong.

   A trust boundary is where data or control passes between contexts with different levels of trust, which means everything crossing it must be validated or authenticated on the receiving side. The one teams most often miss is between their own internal services: once something is inside the network people assume it is trusted, so an internal API accepts a user ID from the caller without verifying the caller is entitled to act for that user. Another commonly missed boundary is between tenants in a shared multi-tenant datastore, where the boundary exists only in application code. Naming a missed internal boundary is a strong interview answer because it shows you understand that the perimeter is not the boundary.

4. Question 4

   How do you prioritize the threats you find?

   I rate impact — what an attacker gains and how much data or capability is in the blast radius — against likelihood, which is driven by exploitability, exposure, and whether the attack requires privileges or user interaction. I deliberately avoid pseudo-precise scoring: numeric schemes like DREAD have well-known consistency problems, so I would rather have a defensible three-tier rating with the reasoning written next to it. I also weigh detectability, because a risk we can reliably see is more tolerable than a silent one, and mitigation cost, since eliminating a whole class cheaply beats a costly point fix. Then the residual risk goes to a named owner who accepts it explicitly with a review date.

5. Question 5

   How do you keep a threat model from becoming shelfware?

   By making its output ordinary engineering work: every accepted mitigation becomes a ticket in the team's backlog with an owner, and the model itself lives with the code rather than in a separate document store. I tie a refresh to triggers people already have — a new trust boundary, a new data class, an authentication change, or a major architecture revision — instead of an annual calendar reminder nobody honors. Keeping it small helps most: a one-page diagram plus a short threat table gets updated, while a forty-page document does not. And I would feed the model into detection and test coverage, so the threats we decided mattered are the ones we are actually watching for.