Closed cybercybercyber closed 7 years ago
13: I actually like to use the word "impede". Speed bumps sounds also good though :)
27: True, perhaps "must" can be replaced with "n the best case ... should"
31 , 50-53: One example that comes to mind (and that I have studied extensively myself) is "soft" tokens - OTP generator apps that aim to replace traditional hardware OTP tokens. In that case, the main goal is to make it infeasible (i.e. too difficult) for malware authors to extract any sensitive data from the app or do instrumentation / code lifting attacks. These things are currently widely deployed in S/E Asia where my company is located.
examples (...) how MASVS-R would safe lives?
It would be very awesome if MASVS-R would save lives :) That said, you have a point, it's quite an outlandish recommendation, and we should revisit these industry recommendations. Do you want to help with those?
just wanted to let you know I'm reading the responses, just had a few busy weeks.
13: impede sounds good to me as well :)
27: I think it's fine to have a design-related requirement in the standard, but maybe a design review after the fact is sufficient?
31, 50-53: I guess this is something we just disagree on :). IMO resilience controls are largely futile. In the case of soft tokens for example, what would keep an attacker from just scraping the otp from the screen on a phone they are root on? The only thing I would recommend is to mention somewhere to always give platform features preference over resilience controls. E.g. if the platform provides a secret store, don't use resilience controls as a replacement for the secrets store, but (if someone things they need to have them) add them on top.
IMO resilience controls are largely futile.
ULTIMATELY futile, yes. But they do make things more difficult for you as an adversary or malware author - to a certain degree. Perhaps enough that it's not worth bothering.
In the case of soft tokens for example, what would keep an attacker from just scraping the otp from the screen on a phone they are root on?
In this particular case the OTP isn't displayed on the screen.
I am not so sure whether all resilience controls are always futile. I would rather say that their effectiveness to impede an attacker depends on many other factors (e.g.: the more they're applied, the more often reverse-engineering scripts will be available, how they behave during runtime, how the output of a proces is related to the UI /storage/etc.)
I rewrote the industry recommendations in this chapter. @commjoen @sushi2k we need more examples under "What Verification Type to Choose":
https://github.com/OWASP/owasp-masvs/blob/master/Document/0x03-Using_the_MASVS.md
line 5: I wouldn't say "measure the security", but rather something like: "provide a standard to compare against".
line 13: "MASVS-R helps defend against specific threats when the end user is malicious and/or the mobile OS is compromised.". I wouldn't use the word defend. Maybe something like: "MASVS-R helps put speed-bumps in the way of the attacker when the end user is malicious and/or the mobile OS is compromised."
line 27: "security must be considered during the design phase". This makes it hard or impossible to retrofit an existing application. Maybe instead say that it needs a security-focused design review (which can be done after the design phase).
line 31: "MASVS-R is applicable to apps that handle highly sensitive data". I wouldn't pin this on the sensitivity of the data (as I mentioned before, online banking may be considered highly sensitive, but wouldn't benefit at all from resilience controls), and instead focus on IP protection. [edit: I like the way it's phrased in line 35]
line 50-53: With the exception of games, I have a hard time coming up with scenarios where resilience controls would be beneficial in the circumstances described in the final column. Could you maybe give examples, e.g. of how a financial application that allows rapid movements of funds would benefit from MASVS-R, or how MASVS-R would safe lives? In particular for the later I'd argue that if a mobile application can put lives in danger and there's nothing that can be done except for client-side controls, then maybe it shouldn't be a mobile app/on a mobile device in the first place?