Getting Developers engaged in threat modeling?

Here’s a couple of things I focus on:

• I try to have a really well defined and documented process, with clear output artifacts.  That conveys the message that the process is not something being developed or being ‘tried out’, but rather it’s a formal company process.
• Often you can find some teams who are more interested in threat modelling, so start with them, and make the output from them available to all developers.  This shows the other teams that the process is not just for them, they aren’t the first, and won’t be the last.

In my experience getting developers or teams involved isn’t actually all that related to threat modelling at all - I think most teams appreciate security and are willing to do an activity that could improve security.  I think its the maturity of the process that matters more, so look to the other processes the team has, and mimic the ways those process seem mature (docs, broad uptake, governance, clear outputs etc.).  Create a process that respects the developers time, and they’ll respect the process.

Most development activity happens in the code that runs on that relatively unchanging architecture. You can model the functions of an application and iterate on designs before writing code, or as part of threat modeling user stories.

Identifying plausible cyber threats is a core step in threat modeling, but taking action is what leads to improved security. Development teams need to refine their threat model outputs, determine which countermeasures to act on, identify those that aren’t relevant, and which ones have already been implemented.

Finding a solution that will help Dev’s threat model application behaviour / functions will go a long way in getting their buy in especially if this is automated.