I've tried not to jump into these types of coversation. This is not a as simple as hackers win, the hacker ecosystem exists so vulnerabilities come to light not just black hats have them, hence gray and white hats. These hackers ethically disclosured and tools are developed so mitigations can be developed. So in reality defenders really have no way to ensure their security feature actually works without hackers;<span></span> the right hand actually needs the left hand. It's truly sad I have to say this to OWASP leaders list, we should know this better than any group this fact.<br><br>On Saturday, May 21, 2016, johanna curiel curiel <<a href="mailto:johanna.curiel@owasp.org">johanna.curiel@owasp.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">>><span style="font-size:13px">I am not surprised by that at all. Being on the "breaker" side of things is </span><span style="font-size:13px">"sexy"; being on the defender side, not so much.</span><div><br></div><div>Innovation is about thinking out of the box solutions and this is what we are not doing enough. </div><div>Sure not within OWASP. Sure not in Defender projects. Except some, like SeraphimDroid using Machine learning to stop malware.<br><div><br></div><div>So we accept our loss blaming it to the fact that is easier, sexier to hack than protect and create defense?</div></div><div><br></div><div>Thats is a quite sad scenario and fate to accept...sure for a bunch or 'security experts' in this community. </div><div><br></div><div>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<a href="https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project" target="_blank"> core values:</a><br></div><div><b style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px"><br></b></div><div><b style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px">"INNOVATION: </b><span style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px">OWASP encourages and supports innovation and experiments for solutions to software security challenges"</span><br></div><div><br></div><div>Projects like Rust are trying to do that. </div><div><br></div><div>Why can't we discuss and brainstorm new ways to defend applications? Bring a balance by spending more energy on this?</div><div>How can OWASP motivate this more?</div><div><br></div><div>Only answer I get here is that we are doomed and that hackers have the advantage.😒</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 21, 2016 at 8:21 PM, Kevin W. Wall <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','kevin.w.wall@gmail.com');" target="_blank">kevin.w.wall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, May 20, 2016 at 1:02 PM, Timothy D. Morgan <<a href="javascript:_e(%7B%7D,'cvml','tim.morgan@owasp.org');" target="_blank">tim.morgan@owasp.org</a>> wrote:<br>
><br>
</span><span>>> Respectfully, and that you understand, I'm more than a ZAP fan. I<br>
>> contribute/promote this project . Don't get me wrong, ZAP is my favourite<br>
>> tool and I just feel like they have used something I care for bad purposes,<br>
>> like thieves that steals your car to commit a bank robbery.<br>
>><br>
>> I think we need to at least incentive(not only financially) and motivate<br>
>> more research into defending applications. Our defender projects help but<br>
>> they are far out cry to really make a difference.<br>
><br>
> Ok, so we all agree tools are just tools and they can be used for good or<br>
> evil.  Let's put that behind us, yeah?<br>
><br>
> I think the point Johanna is making is that while there are a lot of offensive<br>
> tools in the OWASP lineup to help everyone *understand* what the security<br>
> problems are, there are fewer mature tools projects on the defense side to<br>
> help developers solve them.<br>
<br>
</span>I am not surprised by that at all. Being on the "breaker" side of things is<br>
"sexy"; being on the defender side, not so much.<br>
<br>
Also, the success criteria is much different. On the "breaker" side, you<br>
are proclaimed to have a successful tool if you either 1) greatly automate<br>
what used to be a tedious manual process, or 2) are able to find<br>
vulnerabilities that other pen testing tools are not able to find.<br>
<br>
On the defense side, the security community throws stones at any APIs that<br>
fail in any manner, despite those failures not being part of the developer's<br>
original threat model. (But that's a different story; IMO, the failure there<br>
is not clarifying what the threat model was in the first place and instead<br>
leaving it implicit and thus open to interpretation.)<br>
<br>
On offense, you don't have to bat 1000 (i.e., find all possible<br>
vulnerabilities) to be considered successful; on defense, your better<br>
bat at least close to 1000 if you expect to survive.<br>
<span><br>
> Is that a problem?  Is it just the nature of the beast that our solutions on<br>
> the defense side involve more documentation, testing guides, and awareness<br>
> campaigns?  I'm actually not sure the answer to that.<br>
<br>
</span>I don't think it is a "problem" per se. I do think it is the nature of the<br>
beast. For instance, the tool provider doesn't generally get blamed if the<br>
tool user fails to use the tool incorrect and doesn't find all the possible<br>
vulnerabilities because documentation is poor. On the defensive side, I'm<br>
not sure that is true. Maybe that's because there we are dealing with a<br>
different community (developers) who very well may be blamed if there is<br>
a breach that gets through because they failed to use some defensive API<br>
in the correct manner because it was poorly documented and so they just pass<br>
that frustration and blame on, where as the offensive tools are most often<br>
are used by those in the security community (e.g., red teams, etc.) and<br>
they know that tools like ZAP are doing a difficult job and understand if<br>
there are a few false negatives because those must be balanced against false<br>
positives. (I am not trying to say that this attitude is prevalent amongst<br>
developers, but when there is a breach, I think they are more often made<br>
out to be their company's scape goats than someone from, say, the company's<br>
pen testing team.)<br>
<br>
The other part, which we all know and have repeated many times in these<br>
OWASP mailing lists, is that for a black hat to be successful, s/he only<br>
has to find a single way it. For the development teams to be successful,<br>
they have to defend every possible path in. That playing defense is harder<br>
than playing offense is simply part of the nature of the beast. Black hats<br>
have a further advantage in that they don't have to abide by the law, but<br>
as white hats, we do.<br>
<span><br>
> What I do think, however, is that while technical frameworks designed for<br>
> defense are a great idea, they aren't going to be adopted by the<br>
> majority of developers who need it if they are developed as independent<br>
> libraries/modules/etc.  The developers who need it have never heard of OWASP,<br>
> and even if they have, they aren't sufficiently motivated to go out of their<br>
> way to integrate a security framework into their day-to-day development.  So I<br>
> don't think adding a bunch more defense tools is really the answer unless<br>
> those are somehow integrated into standard frameworks and development<br>
> platforms.<br>
<br>
</span>Well, even if we (as the general InfoSec/AppSec community, not just OWASP)<br>
had a plethora of defensive APIs or other defensive tools to use, that<br>
still would not solve the problems. The bottom line is that the companies<br>
playing defense realize that this costs money, deployment time, etc. and<br>
they have to weigh those things against minimizing development costs and<br>
time-to-market, etc. This is particularly true for small-to-medium businesses.<br>
Many of them simply do not have the resources (staff, time, or $$) to<br>
adequately protect their web sites, etc., so instead, they keep their fingers<br>
crossed, _maybe_ by some hacking insurance, and outsource it to someone that<br>
1) they hope knows what they are doing, and 2) can point fingers at as the<br>
scape goat should something bad happen. (Okay, I may be exaggerating a little,<br>
but not that much. They certainly do not come out and admit that though.)<br>
<span><font color="#888888"><br>
-kevin<br>
</font></span><div><div>--<br>
Blog: <a href="http://off-the-wall-security.blogspot.com/" rel="noreferrer" target="_blank">http://off-the-wall-security.blogspot.com/</a>    | Twitter: @KevinWWall<br>
NSA: All your crypto bit are belong to us.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div>Johanna Curiel </div>OWASP Volunteer</div></div>
</div>
</blockquote>