MASVS v2.0.0 Release Candidate (RC)

[cpholguera]

With the MASVS refactoring we set a couple of goals:

• Keep Abstraction: leave the details to the MASTG.
• Simplify: have less controls by removing overlaps and redundancies.
• Bring Clarity: use standard terminology whenever possible to leave no room for ambiguity in language and formulation. This includes standards such as NIST-SP 800-175B and NIST OSCAL as well as well-known and used sources such as CWEs, Android Developer Docs and Apple Docs.
• Narrow scope: rely more on other standards including OWASP ASVS, OWASP SAMM and NIST.SP.800-218 SSDF v1.1

The new release candidate includes a lot of news for the MASVS. In this post we present you the work we've done for the MASVS Release Candidate (MASVS v2.0.0 RC), what has changed in comparison to MASVS Refactoring Beta Proposal (MASVS v2.0.0 beta) and present the next steps of the MAS project.

• About the MASVS Release Candidate
• Changelog
• Summary of MASVS v1.4.2 Removed Controls
• Next Steps

❗❗❗ WE NEED YOUR FEEDBACK: Please post your comments and feedback here or use the spreadsheets and comment in the individual cells (open for comments until Feb 12th 2023). Thank you very much.

• RC - MASVS-STORAGE
• RC - MASVS-CRYPTO
• RC - MASVS-AUTH
• RC - MASVS-NETWORK
• RC - MASVS-PLATFORM
• RC - MASVS-CODE
• RC - MASVS-RESILIENCE

About the MASVS Release Candidate

A lot has changed in the MASVS since we started with the refactoring back in July 2021 and finished collecting feedback in September 2022. To produce this new iteration of the MASVS refactoring we have done the following:

• Processed all feedback from each of the Beta Proposal comments from the community.
• Tried to spot overlaps and redundancies (again) e.g. MASVS-NETWORK-1 (beta) vs MASVS-NETWORK-2 (beta).
• Tried to start all controls with “The app…”.
• Tried to formulate all controls using a "positive" formulation.
• Tried to negate each control and see if it still covers the same.
• Go through all test cases and double checked coverage.
• Questioned what/how are we protecting against for each control.

Apart from being extremely insightful, this exercise has allowed us to provide you with an even cleaner version of the MASVS which is designed to remain as a timeless baseline for mobile app security and leave the heavy lifting to the MASTG which will become more dynamic and allow for more specific and flexible testing.

Check our latest talks in the MAS website for more details: https://mas.owasp.org/talks/

Why are there no levels in the new MASVS RC controls? Introducing Profiles:

The Levels you already know (L1, L2 and R) will be fully reviewed and backed up with a corrected and well-documented threat model.

Enter MAS Profiles: We move the levels to the MASTG tests so that for the same control we can evaluate different situations (e.g. in STORAGE-1 it’s ok to use internal storage for L1 but L2 needs more). This might result in different tests according to the required profile.

Transition time: before releasing the final MASVS v2.0.0 we'll try to map all the new proposed test cases to the new profiles (at least L1 and L2) so that even if the MASTG refactoring is not complete you will be able to know what you should test for and you'll be able to find most of the tests already in the MASTG (at least in the current format).

• Map the current MASTG tests to the new MASVS v2.0.0.
• Assign profiles to the proposed MASTG atomic tests (at least L1, L2 and R).

Changelog

These notes reflect the changes made to the MASVS Refactoring Beta Proposal (MASVS v2.0.0 beta) to turn it into the MASVS Release Candidate (MASVS v2.0.0 RC) after addressing all comments, requested changes and concerns.

MASVS-ARCH

No changes.

MASVS-STORAGE

