What Changed and What you need to know about PCI DSS 3.0
The new PCI DSS version 3.0 guidelines will take effect on the 1st of January 2014 but will only be forced in 2015. Still, 1 year passes by so quickly so read this document to see what changed and what is new in the new PCI DSS 3.0 guidelines and check how it might impact your business and the security of your websites and web applications.
Your Information will be kept private.
Your Information will be kept private.
This is an archive post from the Netsparker (now Invicti) blog. Please note that the content may not reflect current product names and features in the Invicti offering.

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: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:"PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity's overall security strategy."
- 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
- 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.