In a STRIDE per-element sweep, one reviewer types a payroll SFTP drop as a data store and another as a flow - how do you settle it?
answer
- the type is the input, not a label
- same letters, different questions
- retention is what a flow typing loses
- union beats adjudication
- decide once, in a written convention
basics
~20 sElement type decides which rows you get, so a contested type is a signal that the component has two roles. Model it as both, take the union of the threats, write down the typing convention, and timebox the argument.
solid answer
~50 sThe disagreement matters because the type selects the row set, and it usually means the component genuinely does two things: an SFTP drop moves a payroll file and also retains it on disk. Typed as a flow you ask in-transit questions - modification en route, interception, the transfer window failing. Typed as a store you ask at-rest questions - who can read last quarter's files, how long they sit there, who can delete or alter them, and whether the drop is itself the record of what was paid. Against an insider payroll admin those at-rest questions are the ones that find real exposure, and a flow-only typing loses them. So I take the union rather than adjudicating, record a house rule - anything that retains data at rest earns a store row even if it also carries a flow - and cap the debate, because the goal of the session is finding threats, not classifying boxes.
go deeper
Understand that the element type chosen on the diagram decides which STRIDE categories get asked, so labelling a component is a decision with consequences rather than paperwork.
Be able to show that a flow typing and a store typing generate different concrete threats even where the letters match, using retention and historical read access as the example.
In a live session, resolve the ambiguity by modelling both, surface the threat that only one typing finds, and keep the discussion inside a couple of minutes.
Own the fragile input: publish the typing convention, make the judgment visible in the record, and weigh analysis rigour against the session cost a delivery organisation will actually pay.
## Why the typing argument is not pedantry STRIDE-per-element answers a question of the form "what can happen to *this kind of thing*". The kind is the input. Change the input and the output changes, so an ambiguous element is a genuine fork in the analysis, not a labelling quibble. The letters can look reassuringly similar - a data flow row and a non-log data store row are both tampering, information disclosure and denial of service - which is exactly what makes this trap quiet. The letters overlap; the threats they generate do not. ## The payroll example A payroll batch export writes a file to an SFTP drop. Finance's system fetches it, an internal reconciliation job also reads it, and files stay in the directory until someone clears them. The attacker to assume is an insider - a payroll administrator with legitimate access - and the assets are personal data and money. **Typed as a data flow** the questions are about transit: can the file be altered between the exporter and the consumer, can it be read by someone positioned between them, can the transfer be blocked so payday slips. All real. **Typed as a data store** the questions change shape: who can list the directory and read every prior period's file, how long files are retained and who decided that, who can overwrite or delete a file after it has been written, and - the important one - is this drop the record of what was paid? If reconciliation treats the dropped file as the authoritative record, that store carries repudiation as well, because an insider who alters a file and clears the earlier one removes the evidence of the change. The two row sets are not equivalent. A flow-only typing loses retention, historical read access and the audit-truth angle - and those are the rows an insider actually exploits. ## The call to make 1. **Model both.** The cost of a second row set is a few minutes; the cost of the wrong one is a missing class of threat. Take the union. 2. **Read the disagreement as information.** Two experienced reviewers typing the same thing differently almost always means the component has two roles. That observation belongs in the model notes, because it is often the reason the component is risky in the first place. 3. **Write a house rule so it is decided once.** A workable one: anything that retains data after the transfer completes earns a store row in addition to the flow it participates in. Publish it with the team's modeling guidance so the same argument does not recur per session. 4. **Timebox.** Give it two minutes and move on with the union. Sessions die from taxonomy debates, and a method that costs an hour of classification per component will simply stop being run. 5. **Record the decision.** When the model is reviewed later, "we typed it as both, here is why" is the difference between a considered choice and an apparent oversight. ## The wider principle Every structured elicitation method has a fragile input: some judgment made before the method starts, that the method then treats as fact. In per-element STRIDE that input is the element type. The method is only as trustworthy as that step, and its rigid appearance can hide how much judgment went into it. A lead's job is to make the fragile step visible - conventions written down, ambiguity resolved by union rather than by whoever argues longest, and the choice recorded - rather than to pretend the classification was obvious. ## What a strong answer sounds like It does not pick a side. It names why the type matters, gives one concrete threat that only appears under the store typing, proposes the union as the cheap resolution, and then moves the conversation up a level: how the team makes this decision consistently next time, and what it costs the session if they do not.
- Does taking the union of both row sets not inflate the threat list with duplicates?Some overlap appears, but the duplicates are cheap to collapse when you write concrete threats rather than bare letters - two rows describing the same modification of the same file merge into one line. The asymmetry favours the union: a duplicate costs a minute of editing, a missing retention threat costs an exposure nobody looked for.
- What convention would you actually publish for this case?That any component which retains data after a transfer completes is modelled as a data store in addition to the flows it participates in, and that a store whose contents are treated as the record of what happened also carries repudiation. Two sentences, in the team's modeling guidance, applied by default and overridable with a written reason.
- How do you keep this from becoming a recurring argument in every session?Decide it once outside the session and cite the rule inside it. Sessions should spend their time on threats, not taxonomy, so the facilitator's job is to apply the convention, note the ambiguity for the record, and keep moving. A team that relitigates typing every time will quietly stop threat modeling altogether.
saying these in an interview costs you the question
- Argues typing to consensus while the session clock runs out
- Assumes both typings find the same threats because the letters overlap
- Treats element type as a property of the technology rather than its role here
- Picks one typing and leaves no record of the choice
- Calls the disagreement pedantry and moves on without the union