Agile and DevOps are without any doubt two of the biggest security trends of recent years. The rapid rise of the cloud has only fueled the need for flexibility and dynamicity. Therefore, it’s natural for developers and organizations to seek methodologies and tools for addressing new requirements faster and innovating more efficiently.
One of the main principles of Agile and DevOps is “shift-left.” By this term, we mean the ability to anticipate some activities, make them more effective, and reduce their cost. For example, shifting-left quality means that you should anticipate testing to identify and fix bugs as early as possible. If we look at it through the lens of Microsoft Security Development Lifecycle, threat modeling is one of the best candidates for shifting left security. But how to do that? Threat modeling has traditionally been somewhat separate from DevOps automation processes. Therefore, we need new ways to make it an integral part of Agile and DevOps.
This is the story of a team of Microsoft Security experts who have joined forces with some of the most famous threat modeling experts from the community to address those concerns. The results are freely available in Integrating threat modeling with DevOps.
There is no single threat modeling process. Threat modeling represents a category of methodologies to evaluate the security of systems, identify their weaknesses, and select the best approaches to counter the potential attacks exploiting them. The Threat Modeling Manifesto represents one of the best sources to understand at a fundamental level what threat modeling is. It is designed with the non-expert in mind, but it also includes some profound considerations with significant implications for most experts.
Not all threat modeling methodologies are equal, though. Some of them focus on automating the process and allow non-experts to use them; consequently, they tend to map best practices and miss those threats that would be identified with a more holistic approach. Others rely too much on the threat modeler’s ability, causing the results to become more dependent on who is doing it. In both cases, the risk is to dilute the valuable insights with generic recommendations that the threat modeling initiative may be felt by some as a bland experience hardly worth the cost.
This is why it is so important to expand our goals and include the maximization of the value for those who consume the results of the threat model. For us, this means focusing on the return on the investment: Threat modeling has a cost, which sometimes is significant; this cost must be compensated by the perceived value of the experience. Ultimately, everything boils down to answering a single question: Can we define a threat modeling process focused on maximizing quality while lowering the costs of the threat modeling exercise?
A team of Microsoft employees covering different roles from around the company joined forces to answer this question. We dedicated three full days to finding this answer as part of a global Hackathon by Microsoft. Given that we identified efficiency as a crucial factor in achieving this result, we called our initiative the “Efficient Threat Modeling” project. The resulting paper collects the learnings from this experience, hoping that they can also be helpful to other organizations around the globe.
Microsoft has a long history and strong experience with threat modeling, and we recognize that it is impossible to achieve such an ambitious goal without help. Therefore, we invited some of the top threat modeling experts to present to us their considerations on the topic. We have had the pleasure of learning from the following experts (in alphabetical order):
Avi, Brook, Izar, and Matthew are co-authors of the Threat Modeling Manifesto.
This initiative has led to producing a paper introducing the ideas discussed during the Hackathon by the participants. While some of those ideas have been inspired or even blatantly taken from the discussions with the said experts, the paper reflects the views of the Hackathon team. As such, the considerations presented there are not necessarily endorsed or even accepted by all our speakers. In any case, we owe them all a debt of gratitude.
Starting with such great inspirational speeches, we have had plenty of ideas to select from. Nevertheless, some of them have had a more substantial impact on us. The most important learning we have taken has been related to the need to focus on the DevOps process, given its prevalence. To us, this means not only the need to make the process available to members of the team, typically by simplifying and automating it, but also to ensure that the experience is deeply integrated with the existing DevOps processes.
Threat modeling should not become yet another burden but instead, an asset to facilitate the security requirements elicitation and collection, the design of secure solutions, the inclusion of activities in the Task and Bug Tracking tool of choice, and the evaluation of the residual risk given the current and future state of the solution.
We hope that at this point you are just curious as we are about how you can achieve those great results. Of course, we do not have all the answers, but unfortunately, this margin is too small to contain it. So, if you do not want to wait 358 years to get a glimpse at our findings, you have just to jump at Threat Modeling with DevOps, where we have collected them all.