The OWASP Mobile Application Security Verification Standard (MASVS) has been a valuable foundation for our mobile security engineering and assessments. This high-level guideline served us well for a long time, particularly with version 1.5.
However, MASVS v2.0 requires additional tailoring, when it comes to specific risk mitigations our customers are facing, such as specific architecture requirements, cryptography implementations, and a stronger focus on data privacy.
Inspired by MASVS, we developed an improved actionable framework for product security, security assessments, SSDLC, and measuring security posture for mobile applications: Cossack Labs Mobile Security Score (CL MSS).
Let’s analyse the limitations of the existing mobile security standards and testing guides, learn about CL MSS approach, evaluate its advantages against the original OWASP MASVS, and explore practical use cases for global industry leaders.
- Addressing mobile security needs
- Meet Cossack Labs Mobile Security Score
- Measurable product security posture
- Tailoring and scoping
- Conclusion
Addressing mobile security needs #
As use cases for mobile devices became more diverse, they started to store and transfer more data, extending the attack surface. Mobile app security—unlike web, backend, and API security—has fewer standards and guides to rely on during software development and assessments.
Most developers keep using OWASP Mobile Application Security (MAS), even though it may not cover all mobile-specific security controls and weaknesses.
Other developers rely solely on the sandboxing and secure storage mechanisms provided by Android and iOS, without looking into advanced security controls, which might not be enough to protect against relevant cyber threats. The OWASP MAS project testing guide MASTG lacks some details and has outdated information.
Meet Cossack Labs Mobile Security Score #
Cossack Labs Mobile Security Score, or CL MSS, is an extension of OWASP MASVS that we use as a mobile security verification framework when addressing mobile-specific risks and threats for mobile apps with increased security risk exposure.
The CL MSS has eight core sections that align with MASVS, covering:
- Architecture and design
- Secure data storage and privacy
- Cryptography
- Authentication and session management
- Network communication
- Platform interaction
- Code quality
- Resilience against reverse engineering and tampering
An additional customisable section #9 is designed to address product-specific needs.
Explore CL MSS framework and address your mobile AppSec needs
The guide classifies requirements into several levels, based on the app’s data sensitivity and threat model:
- L1—Basic Security Level
- L2—Advanced Security Level or Defence-in-Depth
- R1—Basic Resilience Level
- R2—Advanced Resilience Level
CL MSS benefits vs original OWASP MASVS v2.0 #
| Feature | OWASP MASVS v2.0 | CL MSS |
|---|---|---|
| Scope | Limited in later versions | Expanded coverage of security controls |
| Detail level | High-level overview | Specific, actionable requirements |
| Tailoring | Limited | Risk-based approach for customisation |
| SSDLC integration | Not explicitly considered | Seamless integration with SSDLC |
| Scoring | Not available | Security score tracking for progress measurement |
| Cryptography focus | Generic guidance (directs to ASVS for web) | Mobile-specific, in-depth guidance for cryptographic primitives, mobile-relevant crypto-schemes, key managements and encryption regulations |
| Privacy/Compliance | Not a major focus | Addresses data privacy, GDPR compliance, mobile stores guidelines |
Measurable product security posture #
Cossack Labs Mobile Security Score allows tracking mobile product security progress. It clearly demonstrates the impact of security measures on both developers and clients. The checklist lets you calculate the percentage of requirements met for each framework section.
Regular assessments allow:
- Tracking progress over time
- Ensuring new security controls fix weaknesses rather than weaken overall security.
Example: The graph below shows clear, trackable security improvements our team made to a client’s banking application as a result of the security assessment:
The status of banking applications after security assessment and one month of fixing identified issues by the application team. See a detailed case study: Product security for one of the biggest African banks.
This example illustrates that the initial mobile application lacked numerous security controls (see “after assessment” on the graph). After implementation of new controls and enhancing the existing ones, the app’s security posture got a notable improvement (see “after fixes”).
Below you can see a statistic from another product that shows how the application’s security posture changed over time and how it evolved with the introduction of new mobile app features.
Measuring security posture of the mobile app over time, identifying areas for improvements.
Long-term cooperation with our client delivered a stable 80% security score for 2 years and a controlled backlog. By tracking measurable improvements, we defined a clear security roadmap of the product, leading to just a few low and informational issues in recent penetration testing.
Tailoring and scoping #
A one-size-fits-all approach doesn’t work for mobile security. Thus, CL MSS uses a two-step tailoring approach:
- Pre-assessment tailoring: The risk assessment and threat modelling stage identifies the most relevant project-specific security controls. You assess and decide what the application needs/does not need in this framework.
- In-progress tailoring: During the security assessment, you can mark certain controls as “Not Applicable” based on specific features and agreed-upon risk acceptance. When doing the assessment, some security requirements—which are not described in the framework—can be added to the 9th section.
CL MSS covers security controls for different mobile application components, for example WebViews, system keyboard, Web AuthN, biometric authentication, hardware-backed encryption keys storage, encrypted local storage, backups to cloud, etc. Some apps don’t use these components, thus some requirements can be marked as “Not Applicable” and not affect the general security score of the app.
An example of tailored requirements: the app doesn’t derive encryption keys from user passphrase, so requirement 3.5 is not applicable and isn’t counted towards the security score.
The tailoring process often reveals the need for additional security requirements unique to the product—capture and integrate these into the assessment.
Here’s a practical example of how Cossack Labs team used CL MSS to improve product security of a new mobile application of one of the biggest African banks:
Tailored checklist can be successfully used for different types of projects. During the risk assessment and threat modelling stage, you can create a list of requirements unique to your product.
Fulfil Project-specific security controls in the 9th chapter to make those requirements measured. The table will enhance the process when it comes to percentage counting, graph creation etc. as the 9th chapter has support for different projects.
An example of requirements for Project-specific security controls section for crypto wallets
Conclusion #
CL MSS is a mobile security framework that works for both one-time assessments and SSDLC process. It enables measurable security posture evaluation.
Compared to OWASP MASVS, CL MSS offers a more extensive structure, covering a wider range of security controls and providing more specific, actionable security requirements.
