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

[Marcin Wielgoszewski <marcinw86@xxxxxxxxx>]

Hey Joe, I'll address a couple of your talking points since I felt
they were directed more towards my comments on the podcast than
anything.

> 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
>

Definitely.  Issues I have come across time and time again, is when
tuning, what you thought was going to work, had to be revisited a week
later because the code changed and/or the application is accepting
different input somewhere.  this is painful.

> 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.  =)

I did mention WAFs, like IDS, offering visibility into your
applications that you may not have known before.

> 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.

Sure.  I also was able to see "penetration testers" performing their
Nikto "web application scans" outside of their test windows.

> 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.

Alright, so I made some generalizations about IT shops not being able
to handle the extra effort required to maintain a WAF.  Some very
mature organizations may not have that problem, but I would also
venture out on a limb and say they're also not as dependent on those
WAFs for protection as those looking for a fix to their software
insecurity problems.

> 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 struggles you face when deploying a WAF is the one thing that
annoys me when I hear that phrase "throw a waf in front," because it
requires interfacing with so many different groups.  I'm sure if
anyone's read Tao of Network Security Monitoring by Richard Bejtlich,
you'll know that listening on traffic off a SPAN port is not ideal
either, especially when your web servers are pushing 1.0+Gbps.  That,
and you're at the mercy of the switch owner to make sure the right
traffic is being mirrored.

> 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.

With regards to positioning of a WAF on the network, keep in mind the
extra maintenance of tracking the webservers in the WAF itself.  Just
because your receiving traffic from them all, doesn't mean your WAF is
configured to look at it.  You would have to account for this in
change management processes too, so when new boxes pop up you can stay
on top of it.  But definitely, before the load balancer is much
easier, cause you only have to deal with the VIPs, and not any rfc1918
addresses.  But keep in mind, this configuration was deployed in
monitoring mode, and not inline.  I do not think any of the 'big 3'
are mature enough appliances to be placed inline, acting as reverse
proxies for a) increased risk; b) performance; and c) a combination of
blocking and tuning involved.  Like you mentioned above, tuning will
take longer than you think...  the moment you go active and start
blocking, you'll run into more issues with regards to tuning.

> 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.

YMMV is always a given.  We could be here all day and discuss many
scenarios, but then instead of only listening to half of the podcast,
Arian would have listened to about 5 or 10 percent.

> 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.  =)

I think they'll go the way of IDS... get outsourced to the SOC with
(hopefully web security) guys to watch that stuff all day.  IMO,
there's just too much going on, or could be doing day to day to be
immersed in WAF.

And on the subject of tech support...  Have you even tried calling
tech support?  I once asked if there was a section in the admin panel
that allowed me to upload a CA-signed SSL cert instead of using a
vendor's self-signed cert.  The answer?  "What's the big deal?  Just
click okay to the warning error each time."  /facepalm

-Marcin
tssci-security.com

----------------------------------------------------------------------------
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