Since the dawn of civilization, human beings have wanted to standardize the great technological advances they have generated. The Roman Empire extended its way of building roads, bridges, and aqueducts throughout the territories it conquered. The infrastructure of the entire empire was standardized. The factories of the Industrial Revolution followed similar patterns all over the world. And, after all, issues such as the highway code for vehicles are virtually the same all over the world. In one of today’s most important areas – cybersecurity – standardization is also being used to ensure that similar security requirements and tests are implemented globally. This is precisely the objective of OWASP and also that of Google MASA, a mobile-specific section that is part of the App Defense Alliance initiative.

Today there are thousands of mobile applications. In fact, through apps, we can carry out hundreds of actions in our daily lives. This also means that there are a huge number of companies developing them, from all over the world and in a wide variety of economic sectors. This immense diversity, so valuable for users and companies, poses a challenge in terms of the security of the application ecosystem. How can apps that are so different from one another be evaluated? What security requirements are established? In a global economy, who determines which protocols and procedures to follow?

To deal successfully with the diversity of the application ecosystem, we need to turn to our old ally: standardization. That is why the OWASP Foundation collects cybersecurity best practices from around the world and publishes materials, guidelines, and methodologies that have become a standard used and accepted around the globe.

1. MASA, the framework that encompasses the Ms of security for mobile apps

Such is the relevance of the OWASP methodology in the cybersecurity sector that Google has used it to launch a major initiative for securing mobile applications: MASA.

1.1. Google MASA Framework: Protecting yourself and building confidence

The Mobile Application Security Assessment (MASA) is a project that seeks, as its name suggests, to promote the security assessment of mobile applications. To be more specific, of the apps that are available to all users in the Play Store. Thus, developers who submit their apps to such evaluations will obtain:

• A comprehensive overview of their level of protection, implementing the necessary modifications to remedy the vulnerabilities found during testing.
• A badge that will appear in the Play Store to let users know that the application is protected.

What do these security assessments consist of and who performs them? This is where two fundamental documents generated by OWASP come into play: MASVS and MSTG.

1.2. MASVS: Security levels and controls that apps must comply with

The OWASP Mobile Application Security Verification Standard (MASVS) compiles, systematizes, and standardizes the security requirements that mobile applications must meet to protect against malicious attacks and the exploitation of vulnerabilities. To this end, MASVS implements a system that combines two elements: security levels and requirements.

The OWASP proposal contemplates two security levels. The first (L1) is recommended for all applications on the market. The second (L2) should be met by applications that handle sensitive data, such as banking apps.

On the other hand, it establishes a series of requirements grouped into seven broad categories. Thus, depending on the chosen security level, only the L1 requirements must be met or, in addition, also those designed for L2 and which are more demanding or specific.

1.3. MSTG: Test to verify

But OWASP’s work is not limited to stipulating a series of security requirements, which apply to any type of application, regardless of its origin or characteristics. It also has a guide to standardize how tests should be run to check whether or not apps comply with MASVS security requirements.

This document is the Mobile Security Testing Guide (MSTG). A top-level working tool used by cybersecurity analysts around the world. The MSTG stipulates precisely what procedures must be carried out to perform each test and offers technical solutions to facilitate the work of professionals.

Recognized as a de facto standard, the MSTG ensures that security tests are homogeneous, whoever performs them and whatever the application under test.

Thus, the MASVS establishes the security requirements and indicates which test must be performed to verify each requirement. While the MSTG develops the procedures that must be put in place to perform each of the tests successfully. From there, it will be the turn of analysts and companies providing cybersecurity services. They must have the necessary knowledge, technical expertise, and experience to perform the tests successfully.

2. The requirements in the latest version of Google MASA

Originally, Google MASA referred to the evaluations of apps joining the project as having to meet the MASVS requirements for security level 1.
However, in the latest version of the initiative, which was released in July, the requirements of MASVS category one: architecture, design, and threat modeling requirements, have been eliminated.

In addition, it should be noted that Google MASA does not require all level 1 requirements, but that some of them are not part of the MASA specifications. Therefore, it is important to detail precisely which are the 32 requirements that mobile applications must meet if they want to comply with Google MASA requirements.

In the following, we will address these requirements and the tests associated with them, dividing them into the six MASVS categories relevant to the evaluation required by Google.

2.1. Data Storage and Privacy

One of the most important aspects of the security of mobile applications is the storage and protection of sensitive user and business data. Since:

• Sensitive data contained in one app, can be exposed to another app running on the same device.
• Data can leak into the cloud, backups, or the keyboard cache.
• Mobile devices can be lost and stolen, facilitating physical access to data.

As a result, some controls are necessary to secure sensitive information. Of the eight requirements listed in MASVS for security level 1, Google MASA requires compliance with the following six:

1. The credential storage functionalities of the system must be used to store sensitive information. Among these, OWASP highlights personal information, user credentials, or cryptographic keys.
2. Sensitive information should not be stored outside the application container.
3. Sensitive information is not written in the application’s logs.
4. Keyboard caching is disabled on text fields containing sensitive information.
5. No sensitive information is exposed through the user interface. This information includes such important data as passwords or credit card numbers.
6. The application provides the user with full information about the personal data it processes and the security best practices that the user should follow when using it.

2.2. Cryptography

Cryptography is a central element in the development of applications and, also, in their security. Therefore, it is crucial that developers scrupulously follow standard cryptographic conventions, as well as global best practices, paying special attention to three basic issues:

• Use of secure and well-tested cryptographic libraries.
• Proper choice and configuration of cryptographic primitives.
• Use of secure random number generators.

To verify these issues, MASVS establishes six security requirements, applicable to both level 1 and level 2, which are also required in their entirety by Google MASA:

