[Owasp-leaders] Are we helping Hackers or helping Application security?

johanna curiel curiel johanna.curiel at owasp.org
Sun May 22 01:50:31 UTC 2016

>>I am not surprised by that at all. Being on the "breaker" side of things
is "sexy"; being on the defender side, not so much.

Innovation is about thinking out of the box solutions and this is what we
are not doing enough.
Sure not within OWASP. Sure not in Defender projects. Except some, like
SeraphimDroid using Machine learning to stop malware.

So we accept our loss blaming it to the fact that is easier, sexier to hack
than protect and create defense?

Thats is a quite sad scenario and fate to accept...sure for a bunch or
'security experts' in this community.

I might be in the wrong community. I'm looking to create solutions ,
innovate and solve problems and don't keep on thinking the same old
pattern. I though that was one of our core values:

*"INNOVATION: *OWASP encourages and supports innovation and experiments for
solutions to software security challenges"

Projects like Rust are trying to do that.

Why can't we discuss and brainstorm new ways to defend applications? Bring
a balance by spending more energy on this?
How can OWASP motivate this more?

Only answer I get here is that we are doomed and that hackers have the

On Sat, May 21, 2016 at 8:21 PM, Kevin W. Wall <kevin.w.wall at gmail.com>

> On Fri, May 20, 2016 at 1:02 PM, Timothy D. Morgan <tim.morgan at owasp.org>
> wrote:
> >
> >> Respectfully, and that you understand, I'm more than a ZAP fan. I
> >> contribute/promote this project . Don't get me wrong, ZAP is my
> favourite
> >> tool and I just feel like they have used something I care for bad
> purposes,
> >> like thieves that steals your car to commit a bank robbery.
> >>
> >> I think we need to at least incentive(not only financially) and motivate
> >> more research into defending applications. Our defender projects help
> but
> >> they are far out cry to really make a difference.
> >
> > Ok, so we all agree tools are just tools and they can be used for good or
> > evil.  Let's put that behind us, yeah?
> >
> > I think the point Johanna is making is that while there are a lot of
> offensive
> > tools in the OWASP lineup to help everyone *understand* what the security
> > problems are, there are fewer mature tools projects on the defense side
> to
> > help developers solve them.
> I am not surprised by that at all. Being on the "breaker" side of things is
> "sexy"; being on the defender side, not so much.
> Also, the success criteria is much different. On the "breaker" side, you
> are proclaimed to have a successful tool if you either 1) greatly automate
> what used to be a tedious manual process, or 2) are able to find
> vulnerabilities that other pen testing tools are not able to find.
> On the defense side, the security community throws stones at any APIs that
> fail in any manner, despite those failures not being part of the
> developer's
> original threat model. (But that's a different story; IMO, the failure
> there
> is not clarifying what the threat model was in the first place and instead
> leaving it implicit and thus open to interpretation.)
> On offense, you don't have to bat 1000 (i.e., find all possible
> vulnerabilities) to be considered successful; on defense, your better
> bat at least close to 1000 if you expect to survive.
> > Is that a problem?  Is it just the nature of the beast that our
> solutions on
> > the defense side involve more documentation, testing guides, and
> awareness
> > campaigns?  I'm actually not sure the answer to that.
> I don't think it is a "problem" per se. I do think it is the nature of the
> beast. For instance, the tool provider doesn't generally get blamed if the
> tool user fails to use the tool incorrect and doesn't find all the possible
> vulnerabilities because documentation is poor. On the defensive side, I'm
> not sure that is true. Maybe that's because there we are dealing with a
> different community (developers) who very well may be blamed if there is
> a breach that gets through because they failed to use some defensive API
> in the correct manner because it was poorly documented and so they just
> pass
> that frustration and blame on, where as the offensive tools are most often
> are used by those in the security community (e.g., red teams, etc.) and
> they know that tools like ZAP are doing a difficult job and understand if
> there are a few false negatives because those must be balanced against
> false
> positives. (I am not trying to say that this attitude is prevalent amongst
> developers, but when there is a breach, I think they are more often made
> out to be their company's scape goats than someone from, say, the company's
> pen testing team.)
> The other part, which we all know and have repeated many times in these
> OWASP mailing lists, is that for a black hat to be successful, s/he only
> has to find a single way it. For the development teams to be successful,
> they have to defend every possible path in. That playing defense is harder
> than playing offense is simply part of the nature of the beast. Black hats
> have a further advantage in that they don't have to abide by the law, but
> as white hats, we do.
> > What I do think, however, is that while technical frameworks designed for
> > defense are a great idea, they aren't going to be adopted by the
> > majority of developers who need it if they are developed as independent
> > libraries/modules/etc.  The developers who need it have never heard of
> > and even if they have, they aren't sufficiently motivated to go out of
> their
> > way to integrate a security framework into their day-to-day
> development.  So I
> > don't think adding a bunch more defense tools is really the answer unless
> > those are somehow integrated into standard frameworks and development
> > platforms.
> Well, even if we (as the general InfoSec/AppSec community, not just OWASP)
> had a plethora of defensive APIs or other defensive tools to use, that
> still would not solve the problems. The bottom line is that the companies
> playing defense realize that this costs money, deployment time, etc. and
> they have to weigh those things against minimizing development costs and
> time-to-market, etc. This is particularly true for small-to-medium
> businesses.
> Many of them simply do not have the resources (staff, time, or $$) to
> adequately protect their web sites, etc., so instead, they keep their
> fingers
> crossed, _maybe_ by some hacking insurance, and outsource it to someone
> that
> 1) they hope knows what they are doing, and 2) can point fingers at as the
> scape goat should something bad happen. (Okay, I may be exaggerating a
> little,
> but not that much. They certainly do not come out and admit that though.)
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
> NSA: All your crypto bit are belong to us.

Johanna Curiel
OWASP Volunteer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160521/07bddc04/attachment-0001.html>

More information about the OWASP-Leaders mailing list