"Secure to the core" has been the working model at IBM from the inherently secure high-volume-transaction proprietary mainframe systems through to today's value-added security placed on top of the open-source solutions that IBM has embraced since the 1990's. Privacy is about more than just complying with the law, though. IBM believes in getting ahead of privacy regulations because we value the trust placed in us by our clients.

Both privacy and security are concerns in today's mobile world as we carry around more personal information in our devices than we often have in any one institution (including our home).

In this article, I'll review best practices and tools, services, and frameworks that you should consider for your mobile applications that access or process personal information.

DevSecOps IS DevOps

We all experience mobile app updates regularly on our devices because apps are not static. Mobile app publishers are adding new capabilities or fixing bugs on a regular basis to continuously improve the "WOW" experience. This continued lifecycle of creating code, releasing the app, and adapting to feedback is DevOps. And, DevOps is typically done much faster than the traditional, large, heritage system efforts.

As mobile developers, we have to build the appropriate amount of security into any DevOps toolchain as early as possible. Whether you call it DevOps or explicitly identify security by calling it DevSecOps, the "appropriate amount of security" will largely depend on the sensitivity of the data that your app uses.

I'll take you on a tour around the DevOps lifecycle, specifically calling out areas to expand your security capabilities in your mobile app.

DevSecOps diagram

Mobile user authentication

First, let's get an early win with security by adding user authentication to our mobile app. Many mobile apps today onboard you quickly by just tapping into your social networks. IBM Cloud provides the App ID service that, with just a few lines of code, makes this task easy.

To demonstrate this, I'm using my Android app, Appvestr®, which you can find on Google Play. First impressions matter, and improving any required enrollment by not having to type or swipe your email address but instead being able to select from the available accounts as shown here improves the initial app experience:

Sample app, Appvestr, showing user authentication

It's easy to add the IBM Cloud App ID service into your app (be it an Android app like mine or an iOS or web app). First, you must initialize the SDK. After you initialize the App ID SDK, you invoke the resource to activate the App ID UI. You can use any custom logo and can select any identity providers, including any SAML (Security Assertion Markup Language) or custom providers, which means that you can integrate with existing systems of record or provide a single sign-on (SSO) experience.

Sample app, Appvestr, showing IBM App ID service with a custom logo

If you are working with SSO systems, then you're likely building B2E (Business to Employee/Business to Enterprise) apps to support your company's workers. For these apps, one broad operational security (the "Ops" in DevSecOps) and privacy solution would be to allow the organization's enrolled device to be wiped or disabled if lost or stolen. IBM's MaaS360 with Watson is a mobile device management (MDM) offering that provides visibility and control over iOS, macOS, Android, and Windows devices, and Internet of Things (IoT) devices too. MaaS360 limits the exposure of both private data or unauthorized access from that device to corporate assets.

Mobile privacy and security

Between early UX design and user identification and full-on production device security, there are many facets of privacy and security, including:

Privacy regulations
Data security
Application authenticity

Complying with privacy regulations

How many times have you submitted your email address to various websites and asked yourself, "what are they going to do with my personal information?" You may also be receiving more spam email as a result of one or more of those you've entered.

One of the most significant laws to come out recently is the EU General Data Protection Regulation (GDPR), which describes what kinds of information matter and how it's handled. (You can learn more about GDPR in this developer's guide to the GDPR.) IBM was planning and implementing GDPR security and privacy features well ahead of the official release of GDPR, and are continuously certifying employees on this key privacy standard.

For more complete information about GDPR requirements, be sure to review the EU GDPR compliance requirements.

As mobile developers, we'll need to support the following use cases for our mobile app users:

"Opting in" – Users must be presented with this option unchecked as the default so as not to have users unwittingly bypass this important checkpoint. We must decide in our apps if this completely disqualifies the user data as personal information (PI), and if it is fundamental to the app's operation, then exit the app. If the user declines to have PI collected and used, your app may have to use a data obfuscation approach to user identification.
"Withdraw permission" – Users will have the right, after opting in, to withdraw permission. Therefore, all your PI data for that user must then be removed, because even if you're no longer collecting it, it is stored somewhere, which falls under "processed" data.
"Data Subject Requests (DSR)" – Users also have the right to ask for their data. As mobile developers, we must build this into our mobile app security.

You must also define two other privacy roles: controllers and processors. For mobile developers, your UI and database will likely require changes:

"Controllers" control the why and how of data processing activity. That is, controllers set the rules, and you must explicitly show those rules in your app. This transparency allows users to decide to opt in or out based on how you'll use the data, now or in the future.
"Processors" process personal information (PI) in the way that is determined by the controller. If you plan on providing data to a processor, the processor must inherit the controller's rules and actions. For example, a fast food chain may team up with a delivery service. In this case, the fast food app company, as controller, defines and displays the rules, and may share PI with a delivery partner, perhaps to streamline the experience of ordering by not having to login or authenticate twice.

Controllers should track the PI data elements to ensure a catalog of usage is kept, which is, at its simplest, just another simple database that lists the fields and processors that have been given those fields, so that if data does need to be withdrawn, all downstream processors can act accordingly.

Planning and storing data securely

Now that we've planned what data we want to collect, let's plan how we're going to store the data in a secure manner.

