Explaining OWASP and MASVS
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).
What is OWASP?
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.
Why is this important?
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:
- Use as a metric – to provide a security standard against which developers and application owners can compare existing mobile apps
- Use as a guide – to provide direction throughout mobile app development and testing
- Use during procurement – to provide a baseline for mobile app security verification.
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.
MASVS structure
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.
Conclusion
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.