Backlog item 1815: Threat Modeling your software

Are you in with the Threat Modeling movement? We are, and to be honest, I am proud of it.

In 2012 we introduced Threat Modeling at SAP, and from my personal viewpoint, this is one of the smartest moves SAP has taken within the security space for software development, thus far.

My colleagues and I plan to write a series of blog posts about Threat Modeling. You may ask why we are doing this. The answer is quite simple. We are totally convinced that Threat Modeling is a great booster for developing secure products and are happy about the progress made so far. Because of the good progress, we are motivated to share our experiences to convince you to use Threat Modeling if you have not already joined the movement.

Looking for a reason to apply Threat Modeling? Security as a topic is not an isolated event. Your code is integrating with our code, and our code integrates with another’s code, so the likelihood is not small, that if we all apply Threat Modeling, we will learn from each other, and Threat Modeling and our code will improve over time.

If I write about Threat Modeling, our internal one sentence definition is “the systematic approach to uncover security threats during design”.

Let me state upfront, Threat Modeling is not the silver bullet to solve all security challenges, but our data shows that applying Threat Modeling as one of your security measures, helps you to tackle the challenge more efficiently and effectively. This bold statement does not diminish the importance of other measures like code scans, pen testing, code reviews and others. You still need them, but Threat Modeling helps you to organize these things into a structured security big picture.

Back to the headline where you see a high number (rank) given to the backlog item “Threat Modeling your software”. This is meant to convey the priority placed on security by colleagues, which is low to zero. We all know that fixing bugs or vulnerabilities late in the development process, or even after shipment, costs much more than doing the development early in the coding. Threat Modeling allows for “the early security bird that catches the worm”, addressing security in the early stages of development, and the ability to manage this big security picture in a more structured, rational and cheaper way.

The number 1815 also might seem familiar to you. It was the year when the Battle of Waterloo was fought, where Napoleon was defeated by the Seventh Coalition. We can draw an analogy to this in the world wide security community, which has had too many Waterloos in recent years.

But I am hopeful that we can significantly avoid the number of big losses by consistently applying Threat Modeling.

So let’s talk about Threat Modeling, its costs, benefits, limitations, methodology, our experiences and more – stay tuned.

Author: Oliver Kling