For a stadium ticketing on-sale, which assets must the threat model protect?

## What an asset actually is An asset is anything whose **damage, denial or disclosure produces a loss someone cares about**. That definition is deliberately loss-first, because the common failure is inventory-first: teams open the system catalogue, list the databases and services, and call that the asset list. Everything that is not a stored record then becomes invisible to the model. A useful test for each candidate: state the loss and its owner in one sentence — who is worse off, how, and roughly how badly. If you cannot, it is scenery, not an asset. The same test forces you to write down that the seat map's disclosure loss is near zero, instead of silently modelling it as important because it is data. ## The four kinds, on this system **Data.** Buyer contact and payment details exist, and they are a genuine asset with a confidentiality goal. But they are not what the attacker in this scenario is after, and treating them as the only asset is what goes wrong. **Functionality.** The ability to hold a seat, join a queue, and complete a checkout is itself valuable — valuable enough that someone will automate it. Attackers frequently want to **use** a capability rather than steal a record: compute, sending capacity, a working checkout, a quota, a queue position. Functionality abuse only shows up in a model that lists capabilities as assets. **Availability.** For a 9am on-sale, availability is not a background reliability concern; it is the asset. The loss is bounded to a window and cannot be made up afterwards — a sold-out event does not re-run. An availability goal therefore has to carry a scale and a window to be checkable at all: "legitimate entrants can complete a purchase during the on-sale minute" can be violated on paper, "the system should be highly available" cannot. **Reputation.** When an on-sale visibly collapses, or when fans see inventory vanish to resellers in seconds, what is lost is what people believe about the operator. Reputation counts as an asset whenever the damage is belief rather than disclosure. It appears on very different systems too: on a livestreaming platform, a coordinated group pushing a hate raid onto the front page is the loss — no record was read, nothing was corrupted in the usual sense, and the asset at stake is brand trust. Reputation goals still have to be falsifiable or they turn into slogans: "front-page placement reflects genuine engagement rather than a coordinated brigade" gives triage something to work with. ## Money and credentials Two asset types sit slightly apart and are worth naming explicitly. **Money and transactions** are their own asset — fraud loss, chargebacks, resale margin captured by someone else. And **credentials and key material** are a multiplier asset: their compromise invalidates controls elsewhere rather than causing a direct loss, so they rank by blast radius rather than by size. ## What the asset list changes The asset list is not documentation; it is the triage order for everything that follows. On this system, once availability and allocation integrity are the top assets: - Threats from **anonymous bot farms** — distributed queue entry, inventory holding, credential stuffing against fan accounts to reuse their queue standing — dominate. - Threats against the **confidentiality of public information** drop out, however easy they are to describe. - The properties that matter are availability and integrity of allocation, with confidentiality third. On a different system the ordering inverts entirely, and the same modelling effort produces a different surviving threat list. That inversion is the whole point of doing assets first. Two teams with the same diagram and the same method will produce different models purely because one of them wrote down "the tickets database" and the other wrote down "a real fan completes a purchase in the on-sale window". ## Common failure modes - **Table enumeration.** An asset list that mirrors the schema. It is complete and useless. - **Confidentiality tunnel vision.** Every asset gets a disclosure goal, no asset gets a denial goal, and availability threats never enter triage. - **Availability as somebody else's problem.** Treating denial as a reliability concern rather than an attacker goal, when for deadline-bound functionality it is the attacker's cheapest and most effective move. - **Reputation as a slogan.** Listing "brand" as an asset with no falsifiable goal attached, so no threat can ever be measured against it. - **Confusing volume with value.** Ranking assets by record count rather than by what the loss actually costs.