(Continuous) threat modeling: What works?

Description

For years security practitioners have been discussing how to do threat modeling the “right way.” There are many available methodologies, both formal and casual, along with many years of discussion into how to apply threat modeling to the world of Agile methodologies, continuous delivery, fast-moving frameworks, and languages and product integration. Most challenging is the question of how to still produce meaningful results without having a bottleneck in the much sought after security expert—in other words, how to enable teams to threat model their designs and products, taking into account that security may not be a strong part in the teams’ toolkit.

Autodesk has tried to solve these issues by going back to basics, focusing on what to look for as well as the security basics that every architect and developer should aware be aware of as a matter of fact: defending “the crown jewels” against flaws (not against specific threats); helping developers move into a culture of secure development by providing them with a guiding framework (not hours and hours of training); and dealing with issues at their root cause instead of specific best practices.

The company coupled this approach with an attempt to make the threat model a living document, using a “Threat Model Every Story” motto to help every developer make a habit of looking at security in their code, as it is written, in the same way they look at performance (i.e., security as a hallmark of quality code).

Izar Tarandach explains how this approach has worked, discusses both good and bad experiences, and shares lessons learned along the way.