Pre-Authorization Data – The Card Brands Weigh In

I just wanted to pass along what I have heard thus far on this topic from the various card brands.  I’ll keep updating this post as I get more responses.

American Express (aka Trustwave) came back with the following.

“Per your inquiry regarding the storage of pre-authorized data, from what I can tell the American Express DSOP program currently does not address this topic. However, both the PCI SSC and the card brands (including American Express) have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data. That means encrypting it and restricting access to it. The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.

So, while pre-authorization data seemingly is not covered by the PCI DSS/DSOP programs at this time, you must do everything you can to protect it.

I hope this somewhat answers your question. I plan on doing more research to find any official documentation regarding the subject.”

MasterCard International followed up with their response.

“Merchants should talk with their acquirers to determine the pre-authorization rules particular to their vertical market and region.”

Visa quoted their Visa International Operating Regulations manual; section Account and Transaction Information Security Requirements VIOR 2.1.E (Updated):

“Ensure that all agents and Merchants do not store any of the following, subsequent to Authorization:
–    Full contents of any data taken from the Magnetic Stripe (on a Card, in a Chip, or elsewhere)
–    Card Verification Value 2 used to verify Card-Absent Transactions
–    PIN or the encrypted PIN block”

Discover has come back with the following.

“Currently the following restrictions apply:

(a) Sensitive Authentication Data obtained in connection with a Card Transaction must not be retained after receipt of an Authorization Response.
(b) Sensitive Authentication Data must not be recorded on Transaction Documentation or any other records or evidence of Card Transaction.
(c) Any processing, transmission, or storage of Cardholder Data must be conducted in accordance with PCI DSS requirements.”

JCB is still to be heard from.

I was deeply disappointed with MasterCard’s response.  Acquiring banks, for the most part, cannot answer basic questions about the PCI DSS, so we are supposed to believe that they are experts on retention of pre-authorization data based on a company’s vertical market and region?  Talk about passing the buck.

I am also surprised that I have yet to see any of the supposedly “very specific rules that prohibit any storage of sensitive authentication data (SAD) and do not make any exceptions.”  Not that I was expecting any as the Council has a tendency of making a mountain out of a molehill at times.

Based on the responses, I would highly recommend that merchants take American Express’ advice and protect pre-authorization data with the same voracity as they do with post-authorization data.

Pre-Authorization Data – The Definitive Answer

Hot off the press from the PCI SSC and this month’s Assessor Newsletter.

Is pre-authorization data in scope for PCI DSS?

PCI DSS applies wherever cardholder data (CHD) and/or sensitive authentication data (SAD) is stored, processed or transmitted, irrespective of whether it is pre-authorization or post-authorization. There are no specific rules in PCI DSS regarding how long CHD or SAD can be stored prior to authorization, but such data must be protected according to PCI DSS while being stored, processed or transmitted.  Use of PTS-validated payment devices and PA-DSS validated payment applications can support PCI DSS compliance for the protection of data prior to authorization.

With respect to SAD, PCI DSS Requirement 3.2 prohibits storage of SAD AFTER authorization, even if encrypted. Whether SAD is permitted to be stored prior to authorization is determined by the individual payment brands, including any related usage and protection requirements.  Any permitted storage of SAD prior to authorization would be subject to strict conditions and controls above those defined in the PCI DSS.  Additionally, several payment brands have very specific rules that prohibit any storage of SAD and do not make any exceptions. To determine payment brand requirements, please contact the individual payment brands directly.

There we have it.  Pre-authorization data is in-scope with a number of caveats as dictated by the individual card brands.

Just to be clear, I have never argued that pre-authorization data was not to be secured with the same diligence as post-authorization data.  I just could not find anything in the PCI DSS that explicitly called out the coverage of pre-authorization data.  Past training had always explicitly referenced that the PCI DSS was for data stored after authorization, i.e., post-authorization.

Now I guess I am off to bug the card brands about their pre-authorization data retention rules if they are not posted out on their merchant security Web pages.

Google Wallet

Good news for anyone considering using Google Wallet.  Google Wallet encrypts the PAN and only stores the last four digits of the PAN in clear-text according to a forensic assessment conducted by ViaForensics.  The other piece of good news from ViaForensic’s examination was that drive by attacks against Wi-Fi or near field communications (NFC) to intercept Google Wallet communications appear to fail.

Based on ViaForensic’s analysis, it appears that Google Wallet would likely comply with the PA-DSS.  The full PAN is encrypted and communication of the PAN via Wi-Fi or NFC is secured.  Granted there are a lot of other PA-DSS requirements that we do not have a window into that may or may not be PA-DSS compliant.  But on the whole, I would have to believe that Google Wallet would be PA-DSS certified.  So, why is Google Wallet not PA-DSS certified?

First and foremost, in the eyes of the PCI SCC and the card brands, Google Wallet and similar applications are storing pre-authorization data and are just an electronic representation of someone’s traditional wallet.  The PCI SSC does not certify traditional wallets, so why would they certify electronic wallets?  As a result, the PA-DSS does not apply.  Should Google and other vendors of electronic wallets ensure the security of cardholder data?  No doubt about it.

