PCI DSS 6.5 and 6.6

Web applications that process, store or transmit payment card data fall under the Payment Card Industry Security Standards Council (PCI SCC) Data Security Standard (DSS) requirements where they are being enforced by the merchant's acquiring bank or card processing company.

PCI DSS

PCI DSS 6.5 (version 1.2) requires the use of secure coding practices that cover prevention of common coding vulnerabilities in software development processes including the vulnerabilities listed at 6.5.1 through 6.5.10 (taken from the OWASP Top Ten 2007).

PCI DSS 6.6 (version 1.2) requires addressing new threats and vulnerabilities on an ongoing basis and ensuring public-facing web applications are protected against known attacks by either review via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes or by installation of a web application firewall (WAF). This is to ensure web applications exposed to the public internet are protected against the most common types of malicious input. If a WAF is used, a recommendation is that it "react appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5.".

OWASP Top Ten

Therefore the OWASP Top Ten is inherently linked with PCI DSS Requirements 6.5 and 6.6, and updates to it affect PCI DSS compliance. At the OWASP AppSec DC2009 in Washington, the OWASP Top Ten project announced release candidate 1 (RC1) for the Top Ten 2010. The RC1 document is open for comment until 31 December 2009 and is expected to be finalised in January 2010. This will affect every merchant and payment gateway with a web-facing application in scope that is required to be PCI DSS compliant (e.g. merchants and service providers where Self-Assessment Questionnaire validation type 5 applies).

The Top Ten has been revised to focus on risk rather than vulnerabilities. For each web application security risk, the Top Ten document provides an explanation of the risk, how to determine if a web application is vulnerable, how to prevent the problem, example attack scenarios and references. Yes, that's right— you can actually prevent all of these risks, unlike many other risks that business fave which can only be reduced, accepted or ignored.

There has already been discussion concerning:

• the use of a risk-based ranking;
• the degree to which umbrella categories (e.g., A1 Injection) should be used to group multiple risks;
• whether proper error handling is included within A6 Security Misconfiguration; and
• the use of business-related language rather than attack/weaknesses language.

Actions

So what needs to be done? Well, nothing immediately unless you have some feedback on the new document. But prepare for a change in PCI DSS compliance requirements. If requirements 6.5 or 6.6 apply to your systems, this could include the following:

• If you have explicitly detailed the ten vulnerabilities listed in 6.5.1 through 6.5.10 in any internal compliance documents, standards or policies, these will need to be updated to the new risks.
• The vulnerabilities covered in the software development processes of your own web applications may need to be altered.
• Web application vulnerability assessments and/or web application firewalls, need to ensure they address the new listed risks.
• Discuss with your advisors or auditors when the changes apply to your own operations to achieve continuous compliance.

In practice, you may also want to start looking at the Application Security Verification Standard (ASVS) for web applications which gives a broader view of application security issues than those in the Top Ten.

But remember, the Top Ten was of course only meant to be the most important risks to web applications and as the new 2010 RC1 version states, the Top Ten is only the first ten. Your processes, reviews and controls should already be addressing the "new" risks. They are new in the Top Ten, not new problems.