Why does a CAPEC-driven sweep of an airline loyalty-points API miss arbitrage between member accounts?

## The two elicitation styles **Library-driven** elicitation walks a catalog of known attack patterns and asks of each: does this apply to the system in front of me? **Design-driven** (or asset-driven) elicitation walks your own architecture - the assets, the actors, the flows, the trust boundaries - and reasons about what could go wrong here. They fail in opposite directions, and the loyalty-points case is the cleanest demonstration. ## What the sweep found, and why An airline loyalty-points redemption API gets a thorough pattern-library pass. It comes back with injection variants against the search and redemption endpoints, session fixation on the member portal, enumeration of member numbers through the lookup endpoint, and a set of parser and rate-limiting concerns. Every one of those is real and worth fixing. All of them share a property: they are consequences of the **technology and its implementation**, not of the airline's rules. Any HTTP API with a database behind it, a session mechanism and an identifier lookup exhibits the same candidate patterns. That is precisely what makes them catalogable - they recur across thousands of systems, so someone was able to write them down once and reuse them. ## What it missed, and why that is structural The threat that actually loses money is points arbitrage. An authenticated member - often working with a broker who aggregates accounts - exploits the fact that points can be transferred between accounts, pooled into a household or family account, earned through partner promotions, and redeemed against award inventory whose cash value varies wildly. Combine those rules in the right order and you extract more value than was ever paid in. Award seats leave the inventory, the partner settlement is real cash, and the loss lands on the balance sheet. Notice what is *absent* from that description. There is no weakness. No input is malformed, no authorisation check is bypassed, no session is stolen. Every single request is one the system was designed to serve, sent by someone entitled to send it. Nothing has been exploited; the **rules composed in a way nobody priced**. That is why the miss is structural rather than a gap someone will fill in the next catalog release. An attack pattern is reusable precisely because it is independent of any particular product's business rules. A threat that consists entirely of *this* product's rules cannot be reusable, so it cannot be in a reusable catalog. Catalogs do contain abstract entries about abuse of intended functionality, and a candidate who mentions that is being honest - but an abstract category names a **shape**, not a mechanism. It cannot tell you that transfers plus household pooling plus a partner promotion is the combination that costs money. Only someone who knows the economics can. ## Floor, not ceiling The useful formulation: **a library sweep sets a floor of known patterns, never a ceiling of possible threats.** "We achieved full CAPEC coverage" means every applicable catalogued pattern was considered. It says exactly nothing about threats that were never catalogued - and on a system whose value lives in its rules, that is where the money is. A reviewer who accepts a completed sweep as "the threat model is done" has confused an activity with an outcome. ## What you add, and in what order Add an **asset-driven pass**: name what is worth taking, then ask, for each actor position, how a person in that position could obtain it. On the loyalty API, the asset is points-as-currency and the actor positions include an ordinary member, a member cooperating with other members, and a broker running many accounts at once. The question that finds arbitrage is not "which attack pattern applies" but "how could someone entitled to use this system extract value without paying for it?" Complement it with **abuse cases derived from the business rules**: for every rule that creates, moves or converts value, ask what happens if it is invoked at scale, out of the expected order, or in combination with another rule. Ordering matters more than people expect. Running the library first **anchors** the room: once twenty concrete catalogued threats are on the board, the group starts triaging instead of imagining, and the divergent thinking that finds business-logic abuse never happens. Do the asset-driven pass first while the room is still open-ended, then sweep the library as a completeness check. You also need the right people: a security engineer alone cannot derive the arbitrage, because the threat is made of domain knowledge - somebody who understands loyalty economics has to be at the table. ## Proving the second pass was worth it A sceptical manager will ask why you spent a session on something a catalog pass would have covered. Record the **provenance** of every threat: which came from the library, which from the design pass. Then track which ones drove a design change and which were later confirmed by testing or by a real loss. The pattern that shows up is that library threats are numerous, cheap and mostly mitigated by a framework or a standard control, while design-driven threats are few, expensive and the ones that would have hurt.