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.

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.

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.