What Changed and What you need to know about PCI DSS 3.0

When it comes to compliance, especially as it relates to web application security, the Payment Card Industry Data Security Standard (PCI DSS) is usually the main topic of discussion. Unlike the more vague government regulations such as the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule and the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, PCI DSS is very prescriptive.

PCI DSS and its sister regulation PA-DSS provide guidance on exactly what’s expected in terms of how web applications and related systems that process or store cardholder data must be secured. This is beneficial to the entire payment card industry because it helps ensure that everyone is on the same page and leaves little room for interpretation.

PCI DSS 3 for January 2014

Well, the next chapter in PCI compliance has just begun. Over three years after PCI DSS version 2.0 was released, the PCI Security Standards Council (SSC) has published its latest updates in PCI DSS version 3.0. These new standards take effect on January 1, 2014. But don’t be alarmed. The version 2.0 standards will remain in effect through 2014. Therefore banks, merchants, processors and other affected entities will have until 2015 to align themselves with PCI version 3.0’s requirements.

PCI DSS 3.0 – Impact on Your Business

So, how does the new PCI DSS 3.0 standard impact you and your business in terms of web application security? The essence of PCI DSS remains the same:

1) build and maintain a secure network and systems
2) protected cardholder data
3) maintain a vulnerability management program
4) implement strong access control measures
5) regularly monitor and test networks
6) maintain an information security policy.

What’s different about PCI DSS 3.0 is the guidance around integrating its requirements with business processes and enhancing security assessments to ensure all areas are properly addressed. In fact, a new section in PCI DSS 3.0 titled Best Practices for Implementing PCI DSS into Business-as-Usual Processes states the obvious yet it’s something that’s often taken for granted:

“PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy.”

The business-as-usual integration section also highlights the importance of proactive monitoring, timely response, managing changes, and periodic reviews to ensure PCI DSS’s requirements are actually made part of everyday business operations. Again, they’re stating the obvious. However, if you look at web security breaches, the underlying causes are, in most cases, due to a failure in one or more of those areas of security management.

The following are the new requirements in PCI DSS 3.0 that the PCI SSC has made note of:

• Req. 5.1.2 – evaluate evolving malware threats for any systems not considered to be commonly affected
• Req. 8.2.3 – combine minimum password complexity and strength requirements into one, and increase flexibility for alternatives
• Req. 8.5.1 – for service providers with remote access to customer premises, use unique authentication credentials for each customer
• Req. 8.6 – where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) these must be linked to an individual account and ensure only the intended user can gain access
• Req. 9.3 – control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination
• Req. 9.9 – protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution
• Req. 11.3 and 11.3.4 – implement a methodology for penetration testing; if segmentation is used to isolate the cardholder data environment from other networks, perform penetration tests to verify that the segmentation methods are operational and effective
• Req. 11.5.1 – implement a process to respond to any alerts generated by the change-detection mechanism
• Req. 12.8.5 – maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity
• Req. 12.9 – for service providers, provide the written, agreement/acknowledgment to their customers as specified at requirement 12.8.2

Requirements 8.5.1, 9.9, 11.3, 11.3.4, and 12.9 above will be considered “best practices” to follow by the PCI SSC until July 1, 2015 when they will be enforced. The same goes for the web application-specific Requirement 6.5.10 (Broken authentication and session management).

Regardless of how you look at it, practically all of the changes in PCI DSS version 3.0 impact web application security in some way. Looking specifically at the one requirement that impacts web application security the most (Requirement 6: Develop and maintain secure systems and applications) you need to be aware of the following:

• There’s a greater emphasis on risk impact using industry best practices to consider what can actually happen if a vulnerability is exploited
• References to web-application firewall are now more generic (referred to as “automated technical solution”) to, presumably, incorporate additional technologies that can provide similar results
• At a minimum, testing for Requirement 6.6 and the much-changed Requirement 11.3 must include all vulnerabilities listed in Requirement 6.5 (i.e. XSS, CSRF, etc.) – security issues that are closely aligned with the OWASP Top 10 web application security risks
• The recommended Testing Procedures for Requirement 6.6 include an emphasis on reviewing processes and documentation, interviewing personnel, and analyzing system configuration settings to ensure proactive security controls are in place. Security testing outlined in Requirement 6.6 can still be performed by either third-party or internal organizations as long as they remain independent from developers.

All in all, PCI DSS version 3.0 is more of the same with a bit more business-centric substance and practical guidelines. If you have a strong information security program in place, you’re likely already addressing the new requirements. If not, there’s obviously some work in order. You have a year, but as we’re continually reminded working with web application security, time goes by quickly and things are harder to change than we think they’re going to be.

Are Your Web Applications Compliant with the New PCI DSS Version 3?

The time to get started with PCI DSS 3.0 compliance is now. Download it, scan your websites and web applications with Netsparker Web Application Security Scanner and generate PCI DSS version 3 compliance report to start to familiarize yourself with it. The deadline will be here before we know it.

And to ensure that your web applications and business operations are secure and PCI compliant at the same time, follow our complete guide to PCI DSS compliance.