[Owasp-mobile-security-project] Feedback re top 10 mobile controls and design principles

[Jim Manico]

Ken,

I'd love to see you edit the Wiki directly with these insightful thoughts. Agreed Jack?

Jim Manico

On May 25, 2011, at 4:13 AM, Kenneth Van Wyk <ken at krvw.com> wrote:

> Hi all,
> 
> FYI, I have some feedback on the current draft doc. Not sure if it's more appropriate to share here via email or edit directly on the wiki -- so here it is...
> 
> First off, I think it's great to publish a top 10 controls doc (vs. a top 10 bad things).
> 
> 1. Identify and protect sensitive data on the mobile device -- I like this one a lot. Certainly the guidance to favor server-side storage is the right way to go, but sometimes we're forced to store things on the client. 
> 
> We should caveat the "leverage the encryption and key-store mechanisms..." bullet point. We already say to store keys on the server if no good solutions are available on the client. Same should hold true for crypto "provided by the mobile OS/hardware". Case in point, iOS's hardware crypto sounds brilliant in specifications only. The implementation is flawed, and I wouldn't advise anyone to rely on it for anything truly sensitive.
> 
> Other topics in this section are spot on, though -- like using secure deletion...
> 
> 
> 4. Keep the back-end API and mobile platform secure -- While I completely agree with this point, it's really not directly a mobile control, IMHO. Where would it stop if we include this one here? Keep up to date with OS patches on the server? (Never mind, that's already #6 on the list, sort of... :-) Either way, I don't think this #4 belongs on the list.
> 
> 
> 6. Ensure strong vulnerability and patch management in place -- This one seems to refer both to the mobile as well as server side. As I say above, I suggest keeping _this_ list focused on the mobile side of things. That's not to say the server side doesn't matter!
> 
> 
> 7. Employ the secure coding/development practices -- This one is overly general. And parts of it are covered elsewhere, like "use static code analyzer tools" in #6.
> 
> 
> 8. Perform data integration with third party backend applications correctly -- I agree with most of the // comments in the draft doc. This one seems like it needs some more baking.
> 
> 
> 9. Run the mobile client using minimal permission -- YES! I think this one deserves a higher priority on the list. (And iOS fails this one right off the bat...UID=0) I'd vote to move this to #4 in lieu of the extant 4.
> 
> 
> 10. Enforce higher security posture on the device for sensitive apps -- I don't see how this should be a separate item on the list.
> 
> 
> 11. No secrets in code/binary -- YES! I think this one deserves a spot on the list. All iOS apps can be trivially viewed with hexdump (or other such). Trying to hide things in there is problematic at best. Code obfuscation may be helpful, but even still. Some bullets in this section should include:
> o Strip binaries before shipping code
> o Review all embedded strings using static analysis of binary
> 
> 
> 12. Protect your application from other malicious applications on the device -- I like this one, but think it would be somewhat problematic. Certainly on iOS anyway, as apps generally can't see what others are loaded.
> 
> 
> Others for consideration:
> 
> 13. Use caution in registering URL schemes. (In iOS, any app can register an arbitrary URL scheme. E.g., map://foobar.arbitrary.data -- now any other app can call that URL scheme and your app will fire.) If you're going to register a URL scheme, assume others will use/abuse it. Input validation on redirected URLs is vital.
> 
> 
> 
> 
> Now, a couple of general comments, all IMHO of course.
> 
> It seems to me that some of the items on the list were a bit of a stretch. Was the group struggling to (arbitrarily) come up with 10 issues? If that's the case, I'd suggest not being bound to 10 per se. If we can only come up with 9, then so be it, or if there's 11 compelling ones, let it be so.
> 
> Let's try to keep the list specific to the mobile device itself. We can quickly get sucked into the vortex of trying to solve all the world's problems otherwise.
> 
> 
> I don't mean these comments to be overly critical. I think the list is a great effort and much needed in the community. The comments here are purely my opinions about what I see on the current draft.
> 
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> Follow us on Twitter at: http://twitter.com/KRvW_Associates
> 
> 
> 
> 
> 
> _______________________________________________
> Owasp-mobile-security-project mailing list
> Owasp-mobile-security-project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-mobile-security-project