Software Protection Requirements: Why and How?

[muellerberndt]

In this thread I'd like so summarize some of the feedback / criticism I've received regarding how we handle software protections in the MASVS.

The general theme is that the MASVS focuses too much on software protections. In this view, software protections (such as obfuscation) do not count as security measures, as they don't improve security of the app (as opposed to resiliency). Furthermore, reverse engineering resiliency is not needed by the majority of apps.

Another criticism is that "resiliency against reverse engineering" is too broad a definition that does not account for specific goals of the adversary.

I have to that I sympathize with these views. That said, I do see value in software protections, and they are used often in practice.

Maybe lumping security and resiliency controls together into 4 levels is not the right way to go? Should we treat resiliency controls from the "normal" levels, an make them more explicitly optional / tailored to specific scenarios?

Right now, the official wording is already "99% of mobile apps only need MASVS L2". Should L2 be the highest level? The existing resiliency requirements could go into separate "modules" (such as MASVS-R), for example:

MASVS-R1: Code and data obfuscation MASVS-R2: Tampering protection

What do you think?

[cybercybercyber]

+1 to not considering reverse engineering resilience a security feature.

I think the guide should be clear under what threat model RE resilience is useful, and when it's not. For IP protection, sure. But it should also point out clearly that trying to use RE resilience to protect secrets is bound to fail, regardless of the extent the developer is willing to go to.

To protect secrets, IMO applications need to rely on platform features (encryption, keychains, TPM, etc.) and the security guarantees they provide. Protecting against the case where the integrity of the platform is compromised is a lost cause (similar to how on a classic computer it doesn't make much sense to have "the computer is infected by malware running with system privileges" in your threat model).

[jmanico]

+1 to not considering reverse engineering resilience a security feature.

I disagree, with respect. While I did not like how one of the vendors approached OWASP, I think hardening mobile apps from reverse engineering makes analysis a LOT more expensive and more challenging. If you have intellectual property like a video game or other software where you have no choice but to put your IP into the app, then using some kind of reverse engineering protection is critical.

So while I do not think this is a top 10 issue, it sure is a reasonable control that developers should consider.

To protect secrets, IMO applications need to rely on platform features (encryption, keychains, TPM, etc.) and the security guarantees they provide

I agree with this concept. You should NOT use reverse engineering protection to protect a key or other authentication secret. But it still is a valuable way to protect business logic that I have no choice but to put in the app. It at least reduces the number of threat agents who can go after my app, easily.

My 1 and 1/2 cent.

Aloha, Jim

On 12/12/16 5:59 PM, cybercybercyber wrote:

+1 to not considering reverse engineering resilience a security feature.

I think the guide should be clear under what threat model RE resilience is useful, and when it's not. For IP protection, sure. But it should also point out clearly that trying to use RE resilience to protect secrets is bound to fail, regardless of the extent the developer is willing to go to.

To protect secrets, IMO applications need to rely on platform features (encryption, keychains, TPM, etc.) and the security guarantees they provide. Protecting against the case where the integrity of the platform is compromised is a lost cause (similar to how on a classic computer it doesn't make much sense to have "the computer is infected by malware running with system privileges" in your threat model).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OWASP/owasp-masvs/issues/62#issuecomment-266486429, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgcCUMotzQakIKImAGkWBjZ9Bgci0Lvks5rHX16gaJpZM4LIdog.

-- Jim Manico Manicode Security https://www.manicode.com

[pradm-sa]

IMO the requirements change based on the type of domain the application is servicing. For example for a banking application those controls should be must and for a gaming app the risk is low it can be optional. So we may not be able to generalize the MASVS for mobile apps or the level should depend on the data classification and criticality of business the app is used for.

Pradeep

[cybercybercyber]

@pradm-sa : I'm actually the opposite opinion :). Games have significant client-side logic and content which they may want to protect for IP reasons (say, to avoid other developers stealing their graphic assets), so RE resilience may make sense.

A banking application on the other hand has essentially all important functionality on the server-side, and there shouldn't be a need for client-side obfuscation at all.

[jmanico]

Yup, I agree. Games need to put their IP client side. Where a bank MUST put key logic server side.

What I am saying is that in SOME situations, client side protecting to make reverse engineering more difficult is a prudent defense.

• Jim

On 12/14/16 10:35 AM, cybercybercyber wrote:

@pradm-sa https://github.com/pradm-sa : I'm actually the opposite opinion :). Games have significant client-side logic and content which they may want to protect for IP reasons (say, to avoid other developers stealing their graphic assets), so RE resilience may make sense.

A banking application on the other hand has essentially all important functionality on the server-side, and there shouldn't be a need for client-side obfuscation at all.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OWASP/owasp-masvs/issues/62#issuecomment-266987224, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgcCVIvpIm4hz1XRae3GCt5VDVvE64fks5rH7hegaJpZM4LIdog.

[muellerberndt]

Guys, I have pushed a major update that I hope addresses this issue.

Resiliency controls are now "decoupled" from security requirements. I grouped them into a separate set of requirements (MASVS-R) that can be applied if there is a need. It is pointed out that resiliency controls must not replace security controls, but can be applied to mitigate business risks from client-side modding or reverse engineering. I referred to the OWASP "Technical Risks of Reverse Engineering and Unauthorized Code Modification" doc which lists potential business risks and associated technical threats.

Please have a look at the new model and resiliency controls.

[bugwrangler]

Perfect.