Article

Threat modeling in the context of microservice architectures

Introductory thoughts on designing for privacy and security

By Anton McConville
Updated August 4, 2020 | Published April 24, 2020

If data privacy and security were easy, instant, and immediate features that you could build into applications, then there would be no data breaches or invasion of data privacy.

The truth is that there is no single silver bullet for security in software systems. However, there are strong building blocks and good security habits that can help mitigate threats foundationally.

This article considers privacy and security as part of design throughout the life of an example application. Specifically, I outline the concept of threat modeling and discuss the process that my team used to build security into a mobile application that we call Example Bank.

Background

Earlier this year, my team received a feature request for one of our mobile apps, which would require personal information to be stored. In the first release of our app, we avoided storing personal information at all to simplify liability within it. To implement a solution for this feature request, we needed to understand what it would actually take to build a version of the app that handled privacy and security well.

In our Example Bank application, the back end is completely cloud-based, running on Kubernetes and database services on IBM Cloud.

Like many other apps, our mobile app began life as a tiny concept, built as quickly as possible by a hastily assembled small team. There are no security experts on the team. So, this feature request forced us to better understand cloud-native security.

At IBM, we have processes, people, and mechanisms in our builds to secure sensitive data in more controlled ways. While our team can consult all these resources, I wanted to understand what it would be like to build secure, private cloud-native apps for a startup.

At the end of last year, I attended a really interesting talk at KubeCon that introduced me to the concept of threat modeling, and the useful STRIDE methodology, an acronym and framework for considering threats to a system.

Threat modeling with STRIDE

Graphic showing what the letters of the STRIDE threat model represent: Spoofing, Tampering, Repudiation, Info disclosure, Denial of service, and Elevation of privilege

Threat modeling is a process where potential threats, vulnerabilities, or the absence of safeguards, can be identified and enumerated. Then mitigations can be prioritized.

The purpose of threat modeling is to provide defenders with an analysis of what controls or defenses need to be included, given the nature of the system, the probable attacker’s profile, the most likely attack vectors, and the assets most desired by an attacker.

Recently we all gained first-hand experience of threat modeling in real life, as we learned to survive in a pandemic. We identified the threat of infection from other people, or from surfaces we touch, or the threat of infecting other people. Then we thought about ways to thwart those threats by keeping social distance, washing our hands more, wearing masks. Every interaction we have is considered and measured for threats from the virus. That’s an example of threat modeling.

Threat modeling in software systems is a similar idea. Whether from a digital virus or a digital attack, we need to consider the threats and find ways to protect the system. The STRIDE methodology helps with this process by asking us to consider six areas of threat. I drew the diagram at the top of this section to depict it.

So, let’s think through the threats for our mobile app software architecture.

Threat modeling for our example cloud-native application

Here’s the basic cloud architecture for our Example Bank credit card application.

Architecture diagram of the example credit card application

The running app uses HTTPS on a domain that is directed to the hosted microservices running on Red Hat® OpenShift® on IBM Cloud™. A person can create an account (via IBM App ID) by using a generated name for testing purposes. Then, when a person hits the home button of the app, they can click on the various app icons there to create credit card transactions.

Our cloud software to support the feature has three microservices. For more details, you can read about the architecture of the mobile app.

As an exercise, consider the different elements of the STRIDE threat model for such a system, and some initial ideas for thwarting threats. This is not a thorough list, just a set of jumping off options we identified for our use case.

Spoofing

In the context of information security (and especially network security), a spoofing attack is a when a person or program falsifies data to to gain an illegitimate advantage, successfully identifying as another person or program.