A threat-model generator clears a partner link marked 'private network'. Do you accept the result?
answer
- the report is a conditional statement
- wrong inputs fail silently, not loudly
- private from whom, exactly
- assumptions belong in a written list
- flipping the property wakes threats up
basics
~20 sNo. 'Private network' is an assumption the generator accepted as fact, not something it checked. If the partner shares that circuit with its other customers, the link is untrusted and every threat suppressed by that label comes back.
solid answer
~50 sNo — that result is conditional on an input nobody verified. A generator reasons over asserted properties: someone typed 'private network' on the link, so rules about eavesdropping and tampering on an untrusted channel never fired. The tool has no way to discover that the partner terminates that same circuit for two of its other customers, which means a compromised vendor sits inside the boundary you drew around it and customer data in transit is exposed. My response is to pull the assumption out of the diagram and write it down as an explicit, falsifiable statement with an owner and a way to check it — who else is on this link, who can reconfigure it, what happens if it is wrong. Then verify the load-bearing ones and re-run the model. Assumptions are findings in waiting, and they are where automated output fails silently rather than loudly.
go deeper
Remember that words like private, internal or encrypted in a threat model are claims someone typed, not checks the tool performed. If the claim is wrong, the clean result is wrong with it.
Explain the mechanism: rules fire on asserted properties, so a false property suppresses whole threat categories without any error appearing. Be able to name two or three labels that commonly turn out false.
Demonstrate the working habit — an assumptions list with owners and falsification tests, verification effort aimed at the load-bearing claims, and a re-run when one breaks. Talk about the partner conversation, not just the diagram.
Own how assumptions are governed across many teams: who is allowed to assert a trust property, how those claims are revalidated over time, and how you stop a clean automated report from being cited as an approval in a later review.
## Why this is the hardest limit to see Missing threats are visible in hindsight; **wrong assumptions produce a clean report**. The generator did its job perfectly and the answer is still wrong, because the question it answered was 'given that this link is private, what can go wrong?' rather than 'is this link private?'. Every automated threat-modeling result is a conditional statement. The condition set is the labels and properties in the model: this store is encrypted, this network is internal, this component is operated by us, this identity is authenticated, this partner is trusted. Rules fire or stay silent depending on those conditions. Nothing in the pipeline distinguishes a property someone measured from a property someone assumed on a Tuesday afternoon. ## Working the scenario The link carries data to a partner. Someone drew it as a private circuit and the model treats it as inside a trust boundary, so the flow's confidentiality and integrity threats are suppressed as already handled. A human who has dealt with partner connectivity asks a different question: *private from whom?* The partner is a business with other customers, and it may terminate the same circuit for two of them. Now the boundary you drew has three organisations inside it. The relevant adversary is not an anonymous internet attacker — it is a **compromised vendor or a neighbouring tenant on the shared link**, and the asset at stake is **customer data in transit** plus the integrity of what you send. Notice what has and has not changed. The design is the same. No new vulnerability was introduced. What changed is that a stated fact turned out to be false, and with it the trust boundary moved. Threats that were correctly suppressed become live: eavesdropping, tampering in transit, and spoofing of the far end. ## The practice that catches this **1. Make assumptions first-class artifacts.** They belong in a written list beside the diagram, not as adjectives inside it. A usable entry has four parts: the claim ('the partner circuit is not shared'), who asserted it, how it could be shown false, and what breaks if it is. A claim nobody can falsify is not an assumption, it is a hope. **2. Rank assumptions by how much they carry.** Some suppress nothing; some suppress an entire class of threats. The private-link claim is load-bearing — it is the only thing standing between the flow and three categories of threat — so it earns real verification effort. Verification here is mundane and human: ask the partner, read the contract, look at the circuit order. **3. Re-run when one breaks.** An assumption changing is a model-invalidating event, exactly like a new component. The value of having the model in a tool is that you can flip the property and see which threats wake up, rather than reasoning it out in your head. **4. Say what the report means.** A clean generated report should be reported as 'no rules fired given assumptions A, B and C', never as 'no threats'. That sentence is the difference between an honest artifact and a false assurance that someone will later cite in a review. ## Related failure shapes The same mechanism produces other silent clean reports: a store labelled 'encrypted at rest' where encryption is on the roadmap; a component labelled 'internal' that a support tool exposes; an identity labelled 'authenticated' where the check is advisory; 'operated by us' where a managed service means the vendor's operators have access too. In each case the model is internally consistent and externally false. ## What the interviewer is listening for A weak answer accepts the clean report or, at the other extreme, dismisses tooling as useless. The strong answer keeps both halves: the generator did exactly what it can do, and the input it was given is the part only a human can source. Candidates who have run real reviews reach for the assumptions list without being prompted, and can name the two or three claims in any design that carry the most weight — usually about who else is on a network, who operates a component, and what a shared identity is actually permitted to do.
- What makes a written assumption useful rather than decorative?Four things: a claim stated so it can be shown false, the person who asserted it, a cheap way to check it, and what threats come back if it breaks. 'The partner circuit is not shared with other customers, asserted by the network team, checkable from the circuit order, and if false the flow needs authenticated encryption end to end.' That entry does work; 'network is secure' does not.
- How do you decide which assumptions are worth the effort to verify?By how much each one suppresses. Rank them by the number and severity of threats that go live if the claim is false, and verify the load-bearing few. A claim that only affects a low-value internal flow can stay unverified and documented; a claim that is the sole reason an entire transit path is treated as trusted is worth a phone call to the partner this week.
- The partner confirms the circuit is shared. What changes in the model?The trust boundary moves so the partner and its neighbours are outside it, and the flow is re-analysed as crossing into untrusted territory: eavesdropping, tampering and spoofing of the far end are all live again. The practical response is end-to-end authenticated encryption and integrity checking of the payload, so the link's own properties stop being load-bearing at all.
saying these in an interview costs you the question
- Accepts a clean generated report as evidence of safety
- Treats a label in the diagram as a verified control
- Keeps assumptions in someone's head instead of writing them down
- Says private network means only we can reach it
- Never re-runs the model when an assumption changes