And even before the full rollout of PCI 2.0 (or perhaps PCI 1.3, if the Council wants to be ultra wimpy) in October (all Participating Organizations should see details in June), the Council will publish a series of position papers to clear up some other debates. Topics will include end-to-end encryption, tokenization and the Eurocard-MasterCard-Visa (EMV) chip-card standard.
These details came from a variety of sources, primarily two presentations given Tuesday (April 13) and Wednesday (April 14) at the Electronic Transactions Association (ETA) show in Las Vegas.
Officially, the Council's Technical Working Group is still finalizing all these changes. But the details have been confirmed as being in the new version.
The theme of the PCI revisions seems to be fine-tuning rather than a major upgrade. Retailers can expect 14 changes to PCI DSS, three changes to PA-DSS and one change to the Self-Assessment Questionnaire (SAQ). There will be no dramatic new requirements.
(Related story: The Latest PCI Compliance Stats Disappointing For Level 3s)
Some of the changes are designed to clarify requirements while others will provide additional compliance guidance to both merchants and QSAs. Still others will reflect evolutionary changes to meet new technologies and threats.
Searching For Cardholder Data
One expected change will require merchants to search for cardholder data on all their networks and systems. A big source of data breaches is what has been called the "unknown unknowns." That is, you can't protect data if you don't know you are storing it.
For those of you who may have been worried by my earlier prediction that the Council would require you to use automated data discovery tools, officials made it clear that PCI will only require merchants to implement a formal process or methodology for data discovery.
Finding all the places where you have stored cardholder data can be a challenge. Just because you have searched for it once doesn't mean data hasn't leaked out to other systems in the intervening weeks or months. This change is a positive move by the Council, although merchants will have additional work to become compliant.
The focus of the revised requirement is to search the merchant's entire network and all systems--not just the cardholder data environment--for stored cardholder data. Almost every QSA has worked with a merchant that found it had cardholder data stored in unexpected places (including once on a secretary's workstation, which was used previously by a developer), and many QSAs have returned to a merchant a year after an assessment to discover new databases where cardholder data has leaked.
Although I still recommend the use of automated data discovery tools, at least I forecasted the Council's direction correctly. It has taken a step forward by highlighting the problem (you can't protect data you don't know you have) and requiring a formal process for data discovery.
One-Way Hashing Of PANs
Another change will be clarification on strong one-way hashing of PANs. Merchants can remove PAN data from PCI scope by either truncation (deleting all but the first six digits and last four digits) or using a secure one-way hash that cannot be reversed.One-Way Hashing Of PANs
Another change will be clarification on strong one-way hashing of PANs. Merchants can remove PAN data from PCI scope either by truncation (deleting all but the first 6 and last 4 digits) or using a secure one-way hash that cannot be reversed.
There is a controversy is simmering among some in the cryptographic community regarding the reversibility of one-way hashes, and it looks like this change is designed to address it. The details of the arguments are mathematical, and they have to do with the limited size and randomness of PANs (e.g., the BINs are a limited set of numbers, PANs are 16 digits, one digit is a calculated check digit, etc.).
Once again, this clarification promises to be a welcome step by the Council to help merchants and their QSAs clarify what is and what is not in scope. We'll have to see the details to know how well this argument has been laid to rest.
Moving To A Three-Year PCI Lifecycle
One of the more significant changes we will likely see is the Council moving to a three-year PCI lifecycle. At this time it is only a recommendation to the Technical Working Group; no final decision has been made to move from the current two-year lifecycle to a three-year lifecycle for PCI revisions. The longer period reflects the lower number of new requirements expected, and it would allow more time for feedback. Emerging threats and new technologies would be addressed through a combination of interim revisions, supplements and the FAQ on the Council’s Web site.
This change is a positive one for merchants and it further defuses the criticism that PCI is a shifting standard--an argument I disagree with. A longer lifecycle gives more stability to the requirements while still preserving the flexibility to respond to sudden developments or new attack vectors. I hope this change is adopted, but I have one concern.
If the Council is going to rely on its Web site and FAQ to communicate changes for the three years between updates, it needs to find a better way to distribute new information to merchants. For example, I wish the Council would provide an RSS feed on the FAQ (it has done so for announcements) so merchants and QSAs could learn about updates as they happen.
Although the FAQ is currently searchable, it can't notify you when a new or revised answer is posted. A real-life example of this difficulty happened with the recent revision and then again with the re-revision of the Council's position on voice recordings. If the PCI Council is going to use its FAQ and its Web site to update merchants, then I hope it will find an automated way for all of us to learn when new FAQs or clarifications are posted.
Acceptable Network Segmentation Definition
In another change, we can expect the Council to clarify what constitutes acceptable network segmentation. Although segmenting your cardholder data environment from the rest of your network is not required by PCI, it is the only way to approach compliance that preserves both your budget and your sanity.
Segmentation sounds simple, but there are frequently questions about whether particular implementations are "segmented enough" to reduce scope. I am hoping the revised version will have examples, but there are so many possible alternatives that I am not holding my breath. Nevertheless, any additional guidance will be very welcome.
End-To-End Encryption, Tokenization, EMV
As part of the changes, we can expect to see position papers that provide guidance on a range of emerging technologies. One of the first will address end-to-end encryption and we can expect it this Summer or Fall. Other papers will address tokenization and even the Eurocard-MasterCard-Visa (EMV) chip-card standard.
It will be interesting to see if the EMV paper addresses the most recent compromises, especially with the recent conversion to chip-and-PIN in the Canadian market.
The position papers will be welcome, especially if they fulfill the promise of combining a primer on the topic with recommendations for implementing the technology in a PCI-compliant manner. Don't expect the implementation recommendations to be too specific, though.
Also among its clarifications, the Council will update its table of what constitutes cardholder data and, interestingly, address the applicability of PCI for card issuers. This latter issue is one that has annoyed and upset merchants since the dawn of PCI.
I am looking forward to this clarification knocking down some of urban myths about whether PCI applies to issuers. The Council's official position (FAQ #5391) is that PCI applies to everyone. But enforcement is a brand issue, not a PCI Council issue.