In STRIDE, how do you model Tampering against a process's own configuration and code?

## Why configuration is a first-class Tampering target A process is not just a box that transforms user data. It is a box whose behaviour is *parameterised* by things it reads at start-up or at run time: a config file, environment variables, a feature-flag service, a rules or pricing table, a policy document, a template, a plugin directory, the code artifact itself. Every one of those is an input, and every input has a source, and every source-to-process arrow is a data flow that can cross a trust boundary. The reason this gets missed is that config usually arrives from somewhere that *feels* internal — a shared cluster service, a mounted volume, a local port on the device, a bucket 'we control'. Feeling internal is not a trust boundary argument. The question is always which principals can write it, and whether that set is narrower than the set who should be able to change what the process does. ## Two worked shapes **A feature-flag service read over an unauthenticated in-cluster endpoint.** The flags decide whether a payment path is enabled, whether a new authorization check is enforced, whether a debug behaviour is on. Any workload that can reach the endpoint can flip one. The attacker here is not an anonymous internet user; it is an authenticated, low-privilege workload that got a foothold somewhere in the cluster. The asset is the service's behaviour — the ability to turn a control off from a position that gives no direct access to the data the control protects. The Tampering row goes on the flag flow and, if the flag store accepts unauthenticated writes, on the store too. **A smart meter that accepts its tariff table as an unsigned config blob.** The attacker owns the device; there is no perimeter left to defend. The asset is metering integrity and therefore money. The meter's data handling can be perfect and the meter still bills wrongly, because the *rules* were replaced. Notice that no user data was modified — this is Tampering with the process, not with a store of records. Different attacker positions, different assets, same STRIDE row: an input that determines behaviour, writable by someone who should not determine behaviour. ## How to enumerate it on the diagram When you sweep a process element, do not stop at its request flows. Ask: - **What does this process read that changes what it does?** List config sources explicitly and draw them; a config source that only lives in your head cannot get a threat row. - **Who can write each source?** Name principals, not systems. 'The deploy pipeline' and 'any pod in the namespace' are very different answers. - **Does the process verify anything before applying it?** Verification means an integrity check the process performs, not an assumption about where the value came from. - **What happens when a source is missing, malformed, or fails verification?** A config path that falls back to a permissive default converts a Tampering threat into a trivially reachable one — deleting the file becomes as good as forging it. ## Controls that actually answer it - **Restrict the write.** The narrowest fix and often the right one: config that only the deploy identity may change, a flag service that requires an authenticated caller with an explicit role to mutate, a read-only mount, an immutable image for code. - **Verify on load.** Where the artifact travels through places you do not control — a device in a customer's home, a blob in shared storage — the process should verify a signature over the artifact before applying it, so that possession of the storage is not enough to change behaviour. The verifying key ships with the process; the signing key lives where the tampering party cannot reach it. - **Validate the content.** Integrity checks prove the bytes came from an authorized source; they say nothing about whether the values are sane. Range-check tariffs, bound rule counts, reject unknown fields. This is the layer that catches an authorized-but-wrong change. - **Fail closed.** No verification, no start. A safe default is one that keeps controls enforced, not one that keeps traffic flowing. - **Make changes attributable.** Recording who changed which flag, and when, does not prevent the change, but it converts a silent behaviour swap into something you can find and reverse. ## The interview signal Saying 'and the config is an input too' is a small sentence that separates candidates. It shows you model the system as it actually behaves rather than as the happy-path data diagram suggests, and it usually surfaces the cheapest high-value mitigation in the whole exercise, because config write paths are typically far broader than anyone intended.