Why does a threat model's mitigation entry name a control family rather than a specific security product?

## What the mitigation entry is for A threat model ends with a list of things that could go wrong. Each of those threats needs an answer, and that answer has two audiences. An engineer has to be able to build it, and a reviewer has to be able to ask a single question of it: with this in place, does the attacker's path still work? An entry that cannot serve both audiences is a note, not a mitigation. ## What a control family is A control family is a class of countermeasure defined by what it does, independent of who supplies it. Typical families include: authenticating the identity of a party before acting on its request; authorizing each request against the resource it touches; validating and canonicalizing input at the boundary; protecting integrity cryptographically with a signature or MAC that the consumer verifies; encrypting data at rest; rate limiting, quotas and throttles; tamper-evident audit logging; isolation and segmentation between components; resource limits that bound the work one caller can cause; human-verification and automated-client detection; key management and rotation. Notice that every one of those names a behaviour. That is exactly what makes it reviewable: you can hold the threat next to it and reason about whether the behaviour removes the attacker's move. ## Three ways a product name fails **It is not reviewable.** A product answers a threat only in a particular configuration, on a particular flow. 'Product P' in the mitigation column asserts nothing a reviewer can check without going and reading P's ruleset, which the model does not contain. **It rots.** Tools get replaced, renamed, consolidated and re-tendered. A model whose safety claim is a vendor name becomes unverifiable the first time procurement changes, and the next reader cannot tell whether the design is still sound. **It hides a class mismatch.** This is the expensive one. A product name feels like a decision, so nobody asks which class of control it belongs to - and if the class is wrong, the threat is simply unanswered while the row looks green. ## A worked example An events ticketing platform models the sale of a high-demand event. The threat: anonymous automated buyers acquire the entire allocation within seconds of sale opening, and resell it. The attacker is an unauthenticated internet client running at scale; the asset at stake is inventory availability and the revenue and reputation attached to it. The team writes 'put a web application firewall in front of it' in the mitigation column. A web application firewall is a request-filtering control class. It inspects request content and blocks what matches malicious patterns - injection payloads, known exploit shapes, some crude floods. The bot's requests contain nothing malicious. They are well-formed purchases that a fast, lucky human could plausibly have sent. Filtering request content therefore has nothing to say about this threat: the class is wrong, and no amount of tuning changes that. The families that do answer it look different. Per-identity purchase quotas enforced server-side at the point the inventory is decremented. Identity proofing that raises the cost of minting a hundred fresh accounts. Human-verification challenges on the purchase step. A queue or lottery that removes raw speed as the winning strategy. Velocity anomaly detection with hold-and-review as a detective backstop. Those are five genuinely different designs, with different costs and different effects on ordinary customers - and choosing between them is the actual work the mitigation entry exists to record. ## How to write a good entry Name the family, the enforcement point, and who enforces it. 'Enforce a per-verified-account limit of N tickets per event, checked server-side in the inventory service at decrement time' can be built, tested and argued with. 'Add bot protection' cannot, and neither can a vendor name. One useful discipline: state, for each entry, which security property the control restores for this threat. If you cannot say it in a phrase, the entry is probably a purchase rather than a countermeasure. ## When technology may appear The model is allowed to record constraints - the platform the service runs on, a capability the design already depends on, a limitation that rules a family out. What should not appear is a technology name standing in place of the family, because that is the part under review. Keep the class and the enforcement point as the assertion; let implementation choose the box later, and let the model still be true when it does.