[Owasp-leaders] Fwd: 2012 Rugged Summit

Dennis Groves dennis.groves at owasp.org
Tue Sep 4 16:26:03 UTC 2012


Even if developers were completely 100% aware and wrote perfect code (100%
secure and rugged), or even better used AppSensor and wrote applications in
a way that code actually anticipated and defended itself against hostile
activity, you are still going to get screwed.

A) complexity - The application lives in an Eco-system. Apps run on servers
that reside in networks that have physical locations. Some of those parts
may not even be under the control of the developers; perhaps they reside in
the cloud...

B) entropy - the requirements will change over time, features will be added
over time and code from yesterday will decay or become vulnerable from all
this mud-ball feature adding as it molds and adapts to do things it was
never designed for.

In the end its all about the data! And applications are only proxies to
CRUD data.

I maintain that this is a people problem - who has access to what, when and
what they can do with it is about data and identities and access control.
So teaching input validation is important, but it is not a sufficient
condition to create an acceptable level of risk to the business.

A fundamental security architecture pattern is to remove identity
management and access control from the application. The application must
not be the policy enforcement point! Otherwise when the attacker
compromises either the application or database, he gains control over
everything! This is as bad as hard-coded or plain text passwords!

Dennis


On Tue, Sep 4, 2012 at 2:06 PM, Teresa Stevens <
teresa-ann-stevens at comcast.net> wrote:

> But, in my opinion, most developers are not even aware of the most
> commonly avoided security vulnerabilities. There is very little to "no"
> awareness and training given to developers. Writing secure code does not
> take that much longer. There needs to be more of an emphasis on "security
> awareness and training" given to developers.
>
> Thanks,
>
> Teresa Stevens, CISSP, MSIA, PMMC
> Information Security Project Manager
> San Francisco Bay Area
> 510-842-8868 (home), 510-872-2187 (cell)
> http://www.linkedin.com/pub/teresa-stevens-cissp-msia/26/914/94b
>
>
>
> From: Dennis Groves <dennis.groves at owasp.org>
> Date: Tuesday, September 4, 2012 5:06 AM
> To: OWASP Leaders <owasp-leaders at lists.owasp.org>
> Subject: [Owasp-leaders] Fwd: 2012 Rugged Summit
>
> Feedback???
>
> But this is not the developers fault, nor responsibility...
>
> Three patterns:
>
> Vulnerabilities run right through the entire delivery stack!  Writing
> better apps is not going to make poorly designed stateless protocols
> safer! (Just one of hundreds of examples...)
>
> Developers are not stupid - they are delivering exactly what they are
> asked to deliver: feature, feature, feature... If developers were giving
> business anything other than what they were asked for they would be fired!
>
> Entropy: its the law.  Software is written to meet the business
> requirements today, but change happens; and the software decays. So even if
> it were to write secure software today, tomorrow it will not be.
>
>
>
> Dennis
>
> FWIW, I love the rugged software concept! I wrote my masters thesis on
> 'security stories' two years ago and have been using this idea for about
> four years now...  I am just have questions that remain in my head despite
> my project successes - issues that I think that also have to be overcome...
>
>
> On Tue, Sep 4, 2012 at 2:02 AM, Jerry Hoff <jerry at owasp.org> wrote:
>
>> **
>> Hi Dennis,
>>
>> In my experience, it's that the vast number of organizations are doing *little
>> to nothing* to improve security within their development shops.  It's
>> not that we are doing the wrong things, it's that we are not doing anything.
>>
>> Jerry
>>
>>
>> On 9/3/12 8:00 PM, Dennis Groves wrote:
>>
>> Well Said!
>>
>> On Sat, Sep 1, 2012 at 10:15 PM, Jerry Hoff <jerry at owasp.org> wrote:
>>
>>  "We have no proof that any of the things that we recommend in this
>>> handbook will work. Of course, nobody has any proof that what anyone is
>>> currently doing works either. *What we do know is that we need to try
>>> new
>>> approaches*, for it is certain that the problem is scaling up much
>>> faster
>>> than our ability to apply our current techniques."
>>>
>>
>> And we know this because on the whole shit is still broken, despite all
>> the things tried over the last couple of decades and things are still
>> broken...if not more broken than ever...
>>
>>
> --
> --
> Dennis Groves <http://about.me/dennis.groves>, MSc
> dennis.groves at owasp.org
>
>  <http://www.owasp.org/>
>
> *This work is licensed under the Creative Commons
> Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of
> this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/ or
> send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain
> View, California, 94041, USA.*
>
>
>
>
> --
> --
> Dennis Groves <http://about.me/dennis.groves>, MSc
> dennis.groves at owasp.org
>
>  <http://www.owasp.org/>
>
> *This work is licensed under the Creative Commons
> Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of
> this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/ or
> send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain
> View, California, 94041, USA.*
>
> _______________________________________________ OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>



-- 
-- 
Dennis Groves <http://about.me/dennis.groves>, MSc
dennis.groves at owasp.org

 <http://www.owasp.org/>

*This work is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of
this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/ or
send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain
View, California, 94041, USA.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20120904/c3c37d22/attachment-0001.html>


More information about the OWASP-Leaders mailing list