1. The app does not rely, exclusively, on symmetric cryptography, whose keys are present in the source code of the application.
2. Well-proven cryptographic primitives are used.
3. The cryptographic primitives used are appropriate for the particular use case of the app. Furthermore, their configuration has been carried out following the best practices in the field.
4. No cryptographic protocols or algorithms considered obsolete in terms of security are used.
5. The same cryptographic key is not reused for multiple purposes.
6. A secure random number generator is used to generate random values.

2.3. Authentication and Session Management

The experts in charge of conducting MASVS argue that a vital part of the overall architecture of mobile apps is that users must log in to a remote service. And while this is server-centric, it is important to set requirements focused on how each user’s accounts and sessions should be handled.

Of the eight requirements for applications undergoing a Level 1 assessment, Google MASA includes the first six:

1. Authentication for remote services. This implies that an authentication mechanism including username and password is put in place on the remote server.
2. If stateful session management is used, the remote server must use randomly generated session identifiers to authenticate client requests without sending credentials to the users.
3. If stateless token-based authentication is used, the remote server must provide a token that has been signed using a secure algorithm.
4. As soon as the user logs off, the session also ends on the server.
5. A password policy has been established and is enforced on the remote server or endpoint.
6. The server implements a protection mechanism if excessive authentication credentials are entered.
7. Sessions are invalidated on the server after a predefined period of activity occurs. Likewise, access tokens also expire after this period.

2.4. Communication over the network

An important aspect when checking the security level of an application is the communication between the application and the server services. It is therefore essential to guarantee the confidentiality and integrity of the data exchanged. For this purpose, MASVS version 1.4.2. establishes that, as a minimum, secure and encrypted channels must be used, using the TLS protocol, according to the appropriate configurations. This translates into three basic requirements that must be met by all applications subject to level 1 verification:

1. The information is sent, in encrypted form, using the TLS protocol. And the secure channel is used consistently in the mobile app.
2. The TLS protocol settings are in line with industry best practices. In case the operating system of the mobile device does not support the recommended standards, these practices are followed as best as possible.
3. The application verifies the X.509 certificate of the remote endpoint when establishing the secure channel. In addition, only certificates signed by a trusted Certificate Authority (CA) are accepted.

2.5. Platform Interaction

This category of MASVS requirements focuses on verifying that the platform APIs and standard components are used securely. In addition, the four Google MASA requirements focus on how communication between apps takes place: inter-process communication (IPC). It should also be noted that MASVS includes four other requirements necessary for level 1, in addition to those listed below:

1. The app requires the minimum amount of permissions necessary.
2. All inputs coming from both the user and an external source are properly validated and, if necessary, sanitized. This includes information received through IPC mechanisms such as Intents, URLs, and data coming from the network.
3. No sensitive functionality is exposed through URL schemes. And if it does, it is because this mechanism is protected with guarantees.
4. No sensitive functionality is exposed through IPC mechanisms. Unless, as in the previous case, these mechanisms offer sufficient security guarantees.

2.6. Code quality and compiler configuration

The last category of MASVS that includes requirements for security level 1 revolves around code quality and compiler configuration. Through these checks, OWASP seeks to encourage testers to ensure that basic security practices were in place when developing the application. And that the functionality provided by the compiler has been enabled. This translates into nine requirements, applicable to both level 1 and level 2. However, Google MASA only requires compliance with the first five and the last one:

1. The application is signed and has a valid certificate, whose private key is optimally protected.
2. The app was published in relay mode and with the appropriate settings.
3. The debugging symbols have been removed from the native binaries.
4. Debugging or developer support codes have to be removed. For example, test code, backdoors, or hidden configurations. In addition, the application should not make detailed logs of errors or debug messages.
5. Third-party components have been identified and reviewed, taking into account known vulnerabilities.
6. The free security features of the tools are enabled. Some of these features are byte-code minification, stack protection, or automatic reference counting.

3. A comprehensive security verification system for apps.

Although the key to OWASP’s standard verification system lies in the relationship between the MASVS security requirements and the tests associated with each of them that appear in MSTG, both documents include further information that is of great help to analysts, cybersecurity service companies, and mobile app developers.

Thus, MASVS, at the end of each category of requirements, provides a section of information linking these requirements with the OWASP top 10 mobile application risks and with the main known vulnerabilities (CWE) in these areas. This helps to provide the entire OWASP methodology with coherence and cohesion. And helps analysts to perform their activities within a standardized and common framework.

For its part, MSTG, in addition to contextualizing and explaining multiple tests that allow verification of compliance or non-compliance with requirements, provides technical solutions and methodological advice. In addition, at the end of this detailed guide, the OWASP team provides analysts with a series of testing tools to facilitate the requirements evaluation process.

4. What happens if the applications do not meet Google MASA security requirements?

If once the authorized laboratory performs the evaluation, it detects requirements that are not met, and the developer must carry out the necessary actions to correct the security problems or inadequacies found.

In this task, he will rely on the report issued by the evaluators. This document should include assessment comments and provide the steps to be taken to remedy the vulnerabilities detected. Once these actions have been completed and the app meets the requirements, the lab will send a validation report directly to Google, so that it can issue the Google MASA badge.

Hence, the company performing the app security assessment process must have an extensive background in cybersecurity and cyberintelligence. Not only does it have to carry out the tests. But it must also have the necessary knowledge to make recommendations that are in line with the problems detected and the characteristics of the mobile application under study.

In short, Google MASA framework is based on the OWASP methodology to extend standard security requirements throughout the mobile application ecosystem.
To this end, apps must undergo independent evaluations in which, through the tests included in the OWASP MSTG, it is checked whether the mobile applications comply with the basic security requirements included in MASVS. The ultimate goal is to safeguard the information entrusted to them by companies and individuals. And to protect businesses’ and users’ privacy.