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

Jonathan Carter jonathan.carter at owasp.org
Tue Nov 4 17:56:38 UTC 2014


Sure, let me post the data later today. I'm not at the office but I can dig
it up later on today.

On Tue, Nov 4, 2014 at 9:55 AM, Jonathan Carter <jonathan.carter at owasp.org>
wrote:

> 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/67fec821/attachment-0001.html>


More information about the OWASP-Leaders mailing list