Do you have what it takes to pass your PCI audit?

With every company reliant on software to run its business, an alarming rise in data breach incidents across industries, but especially credit card processing, means application security is becoming an increasingly critical part of any organization’s overall IT security strategy. For organizations that store, transmit or process credit card information, it is vital as they must be able to demonstrate compliance with the Payment Card Industry Data Security Standards (PCI DSS). The PCI DSS standard attempts to protect consumers while safeguarding the reputation of the industry itself and, while not a government mandate, this industry initiative has rapidly become compulsory for any merchant wishing to transact with the major credit card companies. By being able to demonstrate and sustain compliance, the industry as a whole is signaling to the public that they have efficient and effective processes that assure the security of payment software. However, not all organizations are able to do so!

The PCI Security Standards Council continues to enhance the PCI DSS as needed to ensure that it includes any new or modified requirements necessary to mitigate emerging payment security risks. Just as The PCI DSS doesn’t rest on its laurels, neither should an organisation and, therefore, it should come as no surprise that compliance is not a one-time event, but rather an annual undertaking requiring continually improved audit procedures. In fact, many organizations are discovering that a more efficient process is necessary with every audit.

The PCI DSS, created by the major credit card companies, includes requirements for security management, policies, procedures, network architecture, design and other critical protective measures. However, one very prescriptive requirement – Section 6.6 – that requires an organization processing payments to secure all web applications by either conducting a code review or installing an application firewall is proving problematic with many failing this element during their initial audit. In fact a study by VeriSign, itself a Qualified Security Assessor for PCI audits, reported that 56 percent of its client organizations initially failed Section 6. This is cause for concern as the PCI has good reason to focus its industry governance efforts on the security of applications. Over the last decade, the frequency and intensity of attacks directed at the application layer has dramatically intensified. Recent industry findings are sobering:

• The total number of vulnerabilities reported in major applications has traditionally increased quarter over quarter and is expected to climb steadily in the future.
• The number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in operating systems.
• More than 62 percent of companies experienced a security breach in 2008 due to insecure software, a Forrester Research survey revealed.
• A WhiteHat Security study recently tested more than 600 live, public web applications and found that 9 out of 10 had at least one significant security vulnerability.
• Nearly 60 percent of all applications fail their first security test. For internally developed applications, this statistic climbs to nearly 90 percent.

Section 6.3 states: “Review custom application code to identify coding vulnerabilities.” It requires PCI DSS compliant organizations to not only identify but prevent common security problems during the software development process via source code analysis (SCA), penetration testing techniques or use of an application firewall. While SCA is widely considered the most thorough approach, development best practices urge the adoption of more than one of these solutions – budget and resources permitting. Completing the “bare minimum” to pass an audit can still leave a company exposed to cyber attacks, as recent publicized security breaches have proven. Hannaford Bros., a supermarket chain based in New England, passed their PCI audit and then got hacked. They lost 4.2 million credit and debit card numbers, which directly led to more than 2,000 cases of fraud – not to mention a nasty class action lawsuit.

Section 6.5 urges not just code review but secure web application development from the beginning, relying on secure coding guidelines such as those issued by the Open Web Application Security Project (OWASP) that details the “top 10” most common vulnerabilities, including well-known methods such as broken authentication, cross-site scripting, injection flaws and denial-of-service attacks. Here, as in section 6.3, applying multiple application security technologies is advised. Using only an application firewall, for example, an organization would have difficulty meeting Section 6.5.8, which addresses insecure storage of data. Most application firewalls don’t reside inside the application and, as a result, can’t identify if data is being stored insecurely.

It is important to weigh up the various application security methods, because Section 6.6 mandates that organizations secure all Web applications using either code reviews, application penetration testing or application firewalls. Moreover, with the issuance of PCI DSS 1.2 in June 2008, compliance with Section 6.6 became mandatory. Automated SCA or application scanning products can be employed to meet this requirement, provided they are configured and managed properly. Even with the move to compulsory status, 6.6 still lets companies choose “either/or” from a list of possible fixes, causing many to over-rely on a single approach. This is one of the key reasons that the PCI Security Standards Council stresses that “proper implementation of every option would provide the best multi-layered defense.”

Specifically, 6.6 reads: “Ensure that all web-facing applications are protected against known attacks by applying either of the following methods: (1) installing an application layer firewall in front of web-facing applications, or (2) having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.” It’s very difficult to pass Section 6 without clearing the sizable hurdle of 6.6 – a reality that causes many organizations to seek a trusted application security partner.

Passing a PCI DSS audit – particularly the more onerous requirements of Section 6 – often necessitate partnering with an application security vendor who can provide expertise, technology and processes that can accelerate the compliance effort. Until organizations take 6.6 seriously, PCI compliance failure rates, and perhaps more importantly corresponding cyber attacks, will continue to grow.