PCI 6.6 Information Supplement Released!

Today, the PCI Security Standards Council has released an “Information Supplement: Payment Card Industry Data Security Standard (PCI DSS) Requirement 6.6 Code Reviews and Application Firewalls”. This guidance provides supplemental information, and in no way replaces or supersedes Requirement 6.6 in the Data Security Standard.

The Information Supplement is located here.

There have been many questions and concerns regarding this requirement- clarity as been delivered! While the intent was obvious, the terminology had created quite a buzz in the Application Security community. I think the Securology blog summarized some of the questions posted various blogs and mailing lists:

1) What are Web-Facing Applications? In a prior post I detailed perspective shared with many fellow QSAs when performing an onsite audit. The PCI Security Standards Council answered this question very succinctly- I will paraphrase this as ‘web applications accepting input from untrusted environments.’

There is further elaboration a couple lines later (quoted this time), “The intent of Requirement 6.6 is to ensure web applications exposed to the public Internet are protected against the most common forms of malicious input,” which leads very clearly to question two…

2) What are “known attacks?”

“The minimum vulnerabilities to consider are described in Requirement 6.5 (refer to the References section for other sources of information on web applications)”

The additional sources reference the following:

  • OWASP Top Ten
  • OWASP Countermeasures Reference
  • OWASP Application Security FAQ
  • Build Security In (Dept. of Homeland Security, National Cyber Security Division)
  • Web Application Vulnerability Standards (NIST)
  • Web Application Firewall Evaluation Criteria (from our friends at WASC, the Web Application Security Consortium)

3) What specifically is, “An organization that specializes in application security?”

“Manual reviews/assessments may be performed by a qualified internal resources or qualified third party. In all cases, the individual(s) must have the proper skills and experience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings. Similarly, individuals using automated tools must have the skills and knowledge to properly configure the tool and test the environment, use the tool, and evaluate the results.”

“If internal resources are being used, they should be organizationally separate from the management of the application being tested.”

There some real fantastic clarifications! I whole heartedly echo Ivan Ristic’s comments regarding how, “the Council has gone to a great length to discuss how they don’t want to see the automated tools (of any sort) used to just tick a few boxes away. Throughout the document they emphasize the importance of doing the job properly, and by qualified personnel.”

4) Does black box, or run-time testing meet the requirement?

This question has been elegantly answered above. There are four bullets on the first page of the guidance document speaking to what types of activities can meet the ‘custom application code review’ requirement:

  1. Manual review of application source code
  2. Proper use of automated application source code analyzer (scanning) tools
  3. Manual web application security vulnerability assessment
  4. Proper use of automated web application security vulnerability assessment (scanning) tools

5) What does 6.6 say about remediation?

The original standard states, “that custom application code is periodically reviewed…: (and) that all coding vulnerabilities were corrected; and that the application (is) re-evaluated after the corrections” I will be doing a separate post on how or where to draw the line- I think this is a function of risk management and a solid auditor will earn their keep in evaluating those processes.

In the landscape of regulatory standards out there, PCI has done a pretty fantastic job of maintaining a prescriptive and technical set of audit points. C’mon, do we want absolutely EVERYTHING dictated to us? How ‘big brother’ does a set of requirements need to be? </humor> In all seriousness, balancing the notion of ‘prescriptive requirements’ and ‘latitude of application’ is a delicate act, and I feel that PCI is doing it quite well.

6) What is an application layer firewall?

“In the context of Requirement 6.6, an “application firewall” is a web application firewall (WAF), which is a security policy enforcement point positioned between a web application and the client end point. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-along device, or integrated into other network components.” There are three full page on the WAF remediation option, from definition to recommended capabilities and additional considerations.


There have been questions and complaints surrounding the responsiveness and agility of the council. I will do a separate post on the successes and public commitments of the PCI SSC- let’s make it simple and communicate how very active those unsung heroes are responding to thousands of queries, clarifications, standards development, forensic and incident research, not to mention the legal ramifications of what they publish.

Hats off, and congratulations to the hardworking team at the PCI Security Standards Council. There is an untold mountain of work required to develop standards and guidance verbiage, achieve consensus AND legal blessing from all five payment brands prior to publishing anything. Keep up the great work!!!

