A common delusion in security engineering is the idea that one could secure a system by identifying items that need protection (assets), describing the ways in which they might be damaged (threats or attacks, which are not synonymous but often confused), and then implementing countermeasures or mitigations such that all, or the most common, or the most damaging threats are covered. The system thus becomes secure with respect to the threat model, so the reasoning. This is the model underlying the Common Criteria, and it works fine as a descriptive model. To give an example from everyday life, consider a bicycle as an asset. If your bicycle gets stolen (the threat), your damage is the value of the bicycle plus any collateral damage that the loss may cause you, such as coming late to an appointment, having to pay for a taxi or public transport instead of riding your bicycle, and having to go to the gym for workout instead of getting a workout for free on your way to work. The typical countermeasure against this threat is locking the bicycle to a fence, pole, or other appropriate object. Locking your bicycle reduces the risk of it being stolen. What could possibly go wrong? Besides the obvious residual risk of your countermeasures not being strong enough, this could go wrong:

This (ex-)bicycle was and remains properly locked and no vulnerability in the lock or in items the lock depends on have been exploited. Yet, somebody made a fortune stealing bicycle parts, and somebody else lost a bicycle to an attack. What’s the problem? The problem is the gross simplification in the asset-threat-countermeasure model, which neglects three important factors:

1. Adaptive adversaries. A countermeasure does not oblige the adversary to stick to the original attack plan that the countermeasure is targeted at. Security measures change the threat model. They don’t force the adversary to give up, they force the adversary to change strategy and tactics.
2. The victim’s loss and the adversary’s gain are not necessarily the same. In the case of the bicycle above, the lock may reduce the attacker’s gain to the black market value of the removed parts. The victim’s loss is still one bicycle.
3. Asset dependencies. Thinking of a bicycle as one asset is an abstraction. A bicycle is really a collection of assets—its parts—and an asset by itself. Such dependencies, nested assets in this case, are common.

The bicycle lock, it turns out, is not really a bicycle lock, it’s a bicycle frame lock. It protects only one sub-asset of the bicycle, and an economically motivated adversary can make a gain that seems worth the risk without breaking the lock.

Prescriptive threat modeling—threat modeling done with the aim of finding a proper set of security features for a system—needs to take these issues into account. A good threat model anticipates changes in attacker behavior due to security measures. A good threat model considers not only damages to the victim but also gains of the adversary, as the latter are what motivates the adversary. And good security engineering is biased towards security, always overestimating adversary capabilities and always underestimating the effect of security measures, systematically.