Threat modeling is an exercise that helps with quantifying threats to understand how attackers (threat actors) may be able to compromise a system and then make the appropriate mitigations to thwart the potential risks posed. Typically, threat modeling is an exercise that takes place before deployment to production systems as part of the design phase but can also be used in the beginning stages of any security testing. Threat modeling will usually include the following activities:
Identifying all assets in a system, creating an architecture overview
Decomposing the system (or device)
Identification of threats
Document all the threats with their respective scenarios, and
Rate each threat by its likelihood as well as impact using a rating system
A framework used to help enumerate and identify threats is STRIDE, which is a mnemonic described in the following table:
Pretending to be someone or something you are not
Impersonating another user
Modifying data or code
Deleting log files to conceal activity
Claiming to have not performed an action.
I never executed that DROP TABLE in production
Exposing information to someone not authorized to see it
Hardcoded usernames and passwords in source code
Denial of Service
Deny, limit, or degrade service to users
Exhaust server side infrastructure with requests
Elevation of Privilege
Gain capabilities without proper authorization
Gaining admin privileges
Common risk rating systems used in threat modeling are DREAD, and CVSS but several others are also available. DREAD, another mnemonic, is scored on a scale of 1 to 3 according to each category described below and a final score is the average. 1 is low risk, 2 is medium risk, and 3 is high risk. Often, the scoring scale is modified to fit the need of an organization, such as 0 to 10.
How bad would an attack be?
Can subvert all security controls and get full trust to take over the whole ecosystem.
Could leak sensitive information.
Could leak trivial information.
How easy is it to reproduce the attack?
The attack is always reproducible.
The attack can be reproduced only within a timed window or specific condition.
It's very difficult to reproduce the attack, even with specific information about the vulnerability.
How much work is it to launch the attack?
A novice attacker could execute the exploit.
A skilled attacker could make the attack repeatedly.
Allows a skilled attacker with in- depth knowledge to perform the attack.
How many people or users will be impacted by a successful attack?
All users, default configurations, all devices.
Affects some users, some devices, and custom configurations.
Affects a small percentage of users and/or devices through an obscure feature.
How easy is it to discover the threat?
Attack explanation can be easily found in a publication.
Affects a seldom-used feature where an attacker would need to be very creative to discover a malicious use for it.
Is obscure and unlikely an attacker would discover a way to exploit the bug.
Threat models should answer the following four questions:
What are we building?
Use data flow diagrams (DFD) to assist with modeling components and how they interact locally as well as with external services
DFDs should show each process, user, entity, data store, and protocols that connect assets
What can go wrong?
Leverage STRIDE to help identify and enumerate threats
What are we going to do about the issues that can go wrong?
DREAD aids with risk scoring and prioritization. The higher the risk, the higher priority the threat should be addressed or mitigated.
How well was our analysis?
Conduct a retrospective activity to check the overall quality, progress, and future planning.
Threat modeling should be done early, and as often as possible. Threat model owners are best in the hands of the software teams and should considered a living document that is updated as new features are planned.
A great book and also an authoritative reference is "Threat Modeling: Designing for Security".