DSS v2.0 has been released. So what now?
The new version goes into effect on January 1, 2011, and stakeholders should begin using the new standards as the basis for their payment security programs as of this date. For purposes of validation for compliance, the old standards are grandfathered for 14 months (essentially, until the end of 2011). Nevertheless, the Council urges stakeholders to complete their transition to the new standards as quickly as possible, particularly where any new control requirements are critical for protecting cardholder data.
Many of you have probably been too busy to read up on the changes in the new version, so I’m going to boil it down for you the best I can here, focusing on those aspects that are likely to have some impact on your compliance efforts.
The most significant changes to the standard are as follows:
o Clarified boundaries between Internet and CDE (1.3)
o Clarified that the cardholder data environment is comprised of “people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.”
· Outbound traffic restrictions
o 1.3.5 was softened, such that outbound traffic has to be “authorized”, but doesn’t necessarily have to go through a proxy in a DMZ
· Key management
o Key changes are no longer required annually, but can instead be changed according to vendor best practices (typically every three years)
o Clarified that split knowledge and dual control applies only for manual key management processes
o 3.6 was clarified in Testing Procedure 3.6.b that service providers should provide key management guidance to customers covering transmission, storage, and update of customer keys (not just storage), in accordance with Sub-Requirements 3.6.1 through 3.6.8.
o Added language for virtualization technologies in scope definition and various specific DSS requirements
o Virtualization has always been allowed and still is – they just clarified the wording.
o See our other article here for virtualization best practices in a VMWare environment.
· Risk-based approach
o 6.2 was clarified to explain that new vulnerabilities will need to be monitored as they are published and assigned a ranking according to risk/relevance. This will then have to be tied into the application development/testing methodology (see requirements 6.5.6 and 11.2) to ensure these issues are being checked for. This is only a best practice until June 30, 2012, when the requirement will go into full effect.
o 12.1.2 was clarified to list specific examples of acceptable risk assessment methodologies (ISO 27005, OCTAVE, and NIST SP 800-30)
· Alignment between PA-DSS and PCI-DSS
o Alignment of terminology between standards
· Recognition of small merchant environments
o New web site created for small merchants: https://www.pcisecuritystandards.org/smb/
· New PCI Council website and updated supporting documentation
o New SAQs are expected to be published this month (November, 2010)
Additional upcoming updates (from the Counci’s Special Interest Groups):
· Issuer guidance
· Virtualization guidance
· Bluetooth guidance
· Scoping guidance
· Emerging Technologies guidance
You can download the new version of the DSS and supporting documents here:
The PCI Council’s presentation about the changes to version 2.0 of the DSS and PA-DSS will be available for download in the near future (as of the time of this writing, it has not been published):
More detailed information will be forthcoming, but that’s the gist of the changes. The good news is, most of the changes were clarifications of wording to help make the intent of individual requirements clearer, and in every single case, the clarifications are perfectly in line with the guidance Halock has always provided to our clients. So if you’ve been working with our team, you’ll likely have much less work to do as you adapt for version 2.0 of the DSS.
Jeremy Simon, PCI QSA, CISSP, CISA
Practice Lead, PCI Compliance Services