The PCI Council has said that encrypted cardholder data “may be deemed out of scope” in some circumstances. Although these words sounded reassuring to some, IT execs need to read the Council’s statement carefully. IT's implementation of encryption and tokenization technologies may cause out-of-scope data to quickly morph into in-scope data.
Last week, StorefrontBacktalk Editor Evan Schuman argued that, practically speaking, there may be no difference between how you should protect in-scope and out-of-scope cardholder data. I share his frustration, and I generally agree with many of his conclusions. Maybe what we need is a third designation: temporarily out of scope.
The Council already accepts this concept of temporarily out of scope data in cases of cancelled, fraudulent, or stolen cards. Some retailers feel it’s safe to use these PANs for testing and they consider them out of scope. The Council has a FAQ stating: If the issuer confirms the cards are inactive or disabled, the PANs no longer pose fraud risk to the payment system. The PCI DSS would not apply in these cases. If, however, the PAN is later reactivated, PCI DSS will again apply.” What was once out of scope can quickly become in scope, and therefore I discourage my clients from storing inactive or disabled PANs.
This discussion has very real implications for IT execs (budgets, policies, procedures) and encryption and tokenization vendors (their business case). In a posted FAQ, the Council asked itself: "Is encrypted cardholder data considered cardholder data that must be protected in accordance with PCI DSS?" And it answered: “Encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” Let’s focus on two questions that arise from that sentence.
The first question is, what does “the means to decrypt” include? We need, as always, to look at the Council’s intention and not just dissect its words. Although this sentence was followed by a discussion of who manages the encryption keys, I believe the Council intends “decrypt” to mean any way to get from encrypted or tokenized data (i.e., out of scope) to plain text data (i.e., in scope). That includes gaining access to the keys, but it also includes access to token lookup tables or any other way to get back to the original data. That means you need to be just as concerned with social engineering attacks, malicious insiders and phishing as you do with hackers stealing encryption keys.
The second question is what constitutes an “entity”? Does it have to be a third-party? Could an entity with the means to decrypt cardholder data be a subsidiary of your company and, if so, is that data still considered out of scope? If it’s not a subsidiary, can your company have a partial ownership stake in this entity? Is there a test for an entity’s independence? Could the entity be your nephew, Jimmy? One thing an entity does not include is segmentation, which is already an implied part of PCI DSS.
Don’t expect a definitive answer from either the Council or the brands as to whether you could have a subsidiary (rather than a third-party vendor) with sufficient legal and operational separation to meet the Council’s intent. If you are thinking of pursuing this course, you need to examine the particular circumstances and discuss it with your QSA as well as maybe a couple dozen lawyers.
The PCI Council’s FAQ concludes by reminding merchants to “be aware that encryption solutions most likely do not remove them completely from PCI DSS.” The Council is saying that neither point-to-point encryption nor tokenization is a panacea. Silver bullets have been outlawed. These technologies are designed to limit your PCI scope not necessarily to eliminate it. Even in the most optimistic scenarios, you still have legacy applications as well as key-entered (POS or MOTO), e-commerce and call center transactions where people, computers and sometimes paper exist along with all that messy in-scope cardholder data. Realistically speaking, as long as you take plastic, PCI DSS applies to you. With apologies to the diamond industry, “PCI is forever.”Some people reading the FAQ will be disappointed and regret that the Council did not go far enough or say that it opened up more questions than it answered. I prefer to give the Council and its Technical Working Group credit for taking on the subject. The Council said at its September 2009 Community Meeting that its evaluation of new technologies was in the early stages and that nothing definitive would come out soon. Also keep in mind that every word and punctuation mark in the FAQ had to be blessed by each of the five payment brands. Speaking as someone who worked for one of the brands, this is no easy task.
Where does the Council’s position on encryption leave IT execs who are wondering what data is in scope versus out of scope versus what I referred to as temporarily out of scope, and what should they do to protect each type of data?
Let me say first that I am a fan of both point-to-point encryption and tokenization when they are properly implemented. Either technology--again, if properly implemented--can reduce your scope and minimize both the effort and the cost of PCI compliance. As always, the questions arise when we discuss the specific details. In-scope data (including encrypted data when you have the means to decrypt it) must be protected, per the DSS. Some out-of-scope data does not need to be protected. In this category I include properly truncated PANs that are explicitly out of scope.
What’s left is my so-called temporarily out-of-scope data, by which I mean data that, while out of scope today, may be in scope tomorrow. For example, your vendor may be hacked or fall victim to a phishing attack and encryption keys or lookup tables may be compromised. Or, a malicious insider may request that the vendor decrypt some data and send her the clear text PANs. Or, an insider with a legitimate need for the data loses the clear text data (or a storage device or laptop) or leaks it to other systems that you classified as out of scope.
Basically, if you can imagine a reasonable scenario whereby your out-of-scope data can morph to in-scope data, then it fits my definition of temporarily out of scope. If this possibility exists, for the sake of your company and your brand (and maybe your job), you need to consider protecting this temporarily out-of-scope data, per the DSS. That is, treat such data as if it is in scope.
This conclusion may not be exactly the same as the one Evan reached in his piece last week, and you may not agree with it. Either way, I’d like to know what you think. Leave a comment, or E-mail me: [email protected].