While many parts of the standard have caused headaches for companies using credit cards in their business, Section 6 is especially painful. Like other PCI DSS requirements, some of it is common sense and easy to implement, and the rest is ambiguous and confusing to understand, not to mention difficult and costly to implement.
What makes it more painful is that unlike the rest of the standard, the last part, Section 6.6, is only recommended as a "best practice." It becomes a requirement June 30, 2008, and if companies want to be compliant by that date, they have to begin their work now.
Code reviews or firewalls?
To achieve compliance with Section 6.6, companies have two draconian alternatives: either conduct code reviews for all their Web applications, or install an application-level firewall.
But before delving into the specifics of Section 6.6 and some acceptable workarounds, let's briefly review Section 6. Again, as with the rest of the PCI DSS, some of these guidelines may already be part of your IT security program.
These are best practices for any company with an in-house software shop. Besides Microsoft's SDL, the Open Web Application Security Project (OWASP) has methodologies for integrating secure coding into the development lifecycle. In fact, OWASP best practices are part of Section 6.5.
OWASP's top ten for 2007 include cross-site scripting (XSS), injection attacks, improper error handling, and broken authentication and session management. But new culprits include cross-site request forgery (CSRF), insecure cryptographic storage and communications and failure to restrict URL access.
Does that mean you're going to take a beating from your PCI auditors if you follow the current OWASP list and not the letter of the law in the PCI standard? This is one of the PCI gray areas that have caused so many headaches for businesses trying to become compliant. The best answer is that it depends on your auditors.
Since this section is slated for an update next year, it's likely auditors will call this a "compensating control," one of PCI's few loopholes. It would also be hard to penalize a company for using an updated version of OWASP. It's still OWASP, and the standard recommends using it.
Companies seeking PCI compliance already have to budget for third-party consultants to scan their networks. Section 6.6 just adds to that burden, since these scanning consultants don't always perform application code reviews.
But there is an alternative. Companies will be compliant if they use a Web scanning tool such as SPI Dynamics WebInspect, Watchfire's AppScan (these companies were recently acquired by Hewlett-Packard and IBM, respectively), or Cenzic's Hailstorm. An enterprise must also show it has the expertise to fix uncovered vulnerabilities. Combining this with developer training wrapped around OWASP is a plus.
Though WebInspect and AppScan don't do line-by-line code reviews, the PCI Security Standards Council has hinted they fit the bill. This is another area that may be more clearly spelled out in next year's redraft.
Many companies offer PCI compliance tools that check for data protection and leakage, but few address the application security requirements of Section 6. If you're looking for a tool to assist with Section 6 compliance, stick with traditional scanning tools like WebInspect and AppScan and code review products from Ounce Labs and Fortify Software. WhiteHat Security and Veracode are among the vendors that provide code review as a service.
Section 6 has unique challenges that are different from the rest of the PCI standard, and those challenges require a different approach for compliance.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and is the author of The Little Black Book of Computer Security available from Amazon. He has a regular radio show on computer security on WIIT and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
This was first published in December 2007