In STRIDE, which security property does Tampering violate, and which diagram elements can carry it?
answer
- the middle letter of the CIA triad
- writing, not reading
- three of the four element types
- external entities are impersonated instead
- config and code count as targets too
basics
~20 sTampering violates integrity: someone modifies data or code they are not authorized to change. On a data-flow diagram it applies to processes, data flows and data stores, but not to external entities, which get spoofed instead.
solid answer
~50 sEach STRIDE letter names a security property under attack, and Tampering is the one that attacks integrity — unauthorized modification of bits, whether they are in transit, at rest, or the rules a process obeys. In the classic STRIDE-per-element table, a process can carry all six letters; a data flow and a data store each carry Tampering, Information Disclosure and Denial of Service; an external entity carries only Spoofing and Repudiation. So T lands on three of the four element types, which is why it is usually the most frequent letter on a real diagram. Practically, I look for it wherever a flow crosses a trust boundary, wherever a store is writable by more than its owning process, and wherever a process loads rules or configuration from somewhere else. The answering control family is integrity: write authorization, signatures or message authentication codes, append-only storage, and validation on load.
go deeper
Be able to say the word integrity the moment you hear Tampering, and to give one example each of a modified message, a modified stored record and a modified config value.
Explain the per-element mapping and why external entities are excluded, and name the three control families — restrict the write, make modification detectable by the receiver, reconcile afterwards.
An interviewer expects you to sweep a real diagram and produce Tampering rows in the right places, then argue why per-hop transport protection leaves the resting places open and choose an end-to-end control instead.
Own the question of how integrity is enforced across a whole estate: which artifacts must be signed at origin, where verification is mandatory versus advisory, and how much detective reconciliation buys you where prevention is impractical.
## The letter and the property STRIDE is a threat-enumeration mnemonic. Each of its six categories is named after a security property that is being violated, not after a named exploit: | STRIDE category | Property violated | Desired property | | --- | --- | --- | | Spoofing | Authenticity | Authentication | | **Tampering** | **Integrity** | **Integrity** | | Repudiation | Non-repudiation | Non-repudiation | | Information Disclosure | Confidentiality | Confidentiality | | Denial of Service | Availability | Availability | | Elevation of Privilege | Authorization | Authorization | Tampering is therefore the integrity letter: an attacker **changes** something they are not authorized to change. The contrast that matters most in an interview is with Information Disclosure — that letter is about *reading* what you should not read; Tampering is about *writing* what you should not write. A candidate who describes stolen customer records as a Tampering threat has swapped the two. ## What can be tampered with Three things, and forgetting the third is the common gap: 1. **Data in motion** — a message, a file transfer, a request or response on a data flow. 2. **Data at rest** — rows in a table, objects in a bucket, a file in a shared directory, a message parked on a queue. 3. **The instructions a process obeys** — its configuration, feature flags, environment, rule or rate tables, and its loaded code. Changing these changes behaviour without touching a single user record. ## STRIDE-per-element: where T is allowed to land The per-element form of STRIDE walks the diagram and applies only the letters that make sense for each element type: - **External entity** — Spoofing, Repudiation. - **Process** — all six. - **Data flow** — Tampering, Information Disclosure, Denial of Service. - **Data store** — Tampering, Information Disclosure, Denial of Service; Repudiation as well when the store *is* the audit log. Tampering appears on three of four types. External entities are the exception, and the reason is worth being able to say out loud: an external entity models something outside your control — a person, a partner system, a device you do not operate. You cannot harden it, so the model asks what it can do to you, not what you can do to it. An attacker who wants to change what an external entity sends does not modify the entity; they impersonate it (Spoofing) or modify the flow between it and you (Tampering on the flow). Writing 'add integrity controls to the external entity' as a mitigation is a sign someone has not understood the notation. ## Threat, vulnerability, risk, control Keep the four apart when you write the finding down. 'An operator can rewrite the totals file before it is loaded' is the **threat** (Tampering). 'The drop directory grants write to a shared group' is the **vulnerability** that makes it reachable. 'Payments settle against altered totals and the discrepancy surfaces at month end' is the rated **risk**. 'The extract job signs the file and the loader refuses an unverified one' is the **control**. Interviewers who ask you to threat-model live are listening for exactly this separation, because a list that mixes them cannot be prioritised. ## The answering control family Integrity controls come in three flavours, and picking between them is a design decision, not a cryptography decision: - **Prevent the write at all** — write permissions, a store only the owning process may write, a queue only one identity may publish to, immutable or append-only storage. Cheapest and strongest when the tampering party has no legitimate reason to write. - **Make modification detectable by the receiver** — a message authentication code when both ends share a secret, a digital signature when the verifier must not be able to forge, applied end-to-end across every hop where the artifact is exposed rather than per-hop. - **Detect after the fact** — reconciliation against an independently derived total, and a tamper-evident record of who wrote what. One trap: an unkeyed checksum published next to the artifact is not an anti-tampering control. It detects accidental corruption. An attacker who can alter the artifact can usually recompute the checksum, so it only counts as integrity when it travels through a path the attacker cannot reach or is itself protected by a key. ## What good looks like on a whiteboard Sweep the diagram element by element rather than brainstorming. On each flow: who else is on this path, and would the receiver notice a changed message? On each store: who can write, and does the reader ever check? On each process: where do its rules come from, and are they trusted just because they arrived from inside? That sweep is what produces the Tampering rows; the mitigation column is filled in afterwards, one control family per row.
- An attacker edits a row in the roles table so their own account reads 'admin'. Do you file that as Tampering or Elevation of Privilege?Both, and I would write both rows. The unauthorized write against the store is the Tampering threat — that is where the control goes, since the store should not be writable by that path. The privilege the attacker then holds is the Elevation of Privilege consequence at the boundary. STRIDE categories are not mutually exclusive; the useful discipline is naming the action against the asset separately from the outcome, because they attract different mitigations.
- Why does STRIDE-per-element assign no Tampering threat to an external entity?Because an external entity is outside the system you can change — a user, a partner service, a device someone else operates. The model treats it as an actor whose behaviour you cannot constrain, so 'harden it' is not a mitigation you can write. An attacker who wants different content from it impersonates it, which is Spoofing, or alters the flow it sends on, which is Tampering against the flow.
- Does putting a flow inside an encrypted channel close its Tampering threat?Only for the hop that channel covers, and only if the channel actually authenticates the bytes rather than merely concealing them. Confidentiality and integrity are separate properties, so 'it is encrypted' is never by itself an answer to a T row. And a per-hop control leaves the artifact unprotected wherever it sits between hops — if the data lands in a store, is queued, or is re-emitted by a middlebox, the T threat on that resting place is still open.
saying these in an interview costs you the question
- Describes stolen or leaked data as Tampering
- Maps Tampering to confidentiality or availability
- Thinks Tampering only applies to data in transit
- Treats an unkeyed checksum as an anti-tampering control
- Writes integrity mitigations against an external entity
- Says encryption alone closes every Tampering row