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

Kevin W. Wall kevin.w.wall at gmail.com
Sun May 22 00:21:55 UTC 2016

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 OWASP,
> 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.)

Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

More information about the OWASP-Leaders mailing list