If privacy and data security were easy, instant and immediate features that you could incorporate into applications, then there would be no data breaches or invasion of the privacy of that data.
The truth is that there is no single magic solution for the security of software systems. However, there are solid building blocks and good security habits that can fundamentally help to mitigate threats.
This article considers privacy and security as part of the lifelong design of a model application. Specifically, I describe the concept of threat modeling and discuss the process that my team used to incorporate security measures into a mobile application that we call Banco Modelo.
Context
Earlier this year, my team received a feature request for one of our mobile apps that would require the storage of personal information. When launching the first version of our app, we totally avoid storing personal information to simplify the accumulated responsibility in the app. In order to implement a solution to this feature request, we need to understand what it would really take to build a version of the application that handles privacy and security well.
In our Banco Modelo application, the backend is completely cloud-based, running from Kubernetes and database services on the IBM Cloud.
Like many other apps, our mobile app started out as a simple concept, built as quickly as possible by a small team hurriedly assembled; there are no security experts on the team. Therefore, this feature request forced us to better understand native cloud security.
At IBM, we have processes, people and mechanisms in our buildings to protect sensitive data in more controlled ways. Although our team can consult all these resources, I wanted to understand what it would be like to create native private and secure cloud applications for a startup.
At the end of last year, I attended a very interesting talk at KubeCon, in which I was introduced 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
Threat modeling is a process where potential threats, vulnerabilities or the absence of safeguards can be identified and listed. In this way, mitigations can be prioritized.
The purpose of threat modeling is to provide defenders with an analysis of which controls or defenses need to be included, given the nature of the system, the likely profile of the attacker, the most expected attack vectors and the most desired assets by an attacker.
Recently, we have all accumulated first-hand experience of threat modeling in real life as we learn to survive in a pandemic. We identify the threat of being infected, or the surfaces we touch, or the threat of infecting others. Then we thought of ways to stop these threats through social distance, by washing our hands more and wearing masks. Every interaction we have is considered and measured for virus threats. This is an example of threat modeling.
Threat modeling on software systems is a similar idea. Whether from a digital virus or a digital attack, we need to consider threats and find ways to protect the system. The STRIDE methodology helps in this process, highlighting the consideration of six threat areas. The diagram I drew at the beginning of this section represents this methodology.
So let’s look at threats to our mobile application software architecture.
