A Web Application Firewall May Be In Your Future

  • Team Omega
  • April 1, 2013

Auditors are recently cracking down on PCI DSS requirement 6.6 to either

1)      Review public-facing web applications considered to be in scope via manual or automated application vulnerability security assessment tools or methods, at least annually and after ANY changes

2)      Run a web application firewall in front of any public-facing web applications that are considered to be in scope. 

This means that you must either run extensive tests and re-test every time you make a change to your web application or place a web application firewall in front it.  In-scope web applications include any web applications that are either directly in the cardholder data environment or any web applications that are used to access machines in the CDE.

Manual web application vulnerability assessments are very likely just way to labor-intensive to be used either by your own organization or by your vendors to assess web applications especially considering their high rate of change.   So, unless you go through the expense and process of setting up an automated application vulnerability security assessment tool, and become an expert in its use, you are left with the simplest approach of installing a web application firewall in front of your web applications.  

A web application firewall (WAF) as defined by OWASP, the open web application security project, “is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation.  Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection.”   Unlike a standard network firewall, it focusses specifically on web application traffic not on all IP traffic.  Once a WAF is put in place it watches all HTTP and HTTPS browser to web server traffic for attempts to attack your web applications and prevents the attack.  So even if your own developers or one of your vendor’s developers left a vulnerability open in their web application, the WAF will prevent it from being exploited by a browser user or even a hacker tool that looks like a browser to your web application.

Be sure and check that all your in-scope web applications or service providers that host your in-scope web applications are completely protected per PCI DSS requirement 6.6 before your QSA identifies a gap.   Otherwise, if the QSA doesn’t detect a gap, instead of a QSA, you may find a PCI forensic inspector (PFI), or even the US Secret Service  knocking on your door one day.   No merchant wants that.