• MASVS-STORAGE-1 (beta): REWORDED to solve the main concern here: having a L1 test for data in internal storage (here it's the system encrypting, not the app)
• MASVS-STORAGE-2 (beta): TEST CASE for MASVS-CRYPTO-2 (RC) since key storage is part of key management according to NIST-SP 800-175B.
• MASVS-STORAGE-3 (beta): TEST CASE for MASVS-STORAGE-1 (RC) since logs is just another area for that control
• MASVS-STORAGE-4 (beta): REMOVED since it requires a rooted/jailbroken device and if that's the case, you can already extract the data from memory when / if it becomes available.
• MASVS-STORAGE-5 (beta): REMOVED since the assumption is that following the rest of the MASVS should be enough to cover for all baseline privacy concerns. For more please check the MASTG chapter on privacy.

MASVS-CRYPTO

• MASVS-CRYPTO-1 (beta): TEST CASE for MASVS-CODE-3 (RC) which was added as part of this refactoring to cover for secure implementations.
• MASVS-CRYPTO-2 (beta): becomes MASVS-CRYPTO-1 (RC)
• MASVS-CRYPTO-3 (beta): UNCHANGED, becomes MASVS-CRYPTO-2 (RC)
• MASVS-CRYPTO-4 (beta): TEST CASE for MASVS-CRYPTO-2 (RC) since key hardening is part of key management according to NIST-SP 800-175B

MASVS-AUTH

No changes.

MASVS-NETWORK

• MASVS-NETWORK-1 (beta): REWORDED to cover for all network traffic.
• MASVS-NETWORK-2 (beta): TEST CASE for MASVS-NETWORK-1 (RC) since that one covers for all traffic now.
• MASVS-NETWORK-3 (beta): TEST CASE for MASVS-NETWORK-1 (RC) since having network security configurations in the app settings and related networking APIs which are in line with the current best practices is required for the traffic to be secure.
• MASVS-NETWORK-4 (beta): TEST CASE for MASVS-NETWORK-1 (RC) since validating the identity of all remote endpoints is required for the traffic to be secure.
• MASVS-NETWORK-5 (beta): REWORDED removing "at least". Becomes MASVS-NETWORK-2 (RC).

MASVS-PLATFORM

• MASVS-PLATFORM-1 (beta): TEST CASE for MASVS-PLATFORM-1 (RC) since permissions are tightly related to IPC and can be part of more complex attacks but per-se, today, do not represent a vulnerability.
• MASVS-PLATFORM-2 (beta): REWORDED to simplify and extend coverage. Becomes MASVS-PLATFORM-1 (RC).
• MASVS-PLATFORM-3 (beta): REWORDED to simplify it. Becomes MASVS-PLATFORM-2 (RC).
• MASVS-PLATFORM-4 (beta): TEST CASE for MASVS-STORAGE-1 (RC) since excluding sensitive data from platform backups is a hardening measure for that control.
• MASVS-PLATFORM-5 (beta): REWORDED to simplify it. Becomes MASVS-PLATFORM-3 (RC).

MASVS-CODE

• MASVS-CODE-1 (beta): REMOVED since its test cases were actually about impeding comprehension (e.g. by removing non-production artifacts such as URLs, test credentials, backdoors, etc.) and preventing dynamic analysis (e.g. via debugger) so we could map all all of them to MASVS-RESILIENCE-3 (RC) and MASVS-RESILIENCE-4 (RC).
• MASVS-CODE-2 (beta): TEST CASE for MASVS-CODE-4 (RC) since it's just testing libs for PIE, SSP and NX which can be considered a protection against "untrusted inputs".
• MASVS-CODE-3 (beta): UNCHANGED, becomes MASVS-CODE-1 (RC).
• MASVS-CODE-4 (beta): UNCHANGED, becomes MASVS-CODE-2 (RC).
• MASVS-CODE-5 (beta): REWORDED to cover for not only third-party components and to cover for native/platform APIs and frameworks such as Flutter as well as platform provided implementations for security critical code. Becomes MASVS-CODE-3 (RC).
• MASVS-CODE-6 (beta): REWORDED to simplify it. Becomes MASVS-CODE-4 (RC).

MASVS-RESILIENCE

• MASVS-RESILIENCE-1 (beta): UNCHANGED.
• MASVS-RESILIENCE-2 (beta): REWORDED to simplify it.
• MASVS-RESILIENCE-3 (beta): REWORDED to simplify it.
• MASVS-RESILIENCE-4 (beta): REWORDED to simplify it.

MASVS-RESILIENCE will introduce four strategies on how to apply these controls:

• Strategy 1 (RASP): The app reacts to dynamic analysis and tampering techniques.
• Strategy 2 (layered protection): The app uses a layered strategy for its resilience techniques.
• Strategy 3 (variability): The app uses a variable strategy when applying resilience techniques (on every release).
• Strategy 4 (unpredictabilness): The app uses an execution strategy making its resilience techniques unpredictable.

Summary of MASVS v1.4.2 Removed Controls

MSTG-STORAGE-10

This should be part of the Architecture and Design phase of the app and is mitigated by following proper secure coding design.

In addition to that, it requires a rooted/jailbroken device and if that's the case, you can already extract the data from memory when / if it becomes available.

MSTG-STORAGE-12

Removed since the assumption is that following the rest of the MASVS should be enough to cover for all baseline privacy concerns. For more please check the MASTG chapter on privacy.

MSTG-STORAGE-13

This should be part of the Architecture and Design phase of the app and is mitigated by following proper secure coding design.

The app developers might decide to:

A) Exclusively retrieve data from a remote endpoint and make it only reside in the app volatile memory.
B) or store sensitive data only locally encrypted and never in a remote endpoint.
C) Hybrid (most common)

