I’ve worked on a couple of threat modelling jobs for Wire-Security. We take a STRIDE approach to the methodology. You’ll come across many resources online from other bloggers etc. that will be a much more comprehensive guide for some people but I’m going to keep it simple here, and hopefully satisfying, and write about what works for us.
STRIDE comes in great for a guide to writing part of your report however we also need to add a graphic.
Your flow diagram is going to be the first thing you do after reading the documentation. You will probably come back to it numerous times to refresh it, add more vectors etc. but this visualisation is paramount and will keep your mind focused as you work through your report.
STRIDE stands for:
- Information disclosure (privacy breach or data leak)
- Denial of service
- Elevation of privilege With this you are going to consider various theoretical attacks that you can group under each heading. Below is a breakdown of the guidance we use when approaching a threat modelling exercise with a STRIDE methodology.
In the context of information security, and especially network security, a spoofing attack is a situation in which a person or program successfully identifies as another by falsifying data, to gain an illegitimate advantage. This category is concerned with authenticity.
Tampering refers to malicious modification of data or processes. Tampering may occur on data in transit, on data at rest, or on processes. This category is concerned with integrity.
Repudiation refers to the ability of denying that an action or an event has occurred. This category is concerned with non-repudiation.
Information Disclosure refers to data leaks or data breaches. This could occur on data in transit, data at rest, or even to a process. This category is concerned with confidentiality.
Denial of Service
Denial of Service refers to causing a service or a network resource to be unavailable to its intended users. This category is concerned with availability.
Elevation of Privileges
Elevation of Privileges refers to gaining access that one should not have. This category is concerned with authorization.
The process used to develop a threat model is dependent on product/service documentation, and knowledge and insight from developers, product owners, expert users, etc. Usually gathered through interviews.
One or more visual representations of the target system(s) to ensure that the team’s understanding of the system is aligned with the purpose of the threat modelling exercise. From there, threats are listed, documented, and weighted for relevance. Additionally, potential mitigation actions, if any, are identified. A threat modelling exercise is not a risk assessment. The evaluation of probability, which is critical for a risk qualification, is not a formal part of threat modelling. As such information collected during a threat modelling exercise can augment a risk assessment but should never be considered an expression of risk on its own.
Thank you so much for reading. As of right now most of us are in lockdown due to the 2019-nCoV Coronavirus so if you have some knowledge to share with the community then please do! There’s loads of videos, streams, talks, blogs, etc. coming from everyone in #InfoSec and it’s lovely to see.
Stay safe, Jabo xx