[Owasp-leaders] OWASP Mobile Top 10 - potential conflict of interest in M10

Jonathan Carter jonathan.carter at owasp.org
Tue Nov 4 17:55:36 UTC 2014


In my own work, I have always added that security through obscurity *alone*
is not sufficient.  It certainly helps but it is by no means a panacea.

On Tue, Nov 4, 2014 at 7:42 AM, Neil Smithline <neil.smithline at owasp.org>
wrote:

> I think the difficulty here is that the sort of protection that
> obfuscation provides is hard to pin down. Us security guys like to say "Add
> this control to block this attack." In that sense, obfuscation is not a
> security control as it tends to makes things harder but not block them.
>
> We all know that you can't have security by obscurity so arguing that
> obfuscation adds security feel inherently wrong.
>
> I like to use the word "safety" to describe the benefits of obfuscation.
> It makes some attacks harder and greatly reduces the risk of accidental
> data disclosure that can happen when, for example, a curious but benign
> user eyeballs page source.
>
> Using my vernacular, we can definitively say that obfuscation is not a
> security control, only a safety control.
>
> The question now becomes: do we include a control that provides lots of
> safety but not security in the T10? We have to remember that a T10 may be
> the only security guide a developer will look at.
>
> My thought is that obfuscation is too critical to mobile apps' security
> (and possibly their IP protection and performance) to be ignored
> altogether. That said, obfuscation ain't security. So including it but
> adding some notes about how it is not really security but too important to
> be omitted is the best compromise.
>
>
> Neil Smithline
> 408-634-5764
> http://www.neilsmithline.com
>
> On Tue, Nov 4, 2014 at 10:19 AM, Jack Mannino <jack.mannino at owasp.org>
> wrote:
>
>> So I think the original intention for what that category was supposed to
>> represent and what it "became" are two different things.
>>
>>
>> https://www.owasp.org/index.php?title=Mobile_Top_10_2014-M10&action=history
>>
>> I think we can all agree that the last iteration wasn't up to snuff. At
>> the same time, there was very minimal community involvement except for
>> either smallish consultancies or large software companies and more
>> post-mortem griping than intelligent, constructive debates along the way.
>> Pick your poison.
>>
>> I'm respectfully bowing out of the next iteration, but I'd encourage any
>> of you that see flaws to contribute when they put out their next call for
>> contributors. I fully respect Jason Haddix' integrity as he moves the
>> project forward.
>>
>> On Tue, Nov 4, 2014 at 9:46 AM, Gunnar Peterson <gunnar at arctecgroup.net>
>> wrote:
>>
>>> To add onto to Erwin's point I do think there is something to be said
>>> for obfuscation. Its totally true that even if its worth considering- its
>>> security, but not as we've known it, Jim.
>>>
>>> However, I think Mobile clients are different from defending servers.
>>> The good ol' DMZ model where we do not trust clients does not give us much
>>> to work with on mobile clients. My take is that we need a new playbook for
>>> mobile clients and that requires a different mindset from the DMZ. I
>>> propose Moscow Rules, from the old Cold war rules to operate behind enemy
>>> lines(1). The DMZ assumed a level of separation that is not possible on the
>>> client side. Instead of separation we need to do things like vary our
>>> pattern.  Which brings us back to obfuscation.
>>>
>>> Its security 101, that obfuscation is only a speed bump. But there is
>>> one additional benefit that we can get from it, and that is limiting
>>> failure. If client code is obfuscated on a per instance or per user basis,
>>> then any single client can be busted, but getting a single attack to work
>>> across an array of many clients with unique obfuscation routines is
>>> substantially more difficult. Sort of like RAID, redundant array of
>>> inexpensive of obfuscated speed bumps. There is some value worth
>>> considering for defenders to limit the reach of any single attack against
>>> all your users. Or said differently, the speed bump does not protect the
>>> instance itself so much as the combined effect limits the break of one app
>>> cascading across all the apps and all the users.
>>>
>>> -gunnar
>>>
>>> 1. Moscow Rules stuff is in the middle -
>>> http://1raindrop.typepad.com/1_raindrop/2014/05/cloud-security-defending-the-new-corporate-perimeter.html
>>>
>>> On Nov 4, 2014, at 1:58 AM, Erwin Geirnaert wrote:
>>>
>>> > Hi Andrew,
>>> >
>>> > If mobile code is not obfuscated it can be a starting point to detect
>>> hard-coded secrets.
>>> > Code that is not obfuscated can also be easily abused to create rogue
>>> malicious apps, especially for Android.
>>> >
>>> > So I think it should be there.
>>> >
>>> > Best regards,
>>> >
>>> > Erwin
>>> >
>>> > -----Original Message-----
>>> > From: owasp-leaders-bounces at lists.owasp.org [mailto:
>>> owasp-leaders-bounces at lists.owasp.org] On Behalf Of Andrew van der Stock
>>> > Sent: 04 November 2014 08:07
>>> > To: owasp-leaders at lists.owasp.org
>>> > Subject: [Owasp-leaders] OWASP Mobile Top 10 - potential conflict of
>>> interest in M10
>>> >
>>> > Hi folks,
>>> >
>>> > I've had some feedback on Twitter about the OWASP Mobile Top 10.
>>> > Number 10 includes a control that I don't believe is a sound security
>>> control (security through obfuscation). Coupled with the nature of the
>>> employers of those who contributed, all of whom have some form of
>>> obfuscation product, I'm really not comfortable that M10 is a sound control
>>> or the risk of binary analysis is so high that requires it (no other OWASP
>>> standard contains it!), and more to the point M10 has a strong appearance
>>> of conflict of interest.
>>> >
>>> > I know many of those involved in the project, and don't doubt for a
>>> second their honest desire to create actionable advice, but I am very
>>> concerned that the Mobile Top 10 has an obfuscation control written in by
>>> folks who sell obfuscation controls.
>>> >
>>> > Can we please see the research that demonstrates that binary analysis
>>> is one of the top threats to well written mobile code? I use it as a way to
>>> improve my client's apps, and obfuscation just makes my job harder, not the
>>> code safer.
>>> >
>>> > thanks
>>> > Andrew
>>> > _______________________________________________
>>> > OWASP-Leaders mailing list
>>> > OWASP-Leaders at lists.owasp.org
>>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>> > _______________________________________________
>>> > OWASP-Leaders mailing list
>>> > OWASP-Leaders at lists.owasp.org
>>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>> >
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20141104/7d03e935/attachment.html>


More information about the OWASP-Leaders mailing list