The Payment Card Industry Security Standards Council (PCI SSC) has released a draft version of the Payment Card Industry Data Security Standard (PCI DSS) Version 3.0 to Qualified Security Assessor (QSA) companies. This release was not made available to the general public as PCI SSC is still reviewing feedback from QSA companies and other participating organizations before the final version is released in November 2013. The new PCI DSS 3.0 compliance requirements will go in to effect for all companies on January 1, 2015 but there are a few requirements defined in PCI DSS 3.0 that will not be required for compliance until July 1, 2015.
PCI SSC has categorized the changes for the standard into three types: Clarifications, Additional guidance and Evolving Requirements. PCI SSC defines a clarification as a means to make the intent of a particular requirement clear to QSA’s and entities that must comply with PCI DSS. Additional guidance provides an explanation, definition and/or instructions to increase understanding or provide further information or guidance on a particular topic being assessed. Evolving requirements are changes to ensure that the standards are up to date with emerging threats and changes in the market and are new requirements for the most part.
In total there are a proposed 99 changes between the three types of changes, which were nicely defined in the document “PCI DSS 3.0 Summary of Changes” provided by the council. The majority of changes, 71 to be exact, are clarifications followed up by 23 evolving requirements and 5 changes that fall under the “additional guidance” category. This blog post provides a high-level overview of the proposed changes in the draft PCI DSS V3.0 and this overview is not specific to particular requirements. Neohapsis will be releasing a series of blog posts dedicated to PCI DSS V3.0 that will explore individual requirement changes in great detail.
So enough setup, here are some key takeaways of high-level changes to PCI DSS Version 3.0.
Scope of PCI DSS Requirements
PCI SSC added some clarification around the responsibilities for defining scope for both the entity seeking compliance and the QSA performing the validation. PCI SSC did a great job of clarifying the scoping process by providing examples of system components that should be included are part of the scope for a ROC assessment. In addition to system components, the scoping guidance section contains requirements for capturing all purchased or custom developed applications that are being used within the cardholder data environment (CDE). Compared to PCI DSS Version 2.0, this section of PCI DSS Version 3.0 has been broken out to be more descriptive as well as to display the details in a clearer manner to help entities better understand the scoping process.
Use of Third-Party Service Providers / Outsourcing
The use of third-party service providers to support an entity’s cardholder data environment (CDE) and the related PCI DSS validation requirements have not change that drastically. All entities that fall under PCI DSS are still required to validate that each third-party service provider is PCI DSS compliant by obtaining a copy of their attestations of compliance (AOC) or by having their QSA assess the compliance status of each third-party service provider for relevant PCI DSS requirements.. However, the draft of PCI DSS Version 3.0 provides examples such as advising entities seeking PCI compliance to validate the IP addresses for quarterly scans if one or more shared hosting providers are in-scope for their CDE. Furthermore, entities seeking compliance are advised to work with service providers’ to ensure that contractual language between the two parties clearly states PCI DSS compliance responsibilities down to the requirement level.
The biggest change that I see in PCI DSS 3.0 is the emphasis on making PCI DSS controls part of “business-as-usual” (BAU) as compared to a moment in time assessment. To get this message across, the draft version of PCI DSS 3.0 provides several best practice examples for making PCI are part of BAU. These best practices are not requirements, but the council wants to encourage organizations to make PCI a part of BAI. The goal of this change in thinking is to get businesses to implement PCI DSS as part of their overall security strategy and daily operations. PCI DSS is stressing that their compliance standard is not a set-it and forget-it mentality.
Some important areas in this new mentality focus on security processes. For example, entities should be validating on their own that controls are implemented effectively for applicable businesses processes and related technologies. Some specific examples related to this new mentality focus on antivirus definitions, logging, vulnerability signatures and ensuring that only appropriate services are enabled on systems. With this new mentality, entities should look to take corrective actions when compliance gaps are identified so that PCI DSS compliance can be maintained at all times and not wait until their QSA comes to validate their compliance. When gaps are identified, implementation of compensating or mitigating controls may be necessary and should not be left open until the start of a QSA assessment.
Lastly in regards to BAU, the company seeking PCI DSS compliance should continue to have open dialog with their QSA throughout the year. Good QSA companies will work with their clients to help ensure the right choices are being made in between ROC assessments.
Until Next Post
This is just one of multiple blog posts about upcoming changes in PCI DSS version 3.0. Neohapsis will be releasing additional posts on more specific PCI DSS 3.0 requirements in the near future. If you are required to be PCI DSS compliant then I would recommend having a talk with your QSA company to start planning and preparing for PCI DSS 3.0. You are also welcome to reach out to Neohapsis as we have multiple QSA’s who are seasoned professionals who can address your PCI DSS and PCI PA DSS compliance questions.