How do you run STRIDE elicitation inside a PASTA-framed engagement without duplicate or orphan findings?

## Why combine at all Each method has a hole the other fills. A category-driven walk such as STRIDE gives *recall*: six categories - spoofing against authentication, tampering against integrity, repudiation against non-repudiation, information disclosure against confidentiality, denial of service against availability, and elevation of privilege against authorization - applied systematically so that a threat class is not missed because nobody thought of it that morning. What it does not give you is *priority*: the raw output is a flat list where a theoretical repudiation gap on a debug endpoint sits beside a tampering path on the money flow. PASTA supplies the opposite. Its seven stages run from definition of objectives, through definition of the technical scope and application decomposition, to threat analysis, weakness and vulnerability analysis, attack modeling, and finally risk analysis and management. It is risk-centric and attacker-simulation oriented: it starts from business objectives and impact and ends at risk decisions. Its weak point is elicitation - stage four leans on threat intelligence and analyst judgment, so coverage varies with who is in the room. So the combination is: PASTA frames, STRIDE elicits. ## The concrete wiring Take a platform team migrating to a new identity provider. The asset is credentials and keys; the attacker position worth taking seriously is a compromised operator of the IdP tenant - someone with legitimate administrative reach into the directory and the token-issuance configuration, not an anonymous internet user. - **Stages 1-2 (objectives, technical scope).** Business objectives name what must not happen: no silent account takeover, no undetectable privilege grant, no loss of the audit trail that proves who granted what. This is what later lets you rank findings. - **Stage 3 (application decomposition).** Produces the diagram, its elements and its trust boundaries - crucially, the boundary between your platform and the IdP tenant, which is now an external administrative surface. - **Stage 4 (threat analysis).** Run the STRIDE walk here, over that diagram. This is the substitution: category-driven elicitation replaces or augments intel-driven brainstorming as the way stage four gets populated. - **Stages 5-7 (weakness analysis, attack modeling, risk).** These consume the elicited threats. Attack modeling chains individual threats into plausible attacker paths; risk analysis attaches impact using the objectives from stage one and drives accept, mitigate, transfer or avoid. The sentence to remember: *the STRIDE output is an input to attack modeling, not a second deliverable that runs alongside it.* ## Where duplicates come from, and the fix Duplicates appear at the seam because the same underlying weakness has two natural names. "Tampering on the token-issuance configuration flow" and "attacker path: compromised tenant operator alters claim mapping to grant themselves an admin role" are the same defect described once as a category-per-element threat and once as an attack scenario. If elicitation and attack modeling keep separate lists, the register double-counts, remediation gets assigned twice, and any later coverage claim is inflated. The fixes are unglamorous and they work: 1. **One register, one canonical id.** An attack scenario references the ids of the threats it chains; it does not restate them. 2. **Agree granularity once.** Decide up front at what level the walk records a threat and hold that line for the whole model. Mixing granularity inside one engagement is the largest single source of apparent duplicates. 3. **A de-duplication pass at the seam**, before attack modeling begins, with a single named owner of the register. 4. **Traceability columns**: business objective -> element or flow -> category -> attack scenario -> risk decision. When a row cannot be filled end to end, you have found either a duplicate or an orphan. ## Orphans, in both directions An orphan going forward is an elicited threat that no attack scenario picks up and no risk decision covers. It must be explicitly marked accepted or deferred with a reason - silence is how a real finding disappears while the model still looks complete. An orphan going backward is more interesting: a business objective from stage one for which no threat was ever elicited. That is not tidiness, it is a scope gap. If "the audit trail proving who granted what must survive" has no associated repudiation threat anywhere in the model, either your diagram is missing the logging path or the walk skipped it. ## When not to combine Combining costs elicitation time and coordination, and it needs someone who can hold both frames. Skip it when the team is running its first models - one method, learned properly, beats two half-run. Drop back to one when the seam produces nothing new: if the attack-modeling stage never adds a chain beyond the elicited list, or if the two views converge to the same handful of items every time, you are paying twice for one result. And if the backlog is untouched after either method, the problem is not the method combination at all.