Archive for April, 2008

PCI 6.6 Information Supplement Released!

April 22, 2008

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

…You should be reading Matt Flynn

April 18, 2008

I have to admit that I have begged, borrowed, and flat out stolen RSS feed lists from friends, peers, and collegues.  I’m not sure how I came across this Matt Flynn guy, but I’m glad I did.  His posts are insightful, varied, objective, and amusing.  Anyway, if you haven’t read him, add his feed to your list, and/or start with this outstanding post on ‘IT Risk = Lost Business Opps‘.

Keep the content coming, Matt!

Formal Guidance for PCI Requirement 6.6- COMING SOON!

April 16, 2008

How can you not love Las Vegas? I’m at the Electronic Transactions Association’s 2008 Annual Meeting and Expo, and have enjoyed the communications and feedback in the meetings attended. It seems all the major players in the payment industry are here! I was sent to represent WhiteHat for the PCI Security Standards Council’s meetings for the Payment Application – DSS and Quality Assurance discussions.

There were a couple of documents disseminated in hard copy intended for review and discussion amongst the QSA, ASV, and Parcitipating Organization communities. You can see some of the leaked language here. I am told these documents will be made public on Friday, I will post a link as soon as I see it.

My encouragement to readers prior to the release of that document is to focus on the very obvious intent of Requirement 6.6, “Ensure that all web-facing applications are protected against known attacks.”

While there has been a great deal of discussion and and conjecture about percieved responsiveness- the PCI Council has been very active in gaining concensus for specific guidance language. The PCI SSC has remained true to their mission, “to enhance payment account security by driving education and awareness of the PCI Data Security Standard and other standards that increase payment data security.”

The council is finalizing a guidance document for two requirements in the PCI Data Security Standard version 1.1:

  • Requirement 6.6, concerning the protection of web-facing applications, and
  • Requirement 11.3, the penetration testing requirement.

After these guidance letters are posted on the PCI SSC’s website, we will discuss their contents in the open.


Follow

Get every new post delivered to your Inbox.