After peeking behind the curtains in our blog posts about Bug Bounty and Application Security testing, we’re continuing our series about how we secure SAP S/4HANA within our secure software development lifecycle by taking a step back. One of the first things we do when we develop and even design our software is called “Threat Modeling”. It’s mandatory at SAP and it also requires a sound knowledge on security – and in a way, you need to be able to think like a hacker. Let’s look into some details.

Firstly, a short introduction into “Threat Modeling”. Since I like analogies, imagine a jeweler. They have some items displayed in the shop window. Most probably not the most valuable ones, but enough to attract attention. Inside the shop, they also have displays, where more of their range can be adored. Lastly, they have a safe (or even more than one) where the real valuable items are stored.

How to break into a jewel store

Now, when you do threat modeling, you ask yourself how a potential shop breaker might be able to get to these different points. To stay in the analogy: the shop window is easiest to get into, but still needs some basic protection (e.g., special hardened glass). But what about the backdoor? The displays inside are a bit more secure, since someone needs to be inside to break and empty them – a security guard would mitigate most threats in this case. The last line of defense, the safe, is already pretty secure, only very professional criminals will be able to get in – the jeweler would need to weigh the potential costs of securing the safe even more against the reduced risk.

As I said, the principle is easy. For our software solutions it means that we are validating the software architecture against potential security threats.  And when you are trying to secure an application, you’re almost literally will be doing what I just described.

There is another commonality between the jeweler shop and software. It does sound relatively easy, validating and analyzing the security measures of the jeweler, right? But that does not mean that anyone can do it, on the contrary. In order to evaluate the effectiveness of all these security measures, an independent expert is usually involved. They probably need to know the different glass options a jeweler has for their shop window as well as the various safety measures that a safe provides – in other words, they must be experts on different fields, and they would have to think both like a burglar and the jeweler at the same time.

A year of Threat Modeling

Similarly, those experts at SAP that lead the threat modeling for our different pieces of software have undergone a thorough and extensive education on the subject. In fact, it takes well over a year of trainings, workshops and self-study to be able to lead a threat modeling workshop at SAP.

Make no mistake, though – our developers really like doing Threat Modeling Workshops. The outside expert brings in new angles and ideas about “what could go wrong”.  It is a perfect opportunity to take the time to only think security and validate the already planned measures. Nobody wants to implement software that can break easily.

Looking at it from a different perspective (and yes, I’m using a “buzzword here”), our threat modeling approach shows that we already have implemented the “shift-left” approach, which is a different (and currently rather trendy) way of saying that you want to build security into your product as early as possible. With our threat-modeling approach, this is about as “left” as you can get, literally starting when the software is still a sketch on a whiteboard.

Where to find threats

Going back to the specifics, however, how do we actually perform a threat modeling workshop? Software these days is highly complex, so those workshops would not work without some kind of tools and methodologies. Also, we are not only looking at the security of the solution, but also at the data privacy and protection. And, since we’re a cloud company as well, we don’t restrict our analysis to just the application – we’re also looking at the infrastructure, at the database and at how the solution can be operated securely. In other words, as with our other security measures, we view security and privacy holistically.

In our threat modeling workshops, however, it all starts with the architecture.

What’s helping us in getting a clear view on the architecture is : Technical Architecture Modeling (TAM), which is an SAP internal standard, combining FMC and UML. This standard is used in every threat modeling workshop.

Another tool, or rather methodology, we use is STRIDE. Without going into details, it’s a great approach to make sure you cover most of the potential risk that software might be exposed to.

There are, of course, quite a few items more on our list of tools and methodologies – most of them could come straight out of a hackers’ toolbox. What’s more, for each item on the list, there are usually several ways to achieve them, including combined vulnerabilities. Which brings me back to my point on software complexity: even if you know which risks you are exposed to, you still need to have an expert to properly evaluate these risks.

The Threat modeling mindset

At SAP, we are lucky to have these experts – and even though it takes a long time to become an expert for threat modeling, we have a long list of colleagues who are not only motivated, but enthusiastic about helping fellow developers secure their software. Which is great, as SAP software tends to be more complex than other software in the market. Take SAP S/4HANA as an example. With more than 300 million lines of code for the core itself, a continuously updated feature set and more and more integrations of other SAP solutions into SAP S/4HANA, threat modeling at SAP and specifically in our SAP S/4HANA Security Team is a continuing story. Just looking at our team, it wouldn’t be a bold statement to say that not a week goes by with at least one threat modeling workshop.

All in all, threat modeling is one of the first steps that anyone should follow when designing new software or in software development in general, for that matter. At SAP we surely take threat modeling seriously, with different tools to support our security experts and even a security curriculum which is focused on enabling more colleagues to lead threat modeling. This strong focus on threat modeling also shows another truth which I witnessed since my very first day in the SAP S/4HANA security team: security is not only part of our processes at SAP, it’s a mindset that everyone in the company has internalized.

Going back to the jeweler: He will mitigate the threats he found to protect his goods. Just as we at SAP will mitigate the threats to protect our customers’ jewels – their data.