How do you threat-model a support agent's 'view as this member' impersonation route in a customer portal?

## The feature is the surface A hotel-group loyalty portal has a route that lets a phone-support agent view and act inside a member's account, because that is how a support call gets resolved without reading a password over the phone. Nothing here is a bug. That is what makes it a good threat-modeling exercise: the interesting surfaces in real systems are frequently **capabilities that work exactly as designed**. The first artifact is not a threat, it is an **assumption**. Write it into the model explicitly: *support agents are trusted to act inside any member's account*. Assumptions carry the weight of a model - they are the conditions under which its conclusions hold. An unrecorded assumption cannot be reviewed, cannot be revisited when the support team grows or is outsourced, and cannot be flagged when a phishing wave hits the support tenant. Recording it is also how you resist the answer 'that is fine, they are employees', which is not an argument, it is the assumption restated. ## What it looks like on the diagram Draw the operator zone (agents, their console) and the member data store, and draw the impersonation route as a flow crossing into member context. Three properties of that crossing decide the whole analysis: - **It is always open.** Not a rare break-glass path with an approval - a normal working tool, used constantly. - **It is wide.** Its reach is not one member but the entire member population. - **It is authorized.** No control is being bypassed when it is used. That third property is what changes the STRIDE result relative to a public surface. ## Which categories dominate, and why not elevation On a public web surface, elevation of privilege and spoofing lead. Here elevation is granted, so the residual threat is **abuse of a granted capability**, and the list reorders: - **Information disclosure** (violating confidentiality). An agent opening accounts that no case ever touched - an ex-partner, a public figure, a colleague. There is no malformed request to detect; every one of these looks exactly like work. - **Repudiation** (violating non-repudiation). If the system writes the impersonated action under the member's identity alone, the trail asserts something false: that the member did it. Then a disputed redemption cannot be resolved, and an agent can deny an action honestly recorded against someone else. The requirement is that both identities ride on every record - the acting agent *as* the member - in the store, in the audit trail, and in anything the member is later shown. - **Tampering** (violating integrity), pointed at the money-equivalent asset: a points balance, a redemption, a stay credit. Spoofing is not the story: nobody is claiming a false identity, the system knows exactly who is acting. ## Controls skew detective, deliberately Against an adversary whose access is legitimate you cannot prevent your way out - the capability is the job. So the model spends prevention narrowly, on **scope**, and buys the rest in the ability to notice and to prove: | Ask | Type | What it buys | | --- | --- | --- | | Impersonation is read-mostly; redemptions, transfers, email and credential changes excluded | Preventive | Removes the money and account-takeover paths from the capability | | Session bound to a case reference and time-boxed | Preventive | Ties each use to a reason and ends it automatically | | Both identities on every write and every log entry | Detective | Preserves attribution; makes disputes resolvable | | Member notified out of band that support accessed the account | Detective | Puts a party with the right incentive in the loop | | Volume and pattern review over agent access | Detective | Surfaces browsing that no case explains | | Persistent banner showing the agent they are acting as a member | Preventive | Prevents honest mistakes, which are most of the incidents | Notice the shape of the argument: the preventive controls narrow *what the capability can reach*, and the detective ones cover the part that cannot be narrowed. That is the standard answer for an insider surface, and being able to state why the mix looks like this is the point of the question. ## The cheapest mitigation is sometimes removal The model should also price the option of not having the crossing at all. If most cases are answered by a scoped read-only view of the member's recent activity, then a permanently open path into every account is being maintained for a small tail of cases - and the residual is that every agent account is a path to the whole member base. Splitting the feature is usually the realistic outcome: a scoped read view for everyday work, and a genuinely exceptional, approved, loudly logged acting-as path for the rest. ## Where this stops The model's job is to state what evidence must exist and which actions must be out of scope. How that evidence is monitored afterwards, and how an incident is investigated, belongs to operations. What the threat model owns is the crossing, the assumption underneath it, the reordered category list, and the requirements it hands to the team building the feature.