12 Responses to “PCI 6.6 Information Supplement Released!”

  1. PCI Section 6.6 | Grumpy Security Guy Says:

    […] Ford has a good roundup of the new PCI 6.6 clarification in PCI 6.6 Information Supplement Released. All I have to say is well done to the PCI council! From my first pass it seems like it is pretty […]

  2. VERT Says:

    PCI Requirement 6.6 Update Released…

    It looks like the PCI Security Standards Council has posted their update to Requirement 6.6 (available here). They have provided information above and beyond what I mentioned last week. They have also provided a great deal of clarification around Web…..

  3. Tod Says:

    Maybe I’m missing something here … but, my reading of this document is that it negates the entire intent of 6.6.

    Requirement 6.6 should be requiring a code review, automated at minimum … or a WAF for the big guy’s that just can’t review 100+ thousand lines of code. However, I don’t want to go off on a tangent of what 6.6 should be doing.

    Page 2 of the Supplement under Option 1 lists four alternatives … only one of which may need to be done to be compliant. However, alternatives 3 & 4 of Option 1 are already being accomplished to meet Req 11.3, annual penetration testing. Req 11.3 is required for everybody … unless, somebody is letting somebody bypass 11.3 on the road to compliance.

    Again, maybe I’m missing something … but this Supplement just negated Req 6.6 all together.

  4. Rafal Los Says:

    Good analysis – great round-up of the facts to help disspell some of the outstanding confusion. The more we write, the more people read, and more they will understand… at least that’s the hope.

    Thanks for the article.

    I have put together a similar one regarding just the new update on http://portal.spidynamics.com/blogs/rafal/archive/2008/04/22/Navigating-the-PCI-DSS-Standards_2E002E002E00_.aspx


  5. greg reber Says:

    This clarification does clarify, but I’ll bring up two points of contention:

    1 – black box penetration tests of applications do not provide the same level of risk perspective as a source code analysis, and in my opinion, should not be called ‘code review’ or equated as risk management options

    2 – WAF implementation and source code analysis together will provide the best security. WAF onfigurations that take into account results from a code review are tailored to the risks present in the application, not just some generic list of vulnerabilities.


  6. PCI Requirement 11.3.2 - Penetration Testing « Trey Ford - Security Spin Control Says:

    […] Requirement 11.3.2 – Penetration Testing Tod raised a question in response to the PCI 6.6 Information Supplement Released post, a question heard by many QSAs (and […]

  7. securology Says:

    Trey, thanks for the link back!

    It’s good to finally have the supplement, but it would have been nice to have it months ago. Do you think the PCI Security Council watered down 6.6 by allowing blackbox (rutime) scans to meet the requirement for a “code review”?

  8. PCI 6.6 Webinar *TOMORROW* « Trey Ford - Security Spin Control Says:

    […] other background reading, check my prior 6.6 briefing, and the article in SC […]

  9. OnSaaS » Blog Archive » Tough Security Questions for SaaS Providers - Part 2 Says:

    […] Ford of Security Spin Control has a fairly good explanation of the recently released PCI information supplement on requirement […]

  10. treyford Says:

    @Securology, re: watered down 6.6- almost all regulatory requirements have experienced some degree of erosion and clarification, and I feel that infers the balance in the prescription and application of those standards.

    In no way do I think that the interpretation of ‘code review’ was diluted by not adding the word ‘source’ before the word ‘code’ to the standard. As I see it, source code review and run time testing both help in painting a more complete view of what vulnerabilities a web facing application may have.

  11. Benchmarking Application Security Expertise! « Trey Ford - Security Spin Control Says:

    […] Benchmarking Application Security Expertise! By treyford In protecting websites, we know there is a very serious need for expertise.  What is the best way to communicate that?  Certifications are one of the only routes to establishing a benchmark for expertise in this fast paced technology driven industry.  Defensible application security expertise is in high demand- this is even called out in some of my favorite guidance language: […]

  12. Zen 2.0 » Blog Archive » Tough Security Questions for SaaS Providers - Part 2 Says:

    […] Ford of Security Spin Control has a fairly good explanation of the recently released PCI information supplement on requirement […]

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 )

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

%d bloggers like this: