Prepare the threat model before assembling a product list. Identify the asset, the operation in which it needs protection and the capabilities of the attacker it must withstand.
Evaluation approach
Separate the data flow into device, application, network, identity provider and backend. At each transition, document which information is trusted and who verifies it.
Application example
In a loyalty system, the points balance belongs on the server. A screen displayed on the device is not proof of that balance. Start protection decisions with this business rule.
Limits and considerations
Giving every conceivable threat equal priority produces an unmanageable plan. Assess impact and feasibility together.
Questions for the first working session
Before drawing a diagram, write down the outcome to prevent: unauthorized transfers, access to paid content without permission or disclosure of private data. Then describe the attacker's access to an account, application file, device and network. This exposes relevant paths instead of treating every theoretical threat alike.
Each scenario needs preconditions, the intended change, the expected defense and the residual risk. If a control makes only one path harder, examine the alternatives. A threat model should not become a justification written after the product has already been purchased.
Checks and decisions
- Name the asset
- Describe attacker privileges
- Define the unwanted outcome
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.