Threat modeling in the context of microservice architectures

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.

Consider the following ideas to thwart these kinds of threats:

  • Make the mobile app available through trusted sources like the Apple App Store, Google Play Store, or a recognizable secure domain (see IBM Domain Name Services).
  • Use industry standard authentication protocols, for example IBM Cloud App ID.
  • Use a cloud provider with the highest level of government certification (see IBM Cloud Security).

Tampering

Tampering refers to many forms of sabotage, but the term is often means intentional modification of products in a way that makes them harmful to the consumer.

Consider the following ideas to thwart these kinds of threats:

  • Build with Federal Information Processing Standard (FIPS)-compliant encryption container platforms like Red Hat OpenShift 4.3.
  • Scan code for vulnerabilities, for example with IBM AppScan.

Repudiation

In digital security, non-repudiation means either a service that provides proof of the integrity and origin of data, or an authentication determined to be genuine with high level of confidence.

Consider the following ideas to thwart these kinds of threats:

Information disclosure

Information disclosure is the unwanted dissemination of data technology, or privacy. There are legal and political issues to consider. Information disclosure is a violation of data privacy or data protection. The challenge of data privacy is to use data while protecting individuals’ privacy preferences and their personally identifiable information.

Consider the following ideas to thwart these kinds of threats:

Denial of service

A denial-of-service attack (sometimes called a DoS attack) is a cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to the Internet.

Consider the following ideas to thwart these kinds of threats:

Elevation of privilege

Privilege escalation is the act of exploiting a bug, design flaw, or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user.

There are many layers to think about with privilege: database management, endpoint management, container management, and there are many approaches for managing these layers. Consider ways to fight threats at the following layers of privilege:

This article and list is not intended to be a definitive guide for securing your app. The intention is to offer an example of how threat modeling works, and some of the solutions that can help thwart threats.

GDPR and privacy by design

The General Data Protection Regulation (GDPR) is a European Union regulation that helps people gain control over the way companies use their personal data. It was implemented on May 28, 2018, and violating GDPR can carry a fine of 4 percent of your company’s annual revenue, or €20 million, whichever number is larger.

GDPR basics

Data can’t be protected unless it is secure, which is why GDPR is related to security when you are designing for privacy. Aside from the financial implications of GDPR, data breaches can leave actual human beings vulnerable to real-world implications.

To quote the GDPR Privacy By Design text:

The term “Privacy by Design” means nothing more than “data protection through technology design.” Behind this is the thought that data protection in data processing procedures is best adhered to when it is already integrated in the technology when created.

I really like the idea of stepping back when designing an app and trying to model not just the security threats to a software system, but the threats presented by the abuse of a person’s personal data within the system.

In our Example Bank app, we built in some explorative UIs to show a few privacy concepts in action.

Screen capture of the main screen of the Example Bank app

It is a simulated mobile app for a fictitious bank. You can sign into the app and simulate credit card transactions.

Screen capture of the right to consent screen of the Example Bank app

When the users create an account, they select a check box to signal their consent.

Screen capture of the right to consent management screen of the Example Bank app

In the account view, users can delete data, which anonymizes tracking data, allowing it to be used for analytics but not connected to any one user.

There are other aspects that we wanted to make clear in our UI, for example the Right to Restriction of Processing and the Automated Individual Decision Making/Profile.

When creating your app, it’s important to design the APIs and controls for all of these aspects of data management. You can see how we created those APIs for the Example Bank app.

Summary

This article showed privacy and security as design considerations throughout the life of an example application. Hopefully, you now have an understanding of how threat modeling works and different ways you can use the STRIDE threat model to create applications that are secure. See how we put these concepts into practice in the Focus on data privacy with a back end for a mobile bank app code pattern.

Next steps

Use the open source code and instructions in the following content to understand the steps we followed to build the secure Example Bank cloud application with OpenShift 4.3: