In Part 1 of this series on Mobile App Security, we introduced the first set of the Twelve Basic Tenets of Mobile App Security:
1. Protect data from disclosure for confidentiality reasons
2. Protect data from alteration for integrity reasons
3. Protect data from resource-loss for availability reasons
4. Map and monitor data flows for auditing reasons
“Doveryai, no proveryai.”
This is one of the hundreds of Russian proverbs that have found their way into the lexicon of various industries and governments, and the one most famously used by President Ronald Reagan during his Cold War negotiations with the USSR.
“Trust, but verify.”
It’s an incredibly important concept wrapped into three simple words, especially when it comes to security. Protecting a business against threats is more than simply preventing unknown bad actors on the outside from getting in; it’s also about ensuring that what is inside isn’t, or doesn’t turn, bad as well. A company’s security posture must be flexible, nimble, and willing to turn a curious and critical eye toward any part of the eco-system, inside or out, to identify and mitigate threats against a company’s assets: data, people, processes. Relying solely on static trust, without continuous verification, will result in failures in the security line.
That is why the second set of security tenets around which Mobiquity constructs its security posture focuses on verification of the subjects interacting with corporate objects:
5. Authenticate requests to identify the subject
6. Authorize the role to define privilege
7. Audit the operations for evidentiary collection
8. Manage configurations, session and exceptions
Authenticating the subject can take a few forms, as the subject may be a user or another piece of software, but in general the act of authentication in a mobile solution is actually an implied trust based on the fact that the system interrogating the subject’s credentials is the same (or similar) system that supplied the credentials for authentication in the first place. This is why it is so important to not rely solely on authentication as a means to access a system, and why often times multiple factors of authentication are required. With human subjects, multi-factor authentication is often performed leveraging two of the three classes of authentication—something known, something possessed, and something inherent—so that a user can access a system only by authenticating via a password (known), an ID card (possessed) and/or a fingerprint (inherent).
Similarly, a mobile app will be (or should be) subject to another form of authentication control using keys, generated pseudo-random strings of alphanumeric characters that are securely stored locally and presented whenever access to backend services is required. Keys of this form provide a different and superior level of security because they (1) have higher orders of entropy because software doesn’t need mnemonics to remember things, (2) are more auditable because they are generated on-demand from a single-sourced request, and (3) are much more limited in exposure, not written down on slips of paper or reused over and over by one or more human subjects, but instead stored in a secure storage area and accessed only when required.
On top of authentication, that of knowing the subject, the act of AUTHORIZING the subject is designed to ensure that even valid users of the system are kept out of areas in which they do not belong. Where authentication acts on validation, authorization acts on permission, with the permission defined in the form of a list or by roles. Properly constructed authorization defines the least-privileged access to resources, thereby reducing the exposure of corporate assets to the minimum number of subjects required and minimizing the common threats of misuse, error and malfeasance.
Combined, authentication and authorization form the minimum set for access control, that of allowing or preventing access to a resource through the interrogation of credentials and the assessment of permissions. Generally this control takes one of two forms: Access Control Lists (ACL) or Role-Based Access Control (RBAC). While each has its place, RBAC in mobile has proven to be a superior form of security because it allows for dynamic access control, it removes the development team from the vast amount of responsibility for designing permissions and control upfront, it enables roles assigned to people as well as processes (software), and it ensures the seamless separation of duties where required. It is why so many regulated industries, including payment and healthcare industries, rely on RBAC for compliance.
Even with these mechanisms in place to control access to protected resources, the integrity of those resources must be protected through the use of AUDITING, without which there is no guarantee as to the validity of the object being accessed. Proper auditing ensures that any modifications to objects are tracked with appropriate information logged—including user, role, time and versioning—and continuous monitoring of these logs can reveal areas of threat, both internal and external, that are in need of remediation.
The final tenet in this set is the MANAGEMENT of configurations, sessions and exceptions. While it should go without saying, this is an oft-overlooked piece of the app security puzzle. Configuring security groups and roles to ensure least-privileged access, and maintaining that configuration in the face of changing demands, roles and resources, requires constant vigilance with the DevOps/SysOps team. As important is the management of active sessions on the server side—ensuring tight session timeouts, smart caching policies, session binding and attack detection algorithms—and on the client side—tight login timeouts, forced token refreshes and automatic logouts. And finally, ensuring that exceptions in the communication between mobile app and servers are properly and elegantly handled adds significantly to the robustness of the solution.
Security in the mobile world requires a multilayer, multifaceted approach that relies on an integration with existing backend processes. This is especially true with B2E applications that are delivering sensitive corporate data to its most vulnerable of assets—the employee. Best practices for secure mobile app development are built over years of research and applied practice, and while a number of tools and frameworks can help in building out and maintaining such best practices, the key is to have these practices in place and in use with skilled development teams before attempting to deliver an app to its intended end-user. And skilled teams emerge with education, proper tooling and defined processes, all of which happens in a continuously evolving cycle, growing over time and not overnight.
This is where enterprises should take advantage of mature enterprise mobile service providers, and partner with them to either develop or review their existing tools, applications and infrastructure to ensure that mobile apps are adhering to the highest levels of app security and compliance.
Coming up: Part 3 in this series of mobile app security will explore the attack surfaces for mobile solutions.
Leave your details below and we'll be in touch soon.
