In my previous tip regarding the looming June 30, 2008, deadline for PCI requirement 6.6 compliance, I talked about the good, bad, and ugly of "application code reviews." Well, according to the PCI Security Standards Council, there's another option you can consider for compliance. Throw a Web application firewall (WAF) in front of your Web server and everything's cool. Just like putting a firewall in front of your network keeps everything safe and secure, right? Well, not so much. If only it were that simple.
The considerations for proper implementation of WAFs outlined in the PCI DSS 6.6 Information Supplement are actually pretty reasonable. It talks about the pros and cons of using WAFs and considerations to ensure they work effectively. But there's a dark side to WAFs, especially when using them as your only layer of defense. Here are the things about WAFs you won't hear about but affect your organization -- and ultimately the security of your Web application -- just the same:
- WAFs can be a single point of failure for your Web site/application. What happens when it crashes, it is misconfigured from the start, or it gets reconfigured outside of your change management processes? I once witnessed a situation where a single administrator made an out-of-band firewall change in a large ecommerce firm that took down half of the customer-facing systems. Bad news for business. Adding a WAF to the mix may only complicate already complex systems.
- WAFs won't protect against application logic flaws. What if an attacker is able to manually crawl through your application in non-standard ways and exploit a weakness? Or if your authentication mechanism, logging, or user provisioning systems aren't up to par, there's very little a WAF is going to be able to protect against. Also, WAFs aren't going to protect against underlying network and operating system-level vulnerabilities -- things that can cause just as much trouble for your system as Layer 7 weaknesses.
- Installing a WAF and letting it run is a whole different ball game than proactively managing it day in and day out. The latter of which very few administrators have time to do.
- Certain WAFs may not support SSL/TLS, and therefore they will not be able to protect against attacks carried out via HTTPS. Also consider the internal threat. Your WAF may be configured (or forced) to trust all local traffic. External attacks aren't your only concern.
- The "positive model" of whitelisting acceptable behavior referred to in the PCI DSS 6.6 Information Supplement may work best, but it's only as good as its configuration. All it takes is one oversight to create a gaping hole. With the complexities of today's Web applications and ecommerce platforms, that's not something I'd want to take on if I didn't have to.
The PCI DSS 6.6 Information Supplement states, "Proper implementation of both options would provide the best multi-layered defense." Well, sure, in an ideal world everyone would perform source code analysis, black box testing, and utilize a WAF. I'm all for doing what's right -- at least doing the basics. But the thing many people overlook in the name of compliance and checklist audits is that we don't live and work in an ideal world. Having the resources to be able to master application code reviews and manage a WAF is beyond what many organizations possess.
One other thing: Don't overlook what you may already have. You may actually have "WAF" capabilities in your existing firewall. I know that Check Point, Juniper and other big-name firewall vendors offer at least basic Web application layer protection as well as some add-on modules that provide pretty in-depth controls. If you have that, use it. It'd be a great add-on without the expense and effort of managing a separate WAF.
In the end, I go back to what I said in my previous tip: The simplest, least expensive, and most reliable way to ensure reasonable Web security is performing automated scans and hands-on manual analysis. Don't drain the ocean. Just focus on the basics. Once you get your periodic vulnerability testing processes in place, you can make improvements over time with source code analysis. Then, as a final layer of defense -- when resources permit -- you may consider installing a Web application firewall. No doubt it will serve you well long term, but that's not what most people need to focus on at the moment.
-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blogkbeaver@principlelogic.com.