But a more important reason that the PCI SSC is backing away from certification is related to the other findings in ViaForensic’s report.  Their analysis also uncovered some not so good news in that Google Wallet stores a lot of personally identifiable information (PII) unencrypted.  This PII includes such information as cardholder name, expiration date, credit limit and account balance.  I think most people would now start to understand why the PCI SSC backed away from certifying such applications.

The PCI SSC does not want to be on the hook for the unsecured PII.  If the PCI SSC were to certify Google Wallet as PA-DSS compliant, I am sure their lawyers informed them that such a certification would drag them into lawsuits involving the exposure of the unsecured PII even though the PA-DSS does not cover PII outside of the PAN.  Their lawyers probably advised them that a PA-DSS certification would likely imply to users of these electronic wallet applications that their PII was included in the PA-DSS certification.  As a result, the PCI SSC and card brands would likely have to launch a massive and costly educational campaign to explain to the public that the PA-DSS certification was only related to protection of a cardholder’s PAN and nothing else.  And even with such a campaign, the PCI SSC would likely still get dragged into lawsuits over peoples’ PII being exposed.

And the likelihood of such lawsuits is very high.  Smartphones are regularly lost and the security protecting them is almost non-existent, if security is even enabled.  A hacker can easily take a lost smartphone and obtain enough information to perform identity theft.  Hackers could even decrypt the PAN given the high likelihood that the PIN to decrypt the PAN could be derived from other information on the smartphone.  The nightmare scenario would be development of malware delivered through the smartphone’s application store that harvests the PII.

At the end of the day, there is just too much risk involved in certifying such applications because there is just no way to manage the risk.  So those of you thinking the PCI SSC should certify these applications need to rethink your position.

FYI  This is my 200th post.  I never guessed that this blog would last this long and I want to take this time to thank all of you for keeping this going.

Mobile Payment Application PA-DSS Certification Clarification Announcement

On Friday, June 24, 2011, the PCI SSC issued a press release and a number of supporting documents regarding PA-DSS certification.

In my opinion, the most important part of this announcement is in the FAQ and is the classification of mobile payment applications.  According to the PCI SSC, they have identified the following three categories of mobile payment applications.

• Category 1 – any mobile payment application that operates on only a PCI PTS certified device.
• Category 2 – any mobile payment application that meets all of the following criteria: the application that is “bundled” with a specific mobile device; the mobile device is purpose built and performs only the payment function; and when installed on the device per the vendor’s PA-DSS implementation guide, allows the merchant to meet and maintain PCI DSS compliance.
• Category 3 – any mobile payment application that runs on a consumer electronic device such as a smartphone, tablet or PDA that is not dedicated to payment processing.

What the PCI SSC has stated in this latest clarification announcement is that Category 1 and 2 applications and devices can continue through the certification process.  For the first time, these mobile applications have been explicitly called out even though these sorts of applications have been part of the certification process in the past.

What is interesting is the definition for Category 3.  What the PCI SSC appears to be saying is that applications such as Google Wallet and the like may have to go through PA-DSS certification.  While this makes sense from a payment security perspective, it takes the PCI DSS into the realm of pre-authorization data.  While the PCI SSC will not officially certify mobile payment applications in Category 3 at this time, they are highly recommending that mobile payment applications in this category use the PA-DSS as a guide to ensure their security.  The PCI SSC also commits to releasing guidance on what PCI DSS requirements are relevant to Category 3 mobile payment applications while it continues to research how it should handle these mobile payment applications.

However this is not the first time the PCI SSC has delved into recommendations regarding securing pre-authorization data.  At the first PCI Community Meeting in September 2007, there was an infamous breakout session on the security of pre-authorization data.  And sometime later this year, the PCI SSC has said it will issue an informational supplement on securing pre-authorization data.

The other important piece of news from this announcement is that, in the interim, the PCI SSC is asking merchants to conduct their own risk assessment of Category 1 and 2 mobile payment applications to determine how well they comply with relevant PCI DSS requirements. These risk assessments should include consultation with an organization’s QSA as well as acquiring banks.

A Conundrum?

Bear with me on this as there is a point.  It just takes a lot of set up to get to that point.

I am working with a client that issues corporate credit cards to its employees.  The PCI SSC has issued FAQ #8715 that states that these corporate cards are not covered by the PCI DSS and that it is up to the individual card brands to dictate the controls required for securing these corporate credit cards.

The card brands are stating that while not covered by the PCI DSS, corporate credit cards do need to be appropriately secured (see requirement 3 for some recommended security methods).  As far as any drivers for securing these cards, the card brands point to any relevant personally identifiable information (PII) laws and regulations.  However, the card brands do point out that any post authorization data related to these corporate credit cards such as billing statements that show the full PAN are in-scope for PCI DSS compliance.

The PCI SSC has just issued a change to the call center FAQ stating that CVV/CVC/CID cannot be retained in digital recordings.  The rationale is that once the transaction is complete, the CVV/CVC/CID information that exists in recordings is now covered by the PCI DSS because it is now post authorization data.

