Why does threat modeling aim to raise attacker cost above expected gain rather than eliminate a threat?

## The inequality every control is really tuned against Attacker economics treats an attack as an investment decision. An economically motivated attacker proceeds when expected gain > cost of the attempt and stops when the inequality flips. Both sides are richer than they look. **Expected gain** is not the asset's face value. It is what the attacker can actually realise, discounted twice: by the probability that the attempt succeeds, and by the probability that they keep the proceeds. A stolen loyalty-points balance is worth its *resale* price to a broker, not the airline seat it nominally buys. A card number is worth what a validated card fetches, not the victim's credit limit. If clawback, reversal, account termination or prosecution are likely, the retention probability falls and so does expected gain — which is why a purely detective control, one that prevents nothing, still moves the economics. **Cost** is money plus time plus skill acquisition plus exposure. Renting infrastructure and buying stolen input data are the obvious parts; the parts people forget are the one-off cost of *learning* a technique against your particular design, and the legal risk carried by each attempt. ## Why "eliminate the threat" is usually the wrong goal A threat is what could go wrong; a vulnerability is the specific flaw that lets it happen; a risk is the rated consequence; a control is what you do about it. You can eliminate a *vulnerability* — that is what a fix is. You usually cannot eliminate a *threat*, because the threat is a consequence of the functionality existing at all. A payment form that tells anyone whether a card is chargeable is a card-testing threat by construction: the only way to remove it is to stop accepting cards. So the honest design target is not "make this impossible" but "make it cost more than it is worth", and the honest acceptance test is a price, not an absolute. Stating the goal as impossibility does real damage. It sets a test nobody can pass, so the conversation never gets to the useful question of *how much* friction. And it tends to produce controls that are absolute for legitimate users — a hard block, an identity check on every action — while the attacker pays a small one-time cost to route around them. ## Worked example: card testing on a micro-donation form A charity accepts one-dollar donations. An anonymous fraudster with a bought list of card numbers uses the form as an oracle: submit a card, read the response, keep the ones that authorise. Their cost per attempt starts at a fraction of a cent — a request, a rotated address, no human involvement. The gain per validated card is worth far more than that, so the inequality holds by a wide margin and the form will be abused continuously. Nothing here can be eliminated: the merchant must submit the card to learn whether it is good. What can be changed is the price of an attempt. Per-identity and per-source attempt limits force the attacker to spread across more infrastructure. A challenge or computational cost on the submit path puts a floor under each attempt. Making failure responses indistinguishable removes the oracle quality, so the attacker must pay for a signal they used to get free. Velocity rules that fail an entire batch after a few declines destroy the economics of bulk. None of these stops a determined attacker testing one card; together they aim to push cost per attempt above what a validated card is worth, at which point the rational attacker abandons this form for a cheaper one somewhere else. The defender's own cost is part of the calculation too. Friction that costs a real donor a conversion is a real loss, so the design question is where to spend the friction — on the anonymous, high-velocity path, not on everyone. ## The second lever: reduce the gain The inequality has two sides, and the cheaper move is often to attack the gain rather than the cost. A loyalty-points marketplace where points are freely and instantly transferable has a liquid asset: theft converts to cash immediately at close to face value. Making resale illiquid — transfer holds, transfers only between long-established accounts, redemption limited to non-transferable goods, identity checks at cash-out — collapses the resale price without making account takeover any harder. The same logic explains why stored payment credentials are replaced by tokens usable only by one merchant: the dump still leaks, and is worth almost nothing. Devaluing the loot is frequently a smaller engineering change than hardening every path to it. ## The caveat that makes this a judgment call Cost-versus-gain reasoning is a model of a *rational, economically motivated* attacker. It says nothing about someone pursuing one specific victim, an actor funded to impose loss on you, or automation whose per-target cost is already rounded to zero. For those threats the acceptance test cannot be a price, and pricing them is the classic way a threat model talks itself into under-protecting the thing that matters most.