In a STRIDE per-interaction sweep, what is the unit you enumerate, and how does per-element differ?

A STRIDE sweep is a way of forcing yourself through the six threat categories — **S**poofing (violates authentication), **T**ampering (integrity), **R**epudiation (non-repudiation), **I**nformation disclosure (confidentiality), **D**enial of service (availability) and **E**levation of privilege (authorization) — instead of brainstorming and hoping. What changes between the variants is *what you point the six letters at*. ## The unit is the triple, not the node In a per-interaction sweep the row of the analysis is an **interaction**: a source element, a destination element, and the flow that runs between them. On a data-flow diagram that is one directed edge together with both of its endpoints, annotated with the trust boundary it crosses (if any). You walk the edges of the diagram, not the nodes, and for each edge you ask which of the six categories is meaningful *for that crossing*, given what the source is authenticated as, what privileges the destination will act with, and what the destination does with the message. The per-element variant does the opposite: it visits each node once and asks which categories that element's *type* admits. It is cheaper and it is a fine floor, but every threat it can express is a property of the node in isolation. A process that is invoked from two very different places produces one set of rows, and those rows have to be written vaguely enough to cover both callers — which in practice means they are written for whichever caller the modeler had in mind. ## Why the crossing carries threats the node cannot Take an insurance claims platform whose fraud-scoring process is invoked from two paths: the public quote flow, where an anonymous applicant's submission reaches it through the internet-facing quote service, and the internal adjuster path, where a logged-in claims adjuster asks for a re-score on an open claim. The asset at stake in both cases is money — a mis-scored claim is either fraud paid out or a customer wrongly denied. A per-element pass over the fraud-scoring process yields one block of rows. A per-interaction pass yields two triples, and they do not look alike: ``` source -> destination crossing letters that bite anonymous applicant -> fraud scoring internet edge S (assert a stolen identity), (via quote svc) T (shape attributes to lower the score), D (flood the scoring path) claims adjuster -> fraud scoring staff boundary E (adjuster forces an override the role (via adjuster UI) should not permit), R (nobody can prove who re-scored this claim) ``` Elevation of privilege and repudiation only appear on the second row, and they are not properties of the fraud-scoring process — they are properties of *that caller reaching it through that boundary*. An insider with legitimate access is a different attacker from an anonymous applicant, and the interaction is where that difference lives. Equally, spoofing an applicant identity is not a threat on the internal path, where the identity is already established upstream. Reduce both to one element row and you get a row that says "authenticate callers" and hides two genuinely different problems. ## What you actually ask per triple For each interaction, the productive questions are: - **Spoofing** — can the destination be fooled about who the source is? This is about authentication *at this hop*, not somewhere upstream. - **Tampering** — can the message be changed between these two endpoints, or can the source send values the destination will trust and act on? - **Repudiation** — after this interaction, can the source credibly deny it happened? That needs the source to be a distinguishable identity and the destination to keep an attributable record. - **Information disclosure** — who, on the destination side of this crossing, can now read what the message carried? - **Denial of service** — can the source exhaust the destination through this path, or can the path itself be cut? - **Elevation of privilege** — does the source end up acting with rights it should not have on the far side? Many triples answer "not meaningful here" for several letters, and writing that down deliberately is part of the value. ## What it does not give you Per-interaction analysis inherits its boundaries; it does not decide them. If the trust boundary is in the wrong place, every row on that edge is wrong in the same direction. It also does not rate anything — the output is threats, not risks, and turning a couple of hundred rows into an ordered set of fixes is a separate rating step. And its completeness claim is only "every edge got six questions", which is not the same as "every threat was found": threats that live in a sequence of interactions, or in what the system does *between* messages, do not appear on any single edge. ## The cost Rows scale with edges rather than nodes, and edges grow faster than nodes as a design gains external parties. A diagram of a dozen elements can carry three or four dozen interactions, each of which takes up to six questions. That arithmetic is the honest reason teams reach for per-element first and reserve per-interaction for the designs whose risk really does live at the crossings.