MASVS-RESILIENCE Refactoring (till 02.09.22)

[cpholguera]

Hello everybody,

as part of the refactoring process we decided to publish our draft of every section of the MASVS that we (@cpholguera, @TheDauntless and @sushi2k) worked on.

This is based on the MASVS category "V8: Resilience Requirements" (from the MASVS Version 1.4.2): https://github.com/OWASP/owasp-masvs/blob/v1.4.2/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md

Here you can find a summary of the proposed new requirements (more details below):

In the following link we include a nice visualization as a diff spreadsheet including:

• Reason for removal/change.
• Idea behind the new requirement/formulation.
• More context thanks to related Test Cases.
• Filter in column F1 to see
  • the previous version only
  • the new version only
  • or the diff

MASVS-RESILIENCE is open for comments till the 2nd of September 2022. Please comment directly in the Google Spreadsheet (you can comment on each of the cells) or in this GitHub Discussion.

MASVS-RESILIENCE Refactoring Diff

[antoniojturel]

Hola/Hello Carlos / @cpholguera,

Let me introduce myself, my name is Antonio J. Turel, as a Telecommunications Engineering working on ICTechnologies I appreciate this cybersecurity iniciative being in constant improvement. I will try to get some time to other OWASP projects such as MSTG, Top10...

I have already started my collaboration: You'll find a comment in the Google Spreadsheet, I hope this help you and there is also the PR #658 to attend if there are, or not, any edition need it.

Gracias/Thanks

[cpholguera]

Hola Antonio, welcome to the OWASP Mobile Application Security (MAS) project!

Are you on Slack? Please join here:
https://github.com/OWASP/owasp-masvs#connect-with-us

Thanks for your new contributions!

[dzan]

Hi @cpholguera, @TheDauntless, @sushi2k,

First of all, thank you for the continued efforts on MAS and all the work on the refactor! Overall all the category refactors have been great improvements and this one for RESILIENCE definitely is too.

After reflecting on the new version a bit I have 2 suggestions;

1. MASVS-RESILIENCE-4 Split
In general all the merging makes sense but here, in my opinion this now groups together 2 things distinct aspects which maybe are better kept separate;

a. App validates its code at runtime.
b. App detects dynamic analysis.

I feel giving these their own item might make a little more sense conceptually. Splitting off (a) for only code integrity would create the dynamic/runtime counterpart of RESILIENCE-2 (which deals with static code patches), similarly having (b) separate creates the runtime counterpart of the new RESILIENCE-3. This would improve overall structure and clarity of the refactored RESILIENCE I think. In addition when acting on these requirements those are typically distinct techniques, actions, features,...

2. Requirement of Variability
I would propose adding an additional requirement on variability/polymorphism/... not sure what the best phrasing would be. From experience I know that meeting all the current requirements is a great start, it will buy you a lot of time if done properly. However, it's finite and that's where it becomes very important that all of the applied techniques are 'randomised' for each build of the application. Releasing your app over and over again with the same verification code for these requirements, in the same place, taking the same actions,... makes them ineffective over time.

For me this addition would be the sibling of the (refactored) CODE-4 requirement. The combination enables the app to 'reset the clock' on attackers.

So more concrete, an attempt at phrasing;

MASVS-RESILIENCE-x - The app randomises resilience verification techniques and implementation details on every release.

[cpholguera]

Thanks a lot for your feedback @dzan! We'll take it into account for the Release Candidate.