Re: [WEB SECURITY] Fwd: [SC-L] OWASP Podcast #6: WAFs

[Joe White <joe@xxxxxxxxxxxxxxxxxx>]

Arian, given that the silence over on the WAF Reviews site has been
deafening, .. =)  I think the wikipedia page is a great idea.

Also my apologies to the list for being so quite lately but I have
been very busy, .. deploying a WAF, .. =)

That said, I just had a chance to listen to this entire podcast and
thought I might take a moment to offer my thoughts.

First, some general thoughts related to what I have learned during my
WAF deployment:

1)  WAF tuning will take longer than you think
2)  WAF tuning will take longer than you think
3)  WAF tuning will take longer than you think

Sorry, i could not resist that one, . =)

With respect to the points raised in the podcast

My first thought while listening to the content of the podcast was
that it missed what I consider to be the greatest benefit of deploying
a WAF and that is the forensics visibility into the web application
stream that a WAF offers. I can tell you from experience that once you
look under the hood at the web application stream, it is very likely
to offer numerous events that I call HSMs or Holy Shit Moments.  =)

It seems to me that being able to see that UserX ran Paros on the web
application as a privileged/authenticated user at 2:00am on Saturday
morning is a good thing to know.  Also, the authenticated user that
tried a quick XSS test string on a particular parameter is now likely
to get a call from someone senior in his/her organization.  Sure Snort
may notice someone trying a quick SQL injection on your login screen
but I can assure you that visibility into certain web application
specific events was not available pre-WAF deployment.  I also submit
that this visibility alone justifies the time, effort and cost of a
WAF deployment.

It also struck me that the guys on the podcast were making far too
many generalizations about the expertise and technical abilities of
the folks that deploy WAFs.  Sure, they spoke from their own
experience but not everyone is concerned about PCI compliance or a
checklist solution.  There are those of us that are motivated simply
by doing the right thing for our users and our user's data.  I never
expected the WAF to be a magical panacea of happiness, .. far from it.
 I think a closer analogy would be a very powerful blank canvas that
once you take the time to learn it's capabilities will offer you the
ability to do your job better.  This has certainly proven to be the
case with me.

That said, there are certainly no shortage of opinions or passions
about the current state of WAFs.  I think this is a good thing.
Unfortunately, I found the first half of the podcast to be far too
negative and biased.  I am sure we all have an opinion or two about
what needs to be changed in order to make WAFs more useful and also
have an opinion on the order these changes need to be made.  This is
great conversation over a pint or three at your local pub but
speculation about the theoretical possibilities for the evolution of
WAF technology does not help me make the best use of what we have
available to us right now.

Later in the podcast, there was discussion about WAFs before the load
balancer or afterwards and this is certainly a useful discussion
because as the podcast suggested, if you place it behind the load
balancer, you had better hope to have a current network diagram.
Otherwise, you may find yourself pissing in the wind, which is never
particularly fun.  In my Web Application Security Roadmap presentation
at the recent OWASP NYC conference,  I suggest that you are likely to
need the help of other groups within your organization during your WAF
deployment and this was certainly the case for me.

The podcast also offered some discussion on the appliance model vs the
software model for WAF deployments.  I can categorically state that in
my case we did not want the extra load on the load balancer so
shimming the WAF into the load balancer was not a consideration and as
for the software model, adding another module to our web server builds
did not make sense for us either.  So in our case, the appliance model
totally made sense.  This does not mean that the appliance model is
right for you and after my recent experience, I firmly believe that
there is not a general rule of thumb here.  There *may* be a general
rule of thumb for the thought *process* to go though when deciding
which deployment makes sense for you and to be honest, this is the
type of dialogue I was hoping to hear more from the podcast.  For
example, what works for an ecommerce site is not necessarilly the same
thing that works for a CRM site or a full blown SaaS web application,
etc.

In short, I was disappointed that the guys on the podcast made too
many generalizations about what was right for web application security
*all* the time and not that there are many different types of web
applications out there and your milage may vary, etc.

