Another WAF in town

[ivan.ristic at gmail.com (Ivan Ristic)]

On Thu, Sep 24, 2009 at 9:46 PM, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
> > Interesting approach. Curious to know if this will satisfy a
> > PCI auditor as a compensating control (section 6)
>
> I think that's presently untested and therefore likely unknown.
> I would guess it depends on the auditor's perspective. On one
> had, having a separate WAF appliance provides you with separation
> of duties so it's harder for a dev team to configure the WAF so
> it accepts everything (much like I've seem some folks use a regex
> of ".*" for things in Struts validators that they haven't gotten
> around to thinking more deeply about). On the other hand, the
> dev team is in a much better position to truly customize the rule
> set to use an actual whitelist approach.

The problem with that approach (giving developers control over WAFs)
is that virtual patching and secure coding are conflicting
requirements. Asking the same team to do both is only asking for
trouble. I'd rather see developers focusing on the application code,
with other teams handling virtual patching.

Isn't the whole point of WAFs that you don't need developers to use them?


> The mod_security WAF
> approach generally leads to a signature-based, black-list approach.

I will agree that most people use it that way, but that's only because
it's the low hanging fruit: signatures catch worms and automated
exploits and tools, and some offenders with minimal effort. But
there's nothing fundamentally different in a Servlet filter-approach
(not that I've seen this particular tool) from what ModSecurity
already does. Writing white lists in ModSecurity is generally easy,
and many people use them for their virtual patches.

It's not the tool, it's the user who's deciding what to do. Perhaps
ModSecurity is not a good representative of the WAF space for the
purpose of this discussion. It was specifically designed to allow
experienced users to do whatever they liked. In my experience, other
WAFs don't typically offer that. From that point of view, being able
to write some external-to-application Java code to fix a problem may
be very tempting indeed. Still, I would be worried because if the WAF
is too close to the application, the two are bound to gel over time.


> -kevin
> ---
> Kevin W. Wall ? ? ? ? ? Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com ? ?Phone: 614.215.4788
> "It is practically impossible to teach good programming to students
> ?that have had a prior exposure to BASIC: as potential programmers
> ?they are mentally mutilated beyond hope of regeneration"
> ? ?- Edsger Dijkstra, How do we tell truths that matter?
> ? ? ?http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> 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.
> _______________________________________________

-- 
Ivan Ristic
Security assessment of your SSL servers
https://www.ssllabs.com/ssldb/