Do you see the conundrum?  Under the logic used regarding the call center, one could argue that a credit card would be considered post authorization data once it is used for a transaction.  Obviously, that cannot happen as the card would have to be redacted and could not be used again.  However, I have a couple of clients that are doing just that and are trying to apply the PCI DSS to their Human Resources and Travel departments because they store the employees’ corporate credit card information including CVV/CVC/CID.

As I have explained it to them, the differentiator in all of this is that in the case of the call center, all of the data in question is under the control of the merchant and therefore the merchant is responsible to ensure the security of the information.  In the case of corporate credit cards, the corporation is not acting as the merchant as they are acting as the customer on behalf of their employees.  As such, they are allowed to have the card information as long as the employee legally acknowledges that fact and that the card information is appropriately secured.

The Missing Link In Call Center Recordings

Client discussions lately have been revolving around the new call center FAQ out on the PCI SSC Web site.  Most of our clients are arguing with us about why pre-authorization data is ending up in scope?  After all, when a customer places an order via the telephone, it is pre-authorization data.  The answer is that it all comes down to timing.

Everyone understands that call centers routinely record calls to ensure service quality.  For those call centers that provide order entry, those recordings have a high likelihood of recording information that the PCI SSC and the card brands consider sensitive such as the cardholder name, primary account number (PAN), expiration date and sometimes CVV/CVC/CID.

Here is where timing becomes important.

A customer calls into a call center to place an order or conduct any other transaction that requires a credit card.  Until that transaction is completed, any cardholder data provided is considered pre-authorization data by the card brands and the PCI SSC and is therefore not covered by the PCI DSS.

Once the transaction is completed, you are now in the post authorization realm and all information is subject to the PCI DSS.  Under requirement 3.2.2 of the PCI DSS, retention of the CVV/CVC/CID is not allowed.  Even though the recording is prior to the completion of the transaction, once that transaction is complete, the information becomes in-scope for PCI compliance and therefore cannot be retained.

The double edged sword in all of this is that you cannot use a compensating control to meet any of the requirements in 3.2.  As a result, your only alternative is to remediate the situation.


Call Center FAQ Changes – AGAIN

Apparently FAQ #5362 was not good enough and has been changed again.  In addition to some additional background information, the “if the data can be queried” language has returned as a qualifier regarding digital recordings.  See my post on this for additional information.

Of course these recordings can be searched.  There are all sorts of commercial and open source tools available for search audio recordings.

All this is going to do in my opinion is cause my clients to use this as an out for not doing the right thing regarding their audio recordings.

Pre-Authorization Data

Nothing causes more confusion than the discussion of pre-authorization data.  To add to the confusion, the PCI DSS is only relevant for post-authorization data.  In fact, the PCI SSC has a special working group that is developing the standards for pre-authorization data.  And if that is not enough, most people are totally unaware of the concept of pre-authorization data and yet all of us run into it every day.

The first comment I usually get regarding pre-authorization is where do I get the idea that the PCI DSS does not cover pre-authorization data?  At the very first PCI Community Meeting, there was a whole hour long session devoted to pre-authorization data.  It was at this session that the card brands stated that pre-authorization data was not covered by the PCI DSS.  And if you read the PCI DSS, it deals only with the processing, transmission and storage or cardholder data.  While all of these activities occur during the pre-authorization phase, if you really read the PCI DSS, all of the language refers to the transaction after it has been authorized.  However, the current release of the PA-DSS does address pre-authorization data and its protection.

The most common example of pre-authorization data is at your local gas station or convenience store.  When you go to fill up your vehicle and you use a credit card, you swipe your card before you ever pump a drop of fuel.  Have you ever wondered what goes on between that card swipe and you complete filling your vehicle?

When you swipe your credit card, the track data is read and a pre-authorization transaction is sent through to the gas station’s processor for some fixed amount, typically the amount is for approximately $75, more if the station is on an Interstate highway.  This is done to ensure that your credit card has enough left on its limit to pay for your fill up.  Once you complete filling your tank, the pump completes the transaction by submitting the actual cost of the fuel to the processor and the transaction is completed.  However, all the while that you were filling your tank with fuel, the station’s computer system has your credit card data until the transaction is completed.  Until your transaction is approved or declined, the data is considered pre-authorization data.

Another example of pre-authorization data is when you check into a hotel.  When you make your reservation, you provided a credit card for the hotel to guarantee your reservation.  Whether through the hotel’s call center, Web site or the location itself, your credit card information is maintained on file so that you can be charged if you fail to cancel the reservation.

When you finally check in, the front desk clerk swipes your card as part of the check in process.  Based on the number of nights you are staying and some other guest averages, the hotel again issues a pre-authorization transaction to their processor to make sure your credit card will be able to take care of the likely charges for your stay.  All of this is considered pre-authorization.  Your credit card information is not cleared from the hotel’s system until you check out.  As a result, your credit card data can be in the hotel’s systems from a few weeks or months to even years.

There are other examples, but I think you have the picture.  Again, while the PCI DSS currently does not address pre-authorization data, the PCI SSC and the card brands have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data.  That means encrypting it and restricting access to it.  The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.

So, while pre-authorization data is not covered by the PCI DSS, you must do everything you can to protect it.