Refactor of MASVS / MASVS v2 #553
Replies: 5 comments 4 replies
-
Hi MASVS team! Thank you for your hard work on improving MASVS! I really like your v2 idea and I wanted to share some thoughts. Removing overlap with ASVS sounds reasonable because ASVS describes backend-related requirements in more detail. Also, ASVS has more information about architecture and threat modeling. My only concern here is that it will be possible for companies to request review/audit based on MASVS (mobile-only) without ASVS (backend). I think that it is important to underline that your mobile app can't have a good security level if you ignore ASVS. Other thoughts about current MASVS:
|
Beta Was this translation helpful? Give feedback.
-
One more note from me :) MSTG-STORAGE-4: No sensitive data is shared with third parties unless it is a necessary part of the architecture. I always had a feeling that this requirement doesn't belong to Data Storage section. It sounds to me like an ARCH requirement. Usually, to fulfill it I do a list of third parties the app is using and I list all the data shared with them. Sounds more like a general, documents-related, privacy-related, IP-related thing. Also, from my standpoint, privacy-related requirements are almost a separate part of the evaluation:
|
Beta Was this translation helpful? Give feedback.
-
Hi team! Great initiative, in general especially these two concern I can relate to:
Furthermore, zooming in on things I know best I fully agree with @julepka 's comment:
I think it could be very interesting to conceptually split the requirements into 2 groups;
Covering the first group is done based on business 'needs', i.e. what is relevant for the kind of application in question and the actions it enables, data it processes,... If for example the sole concern is hiding client-side logic than maybe impeding comprehension is sufficient and ensuring application integrity is less relevant. Covering the second group of requirements is driven more by the level of risk for the organisation, the expected complexity of adversary tools, time invested by reverse engineers,.. In some way the extent of covering the second group of requirements is more or less equal to the reasoning for L1 and L2 levels currently. Making this more tangible with some (non-exhaustive and quickly put together) examples; group 1: Similar to the current buckets such as eavesdropping, comprehension, device binding,.. Typically I split the current 'dynamic analysis & tampering' in 3 further buckets;
group 2: Includes current 8.7 - 8.9 but could be greatly extended, e.g.; • any runtime verification is inlined in existing and doesn't have its own signature Note that the above list mainly deals with 'impede dynamic analysis & tampering' but a similar enumeration of depth characteristics could be made for 'impeding comprehension' and others. This list is written from an attacker's pov, knowing what makes it more difficult and so what should fundamentally be done. E.g. for 'comprehension' I would start thinking about blockers for some manual 'reasoning' all the way to recent program synthesis tools. |
Beta Was this translation helpful? Give feedback.
-
More details here: https://drive.google.com/file/d/18-SMIDaNFPKHK8V6wWQqvj0UTu4toteQ/view?usp=sharing |
Beta Was this translation helpful? Give feedback.
-
Could you tell me when v2 is planned to be released? Will you continue to refactor the rest chapters (ARCHITECTURE, AUTH, CODE, RESILIENCY) after PLATFORM? |
Beta Was this translation helpful? Give feedback.
-
This post was written in collaboration with @sushi2k and @cpholguera
Current Problems
Context:
Based on our experiences, the following issues often pop up:
Proposal
We would like to refactor the MASVS with the following goals:
Consequences
A refactor like this would be pretty invasive for the MASVS, but we do believe it is long overdue. It would make sense to go to an MASVS v2 (currently at v1.2), potentially also updating the identifiers to MASVS-XX (rather than MSTG-XX).
Together with this MASVS refactor, there will also be a refactor of the MSTG to make sure that every MASVS control has a clearly defined test-case.
Next steps
This is a pretty big undertaking and it would probably be chaos to do this refactor with many people. Because of this, we will create a first draft of MASVS v2 and present that for community feedback. In this first draft, we will try to tackle the issues listed above, as well as any issues that pop up as a result of this post.
Open questions
While we do have quite a good idea of the direction we want to go in, this is a community project so we want community input:
Beta Was this translation helpful? Give feedback.
All reactions