PCI SSC Clarifies Web Application FW & Code Reviews, Officially

The payment card industry security standards council released a publication today providing paths for organizations to take to satisfy the PCI DSS v1.1 Requirement 6.6. As has been consistent, the council has recognized that confusion existed and parties were addressing this mandate in an inefficient and in some cases ineffective manner. The council provides several options for addressing the risks defined in the standard. These options include:

  • Application Code Reviews – (not necessarily MANUAL all the time), and can be achieved through any of these approaches:
    • Manual reviews (granted not possible on proprietary systems)
    • Automated Source Code Scanners
    • Manual Web Application Vulnerability Assessment
    • Automated Web App Scanners
    • Independence and qualification of individuals performing effort (internal or external) remains necessary
    • Integration of these controls should occur and are nicely described in the clarification document (Page 3)
    • Highlighted in the “Additional Considerations” section on Page 6 and 7 there is an important note that not all alerts are cause for non-compliance and some deployments of web applications (use of cookies, unusual headers, etc..) may require an experienced individual to ascertain which are threats and which are not to the organization.
  • Application Firewalls (WAF) – defined as a technology that inspects that packets and hence inputs crossing from an untrusted to trusted environment. In the PCI SSC own words:
    • “…designed to inspect, evaluate, and react to the parts of an Internet Protocol (IP) message (packet) consumed by web applications, and therefore public applications frequently receive uninspected input.” (Page 4)
  • The council is not advocating extra or redundant controls, but is ensuring that the packets are inspected. To this point they have highlighted that OTHER means of accomplishing and mitigating this risk are available such that “IT packet content adequately inspected (i.e., providing equivalent protection) by network firewalls, proxies, and other components do not have to be RE-INSPECTED by a WAF”.
  • Page 5 has a few nice succinct bullets to describe the necessary functionality and inspection protocols highlighted (but certainly not forever set in stone) that must be included in Option 2 WAF.

A great document with lots of specifics to clear the air. Far superior than the information that was available after the ETA conference. There are some nice “Sources of Information” without links, so I have provided those to accelerate your efforts and research:

As always – add comments to enhance and improve our community and the controls under discussion.


James DeLuccia

Additional References:


4 responses to “PCI SSC Clarifies Web Application FW & Code Reviews, Officially

  1. Pingback: PCI SCC clarifies Web Application FW Requirement Sec 6.6 « Payment Card Security & IT Controls Explained

  2. So does 6.6 Code Review Option #4 = 11.2b?

  3. Rob –

    Great question. Section 11.2b refers specifically to Vulnerability Scanning, as those done by an authorized scanning vendor. Section 6 specifically focuses on web applications and their associated risks. It is highly efficient to have them each be one in the same (i.e. Have a full blown web app / vuln assessment for one period, and vanilla vulnerability scans for the other periods by an ASV to leverage the same report), but there are skillset and differences in scope that may arise and create a cost variance that is undesirable.

    Other thoughts?

  4. 6.6 Clarification bullet #4 under code review:

    4. Proper use of automated web application security vulnerability assessment
    (scanning) tools

    11.2b ASV must scan web applications and detect for cross site scripting and SQL injection vulnerabilities. referenced (Technical and Operational Requirements for Approved Scanning Vendors (ASVs) v 1.1 2-4)

    I’ll add another point.

    11.3 Pen Test for the application layer will further test the vulnerabilities for exploits and should cover more of the OWASP and code and in my opinion have a manual process to it.

    I believe by adding the 4th bullet point to the code review it opened the door to the 6.6 requirement to more interpretations of the requirement instead of clarifying it. I have seen too many automated tools miss web application vulnerabilities and 6.6 should have filled that hole.

    My 2 cents.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s