A structured approach to Threat Modeling
I recently stumbled on this article and its associated video which provide a very structured approach to threat modeling & security. Below is my summary of these excellent resources.
Table of Contents
Data collection
Gather information about the system considered and its:
- external dependencies
- entry and exit points
- assets
- trust levels and boundaries, i.e. where data is elevated in privilege
- data flows
Analysis
Identify, classify and prioritise vulnerabilities. For example, where do we have flows between processes without any trust boundary, and what are the associated risks?
STRIDE classification
For each STRIDE category, look for behaviour permitted by the system which creates a vulnerability. A vulnerability may belong to more than one category.
- Spoofing: an entity pretending to be something it is not, generally by capturing a legitimate user’s credentials, e.g.: brute force, CSRF.
- Tampering: the modification of data persisted within the system, e.g.: SQL injection, MITM, DNS cache poisoning.
- Repudiation: the ability to perform operations that cannot be tracked, or for which the attacker can actively cover their tracks, e.g.: prove who did
rm -fr /var/log
. - Information Disclosure: the acquisition of data by a trust level that should not have access to it, e.g.: bad messaging, SQL injection, MITM.
- Denial of Service: preventing legitimate users from accessing the service, e.g.: SQL injection, DDOS.
- Elevation of Privilege: an attack aimed at allowing an entity of lower trust level to perform actions restricted to a higher trust level, e.g.: SQL injection, CSRF.
Each vulnerability is then risk-assessed by “severity” and “probability”. This can however be a bit vague, so using the below scoring system, DREAD, can help be more objective & systematic. A scale of your choice (e.g.: from 1 to 10) can be used for each criteria.
DREAD scoring
- Damage (Severity): how bad would the financial and reputation damage be to your organisation and its users.
- Reproducibility (Probability): how easy is it to trigger the vulnerability. Most vulnerabilities will score high here but those that, for example, involve timing attacks would generally receive lower vulnerabilities as they may not be triggered 100% of the time.
- Exploitability (Probability): a measure of what resources are required to use the attack. The lowest score would generally be reserved for nation states, while a high score might indicate the attack could be done through something as simple as URL manipulation in a browser.
- Affected Users (Severity): a measure of how many users are affected by the attack. For example, maybe it only affects a specific class of user.
- Discoverability (Probability): how easy it is to uncover the vulnerability. A high score would indicate it is easily findable through standard web scraping tools and open source pentest tools. At the other end of the scale, a vulnerability requiring intimate knowledge of a system’s internals would likely score low.
Remediation
For each vulnerability and each aspect of it, consider the most appropriate remediation:
- Spoofing –> Authentication: of users (e.g. two-factor authentication), of requests (e.g. CSRF tokens), etc.
- Tampering –> Integrity controls: validate input, checksums (both of data at rest and in transit), etc.
- Repudiation –> Non-Repudiation: append-only audit logs, digital signatures, etc.
- Information Disclosure –> Confidentiality: encryption (both at rest and in transit, e.g.: using TLS), redaction (e.g.: hide passwords when rendering settings), configuration (e.g.: logs should not print passwords).
- Denial of Service –> Availability: more replicas, rate limits, recovery protocol (e.g.: self-serviced password reset to avoid users self-denying service), etc.
- Elevation of Privilege –> Authorisation: well-defined authorisation model, least privilege, re-authentication.
Conclusion
Repeating the cycle:
- Data collection
- Analysis
- Remediation
at various levels:
- individual components & libraries,
- applications,
- infrastructure,
one can have a very effective & systematic approach to security.
Resources
Threat modeling:
State machines and how to build simpler, more robust & more secure software:
- https://www.youtube.com/watch?v=MtHscXjWbVs
- https://github.com/glyph/automat
- https://clusterhq.com/2013/12/05/what-is-a-state-machine/
- https://clusterhq.com/2014/01/07/benefits-state-machine/
- https://clusterhq.com/2014/03/03/unit-testing-state-machines/
- https://clusterhq.com/2014/05/15/isolating-side-effects-state-machines/