On Aug. 12th, the PCI Security Standards Council released a "Summary of Changes" document that covers proposed...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
changes to the upcoming version 2.0 releases of the Payment Card Industry Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA DSS).
The final 2.0 release were published today, Oct. 28, 2010, following the recent U.S. and EU Community Meetings. In this tip, we'll review the key PCI DSS 2.0 changes, why the changes were made and what they mean for enterprises. (Editor's note: This tip is based on information provided in the Summary of Changes.)
PCI 2.0: The good news
For companies actively working on PCI DSS and PA DSS compliance, the biggest questions are: "How will these changes effect current assessment cycles?" and "Are there significant changes that companies need to think about and plan for now?" The answer to the first question is fairly straightforward. While v2.0 of the standard is available now for review, it does not go into effect until Jan. 11, 2011. From the day the standard goes into effect, an organization that is in the process of developing a report on compliance (RoC) has a full year to comply with the new standard. In other words, there's quite a lot of lead time to review it and plan for compliance.
Reasonably, however, the depth of the changes can make a big difference in terms of planning how that year is spent. If changes are sweeping and require expensive forklift upgrades to existing systems, a year won't seem like much time. Alternatively, minor tweaks to the standard that require few or no changes to existing payment card ecosystems should be easy to implement in 12 months, which brings us to the second question: What are the changes and what should companies think about now to prepare for a post v2.0 PCI DSS and PA DSS world?
Again, there's some pretty good news: The changes are minor and should require no changes to most company's existing CDEs. For most of the changes, the clarification in wording only serves to expand options rather than requiring changes or restriction of options. For example, virtualization is now called out and defined, but use of virtualization remains optional. This holds true for changes to Requirement 6.2 and Requirement 12.3.10, both of which provide an option for companies because many asked to be able to use virtualization, but do not negate or preclude use of the options from v1.2.
Below is a table briefly listing all changes to the PCI DSS (based on information from the summary document) along with SecurityCurve's analysis of how the change will affect organizations that need to be PCI DSS compliant.
|Requirement||Proposed Change||Category||Analysis of Implementation Impact|
|PCI DSS Intro||Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN. Align language with PTS Secure Reading and Exchange of Data (SRED) module.||Clarification||No change required; tightens requirement to cover only PAN, which should have been protected already.|
|Scope of Assessment||Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.||Additional Guidance||Change only if organization had not identified all instances of PAN and had failed to scope CDE properly.|
|PCI DSS Intro and various requirements||Expanded definition of system components to include virtual components. Updated requirement 2.2.1 to clarify intent of "one primary function per server" and use of virtualization.||Additional Guidance||No change: virtualization is optional. Change only if organization wishes to implement virtualization in CDE. No fundamental change to controls.|
|PCI DSS Requirement 1||Provide clarification on secure boundaries between Internet and card holder data environment.||Clarification||No change if company already had appropriate boundaries set between Internet and CDE.|
|PCI DSS Requirement 3.2||Recognize that issuers have a legitimate business need to store Sensitive Authentication Data.||Clarification||No change for merchants/retailers; does allow issuers to store SAD without violating PCI DSS.|
|PCI DSS Requirement 3.6||Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge.||Clarification||No change; does provide leeway in key management practices for archived data.|
|PCI DSS Requirement 6.2||Update requirement to allow vulnerabilities to be ranked and prioritized according to risk.||Evolving Requirement||No change; prioritization ranking is optional.|
|PCI DSS Requirement 6.5||Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications. Include examples of additional secure coding standards, such as CWE and CERT.||Clarification||No change; only elimination of redundant requirements.|
|PCI DSS Requirement 12.3.10||Update requirement to allow business justification for copy, move and storage of CHD during remote access.||Clarification||No change; copy, move and storage of CHD during remote access is optional.|
PCI 2.0: The not-so-good news
Our one caveat to the good news about PCI DSS 2.0 is that the new version of the standard does not do a good job in terms of keeping pace with many new technologies. Guidance regarding emerging technologies are challenge because, by their very nature, they have not been in use for as long as mature technologies have, and an agreed-upon set of best practices has not been established yet by the industry. As new technologies are adopted, there is a risk that compliance requirements will splinter across the brands.
Remember, the PCI DSS has never been a compliance program; it is a standard baseline for assessing compliance that the five major card brands -- Visa, MasterCard, American Express, Discover and JCB -- agreed to use as the foundation for their actual, individual compliance programs. At the end of the day, each of the five major card brands still retains final say on compliance and can implement their own compliance requirements over and above the PCI DSS (and PA DSS) when or if they see fit. But the original intent was to have a single standard for merchants and retailers to adhere to because multiple standards proved difficult to manage and implement. The PCI DSS was intended as a way to bring all the programs together and ease implementation cost at time.
But the problem with having one central standard that all five brands agree on is that changes to the standard need to be reviewed and agreed to by a number of constituents. Since the council operates in a community model (encouraging and incorporating feedback from all members of the PCI DSS community), the constituent base is expanded beyond the five brands to all members of the community. Because the task of reviewing and modifying the PCI DSS proved to be so time-intensive, the council announced a three-year revision cycle, beginning this year. Three years is a long time in IT security and technologies are emerging right now that retailers and merchants need guidance on.
To deal with emerging technology questions, the council set up special interest groups (SIGs) to investigate new technologies and issue guidance documentation. When completed, these documents are made available on the council website as "Information Supplements." The first supplement was released in February 2008 and addressed Requirement 6.6: Code Reviews and Application Firewalls, followed by Requirement 11.3: Penetration Testing in March of 2008 and the PCI DSS Wireless Guideline in July 2009. Other SIGs are currently working on supplements and guidelines for preauthorization, virtualization and scoping. Adding to the growing list of supplements are releases from the brands themselves; case in point, in July 2010 Visa released two best practice documents (currently in the RFC stage) that directly intersect with PCI DSS: PAN Truncation and PAN Tokenization.
The problem with multiple documents is that they're bringing the process back to where it was prior to the PCI DSS: namely a series of disconnected requirements documents rather than a single go-to source.
So in summary, entities that must be PCI DSS-compliant can breathe a sigh of relief. Version 2.0 of the PCI DSS does not offer significant changes; if an organization is currently PCI DSS compliant, there should be no problem being compliant with PCI 2.0. The bulk of the changes have to do with welcome wording clarifications and additional guidance on important aspects, such as how to effectively limit the scope of the assessment surface.
However, the limited changes come with a price: emerging technologies like virtualization, truncation, and tokenization are not covered in PCI DSS 2.0. The SSC is addressing emerging technologies with special interest groups (SIGs) and supplements, which means organizations must seek out and reference multiple documents for complete guidance. Further complicating matters, Visa has set a precedent by releasing best practices for tokenization and truncation outside of the SSC and the PCI DSS.
To maintain the original spirit of the PCI DSS as a single standard, the brands and the SSC must increase integration of the documents and eliminate redundancy. In the meanwhile, review version 2.0 of the PCI DSS and pay careful attention to the supplements and best practices from Visa to ensure all technologies (both mature and emerging) in use in the CDE are compliant.
About the author:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.