Web application firewalls (WAF) are likely to be the product of choice for most SMBs required to comply with PCI
DSS 6.6. The other choices, various code review options, can be very expensive and only capture the condition of your applications at a specific point in time.
Your developers have neither the time nor the security expertise for code review, and if you outsource development, it's beyond your direct control. Automated code scanning tools help, but the reviews still require substantial human intervention.
That's not to say you shouldn't consider code review, but if you have a small IT staff, you can't afford to divert their time and/or your money.
Expect to put some time in up front for installing and configuring your Web application firewall, and be aware that you're not done at that point. The spirit of PCI DSS 6.6 is to protect your applications, which are, after all, the doors to credit card numbers and other sensitive customer data.
You'll need to tune, monitor and re-tune the firewall as it talks to you -- it could be telling you your code has vulnerabilities under attack or that what looked like a threat is just a false positive. In either case, you have to look, assess and respond. This ongoing process will demonstrate to your QSA that you are doing more than trying to comply by spending a few thousand dollars to generate some template reports. You'll get a lot of value out of your investment.
"If you are doing this just to get through the assessment, putting extra effort is probably not going to be very valuable," said Greg Young, research vice president at Gartner Inc., "but if you are really looking to protect your applications, PCI aside, you can put in a little extra effort into monitoring, actually respond to what you are seeing and keep your apps free from vulnerabilities." But while WAF products have matured and become easier to use, they are certainly not plug and play. No security tool is. "People are nervous about the commitment it takes once you put one of these things in; if you have it, you're going to have to do something about it," said Dan Nadir, vice president of product management for WAF vendor Breach Security Inc. "They need to feel comfortable that a tool is going to help them be compliant, or help them have a more secure website and not cost them a bunch of time."
There are a number of deployment models, including full proxy, transparent proxies, inline or out-of-band and even some Web server plug-ins. Young doesn't recommend the latter, out of concern that the assessors will frown on a WAF that doesn't sit in front of the Web applications. The choice won't impact the administration of the firewall once it is up and running, but the wrong architectural selection can leave your network gasping. You'll pay a performance hit no matter what you choose, so select the right architecture for your network and applications.
"Getting it right the first time seems to be the biggest issue," said Young. "Vendors don't know your applications as well as you do, and the types of interactions -- things like connections per second, the kind of data moved are just as important as performance. You have to get involved in making sure you make right sizing selection."
On the high end, WAF modules can be installed on application delivery controllers (ADC) -- heavy duty appliances that act as application load balancers -- from companies like F5 and Citrix. That's a neat solution, but few smaller companies can afford or need ADCs.
For SMBs, Young says to look for upcoming announcements from unified threat management vendors, who will offer WAF as an optional module.
Web application firewalls, do not, however, lend themselves to the managed services model, which is growing very popular for small organizations.
For those who like to roll up their sleeves and get really deep under the hood, there's ModSecurity, a popular well-packaged open source Web application firewall, developed and supported by Breach Security. It's suitable for companies with no more than a few Web servers to protect, but you'll need someone in house who likes to spend their time tuning and writing rules.
Anticipate a "learning period," because these behavior-based tools analyze traffic and establish a base of "normal" behavior over time. A lot of your tuning and tweaking will come during this ramp-up period, as you decide what constitutes a real threat and what is a false positive or irrelevant to your Web application environment.
The level of involvement during and after this initial phase will depend on your applications. If they are static, with only occasional minor changes, you probably won't need to do more than make quick checks to see if anything warrants immediate attention and generate reports as needed for operations, management and audits.
On the other hand, if your applications are very dynamic, with frequent feature and function additions and modifications, the Web application firewall will be relearning and responding to those changes, which means more monitoring and response for you.
Company size doesn't necessarily matter when it comes to WAFs. Many companies with popular, heavily trafficked commercial websites are SMBs when you consider the number of employees and small IT staffs. These sites are likely to change frequently, but security will probably take a back seat to getting new features and functionality into production and generating revenue.
Further, smaller organizations are less likely to have a strong change control program, so apps are more likely to go live without thorough quality and security assessments. WAFs become even more important in this type of environment, meaning care and feeding are a must as you analyze threats against real vulnerabilities.
However, Web application firewalls can become the developers' friend. WAFs reveal not only security vulnerabilities, but also design flaws and problems like broken links. Design flaws can be both a security and a business issue.
For example, Nadir recalls seeing a form that had fields for both credit card numbers and customer ID numbers. Some customers were inadvertently putting their credit card numbers in the ID number field. This was a flaw the application allowed. So, credit card numbers were unprotected because nobody knew they were there and orders went unprocessed.
"Time and time again, people call about PCI, but then they understand how the Web application firewall can help make applications better," Nadir said. "You even see what used to be a PCI project funded by the application people."
"For SMBs, given the resources they have, Web application firewall is usually a good fit," said Young. "You get out of it what you put into it. Using the default configuration, you get a good amount of value, but if you really want to tune and really want to protect yourself, put some effort into looking at alerts and fine tuning."