By Terry Ramos, Vice President of Product Marketing, Qualys, and co-author of “PCI Compliance for Dummies”

For organizations that process, store or transmits credit card data, achieving PCI compliance is causing them to evolve from using a periodic security checklist to employing a continuous process to achieve and maintain a state of security and compliance.  For the security practitioners, this has certainly been a great way to connect with the rest of their organization and explain the risks related to data compromise.  However, now we have the challenge of determining what steps we need to take to meet the compliance requirement while making our networks and systems secure as required.

The PCI Security Standards Council recently released the Prioritized Approach to pursue PCI DSS 1.2 compliance with its six milestones.  Any vendor who provides some sort of PCI compliance-related solution will no doubt be working to implement this approach into their solution in the near future, if they have not done so already. The prioritized approach is a roadmap to meet PCI compliance, but all requirements must still be met.

Although many examples can be drawn upon in the 12-requirement structure, let’s examine Requirement 6 — Develop and maintain secure systems and applications.  And more specifically, let’s look at PCI DSS Requirement 6.6.

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
• Installing a web-application firewall in front of public-facing web applications

Prior to the release of the final DSS, this was probably one of the most discussed new requirements that merchants and service providers would need to comply with.  Initially, it was thought that the requirement would include all three — manual application assessment, regular use of automated assessment tools and installation of a web application firewall.  This is in addition to the requirement for a code review before a custom application goes into production and whenever any changes are made.

In a perfect world where resources are truly limitless, an organization would do all three and would always implement a layered or defense-in-depth approach.  However, “all of the above” is typically not a practical option for most organizations because trying to implement all three elements often brings other complexities, not to mention an increase in cost and resource requirements.

So let’s take a quick look at the type of analysis typically done when we are forced to choose one method over another.  The first option is a manual web application review and assessment. Assuming you select a reputable professional services organization, this is a good option since it is likely to proactively catch the flaws in an application before cardholder data is compromised. This is especially true if the flaws are complex, requiring a sort of connect-the-dots approach, and should be performed just prior to the application being put into production and made publicly available.  For this and other reasons, a competent human can often find flaws that an automated solution cannot.  However, this option is more costly, especially when an application frequently changes.  The testing procedure does allow for this assessment to be performed by a qualified employee of the company who is independent of the web development team.  Certainly, this makes cost much less of an issue, but typically such resources are scarce within organizations.

An alternative to the manual web application assessment is to use an automated tool or service. Only recently has this become a more viable option, as web application assessment tools have largely required a human with advanced knowledge of web application security to tune them during the assessment of optimal results.   A few service-based or cloud-computing options have emerged recently for automated web application assessment.  For an organization that does not have the in-house expertise and needs to perform these web application security assessments on a regular basis, these services are a good option and more cost-effective as compared to the manual approaches discussed earlier.

The service-based approach allows for the automation of repeatable techniques used to identify the most prevalent vulnerabilities, identifies vulnerabilities of syntax and semantics in custom web applications, performs authenticated crawling, profiles the target application, and ensures accuracy by reducing false positives and false negatives through automated testing.  Nonetheless, there is no “silver bullet” to detecting web application vulnerabilities.  Even when using an automated solution, there is still a need at times to perform source code analysis, manual assessment or on-site penetration testing.

The third option is to deploy a web-application firewall (WAF) in front of all publicly facing web servers.  This is also a fairly new technology, and it can be a good, cost-effective option for an organization with a small number of web applications that are not overly complex and dynamic or don’t process a high volume of transactions.  However, the technology and the hardware it runs on are relatively expensive and as best practice, it is not recommended to deploy a large number of web applications behind a single WAF.  In addition, it can be quite challenging to properly configure a WAF to detect and block all malicious traffic that the PCI requirement mandates without breaking some critical functionality along the way.  And with the current move towards cloud computing for all types of applications, the downsides to deploying a WAF are further amplified.  A new option is to combine the benefits of web application scanning to dynamically update and configure the WAF to block for new threats as the application changes. 

Finally, with all these tough choices on the road to PCI compliance, organizations of all sizes really need to look at compliance holistically rather than trying to solve each requirement independently with decisions based solely on which option is least costly.  Organizations need to understand which solutions will meet their needs and partner with providers who can help them meet the PCI DSS requirements effectively.