In my role as Solution Specialist for the Asia Pacific and Japan (APJ) region, I consult with banking, insurance, retail, travel, lifestyle and other companies on their mobile app security needs. Some customers I work with have a very clear understanding of their security requirements. For example, they want to prevent static analysis of their mobile apps or want to comply with the TRM guidelines for mobile app security. Others ask me for advice on what mobile app security standard they should use to build their security model. One of the standards I recommend is the OWASP Mobile AppSec Verification Standard (MASVS). This standard is a good blue print for the mobile app security model companies should aspire to implement.
What is the Mobile AppSec Verification Standard (MASVS)
The Mobile AppSec Verification Standard guidebook defines the MASVS as follows: “The MASVS can be used to establish a level of confidence in the security of mobile apps. The requirements were developed with the following objectives in mind:
- Use as a metric – To provide a security standard against which existing mobile apps can be compared by developers and application owners;
- Use as guidance – To provide guidance during all phases of mobile app development and testing;
- Use during procurement – To provide a baseline for mobile app security verification.”
MASVS defines “two security verification levels (MASVS-L1 and MASVS-L2), as well as a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 contains generic security requirements that are recommended for all mobile apps, while MASVS-L2 should be applied to apps handling highly sensitive data. MASVS-R covers additional protective controls that can be applied if preventing client-side threats is a design goal.”
And since MASVS says that “fulfilling the requirements in MASVS-L1 results in a secure app that follows security best practices and doesn’t suffer from common vulnerabilities“, my recommendation to customers is that they use the MASVS-L1 requirements to build a mobile security roadmap that they can implement to their mobile apps using Appdome.
How to Implement the Mobile AppSec Verification Standard
There are a total of 59 comprehensive MASVS-L1 requirements, grouped in 8 different sections. These sections are:
- V1: Architecture, Design and Threat Modeling Requirements
- V2: Data Storage and Privacy Requirements
- V3: Cryptography Requirements
- V4: Authentication and Session Management Requirements
- V5: Network Communication Requirements
- V6: Platform Interaction Requirements
- V7: Code Quality and Build Setting Requirements
- V8: Resilience Requirements
While some of the requirement are related to how a developer builds their apps, most of the requirements can be implemented on Appdome with a combination of application shielding (RASP), obfuscation, encryption, jailbreak/root prevention, Man-in-the-Middle prevention, data loss prevention (DLP), fraud prevention, malware prevention, piracy prevention and Appdome Threat Events.
Implementing MASVS using Security Release Management
While it is completely possible to implement the complete Mobile AppSec Verification Standard on Appdome in 30 seconds, most customers choose to implement the standard in several mobile app security releases. Just as in a mobile app development process, a developer may choose to release different features across different releases, Appdome allows DevSecOps teams to release different security features across different security releases. They would version these different releases as different Fusion Sets. A typical example would be:
- Fusion Set v1: application shielding + obfuscation + encryption + jailbreak/root
- Fusion Set v2: v1 + MitM + DLP
- Fusion Set v3: v2 + fraud prevention
- Fusion Set v4: v3 + malware and piracy prevention
- Fusion Set v5: v4 + Threat Events
The ability to easily version Fusion Sets and grow the security model is what defines Security Releases Management at Appdome.
Effort Required to Implement the Mobile AppSec Verification Standard
There are 2 ways to implement MASVS. A no-code implementation on Appdome or a manual implementation using SDKs. Let’s look at both options:
No-Code Implementation of MASVS on Appdome
Achieving the MASVS outcome on Appdome is simple. Developers and Security teams can toggle on their desired mobile app security and fraud prevention features on the Appdome Mobile DevSecOps platform, click “Build my App” and 30 seconds later, the app is protected according to the Mobile AppSec Verification Standard. Check out this video to see how easy it is for example to add root prevention and copy/paste prevention to an Android app.
Manual Implementation of MASVS
And while on Appdome, developers and security teams can achieve their outcome in 30 seconds, achieving the MASVS outcome by manually adding security libraries or SDKs to your mobile app is much much more complex and time consuming. Here’s a taste of what developers would need to do to implement encryption (aka V3. Cryptography Requirements)
Developers have 2 paths to encrypt the data in their apps:
(1) Open Source path where they find Encryption libraries that suit their data type. They will also need to decide on the key strength, encryption algorithm and cipher suites they want to use to achieve the desired security outcome. The developer will also need to balance security and performance of the app as well as end user experience. Implementing all this will be a trial and error process, and getting anything wrong can drastically degrade app performance, usability, or the security posture of the app. Based on the architecture of the app, the data structure and the type of encryption required, this would easily take several weeks or more.
(2) Go get an encryption SDK from a commercial vendor, learn what is required to implement the SDK in their app (this will depend on the framework used to build the app, the data structure and where the data needed to encrypt sits in the app (sandbox, strings, resources, preferences and more)). Encryption models for each OS differ from the framework used to build this app. For example an encryption SDK for Swift will be different for the SDK for Objective C. Some apps may have been built in a combination of frameworks. For each version, the SDK vendor may require different plug-ins. Implement the SDK incorrectly, and the data in the app will not be fully encrypted and still open to harvesting by hackers and bad actors. Again, implementing all this will easily take several weeks or more.
On top of this, both paths still require the developer to find a solution for key management. How are the keys generated and where are they stored? The developer needs to do this in such a way that makes the keys easily accessible to the app for encrypting and decrypting the data AND without making the keys easily accessible to hackers so that they can undo all the work the developer put in.
This work will also be different for the iOS version and the Android version of their app. Also the encryption model will need to be updated every time new features are added to the app or when the OS is updated.
All this, just for encryption. The same workflow is required for each of the security features required to meet the Mobile AppSec Verification Standard. And this work is required for each release.
Best Practices for Implementing the Mobile AppSec Verification Standard
Compare the above with the instant outcome on Appdome. When I review this model with customers and we look at what it would take to implement MASVS manually, the consensus typically comes out to about 72 weeks, give or take a few weeks. And remember, this work is required for each build.
Really, there is no comparison. Get started with Appdome today or request a demo to learn how you can instantly implement MASVS.
