A pytm model declares a dataflow encrypted while the real traffic is plaintext. What fails?
answer
- the tool believes whatever you type
- a boolean is cheap to set
- rules match on declared attributes only
- silence, not a warning, is the output
- optimistic drift removes findings
basics
~20 spytm reasons only over what the model asserts. Declaring a flow encrypted stops the disclosure and tampering rules from matching that hop, so the generated report reads clean about a link anyone on the internal network can read.
solid answer
~50 sThe report is confidently wrong, which is worse than having no report. In pytm the threat library matches conditions against declared attributes, so setting a flow's encryption attribute removes exactly the threats you most needed for that hop — and the output looks clean rather than incomplete. This is the signature failure of a source-defined model: a security attribute is one cheap token, easy to set when TLS is merely planned or when TLS terminates at an edge proxy and the internal leg was never modelled as its own flow, and once set it is nearly invisible in a one-line diff. The defences are to default control attributes to the pessimistic value, require the change that flips one to say where the control is enforced, model termination points as real elements, and re-walk the flags when the infrastructure under them changes.
go deeper
Remember that these tools never inspect the running system. They report on what the model file says, so an attribute that is wrong produces a report that is wrong in the same direction.
Explain the mechanism: threat rules are conditions over declared attributes, so setting an encryption or authentication flag stops the matching rules from firing for that element and the finding simply disappears.
Demonstrate how you catch optimistic assertions in practice — ask what evidence backs a control flag, look for hops the logical model collapses, and re-check the flags whenever the underlying infrastructure changes.
Decide the standard: whether unproven control claims may appear in a model at all, what evidence an assertion must carry, and who is accountable when a clean generated report turns out to have described a design nobody was running.
## The failure A source-defined threat model is a set of **assertions**, not observations. Nothing in pytm or threagile inspects a running system. The threat rules are conditions over declared attributes: a rule that would flag interception on a link is written to fire when the model says the link is unencrypted. Declare it encrypted and the rule stops matching. The generated report then contains no finding for that hop — not a warning, not an unknown, an absence. That is qualitatively worse than a missing model. A missing model is obviously incomplete. A report that says nothing about a link is read as saying the link is fine, and it will be cited that way in a design review, in an audit conversation and in the argument about whether a segment needs review at all. The threat you have silenced is real: someone with a foothold on the internal network — a neighbouring workload, a compromised sidecar, an operator on a flat segment — can read or modify the traffic on that hop. ## Why the false assertion happens It is rarely dishonesty. The recurring causes: - **Aspirational modelling.** TLS is on the roadmap for that link, the engineer models the target state, and the target state never arrives. - **Collapsed hops.** The logical model draws one edge from client to service. In reality TLS terminates at an edge proxy, an ingress or a mesh gateway, and the remaining leg to the workload is plaintext. The model has no element for the terminator, so the plaintext leg does not exist as a flow that could be flagged. - **Copy-paste.** A new element is cloned from an existing one and inherits its attributes wholesale. - **Attribute defaults.** If a control attribute defaults to the optimistic value, every element anyone forgets to think about ships as protected. - **Cheap to write, invisible to review.** Adding a link is a visible block in a diff; flipping one boolean on an existing link is one line, and reviewers scanning for structural change scroll past it. ## Two directions of drift, and which is worse **Structural drift** — a hop, a store or an external party exists in production but not in the model. The report is silent about something it never knew existed. Bad, but discoverable: walk the diagram against the deployment and the missing box is the thing nobody can point to. **Assertion drift** — the element is present and its control attributes claim more than reality delivers. This is worse, because the tool actively produces a positive-looking result about a real exposure. There is no gap to notice; there is a clean line where a finding should be. ## Reducing it You cannot eliminate it — the model is a human statement about a system, and statements go out of date. You can make optimistic statements expensive: 1. **Pessimistic defaults.** An unstated control is absent, never present. Forgetting should produce noise, not silence. 2. **Evidence with the flip.** The change that sets a control attribute names where the control lives: the terminating component, the config that enforces it, the policy that requires it. A reviewer can then check one concrete thing instead of taking a boolean on faith. 3. **Model termination as an element.** If TLS ends at a proxy, the proxy is an element and the leg beyond it is its own flow with its own attributes. Most encryption assertions are wrong only because the hop that would falsify them was never drawn. 4. **Tie flags to the change that would break them.** When a load balancer, mesh or network path changes, the model's transport assertions for that path are stale by definition and should be re-checked as part of that work. 5. **Periodic walk-through.** Sit with the people who operate the system and read the model aloud against what is actually deployed. This is the only step that catches assertions nobody thought to doubt. 6. **Separate reviewers for control attributes.** Structural changes can be reviewed by the team; claims about controls benefit from someone whose job is to disbelieve them. ## How to say it in an interview The framing that lands: *the model is an input, not a measurement.* Generation gives you consistency between the model and its output, and nothing at all about the relationship between the model and reality. A clean report from a threat model as code means the declared design has no known-shape problems — which is a statement about a document.
- Which is more dangerous — an element missing from the model, or a control attribute that claims more than reality?The false control attribute. A missing element leaves a gap that surfaces the moment someone walks the diagram against the deployment. A false attribute produces a positively clean result for a link that is genuinely exposed, and nothing about the output invites doubt. Structural gaps get found by inspection; optimistic assertions get quoted as evidence.
- Why is a plaintext internal hop especially easy to miss in a source-defined model?Because models are usually drawn at the logical level, client to service, while the real path terminates TLS at an edge proxy, ingress or mesh gateway and continues in the clear. The model has no element for the terminator, so the exposed leg is not a flow the rules can evaluate. Modelling the termination point as its own element is what makes the hop visible.
- How would you make a control assertion in the model harder to set falsely?Default it to the unprotected value so omission is loud. Require the change that sets it to name where the control is enforced, so a reviewer has something concrete to check. Route control-attribute changes to a reviewer whose job is to disbelieve them, and re-open the assertions for a path whenever that path's infrastructure changes.
saying these in an interview costs you the question
- Says the generated report proves the flow is encrypted
- Thinks pytm checks the deployment to confirm attributes
- Sets control flags true because the control is planned
- Treats a clean report as evidence of no risk
- Worries only about missing elements, never false claims