PCI compliance is not achievable without source code analysis

Application security expert Jack Danahy, co-founder and CTO for Ounce Labs, today asserted that source code analysis is the only means possible to conclusively claim compliance with the Payment Card Industry’s Data Security Standard (PCI DSS).

Regarding the recent 6.6 clarification, Danahy described the need for the various approaches within the standard, but pointed to numerous PCI requirements that are only identifiable within the source code of the application.

An organization cannot be truly secure, and to the point of PCI, compliant, without understanding the internal implementation of the application, because there are a number of areas and common application security errors that can only be found by reviewing the source code. PCI 6.6 is the section most people associate with source code analysis, but the truth of the matter is that there are multiple requirements throughout PCI where it is simply not possible to meet compliance requirements without understanding the source.

As of June 30, 2008 application security, previously a suggested best practice in section 6.6, becomes part of the compliance mandate. Section 6.6, which was recently the subject of a clarification document by the PCI Security Standards Council, addresses the need for securing applications – specifically Web facing applications. The techniques outlined in section 6.6 include manual and automated analysis of both source code and application security vulnerability, as well as the use of Web application firewalls (WAF’s).
 

An interpretation of this mandate that we hear consistently is that organizations believe that this is an either/or situation, which in fact it is not. PCI 6.6 is a toolbox of available techniques. It’s about matching the proper security technologies to the amount of information organizations have about their applications

Vulnerability assessment and Web application firewalling are vital technologies to identify and protect against a variety of risks. But there are particular critical areas like data storage, access control, and transaction auditing and logging that are only truly visible by looking within the application. Weaknesses in these areas will be largely transparent to external tests and identifying them is not within the capabilities of a firewall.  Organizations should address their security assessment needs according to the different types of applications they have and as a result, applications will be tested differently.

Recent high-profile data breaches are proven examples that being in compliance with PCI does not guarantee that an organization is also secure. Founder of the PCI Knowledge Base, Dave Taylor, recently participated in a PCI Webinar with Ounce Labs during which he acknowledged that being PCI compliant is not the same as being secure.
 
Taylor commented:

Code analysis or Web application firewalls alone will not provide an adequate level of security. A combination of the two is needed to really protect Web applications. If organizations implement one, but not the other by the June 30th deadline, they will be in compliance. But they will not be as secure as if they implemented a combination of both types of Web application security.

In addition to the often cited section 6.6, there are other sections of PCI that can only be achieved with analysis of the application’s source code. Sections 3, 4, 7, 8 and 10, address issues including lack of cryptography, accidental storage of credit card security code, insecure networking, bad authorization, access control and logging requirements.

Jack Danahy concluded:

Part of the challenge with many regulations is they require organizations to prove they have not done something inappropriate, in this case with their customer data, and that requires the fundamentally difficult task of proving a negativ. PCI is about securing credit and debit card transactions and part of that effort includes verifying that applications are not misplacing or misusing data. Given the nature of applications, and their internal complexity, there needs to be conclusive and comprehensive insight into the application’s behavior in order to be sure of this. Analyzing the source code is the only technique that makes this possible – period.