Out-Law News 5 min. read

Passing your PCI DSS audit: Tips from a security specialist


Organisations that store, transmit or process credit card information must comply with the Payment Card Industry Data Security Standard (PCI DSS) – yet many audits reveal a common point of failure. Security specialist Jeff LoSapio of Fortify explains why.

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 signalling to the public that they have efficient and effective processes that assure the security of payment software. However, not all organisations are able to do so.

The PCI Security Standards Council (PCI SSC) 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 SSC 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 organisations 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, which requires an organisation 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 (16-page / 194KB PDF), itself a Qualified Security Assessor for PCI audits, reported that 56% of its client organisations 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 (Source: World Vulnerability Research Markets 2007, Frost & Sullivan).
  • The number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in operating systems (Source: The Top Cyber Security Risks, September 2009, The SANS Institute).
  • More than 62% of companies experienced a security breach in 2008 due to insecure software (Source: Application Risk Management in Business Survey, May 2009, Forrester Research).
  • A WhiteHat Security study in 2008 tested more than 600 live, public web applications and found that 9 out of 10 had at least one significant security vulnerability.
  • Nearly 60% of all applications fail their first security test. For internally developed applications, this statistic climbs to nearly 90% (Source: State of Software Security Report, March 2010, Veracode).

Beware PCI DSS, Section 6

While payment card processors fear failing their PCI audits almost as much as getting hacked, it’s the latter event that has the PCI SSC stressing the use of multiple approaches to the application security problem, including the value of building secure code from the outset – as required by Section 6 of the PCI DSS.

However, as we’ve already referenced with VeriSign’s study, Section 6 proves to be one of the most challenging requirements. PCI DSS Section 6 reads, “Develop and maintain secure systems and applications.”

The way it instructs compliant companies to produce secure applications can be distilled into four separate but related activities:

  1. Review the custom-developed code of both external and internal applications to identify security vulnerabilities;
  2. Develop all web applications based on secure coding guidelines;
  3. Verify that processes require developer training in secure coding techniques; and
  4. Implement either an application firewall, source code analysis, or penetration testing to maintain security over time.

Let’s take a closer look at the specific challenges within the sub-requirements in Section 6 where companies often fail and outline some ways to overcome them :

Section 6.3 states: “Review custom application code to identify coding vulnerabilities.” It requires PCI DSS-compliant organisations 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 publicised 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 detail 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 organisation 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 organisations 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 organisation that specialises in application security.” It’s very difficult to pass Section 6 without clearing the sizable hurdle of 6.6 – a reality that causes many organisations to seek a trusted application security partner.

Passing a PCI DSS audit – particularly the more onerous requirements of Section 6 – often necessitates partnering with an application security vendor who can provide expertise, technology and processes that can accelerate the compliance effort.

Until organisations take 6.6 seriously, PCI compliance failure rates, and perhaps more importantly corresponding cyber attacks, will continue to grow.

By Jeff LoSapio, Security Practice Manager , Fortify Software

We are processing your request. \n Thank you for your patience. An error occurred. This could be due to inactivity on the page - please try again.