Regardless of the option, the MASVS-STORAGE protects local data at rest which is stored in the mobile device.

MSTG-STORAGE-15

Removed because it's considered covered by MASVS-STORAGE-1 (RC): we consider that properly encrypting data means that even if it's not deleted on uninstall/after excessive auth-fails it will be safe.

MSTG-AUTH-2

Removed because this is clearly a task to be fulfilled by the remote endpoint and cannot be properly tested from the app side (the remote endpoint must enforce it).

The app side could be considered covered by MASVS-AUTH-1 (RC).

MSTG-AUTH-5

Removed because this is clearly a task to be fulfilled by the remote endpoint and cannot be properly tested from the app side (the remote endpoint must enforce it).

The app side could be considered covered by MASVS-AUTH-1 (RC).

MSTG-AUTH-6

Removed because this is clearly a task to be fulfilled by the remote endpoint and cannot be properly tested from the app side (the remote endpoint must enforce it).

MSTG-AUTH-7

Removed because this is clearly a task to be fulfilled by the remote endpoint and cannot be properly tested from the app side (the remote endpoint must enforce it).
The app side could be considered covered by MASVS-AUTH-3 (RC).

MSTG-AUTH-11

Removed because this is clearly a task to be fulfilled by the remote endpoint and cannot be properly tested from the app side (the remote endpoint must enforce it).

MSTG-NETWORK-5

Removed because this is clearly a task to be fulfilled by the remote endpoint and cannot be properly tested from the app side (the remote endpoint must enforce it). It's covered in ASVS 2.5.6.

MSTG-CODE-6

This should be part of the Architecture and Design phase of the app and is mitigated by following proper secure coding design.

MSTG-CODE-7

This should be part of the Architecture and Design phase of the app and is mitigated by following proper secure coding design.

MSTG-RESILIENCE-7

This can be applied not only to techniques meant to detect dynamic analysis and tampering but also to those meant to impede comprehension. Therefore, it's covered now as a strategy that will be explained in the MASTG.

Next Steps

• Collect and review comments for this MASVS v2.0.0 Release Candidate (RC)
• Release MASVS v2.0.0 (final version)
• Kick-off MASTG Refactor to v2.0.0
• Publish first proposal for MAS Profiles definitions (replacing the current MASVS levels)
• Publish first proposal for MASTG atomic tests (at least titles and proposed profiles e.g. L1, L2)

~ Carlos Holguera, Sven Schleier and Jeroen Beckers, the OWASP MAS Team ~

[syakymchuk]

Hi @cpholguera , sorry for the late comment. But it seems it is the last available day for this ;)

I have just realized that MSTG-STORAGE-12 has been removed completely. I understand that App Privacy (data sharing) aspect will be addressed. But what about "educate the user about ... security best practices the user should follow in using the app". If this is dropped there is absolutely nothing in MAS that addresses the problem of users' mistakes, which is one of the main sources of exploits today. At least in mBanking.

IMHO, this topic deserves a dedicated category since the users' mistakes, or rather their exploits via fishing and social engineering, are the weakest chain in the app cybersecurity link today.

[sushi2k]

@syakymchuk Thanks for your comment! If you say it deserves a whole category, what would you propose as requirements/controls for it?
We were removing almost completely the first section as it is hard to verify many of the items when conducing a penetration test.
How do you verify “User Education” in the MASTG from a pen testing point of view, should the user tick a box when logging in to confirm to not click on any link or pass their OTPs to strangers? And is this already sufficient as "User Education"?

[cpholguera]

Closed for comments. Thanks everyone and if you have any questions please feel free to reach out anytime.