Secure Coding mailing list archives
Another WAF in town
From: ivan.ristic at gmail.com (Ivan Ristic)
Date: Fri, 25 Sep 2009 00:05:21 +0100
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/
Current thread:
- Another WAF in town Kenneth Van Wyk (Sep 24)
- Another WAF in town McGovern, James F (HTSC, IT) (Sep 24)
- Another WAF in town Wall, Kevin (Sep 24)
- Another WAF in town Ivan Ristic (Sep 24)
- Another WAF in town Benjamin Tomhave (Sep 24)
- Another WAF in town Wall, Kevin (Sep 24)
- Another WAF in town McGovern, James F (HTSC, IT) (Sep 24)