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.

Summary:

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!!!

About these ads