Skip to content ↓ | Skip to navigation ↓

The PCI Council recently released version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) during their Community Meeting. Although we’ve already provided The Skinny on PCI DSS 3.0 Compliance Changes, additional perspectives will be covered in this post.

The effective date of the version 3.0 of the standard will be on January 1, 2014, but existing PCI DSS 2.0 compliant vendors will have until January 1, 2015 to move to the new standard, and some of the changes will continue to be best practices for several more months (until June 1, 2015). It’s also good to keep in mind that the standard is in draft mode and subject to change in the upcoming months.

Major Themes in PCI DSS 3.0

There is a general sense that this new version moves the DSS closer with industry expectations for formal standards documents. The changes are not dramatic, but the new version benefits from many clarifications, real-life examples and flexibility built in to enable merchants to meet the intent of the requirements.

The major themes in PCI DSS 3.0 include education awareness, continuous ‘business as usual’, and security as a shared responsibility:

  • Education Awareness. The new version emphasizes the need to establish a culture of security through more education to maintain and drive accountability throughout the organization. It also calls out the need for more processes to ensure that payments are secure, rather than merely ensuring that a merchant has a specific security technology in place.
  • Making PCI ‘Business as Usual’. The new version added a ‘Best Practices for Implementing PCI’ section, aiming to turn it into a ‘business as usual’ process. A good example of this is how it aims to make PCI DSS compliance ‘continuous’ rather than an annual validation exercise. As Adrian Sanabria notes, a security analyst a 451 Research, “rather than adopting PCI’s requirements as full time changes, many businesses would simply go into “panic mode” shortly before the auditor arrives every year, attempting to cram a year’s worth of PCI preparation into a month or two. This aims to address that issue.”
  • Shared Responsibilities. There has been a lot of confusion between merchants and service providers over where responsibilities lie. The new version adds guidance to cloud providers and merchants to ensure there is ‘shared responsibility’. The merchant cannot outsource accountability, as it has shared responsibility with the service provider to comply with the standards. As Sanabria notes, “I predict this requirement may be more of a burden on service providers than merchants.”

What are the changes in the PCI DSS 3.0 that will affect merchants the most?

In the current draft of the PCI DSS 3.0, there are some areas that may have the most impact on organizations that need to comply with the standard:

  • Penetration Testing Methodology. Criticized for the lack of common definition and consistent assessment approach for years, the new version finally calls for a methodology to be in place to achieve consistency in the results. “Without an industry-standard methodology, anything can be passed off as a pentest as long as the QSA signs off on it,” said Sanabria, who used to be a QSA himself. “This is the very reason more than 50 security professionals came together to create and work on penetration testing execution standards (PTES). I would love to see PTES become an industry standard, and hope it makes this requirement easier for merchants,” Sanabria continued. While it’s too early to tell if this new requirement solves the problem at its roots, Branden Williams comments that “it’s a good start, but having a methodology and reviewing the effectiveness of it are very different things.”
  • Increased audit reporting and testing. The intent of this requirement is to ensure consistency in audits, but there might be some unintended consequences. For example, Sanabria mentions that stringent testing procedures are likely to result in a higher number of hours required to deliver a Report on Compliance (ROC), and therefore, a higher cost per audit to the client. As the cost of replacing credit/debit cards gets lower, the cost of compliance grows higher.
  • In-scope systems. Williams sees the requirement to maintain a list of in-scope systems as a challenge to many organizations, as the list may change very frequently for large merchants. If your organization does not have a constant addition or deletion of in-scope systems, this requirement may not affect you.
  • Protecting the terminal. This update focuses on better training and oversight of POS devices in order to reduce tampering and theft. This could potentially have a significant impact to many organizations, but some of the changes may be ineffective since there is a strong focus on this requirement to be flexible to avoid having a costly impact to the merchant. There exists some uncertainty about exactly what the Council will be recommending, and whether a software technology solution may be needed or if it will be solely a physical security requirement.
  • Common vulnerabilities:  The draft version of PCI DSS 3.0 calls for an updated list of common vulnerabilities, which will often be incomplete and could lead to the wrong behavior. As Sanabria commented, “to have a static list of issues could encourage people to fix only what’s on the list and quit.” He suggests that a better approach would be to use OWASP recommendations to find and fix your issues, then use a proper penetration test to validate your efforts.

Are there any other areas that should have been addressed in version 3.0?

As discussed earlier, there is a move to bring the standard closer to industry needs in the language of ‘business as usual,’ but there is no specific language to require organizations to take a risk-based approach to their security.

However, as Williams notes, “the move to more flexible authentication requirements as well as the increased usage of ‘should’ and ‘periodic’ could allow for risk-based decisions.” Personally, I’m still not convinced that this will be enough to create the necessary change in how compliance is treated in many organizations.

Some suggest that the standard should be more prescriptive to create consistency in technologies, especially with how fast technology evolves, while others suggest that providing specific requirements prevent innovation. So should there be more linkage between the standard itself and technology-based specific requirements?

“While I agree with the Council that the standard should be universally applicable, its helpful to create specific rules about technologies and link to them as requirements,” says Williams. “Technologies like mobile and cloud could stand to use some standards that QSAs can assess against to create a solid baseline from which to improve.”

On the other hand, Sanabria believes that prescriptive requirements should be minimized while proactive processes should be encouraged, which will lead to a security-minded way of thinking. He also offers that “higher quality penetration tests and audits ensure and validate that the approach is working. This would ultimately reduce the cost of PCI for the merchant, but requires such a large overhaul of PCI that it is unlikely to ever occur.”

While some expected few changes to the standard in version 3.0, many of these revisions could potentially have a major impact to your organization given the scope of these clarifications and updates. It is refreshing to see the increased emphasis in helping merchants adopt a framework of continuous security, and move them closer to meeting the true intent of the standard.

 

Additional Resources:

 

Related Articles:

 

P.S. Have you met John Powers, supernatural CISO?

 

Title image courtesy of ShutterStock