PCI DSS v2.0: How does it affect your web application security testing?

The latest version of PCI DSS came into effect on 1 January 2011. If you are a merchant of any size accepting credit cards, you must comply with PCI DSS v2.0 Standards from 2012, writes Fabio Cerullo, CISSP.

Since its inception, the objective of PCI has been to provide guidelines on how to store, process or transmit credit card data in electronic format, writes Fabio Cerullo, CISSP. The latest version (PCI DSS v2.0) came into effect on 1 January 2011. If you are a merchant of any size accepting credit cards, you must comply with PCI DSS v2.0 Standards from 2012.

Unfortunately, becoming PCI DSS compliant does not come cheap. Its final cost depends on a number of factors, including your business type, number of transactions processed annually, existing IT infrastructure, and current credit/debit card processing and storage practices. A recent study by Ponemon Institute highlights that merchants which undergo audits to ensure compliance with the Payment Card Industry Data Security Standards are paying an average of US$225,000 each year.

What's new in PCI DSS v2.0

So, what are the changes in version 2.0 that every application security tester needs to be aware of? First, you need to identify those applications that need to be compliant with PCI requirement number 6 - Application Security. These are applications with custom code that handle credit card data (internal and external websites) or likewise applications that require maintenance, patches, updates and upgrades.

To be compliant with PCI requirement 6.2, for example, you need to perform a risk-based vulnerability assessment before applying any patches/upgrades. The standard also requires in section 6.5 that measures are taken to eliminate specific known vulnerabilities, including injection flaws, misconfiguration, URL access rights and more. OWASP compiles and maintains a Top 10 list of Application Security Risks that highlights much of what must be addressed in this requirement.

Finally, according to PCI requirement 6.6, all custom application code has to be reviewed for common vulnerabilities by an organisation that specialises in application security, or organisations must install an application-layer firewall in front of web-facing applications. Although the latter will suffice to meet the requirement, it is not a robust control on its own and it would only be recommended when budget is a constraint. Usually, having the applications undergo a code review is more appropriate and you should only hire reputable experts in the area.

Do not ignore PCI compliance

Ignoring PCI compliance is not an option. Visa fines for non-compliant Level 1 and 2 merchants (more than one million transactions per year) range from US$5,000 to US$25,000 per month and MasterCard Level 1 and 2 merchants must produce a Report on Compliance from a QSA by 31 December 2011.

The first step for all online merchants and service providers which handle credit card data is to download a copy of the PCI self-assessment questionnaire to see exactly what security measures will be expected. Next, request a free scan from an approved scanning vendor (ASV). That will help you identify where the gaps are in relation to the required PCI Level. If the list of vulnerabilities is too long or you do not have the technical skills within your organisation to address these gaps, you may want to hire a qualified security assessor (QSA) to help you address those vulnerabilities.

Read more on PC hardware