In STRIDE-per-element analysis, which of the six STRIDE categories apply to each DFD element type?
answer
- four element types, four different row sets
- things outside your code get only two
- one element type gets all six
- data in motion: the in-transit trio
- log stores earn one extra letter
basics
~10 sExternal entities take spoofing and repudiation; processes take all six; data flows and data stores take tampering, information disclosure and denial of service, with repudiation added for stores that hold logs or audit records.
solid answer
~50 sSTRIDE-per-element walks every element on the diagram and applies only the categories that element type can suffer. The chart is: external entity - S and R; process - all six (S, T, R, I, D, E); data flow - T, I and D; data store - T, I and D, plus R when the store holds logs or audit records. The reasoning is ownership and identity. An external entity is outside the system you build: an attacker can impersonate it and it can deny having acted, but you cannot tamper with, read from or elevate privilege inside something you do not implement. A data flow is data in motion with no identity and no privileges, so only the in-transit trio applies. A process is code running under an identity with privileges, so every letter is live. Each letter names a violated property: S authentication, T integrity, R non-repudiation, I confidentiality, D availability, E authorization.
go deeper
Recall the six STRIDE letters and the property each one violates, and know that the per-element method applies a different subset to each element type rather than all six everywhere.
Be ready to reproduce the chart from memory and justify each row: why an external entity gets only spoofing and repudiation, why a flow gets the in-transit trio, and why a log store picks up repudiation.
Expect to fill the chart live against a design and turn letters into concrete threats naming attacker position, asset and effect, while catching threats other people wrote on the wrong element.
Own how the chart is used across teams: where it earns coverage cheaply, where its per-element framing gives false confidence, and how much cell-filling ceremony a delivery process can actually sustain.
## The six letters and the properties they violate STRIDE names six threat categories, and each one is the negation of a security property you wanted: | Letter | Threat | Property violated | |---|---|---| | S | Spoofing | Authentication | | T | Tampering | Integrity | | R | Repudiation | Non-repudiation | | I | Information disclosure | Confidentiality | | D | Denial of service | Availability | | E | Elevation of privilege | Authorization | Applying all six to a whole system at once produces vague threats. STRIDE-per-element narrows the question: take one element on the data-flow diagram, ask only the categories that element type can actually suffer, and write concrete threats in each applicable cell. ## The element-type chart | Element type | Categories that apply | |---|---| | External entity | S, R | | Process | S, T, R, I, D, E | | Data flow | T, I, D | | Data store | T, I, D (plus R when the store holds logs or audit records) | The rows differ for two reasons: what you own, and whether the thing has an identity and privileges. - An **external entity** is a person or system outside your implementation. Two things can still go wrong from your side: someone can claim to be it (spoofing), and it can deny having done something (repudiation). You cannot meaningfully tamper with it, read secrets out of it, deny it service or elevate its privileges, because those all describe changing something you build and run. - A **process** is code executing under an identity with privileges. Every letter is live: it can be impersonated, its logic and memory can be corrupted, it can fail to record who asked it to act, it can leak, it can be exhausted, and it can be made to run at a privilege it was not granted. - A **data flow** is data in motion. It has no identity to spoof and no privileges to elevate; what you can do to it is modify it, read it, or cut it - T, I, D. Impersonation risk at either end of the flow belongs to the endpoint element, not to the arrow. - A **data store** is data at rest: it can be modified, read and made unavailable. The repudiation asterisk exists because a store whose contents *are* the record of who did what changes character - if the log can be edited or truncated, an actor can deny an action, so R belongs on that store. ## Worked example: hotel key-card provisioning Model a hotel's key-card system: the guest and the front-desk clerk as external entities, a lock-programming process, a key database, an access-log store, and the flows between them. The assets are physical access and guest safety; the attacker positions worth assuming are an insider at the front desk and someone holding a card-programming device. - **Guest (external entity, S and R).** S: a caller convinces the desk they are the guest in room 412 and gets a duplicate card. R: the guest denies having asked for the second card when a dispute is raised. There is no D row - the guest's availability is not a property of the system you are building, and no T, I or E row for the same reason. - **Lock-programming process (all six).** S: a rogue handheld unit presents itself as the front-desk terminal. T: the room number in a programming request is altered so a card is cut for a different room. R: nothing records which clerk programmed which card. I: master-key material leaks out of the process. D: the unit is flooded so no cards can be cut during check-in. E: a clerk-level session issues a master card. - **Key database (store, T, I, D).** T: a row is rewritten so a card opens a suite. I: card credentials are dumped. D: the table is locked and check-in halts. - **Access-log store (store, T, I, D plus R).** The same three, and R because an insider who cut themselves a master card can delete the entry and deny it. This is exactly the case the asterisk in the chart is for. ## What goes in a cell The letter is a prompt, not a finding. A filled cell should read as a concrete threat - who attacks, what asset, what effect - not as the word "tampering". "Not applicable, because..." is a legitimate cell, and keeping it is better than leaving the cell blank, because a reviewer can tell the difference between a considered pass and an unfinished one. ## What the chart does not claim Two limits are worth naming even while you use it. A per-element sheet only asks what each element can suffer on its own, so threats that live in the relationship between elements do not get a row. And the chart's answer depends entirely on how you typed the element in the first place - call the same component a store or a flow and you get a different row set. The chart is a systematic prompt for coverage, not a proof of completeness.
- Why does a data store ever get a repudiation row when most stores do not?Because a store that holds logs or audit records is the evidence of who did what. If an actor can edit or truncate that store, they can deny an action they took, which is exactly a repudiation threat. Repudiation lands on that store because of the role its contents play, not because of the storage technology.
- Why is there no spoofing row on a data flow?Spoofing is an identity threat, and an arrow carrying bytes has no identity to impersonate. What people mean by "spoofing the flow" is impersonating one of its endpoints, and that threat belongs on the process or external entity at that end. Keeping it there stops the same threat being written twice under different owners.
- What belongs in a cell once you know the letter applies?A concrete threat sentence: who is attacking, from what position, against which asset, with what effect. "Tampering" alone is not a threat and cannot be rated or mitigated. A cell you decide does not apply is worth writing down with the reason, so a reviewer can see it was considered rather than skipped.
It is like a building inspection form with a different section for a door, a corridor and a safe: the safe section asks about the lock and what is inside, the corridor section does not, because the questions that make sense depend on what the thing is.
saying these in an interview costs you the question
- Says all six categories apply to every element
- Puts a denial-of-service row on a human external entity
- Claims a data flow can be spoofed rather than its endpoints
- Maps repudiation to integrity or confidentiality instead of non-repudiation
- Treats the letters as vulnerabilities rather than threat categories
- Leaves cells holding only a letter, with no concrete threat written