Threat modeling and scenario validation

Threat modeling is not a list of attacker names. It examines how an actor or error can exploit a dependency and alter a business outcome. Start with assets, trust paths and interfaces, then consider spoofing, tampering, repudiation, unintended disclosure, disruption and privilege escalation where relevant. Write each scenario as a chain: prerequisite, action, weakness or missing control, observable event and consequence. Test the scenario by removing its prerequisite; if it still reads the same, the cause is underspecified. Label unknowns rather than turning possibility into fact. The output is a flow diagram, trust boundaries and a small set of relevant scenarios with evidence needed for confirmation.

Turn a risk scenario into a falsifiable chain: exposed asset or privilege, prerequisite, harmful action, business consequence, and evidence that raises or lowers likelihood. This structure prevents a theoretical possibility from becoming an asserted event. Challenge each link: if the prerequisite is removed, can the path still operate in the same way? If so, the cause is underspecified. Keep impact severity separate from likelihood. Two cases may have the same financial consequence, while an internet-exposed persistent account without MFA and with recent attempts deserves higher priority than a disabled segmented account. Absence of complaints is not evidence of absence when visibility may be incomplete. Worked example: a supplier has a persistent price-edit account, MFA is absent, and logs show failed attempts from a new location. First restrict the account, preserve logs, and verify the change path; do not declare a breach or buy a tool before obtaining evidence.