The ADA (App Defense Alliance) has launched an evaluation standard with the MASA program. It allows developers who have applications published in the Google Play Store to get their apps evaluated by an official lab partner. Most important, developers can receive the official Security Badge that fosters trust in their applications.
With our last blog posts, we already gave you an insight into the basics of mobile app security. We introduced you to OWASP (Open Web Application Security Project), MASVS (Mobile Application Security Verification Standard), and why third-party testing must be a fixed part of the application development cycle. With MASVS, the OWASP has developed an industry-wide standard that provides guidance based on its test criteria and has laid the foundations for mobile security.
To understand the process a little better, below are 7 things you should know before evaluating your applications through the MASA program.
The assessment covers all aspects of client-side security, authentication to the backend/cloud service, and connectivity to the backend/cloud service, including general security and privacy best practices.
As one of the five officials authorized labs to conduct the assessments for MASA, you can directly begin the testing process with DEKRA. Firstly, you have to review and full fill out the intake form on our MASA page. To facilitate the whole process, verify our checklist before the preassessment. Additionally, you can log in to our free pre-assessment online tool.
One year. Recertification is required after one year. DEKRA has a renewal program for apps that needs to be annually checked to maintain the Security Badge.
The free pre-assessment helps to identify potential vulnerabilities within your app before the actual MASA and thereby provides the opportunity to remedy these. So you are saving time and money by performing the pre-assessment upfront. Fees for MASA vary depending on apps, but on average you can expect the assessment to cost between $3-6K.
After completing the required paperwork, you can expect a lab report within 10 days, although completion times can vary based on lab feedback and your team’s ability to implement changes quickly. The best approach is to follow the checklist and the pre-assessment to be sure that your app is in a position to perform the assessment satisfactorily.
OWASP and MASVS can be used with any mobile app, including IoT, fitness/health, social, communications, VPN, productivity, and many more.
DEKRA never discloses any findings to 3rd party. A summary will be shared with Google once the app has met all of the requirements, which will be made public on the MASA Directory. You have complete control over when you want to make these results public.
By incorporating the new MASA validation into the compliance process, it provides various benefits to your company and in particular to your users. First, conducting regular mobile app security is fundamental because this guarantee that your apps follow security best practices in development and that the developers are aware of the new threats that emerge on a daily basis. This increases the transparency and the download rate.
Furthermore, it is important to point out that a 3rd party lab review helps the development team identify/mitigate usual topics in mobile security that could lead to vulnerabilities and in most cases the loss of confidence by your users. So MASA isn’t just an investment in your mobile security but in trust in your application.
Last week we introduced the Mobile Application Security Verification Standard (MASVS) which intends to increase the security of mobile applications by providing a guide and metric for app development. But mobile application security doesn’t end with that.
In order to function properly, mobile application development requires software teams to configure a variety of communication and component layers. However, each layer a developer adds to a mobile application increases the attack surface and opens up new intrusion points. As a result, development teams that fail to secure the layers of their mobile apps and services risk compromising business-critical information, user safety, and device control.
In addition, many of these vulnerabilities are in the application code itself. So developers play a key role in protecting mobile applications – not just in patching them but also in implementing security strategies that actively monitor and address potential threats, regardless of whether an organization has a dedicated security team or not.
To determine the overall security posture of a given application, expert mobile security specialists employ a rigorous methodology. They replicate the threat posed by a series of threat factors over several levels. Where security flaws are discovered, you’ll be told in easy-to-understand terms what the implications are and, most importantly, how to overcome the problem. This kind of mobile application security assessment will also inform you if any security controls are well implemented or not, so you will be aware of the implications in any case. One of the most well-known frameworks to perform this kind of evaluation is MASVS.
Weak app security can have both long-term and short-term effects on your business, including a bad reputation, financial ramifications of a decline in reputation, and sudden drops in customer numbers. The long-term consequences are greater than the short-term: once an attacker has discovered the vulnerabilities in your app, they can exploit them in various ways. While it’s simpler to patch these repetitive and rare security problems, they will damage your brand beyond repair, and you may not have any chance of recovery.
By integrating security assessment into the mobile application development cycle the developers/manufacturers can better identify security weaknesses of the app before a potential malicious attack. We can do this by carrying out mobile app security tests using different vector attacks, among the additional benefits, we could find:
To conclude, by adding a 3rd party assessment, you can make the most of the available labs. They have highly qualified personnel, using the best-in-class cybersecurity tools to achieve the requirements. Along with information on how to prevent security breaches, you’ll also receive neutral assessments of your app’s security status to help you receive more substantial feedback in the review process. All in all, 3rd party testing offers the best possibility to assure a secure and transparent application without any security pitfalls.
Over 3.9 Billion people are using smartphones and there are more than 2.66 million applications available in the Google Play Store1 – the popularity of mobile devices and apps is constantly increasing. Besides the advantages of this trend, it also leads to a huge potential for security weaknesses. Consequently, the further development of security standards for mobile app development is essential. One of the main drivers is the OWASP (Open Web Application Security Project) and the MASVS (Mobile Application Security Verification Standard).
The OWASP is a non-profit foundation providing advice on how to develop, acquire, and maintain trustworthy and secure software applications. It is best known for its “Top 10” list of web application security vulnerabilities which helps developers, designers, and business owners to become more aware of the risks associated with the most common web application security vulnerabilities. OWASP has also created a forum where security experts and information technology professionals can meet and exchange information, build knowledge, and do networking.
By concentrating all this expertise, the Mobile Application Security Verification Standard (MASVS) was developed. Concretely, it defines detailed security requirements that serve as guidelines for the creation of secure mobile apps. To apply the MASVS, protection requirements for the app must be specified. The standard defines a base of security requirements, e.g., TLS protects complete network traffic and only a limited set of X.509 certificates of the endpoint is acceptable or that all communications implement protocols like HTTPS instead HTTP. MASVS-L2 is based on these requirements and adds additional requirements.
The MASVS is a more comprehensive list of security threats that do not fall into the “Mobile Top 10” in the mobile application space. Many, if not all, of the identified risks, are the result of poor programming practices that do not meet security best practices. The MASVS hopes to highlight these gaps and offer dependable mitigations for the risks they create. In that way the confidence in mobile applications’ security can be raised. To cover different types of use, the requirements were developed with the following objectives in mind:
After OWASP MASVS, the following levels are available: MASVS-L1 MASVS-L1+R MASVS-L2 MASVS-L2+R. The correct level is determined by the protection requirements of the app. The conditions for the levels MASVS-L1 and MASVS-L2 are separated into seven categories, from “Architecture, Design, and Threat Modeling Requirements” to “Code Quality, and Build Settings Requirements”. In each case, a base set of requirements is defined according to MASVS-L1, and further conditions beyond that are specified according to MASVS-L2. Resilience requirements are defined in an eighth category.
V1: Architecture, Design, and Threat Modeling Requirements – lists requirements on the architecture and design of the app. This control has 12 security verification requirements where only 5 are included in Level 1.
V2: Data Storage and Privacy Requirements – aim to validate the adequate protection of sensitive data handled by the app.
V3: Cryptography Requirements – ensure that the evaluated app uses cryptography according to industry best practices, specifically with the usage of International Standards.
V4: Authentication and Session Management Requirements – with the interaction between an app and a remote server during information exchange, this control is based on validating how such sessions are handled.
V5: Network Communication Requirements – validate that the communications in the app were designed to protect the confidentiality and integrity of information exchanged between the mobile app and remote service endpoints, for example using TLS protocol with adequate settings.
V6: Environmental Interaction Requirements – this control looks for a validation that the app is able to use platform APIs and standard components in a secure manner, as well as its handling of inter-app communication (IPC).
V7: Code Quality and Build Setting Requirements – aim to ensure that simple security coding practices are followed in the development of the app such as obfuscation and that the compiler activates several security mechanisms to avoid debugging.
V8: Resiliency Against Reverse Engineering Requirements – covers several defense-in-depth features to avoid an external actor to use techniques like tampering, debugging, reverse engineering, etc.
OWASP has released the Mobile Security Testing Guide (MSTG) to verify the OWASP Mobile Application Security Verification Standard, which specifies test cases for each requirement.
As part of the service portfolio offered by DEKRA, evaluations based on MASVS and Google’s MASA are included to guarantee application developers and owners that their apps meet the requirements established by such standards to substantially reduce the attack surface that could exist in the process of developing an application.