I did find one point particularly intriguing, the notion that a
managed service offering is likely to spring up to service WAF
deployments.  I am not sure if I would have even entertained this
notion prior to working through my recent WAF deployment but now I
think I can see where this *might* make sense.  If for no other reason
than the expertise it will take to fully realize the power,
customizability and potential of WAF technology as it currently exists
today.  Until then, there is always the vendor's technical support
line.  =)

Hope this helps.

Thanks,
joe

<<<>>>


On Fri, Feb 6, 2009 at 10:21 AM, Arian J. Evans
<arian.evans@xxxxxxxxxxxxxx> wrote:
> BTW -- In this podcast you will find a glaringly apparent
> anti-WAF bias, which I myself used to have early on,
> before I figured out how to use them, and learned to
> ignore the more dishonest marketeers amongst them.
>
> The anti-WAF bias in the podcast is, amusingly, for the
> wrong reasons IMO, and shows an utter lack of experience
> or understanding of business needs/realities surrounding
> "secure code" and WAFs.
>
> WAFs *are* in a flux right now.
>
> They seem to work well on simple apps for binary syntax
> vulns (SQLi or not). They struggle on complex applications,
> particularly internationalized software, but mostly due to
> implementation issues (charsets, regional encoding support).
>
> They should work even better for many business logic vulns,
> but they don't (again due to implementation and usability
> limitations). Most folks I talk too that have been using WAFs
> for 1-2+ years are openly aware that they cannot protect
> simple business logic issues without explicit configuration
> and do not have the time to find and configure for things that
> the WAFs *could* easily be protecting.
>
> There are only three vendors that make up 95% of the market
> I run into, and for three different (specific) reasons.
>
> One of the three, for example, has some mature features
> for inline production that the other two do not. This makes
> it immediately obvious who has more experience running inline.
>
> Anyway -- there is a lot of discussion that could and should
> be happening around these devices and would really help
> out the consumers (and the WAF vendors, and again by
> proxy the consumers :).
>
> Is anyone really interested in this? I get lots of offline
> comments but the threads stay quiet.
>
> The community over @ SC-L seem to have their heads in
> the sand about what businesses are really doing, and going
> to continue doing to "secure their code".
>
> We should get some real-world WAFness going on here,
> or on Joe's website. And another opportunity:
>
> http://en.wikipedia.org/wiki/Web_application_firewall
>
> The vast majority of you I talk to are in the process of
> evaling, buying, or deploying WAFs. And I stumble across
> more and more of them.
>
> Where are the "Notes from the Field" from those of
> you working with them?
>
> Are we all going to let the software-purist-tautology
> crowd define the solutions out of the problem for us? :)
>
> -ae
>
>
>
> ---------- Forwarded message ----------
> From: Arian J. Evans <arian.evans@xxxxxxxxxxxxxx>
> Date: Thu, Feb 5, 2009 at 5:18 PM
> Subject: Fwd: [SC-L] OWASP Podcast #6: WAFs
> To: "websecurity@xxxxxxxxxxxxx" <websecurity@xxxxxxxxxxxxx>
>
>
> Didn't see this make the webappsec lists -- but it's right up the
> alley of folks on WASC.
>
> Interesting that it does not contain any of the "WAF usual-suspects"
> from WAF-land:
>
> ---------- Forwarded message ----------
> From: Jim Manico <jim@xxxxxxxxxx>
> Date: Thu, Feb 5, 2009 at 3:03 AM
> Subject: [SC-L] OWASP Podcast #6
> To: "SC-L@xxxxxxxxxxxxxxxx" <SC-L@xxxxxxxxxxxxxxxx>
>
>
> Hello SC-L
>
> I just pushed OWASP Podcast #6 live at
> http://www.owasp.org/index.php/Podcast_6 - an OWASP Roundtable with
> Brian Holyfield, Marcin Wielgoszewski, Andre Gironda and myself, Jim
> Manico. Our focus was WAF's.
>
> Thanks and I hope  you enjoy,
> Jim Manico
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L@xxxxxxxxxxxxxxxx
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________
>
>
>
> --
> Arian Evans
>
> "From the hour the Pilgrims landed,
> to the present day, events, occurrences,
> and tendencies prove that to ensure
> peace, security, and happiness, the
> rifle and pistol are equally indispensable"
> -- George Washington
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA