This content originally appeared on Level Up Coding - Medium and was authored by syIsTyping
A brief summary of the talk by Katherine McKinley titled “Thinking about what can go wrong — Threat modelling for developers”
I recently watched this talk about threat modelling, it’s a short talk but there’s quite a bit of insight to unpack, here’s a brief summary.
Summary
The speaker starts with the notion that preventing bugs is better than finding bugs; that bugs found in maintenance phase cost up to 100x more than preventing them in the first place. Therefore in the context of vulnerabilities (ie, “security bugs”, my words) it is better to “shift left” security activities: moving security activities earlier in the process.
One of these activities is threat modelling: looking at what you have and understanding what can go wrong, so as to understand the risks of the product. It is something that anybody can do, not just for security experts, and in fact the developer is probably the best person to threat model for their product since they are closest to it.
The speaker explains the components of a threat model (assets and communications) and goes into detail how to do threat modelling, specifically how to identify threats using the STRIDE model. A worked example was used (a basic ID verification service) to show the application of the STRIDE model, including how to mitigate the identified threats.
There was an interesting question during the Q&A: should threat modelling come before or after design review, since the results of threat modelling might result in major changes to the design? The answer: the system design would have taken into account security requirements, and we might have identified threats while doing the design. However, it is when considering the (full) design that more threats might be identified. That said, the process of threat modelling and system design is continual. This is one reason it is important for developers to do the threat model, so that the threat model can be kept up to date as design changes.
Recommendations:
- “Threat Modeling — Designing for Security” by Adam Shostack. “foundational book in threat modelling space”
- awesome-threat-modelling
Observations and thoughts
- The part that stood out most was that threat modelling is “not just for security experts, and in fact the developer is probably the best person to threat model for their product”.
- Indeed, as the team that designed, built and maintain the product, the developer team would know all the nitty-gritty, the strange behaviour and the ahem workarounds in the product. They are also best-placed to identify logic errors or undocumented/unintended features.
- The topic of threat modelling is gaining lots of focus. In fact the new 2021 version of OWASP Top Ten has just such a new category: Insecure Design.
- “Insecure Design” emphasises on “risks related to design and architectural flaws”, advocating for threat modelling (among other things), and shifting-left into pre-code activities.
- I end this recap with this outstanding quote from “Insecure Design”:
An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.
References
Some other articles you might like
Hi, if you enjoyed this post, I thought that you might keen on the Medium membership to get access to quality content from Medium writers, feel free to use my referral link!
Recap: Threat Modelling and Developers was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by syIsTyping
syIsTyping | Sciencx (2022-03-16T18:11:55+00:00) Recap: Threat Modelling and Developers. Retrieved from https://www.scien.cx/2022/03/16/recap-threat-modelling-and-developers/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.