IBM Hyper Protect DBaaS is the next evolution level on how data is stored in a highly secured enterprise cloud service that is ideally suited for workloads with sensitive data. It allows you to retain your data in a fully encrypted client database without a need for specialized skills. It is available in noSQL and SQL variants. Hyper Protect DBaaS protects against threats of data breach and data manipulation by using the strengths of LinuxONE pervasive encryption, scalability, performance, and IBM Secure Service Container technology.

When you create a service instance, you create a database cluster with one primary and two secondary database instances as replicas. Each IBM Cloud Hyper Protect DBaaS for MongoDB cluster contains a DBaaS Manager, which you can access by using a Web UI, CLI, or a set of RESTful APIs. To work with the API, authenticate your app or service by including your IBM Cloud IAM access token and user ID in your API requests. You can retrieve an access token by first creating an API key, and then exchanging your API key for an IBM Cloud IAM token and IBM Cloud user ID.

For my simple app, Appvestr, a simpler noSQL option is cost sufficient as IBM Cloudant (compatible with Apache CouchDB) is a fully managed JSON document database, with all data being both encrypted at rest and over the wire. Cloudant is accessible through an HTTPS API for web, mobile, serverless, and IoT applications. Cloudant is SOC2 and ISO27001 compliant, with HIPAA readiness optional for Dedicated Hardware environments. IBM Cloudant has a Lite plan that lets you get up and running quickly.

While accessing a database or two may be sufficient for simpler applications, most enterprise-scale mobile apps would connect to enterprise services to provide critical user-related functions. A retail application for example, must still process or inquire about orders by using the existing e-commerce platform of the store. Therefore, to integrate a mobile app with enterprise platforms, it would be easier to just use middleware such as the IBM Mobile Foundation to communicate with these back-end services.

Secure your applications

As hard as mobile developers work, there are phony app developers that may attempt to act as your front-end to your mobile backend services. One infamous example is one country's train ticketing app that had a similar but not authentic "skimmer" app that would take your credit card and add a small charge then pass on the actual ticket purchasing services.

As part of IBM's secure approach to mobile, beyond the security layers of the network infrastructure or the application server, the MobileFirst Server in IBM Mobile Foundation offers extra layers of security. These security features include the control of application authenticity and the access control to the server-side resources.

To secure your application and its adapters, enable the predefined MobileFirst application-authenticity security check (appAuthenticity) in IBM Mobile Foundation. When enabled, this check validates the authenticity of the application before providing it with any services. A security check typically issues security challenges that require the client to respond in a specific way and within a specific time period to pass the check. Applications in production environment should have this feature enabled.

Depending on the nature of your mobile app and the level of security you need, you can configure how long the authenticated token will last. The default is one hour, as most apps are "transactional," which means that we interact with them for easy use cases, and then we're on to the next task.

The who, what, wow of mobile app security

Security and compliance are vast topics that span the entire DevOps (or DevSecOps if you prefer) spectrum. IBM has always taken security topics seriously for our clients' business-critical applications. As mobile apps are on the security perimeter, the need for full-stack security only increases. However, combining a robust Security Reference Architecture with Enterprise Design Thinking can deliver a secure WOW experience to your sponsor users.

Mobile security reference architecture diagram

As mobile innovation also appears to be well-aligned with microservices implementations for several of our IBM customers, as much as we focus on security and compliance on the front-end, our backend microservices should also be secure. As part of the microserivces container offerings, the IBM Kubernetes service has a built-in vulnerability scan that is automatically invoked during your typical continuous integration and deployment toolchain activity.

Summary and next steps

No discussion of best practices for mobile app development would be complete nowadays without including mobile security as a topic. Because so many people are accessing their information and services via mobile devices, the threats from cyber-security hackers have been turned on the mobile computing space more than ever.

While mobile security is often discussed in terms of IT management, mobile application developers also must consider how to build security into their application designs. Mobile application development is faster and more iterative than traditional development; plus, developers have to deal with multiple device platforms and methodologies. They have to securely integrate into backend enterprise services and also cloud delivery platforms, and be ready to scale appropriately, even when demand occurs in less predictable patterns. What's more, there are often unique mobile requirements to manage, such as a user interface with significant restrictions in terms of real estate.

Aspects of mobile app development that are related to security for the mobile app include:

Instrument the mobile app with analytics features, risk detection, tamper proofing, and management control.
Test the mobile app by using a vulnerability analysis tool to automatically scan applications and identify risks.
Design the optimal end-user experience across mobile devices and application types (web, native, and hybrid).
Manage authentication, enforced updates, and versioning of the mobile app.
Apply risk-based analysis of business-critical transactions.
Integrate securely with backend data, systems, and cloud services.
Enable the secure distribution the app using either internal and external app stores.

Security for mobile apps has several dimensions, all with implications for the mobile app development team to one degree or another. Developers must protect the devices, manage access to the device and its data, safeguard personal information, and secure content and collaboration from the mobile device.

As discussed throughout this article, my Android app, Appvestr®, which you can find on Google Play, demonstrates some of these mobile security best practices. Get started now with your own exploration of mobile app security.

In the next article in this series, I’ll show you how you can implement data privacy options in IBM Cloud using basic Cloudant elements and a serverless monitoring agent.

Build a secure and private mobile app experience

Build a secure and private mobile app experience