This is page 2 of:
The Two Scenarios Coming From The PWC PCI Report
September 30th, 2009
For the last four to five years, companies have been told that achieving PCI compliance is much easier if they segment their network. Otherwise, all their corporate systems are in PCI scope. But network segmentation is not a PCI standard, per se. If an organization wants to keep their entire network and the connected systems in scope, it’s up to the company’s management. One possibility is that the PCI SSC could elect to treat tokenization, end-to-end encryption and virtual terminals the same way. This approach would keep the changes to the standards to a minimum. Plus, it would only necessitate the development of formal QSA and merchant training for each of these technologies and how the effectiveness of various implementation options should be measured. The QSAs would wind up owning most of the problem, and the SSC could market how they are embracing the latest technological directions without doing a major rewrite to the DSS.
Another option is to modify the PCI standards by detailing a series of outsourcing options that would include virtual terminals (POS outsourcing), tokenization or end-to-end encryption. Logically, this approach could be written as an extension of 12.8, which focuses on service providers that handle credit card data. There may be other standards (such as 3.4 and 3.6) where encryption and key management assessment procedures would have to be modified to address the scenario where encryption keys are not retained by the merchant at all. The purpose of making such changes to the standards would be to clarify several scenarios where systems and procedures can be deemed “out of scope” for PCI compliance reviews. Again, the actual wording will have to give leeway for interpretation to the QSAs and self-assessors. But by presenting scenarios and testing procedures, the PCI SSC can more clearly show how these technologies are reducing PCI compliance scope.
The Bottom Line
There are a lot of different options for changing the PCI DSS that I didn’t address here, because it’s still pretty early in the process. But I do think it is important for companies to begin to discuss their plans now. I also think this report and its presentation at the SSC meeting are solid evidence that investments in these technologies are “safe” and that the SSC is not going to turn around and suggest they are invalid or non-compliant. As always, if you’d like to discuss this topic, just visit the PCI Knowledge Base and fill out our “Contact us” form, or send me an E-Mail at David.Taylor@KnowPCI.com.
-Marc
October 1st, 2009 at 9:16 am
I too attend the PWC presentation at the PCI Community meeting last week and found it to be a complete waste of time. The PCI Council has been pointing to this study and saying we should wait for the results until they would answer any questions related to scoping, tokenization and end-to-end encryption.
Well we waited for the study and in my opinion didn’t get any more information than we already had from reading the articles that have been posted over the last six months on these same topics. PWC just simply published the same data that other sources have been discussing for some time now.
A better question to ask is why does the PCI council even need PWC? If the PCI Council has a Technical Working Group (TWG) and a Chief Technology Officer (CTO) in Troy Leach shouldn’t these people be able to research these technologies and determine what the recommended solutions should be for merchants. Based on what I saw at the community meeting, neither Mr. Leach nor the TWG are technical enough to evaluate these technologies. So merchants continue to wait for guidance from an unqualified group of people as to how to protect their credit card data.
Organizations have tried to reach out to the PCI Council for answers but the emails we submit take two to three months for an answer and then we receive “talk to your QSA” as a response. We tried to ask questions at the community meeting but were told that “they could not comment on specifics”. This group simply does not have the technical knowledge or background to guide the PCI standard in the right direction!
October 1st, 2009 at 10:10 am
For the last 2 years, a consistent them at the community meetings has been the conflict between “the standard is too vague” and the “the standard is to explicit”. It’s a legacy problem with roots in the evolution of Information Security standards
In the Info Sec world, there is usually a policy hierarchy. The old ESF/ISF formula dictated a “Policy > Standard > Baseline > Procedure” approach. There was only one high-level Info Sec policy, accompanied by a few, slightly more detailed Standards (i.e “Data Classification Standard”. Baseline Controls defined the standard control set for a specific technology (i.e. UNIX baseline) and Procedures gave step by step instructions for implementing the baseline (think “Account Request” process).
The PCI DSS is indeed a standard. It is a high-level document, relatively static, that is more oriented towards “what” than “how”. Given the issuing body and the audience, it’s probably the best level form which to approach the issue. It leaves the freedom to develop the “baselines” and “procedures” in the hands of the implementers (where it belongs).
The PwC study is the first foray into “how” for the PCI SSC, and a response to member input into requests for greater detail in that area. It’s also quite probably as far as the Council will be willing to go in that direction. I suspect the council will pursue their historic course of action in this regard. These technologies will be treated like tokenization, with the implementation left up to the merchant and validation left up to the QSAs.
Specific, published guidance will likely be derived from PCI SSC Special Interest Groups (SIGs). The Wireless and Pre-Auth SIGs have been quite productive, and the Virtualization and Scoping SIGs are making progress. I would not be surprised to see SIGs spring up surrounding these study topics, with guidance forthcoming in 2010. But I’ve been wrong before……