MASVS (The Mobile Application Security Verification Standard) from OWASP is an open-source framework that offers security requirements for mobile apps. MASVS provides a foundation for app developers, testers, and users to enhance the security of mobile apps.
It defines two levels of security verification (MASVS-L1 and MASVS-L2) and a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 focuses on basic security requirements applicable to all mobile apps, while MASVS-L2 is for apps handling highly sensitive data, and MASVS-R considers additional protective controls for specific client-side threats.
What does each MASVS level focus on, and when should it be considered?
MASVS-L1 focuses on essential security controls. These controls represent security best practices recommended for all mobile applications, regardless of their functionality or the sensitivity of the data they handle. These requirements include secure data storage, proper handling of cryptographic keys, secure communication, and adherence to platform security features.
The goal of MASVS-L1 is to ensure a baseline level of security that can prevent commonly seen vulnerabilities. This security level addresses issues such as insecure data storage, weak encryption, and inadequate input validation.
It’s recommended to consider MASVS-L1 for every mobile app as a baseline. This baseline security level is critical in today’s digital world, where even seemingly innocuous apps can become a potential entry point for attackers if they lack basic security controls. Therefore, whether an app is small or large and handles sensitive data, MASVS-L1 should be considered to ensure fundamental security best practices are in place.
MASVS-L2 introduces advanced security controls that exceed standard requirements. These controls are designed to offer more thorough protection against sophisticated attacks and typically focus on areas such as robust data validation, in-depth authentication and session management, high-level cryptographic standards, and security-enhanced network communications.
Unlike MASVS-L1, which is recommended for all mobile apps, MASVS-L2 is generally considered when an application is dealing with highly sensitive data. This could include mobile banking apps, health apps that handle personal health information, apps that deal with personally identifiable information (PII), or any other app where a data breach could result in significant harm or loss.
To fulfill MASVS-L2, a threat model must exist, and security must be an integral part of the app’s architecture and design. As such, developers should carefully analyze the potential threats and vulnerabilities that their apps may face and implement appropriate security measures to mitigate these risks. Therefore, MASVS-L2 should be considered when the possible loss from a security compromise significantly outweighs the costs of implementing advanced security controls.
MASVS-R emphasizes resiliency against reverse engineering and tampering. This level focuses on additional protective controls to impede specific client-side threats, where the end user may be malicious or the mobile operating system could be compromised. MASVS-R could involve controls to prevent attackers from manipulating the app to change its behavior or to protect intellectual property by making it harder to extract sensitive code or data.
MASVS-R is particularly relevant for applications that must protect sensitive intellectual property or where tampering with the app’s code could lead to significant damage. Examples could include financial apps, where techniques such as code injection and instrumentation on compromised devices pose a risk. It may also be relevant for gaming apps where cheating or modding could disrupt fair play and affect the app’s reputation or for apps that, by design, need to store sensitive data on the mobile device across a wide range of devices and operating system versions.
In summary, MASVS-R should be considered when an app deals with highly sensitive data or intellectual property or when it’s crucial to prevent tampering and reverse engineering.
The decision to implement these controls should be risk-based, and while it is recommended for every app to meet MASVS-L1, the ultimate decision lies with the business owners.
In practice, how can MASVS help mobile application teams?
App teams can use the MASVS (Mobile Application Security Verification Standard) as a comprehensive guide for implementing and verifying security in mobile applications. Here are several practical ways to use MASVS:
- Security Requirements: MASVS can be used to define clear and consistent security requirements for mobile applications. It sets the foundation for what security controls are necessary based on the sensitivity of the data handled by the application and the associated threats.
- Guidance during Development and Testing: Teams can use the standard throughout all application development and testing stages. It can inform developers about security best practices and help testers identify areas to focus on for security testing.
- Use during Procurement: Organizations can use MASVS as a baseline to verify the security of third-party mobile applications before integrating them into their infrastructure.
- Risk-Based Decisions: MASVS defines different verification levels (MASVS-L1, MASVS-L2, and MASVS-R) based on the threat landscape and data sensitivity the app handles. App teams can implement controls based on risk tolerance and business needs.
- Security Benchmarking: MASVS provides a standard against which the security of mobile apps can be compared. It can help organizations identify potential security weaknesses in their applications and track improvements over time.
- Building a Threat Model: MASVS can help teams understand the various threats and vulnerabilities that their apps may face. This can guide them in creating an appropriate threat model and a corresponding mitigation strategy.
App teams should integrate MASVS into their entire development lifecycle, from initial design to development, testing, and maintenance. The aim is to foster a ‘security by design’ approach, where security is considered at every stage of the development process.