The Payment Card Industry (PCI) Data Security Standards (DSS) are a broad set of requirements for protecting payment account data security. PCI, which is governed by the independent PCI Security Standards Council, was co-developed by the giants of the payment industry as a standard for consistent data security among the participants in payment transactions and includes requirements for security processes, policies and countermeasures to protect applications and networks. Recent estimates state that the cost of compliance with PCI DSS can reach as high as $10 million for companies with a large volume of credit card transactions.
While the PCI DSS is much more detailed and specific in what organizations are required to do, versus other standards like Sarbanes-Oxley and HIPAA, much is left to individual interpretation as organizations attempt to achieve the compliance necessary to participate in online commerce. And adding to the confusion, the PCI DSS undergoes periodic updates that in some cases appear to conflict with earlier mandates. In this article, we will focus on one of the most fluid areas: Web application security.
Drafters of the original PCI DSS and subsequent updates should be commended for including web application security requirements within the standard. Web applications present one of the largest potential attack surfaces within most enterprises. The leading industry analyst group Gartner estimates that over 70 percent of attacks are now taking place at the application layer; a stark contrast from the network and operating system layer attacks of the previous decade. And so, by including web application security assessment requirements, initially in section 6.5 and later in an appended section 6.6, PCI DSS has recognized the importance of web application security and addressed it proactively to protect cardholder information.
But there's a problem with this proactive approach: Web application security is a moving target. Web applications are popping up throughout the enterprise landscape, and security professionals are caught in a game of "whack-a-mole" trying to address the issues. The underlying technology for web applications has moved to a new generation (sometimes referred to as Web 2.0), presenting a broader attack surface to the nefarious user and stretching even thinner the resources of security personnel. And all the while, PCI DSS is attempting to define prescriptive guidance to ensure that web applications, and the underlying card holder information, is secure. To illustrate this point, let's take a quick look at some of the guidance thus far.
The original draft of the PCI DSS included section 6.5, specifically geared toward web application security. Within that section, guidance appeared clear: All web facing applications must be tested for the OWASP top 10 vulnerabilities. OWASP, a vendor independent group of security professionals, had earlier defined its top 10 means of attack against web applications, and PCI DSS accepted these as a baseline. The standard did not attempt to set priorities within the top 10; it simply said that organizations should regularly test their web applications to ensure that they were not susceptible to any of these threat classifications. And generally speaking, security professionals were pleased with the focus on web application security and the adoption of a fairly well understood testing criteria. In July 2005, MasterCard issued a memorandum to its PCI Scanning Vendors, a group of organizations that had been certified by MasterCard to conduct third party PCI testing. In that memorandum, MasterCard mandated that all PCI Scanning Vendors perform OWASP top ten testing against web applications.
On March 23, 2006, the PCI Scanning Vendors received a remarkable revision letter from MasterCard. In this letter, MasterCard stated:
In July 2005, MasterCard modified and re-published the security scanning Requirements for Vendors document to include requirements for scanning vendors to detect the OWASP top 10 custom web application vulnerabilities. Later in 2005, MasterCard initiated a process to begin evaluating vendor capabilities to detect and report application layer vulnerabilities as part of the annual scanning vendor certification process.
As vendor testing and certification has progressed, it has become clear that scanning vendor capabilities to detect application layer vulnerabilities in a passive, non-intrusive manner is inconsistent. In many cases, vendors are required to perform additional, non-scanning, intrusive tests to isolate these risks.
The intent of the PCI scanning validation requirement is to provide reasonable assurance of perimeter security while operating in a safe, consistent, non-intrusive manner. As a result, MasterCard is announcing a modification to the Security Scanning Requirement for Vendors document to maintain this posture... Effective immediately, all scanning vendors must be able to detect, when scanning PCI clients, two application level vulnerabilities from the OWASP top ten list that lead to the following attacks… Cross-site scripting… and SQL Injection.
In other words, MasterCard has determined that many within its already approved group of PCI Scanning Vendors are not actually qualified to perform consistent OWASP top 10 testing, and rather than change the qualification criteria, they lowered the bar for testing. Let's just focus on two areas of weakness, albeit two very important areas, they seem to say, and we will leave the other eight for another day. This is not the type of change that builds confidence within the web application security community.
Then, in 2006, section 6.6 was added to PCI DSS:
Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
· Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.
· Installing an application layer firewall in front of web-facing applications.Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.
This revision created all kinds of confusion. A literal interpretation seems to imply that organization either need to have all of their code reviewed, or they need to deploy an application firewall. Which raises a couple of issues:
1. What is meant by "application code?" Is this source code? Is it executable binary code? Is it a test of the application to ensure that the executing code is not subject to attack?
2. Regarding firewalls, what exactly is an application firewall? If my network firewall supplier claims to offer some level of application protection, is that sufficient? Is there qualifying criteria for what constitutes an application firewall?
The PCI DSS for web application security, which had initially launched as relatively easy to understand prescriptive guidance (test for the OWASP top 10), had become embroiled in controversy. How should organizations interpret these new requirements?
Fortunately, the PCI Security Standards Council offers an open forum for discussion and clarification of issues. And in early 2007, here's what they had to say about section 6.6 and its requirement for application code review:
"Using specialized third-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the third-party tool also has the internal expertise to understand the findings and make appropriate changes.
The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for."
What the PCI Security Standards Council appears to say is that they didn't really mean that you had to "review" the code, and they clearly didn't mean you had to do a source code review. What they meant to say is that you need to test your web applications, using some sort of tools and/or methodology that works, and that the testing needs to be conducted by competent personnel. And all of this will be clarified later in a written PCI DSS update.
What can we conclude from all of this?
The Payment Card Industry is doing the right thing: They are trying to establish workable standards to protect cardholder information and they are working hard to do so. They've been diligent to include web application security amongst the requirements, an important and rapidly growing area of threat. And the standard, like all good standards, is evolving.
But web application security is complex. The PCI Security Standards Council has come to this realization, and they may be compromising web application security requirements in the interest of time. This is indeed an unfortunate development. With regards to web application security, the entire security community is looking forward to the next revision of section 6 for further clarification and prescriptive guidance… and we are hopeful that the standard will require a minimum set of best practices to ensure the safety of cardholder information that is accessible via the web.
