2021-02-27, 11:00–11:30, ZOOM
In this talk, I will show how our team Threat Models during security testing projects to achieve the completeness of the scope of work. We use gamification to improve this process and I assume it is much less boring than you expect from a threat modeling session. I will share the tools we use and a general approach to the game.
It is funny when I hear security vendors talk about "pushing appsec left" in the development lifecycle. Given that Threat Modeling is the leftest left of all lefts, they actually mean SAST, DAST, DeveSecOps, or another buzzword du jour.
It is fine (dog meme here); you can get away with an "implicit threat model", or rely on your "expert intuition" in most cases. However, one day you will encounter something you never met before, and this approach will fail you, your team, and your client. You will still test the product, but you will not be sure if you did everything you could. You could use some checklists and testing guides, of course, but we all know that even the OWASP Security Testing Guide in all its glory covers only that much of the scope.
This is where offensive Threat Modelling comes in. Usually, we succeed by thinking like the attacker, but here we should turn around and think like the developer. By going through the usual Threat Modeling cycle and applying STRIDE, we can brainstorm and write down all the things that could go wrong and then move out to simulate them. From theory and practice, this is a much more reliant approach for scope definition. And even if you fail to achieve full completeness of testing, your client will at least end up with a decent Threat Model.