On Thu, Sep 24, 2009 at 9:46 PM, Wall, Kevin <kevin.w...@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.w...@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@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/ _______________________________________________ Secure Coding mailing list (SC-L) SC-L@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. _______________________________________________
