Welcome back to our Threat Modeling blog. I think it is quite interesting and helpful to talk about the introduction of Threat Modeling @ SAP.
In 2012 my boss asked me to lead a project introducing Threat Modeling into SAP development. I had initial conversations with a colleague who was driving the topic for quite some time. To get an overview I asked that colleague to give me an explanation on a whiteboard who is now and should be involved in this project. After 10 minutes the whiteboard was full with teams, names of persons, and organizations that where involved so far. Looking at this complex stakeholder landscape, it was clear to me that a project setup involving many people spread across different organizations is not what I wanted to manage. So I raised a thought provoking question to my colleague, if you could work with just one person to drive this topic, who would you pick?
The answer to the question was him and I, which in the end, disappointed other colleagues that were not included. Unnoticed by me, I became quite famous with this 2 person working arrangement, but unfortunately not the fame you typically seek. A year after the project started, while speaking with a colleague, he stated: we have not previously met, but I was very disappointed when you stopped collaborating with us on Threat Modelling. Luckily, I did not know about unwanted fame in the beginning, which would have bothered me. Not knowing in the beginning allowed us to complete the outlining of the basic concept for Threat Modeling @ SAP in a few working sessions.
We came to the conclusion that the methodology needs to have some basic characteristics. It should be self-contained to avoid a huge number of preconditions to be met before a development team starts using the process. It should be time boxed to achieve concrete results in an acceptable time frame. It should be done with the architects and developers that work in the heart of the product. It should center on our existing security product standard. It needs to fit into any development process and approach. And last but not least, it should help increase the efficiency in code scans and testing.
The result was a simple three step methodology consisting of 1) understanding the architecture of a use case, 2) analyzing this use case’s threats in detail (based on the product standard requirements converted into threats), and finally, 3) prioritize the identified threats on the products backlog.
We did not spot the obvious obstacle (at least from hindsight) right from the beginning. When we applied the methodology in the first workshops we immediately saw that you cannot easily scale this approach across a huge product. Eating such a huge product piecewise will take a considerable amount of time. With this in mind, we concentrated on the use case based approach for the time being, and ignored a high level architecture approach for later on.
Overall, we did more than a hundred different Threat Modeling workshops across the SAP product portfolio and the basic idea of our methodology works very well.
Next time let me talk about this methodology in detail, but in closing let me pose the following question to you. Should Threat Modeling be mandatory in your opinion?
Author: Oliver Kling
