Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

Last time I outlined our simple three steps methodology: Understand, Analyze and Prioritize. Sounds too simple? It may or may not be so simple depending on your viewpoint.

Let’s dive a bit deeper on the topics.

We aimed for a methodology that has no preconditions. The more preconditions required, the higher the entry hurdle for the development teams and you may end up in workshops where the preconditions are not met.

Having made that statement, there are still some implicit preconditions.

The first implicit precondition is doing workshops with experienced architects and developers of the product in scope. A big portion of the success of our approach and for Threat Modeling over all, is the fact that it can be a high quality white box approach, testing the internal structures of an application, rather than the functionality. If you have the right guys in the workshops you have great insights into the architecture, design and coding at hand. From my view point the main reason for its high efficiency and effectiveness.

The second implicit precondition is to have an architecture and clear understanding of the use case at hand. The right guys will have the knowhow for sure, but only if you are not early in development and trying to hit a moving target, which is at the very least time consuming. It is not an expectation to have an architecture diagram at hand, as it is a great activity if you draw the diagram during the workshop. (We will follow up on timing of a workshop in a separate blog also).

Last, but not least, the third implicit precondition is some security know how for the workshop. It should be noted that if the workshop moderator has security know how, the workshop experience was very good for all attendees. Be careful in the choice of the moderator, because not every security expert is a good moderator, or vice versa!

We let the guys from the development team explain their use case and their business background. Typically a standard presentation used in development for stakeholder management is sufficient as a high level starting point. Be sure that we dive much deeper – but one step after the other.

If there are multiple use cases we start with one this is security critical.

Phase 1, the understanding phase, allows for learning about what valuable assets you are protecting and where these assets are located in the architecture. This analysis consists of a mix of drawing the architecture diagram, noting down the data flow on this architecture, including the single steps and pointing out data in motion and at rest.

Interestingly you do not need to go down to the lowest level of design in the understand phase. It is sufficient if the external party or moderator understands the basics. Again we will dive deeper with each successive step.

Assuming we now have the architecture and a description of the use case, we start phase 2, analyzing the architecture element by element.

Per element we have a set of threats assigned generically. Keep in mind that the threats are our security requirements from a threat perspective.

A first check is if the threat is applicable or not. Though it is a yes / no decision it is not that simple, but I will discuss this in a later blog.

If the threat is applicable, we try to understand if there is an unmitigated risk. As an example, think about a potential SQL-Injection. If the infrastructure is not taking care of that and many do not do, you have an unmitigated risk. This is nothing that can be solved easily during design, so clearly a task for the development phase. We evaluate the risk and note it down for further processing.

As such we go through all elements and all assigned threats and once we have completed the exercise, which takes typically a few hours we are done with phase 2.

This approach sounds mechanical and checklist based. You might even think that you make or break threat modeling here. If you do threat modeling in a checklist style, you will be doomed. The participants will disengage from the workshop and turn to more interesting things like their smartphone or email. On the other hand the checklist is essential as it gives you a base line and an insurance that you cover the known things in your threat knowledge base. But do not stop here if you do not have an obvious threat. You should twist and turn it to check if a closely related attack is possible on the threat at hand and invite the team for brain storming.

For brevity I would like to refer again to a later blog where we discuss this in more depth. You need to know that the participants attention, collaboration and thinking in this really needed in this phase.

Once you are done with this phase, you can conclude the workshop. One item to be aware of is you might spend too much time in a given day for any phase. As the discussions on security in design are so intense, everyone’s brain will reach a point (typically that happens for me around 3 hours of discussion), where it’s hard to focus on the discussion. My brain starts prickling and one can easily observe that point in time, it is the moment I as a moderator start rushing through the checklist. Stop here. Postpone to another time slot…

Depending on the tooling you use, you might need to press a single button to get a full Threat Modeling report, or possibly you must write a report manually (that is the fun part of Threat Modeling).

Ideally as a rule, the moderator writes the report close to the when the workshop ended. Once the report is available it is handed over to the development team for further processing. Ensure that the project team feels the ownership of the report and are encouraged to follow up on the actions required from the threats found in the report.

Now comes the final phase, where the team discusses the findings again. This time they are deciding on how to handle the risk, with the options of accept, mitigate or delegate the risk. Each rish should be placed on their backlog list and prioritized against functional requirements.  If it is not on the backlog list, a product owner might assume that there is no effort involved, and that the developers can work on it in their spare time…

So our methodology is simple as it is really based on three phases or steps. It is a complex choreography of architecture, design and technology know how, combined with security expertise and know how. It takes these two for the threat modeling tango.

As I did last time, I would like to conclude with a question. If you are doing threat modeling what tools do you rely on?

In our next blog I would like to introduce our threat knowledge base / the SAP product standard security.

Author: Oliver Kling