Introduction

Organizations handling credit cards feel pressure building as the deadline for PCI Requirement 6.6 compliance [1] has passed and well documented breaches have heightened the public and regulatory agencies' concerns about how well companies are securing consumer-specific information. Despite some initial advances, sensitive information is still frequently stolen.  Internal threat an issue, magnified by extended partnerships which ultimately lead to more tasks will be performed outside company facilities. In increasingly complex technical and business environments, no one security approach can deal with all the new and innovative intrusions. But the lack of a security silver bullet doesn't mean data security is impossible. It simply means that businesses have to take a multi-pronged approach to data security.

PCI Requirement 6 - Developing and maintaining secure applications

Payment Card Industry (PCI) Data Security Standard (DSS) Requirement 6, Develop and maintain secure systems and applications. PCI 6.6 itself has two halves, “code review” (the act of finding/fixing vulnerabilities) and “application firewalls” (device designed to thwart website attacks) that merchants may choose between.

Fixing custom application code is not easy

Requirement 6 is about “developing and maintaining secure applications and systems.” Requirement 6.1 requires that vendor-supplied security patches be applied within one month of release. Securing and fixing custom application code is not as easy as downloading a patch from your favorite software vendor. Web application vulnerabilities must be identified, fixes developed, tested, and deployed. In short, you're on your own for the entire process. Setting aside the fact that these two options should not be perceived as competitive, rather complementary, the Council is giving merchants the choice acknowledging budget constraints.

PCI Requirement 6.6 mandates the following:

PCI DSS Requirement 6.6: Ensure that 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.

Testing Procedure: For web-based applications

PCI DSS Requirement 6.6 Testing Procedure: For web-based applications, ensure that one of the following methods are in place as follows. Verify that custom application code is periodically reviewed by an organization that specializes in application security; that all coding vulnerabilities were corrected; and that the application was re-evaluated after the corrections. Verify that an application-layer firewall is in place in front of web-facing applications to detect and prevent web-based attacks. The confusion stems from the interpretation of the requirement. First, let's clear up some high-level misconceptions. Requirement 6.6 is not just for “level ones.” It does not specify service providers or merchants. It does not specify either source code reviews or web-application firewalls.

Complying with Requirement 6.6

Requirement 6.6 is about protecting web applications, plain and simple. Given our modern threat landscape, it is no wonder that PCI Requirement 11.3.2 dictates “application penetration tests” be performed after every “significant change.” Meaningful web application security management requires frequent assessments as code and threats evolve continually. Requirement 6.6 is about developing a repeatable methodology that connects the “Find” (the vulnerability detection) process to the “Fix” process for the systematic, efficient elimination of vulnerabilities from web applications. Additional practical PCI guidance can be found at [16].