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
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.
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:
- Use a reliable and well featured logging service, such as IBM Log Analysis With LogDNA.
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:
- Manage security certificates well and help encrypt transmission of data, for example with the IBM Certificate Manager.
- Build on a FIPS-approved encryption platform like Red Hat OpenShift 4.3.
- Benefit from a database hosted with strong enterprise security encryption at rest, for example IBM Cloud Databases for PostgresSQL.
- Protect encryption keys with IBM Key Protect.
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:
- Use reliable public cloud hosting tools, for example, in our case: IBM Cloud Internet Services.
- Consider rate limiting.
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:
- At the container level, you can use role-based access control with Red Hat OpenShift.
- At the intra-microservice security level, you can use Red Hat OpenShift Service Mesh.
- At the level of managing passwords and accounts, you can use IBM Security Secret Server.
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.
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.
It is a simulated mobile app for a fictitious bank. You can sign into the app and simulate credit card transactions.
When the users create an account, they select a check box to signal their consent.
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:
- Blog post: Build secure microservices applications with OpenShift 4.3 on public cloud
- Article: An introduction to OpenShift 4
- Tutorial: Fun with OperatorHub
- Code pattern: Focus on data privacy with a back end for a mobile bank app
- Code pattern: Microservices with the OpenShift Service Mesh
- Tutorial: Build serverless Node.js applications with the OpenShift Serverless Operator
- Tutorial: Build a Tekton Pipeline to deploy a mobile app back end to OpenShift 4