PCI DSS v2.0

Wouldn't you know it...I go away for a week's vacation and the PCI Council announces the outline of the changes to PCI DSS version 2.0. Well, I might be a little late, but here are the key links you need to look at.

First, here is the link to the press release. The Summary of Changes is here.

This is likely to be all we will see until the PCI Community Meeting in September.

Phishing Does NOT Take a Vacation

I just heard from a school that one of their campus merchants received a phone call today from a caller identifying themselves as "PCI." The caller wanted the merchant to go through some sort of "authentication process" that would install a "data compliance patch" (read: malware) on their terminal. The merchant very intelligently requested a call back number, which the caller would not provide (surprise...).

The good part is that it looks like this school's training program paid off. The merchant didn't do what the caller/criminal wanted, and they contacted their school's PCI coordinator to report the incident.

I'd ask each of you a simple question: If one of your campus merchants got a similar phishing call, are they trained to react the same way as the person above and refuse to go along with the request? If your answer is anything -- ANYTHING -- but a firm "yes," you might want to take a fresh look at updating your training program.

In the meantime, I'd suggest every school pass the word to their merchants that the bad guys are not taking the summer off. Do not let your school get trapped in a social engineering payment card scam.

PCI DSS Update

Thanks to NACUBO's partnership with the Treasury Institute and their becoming a Participating Organization, I listened to an "open mic" session with the PCI Council. I heard some interesting information.

First, we can expect the revised DSS to be officially "version 2.0." This is not necessarily big news, and it reflects the new 3-year lifecycle rather than any extensive changes expected. NACUBO (and any of you who are Participating Organizations) can expect a summary of the changes around August 12, which is before they will be made public.

The revised DSS will be "pre-released" in September, probably just before the Community Meeting on the 21-23rd. Version 2.0 of the DSS will be released to the public on October 28th. Based on the new lifecycle, version 2.0 will be effective on January 1, 2011, but the current standard v 1.2 will not "sunset" (i.e., go away) until December 2011. Since v 2.0 will be announced at the end of October, that gives you 14 months to comply with it.

There was also news on the Special Interest Groups (SIGs). We can expect to see a report on EMV (chip cards) and scoping at the Community Meeting, with reports on tokenization and point-to-point encryption later in the year.

Both the dates for the release of the revised DSS and the SIG reports are later than I and many others had hoped. Bob Russo recognized this in his opening remarks when he asked for patience from all parties. Meanwhile, mark you calendars for late October!

The Council has recordings of its webinars and open mic sessions on its website (click here) so you can listen to them at your leisure. The webinars are free, but you do need to register.

PCI and Toxic Waste!?!

As many of you know, I frequently refer to electronic cardholder data as 'toxic waste,' or at least I suggest that your view these data as such. Well, now it appears I was more right than I ever imagined.

According to this article at StorefrontBacktalk.com, "huge amounts of the carcinogen BPA were found on 40 percent of the receipts collected from “supermarkets, automated teller machines, gas stations and chain stores."

So now I have to ask each of you another question: why are you retaining all those PAPER receipts!?! Don't forget, Visa says you don't need to keep the data no matter what your processor or anyone else says. So, why are you loading up all those file cabinets with, literally, toxic waste?

Time to either get PCI compliant or call in the EPA!

2010 Data Breach Report Now Available

Verizon Business has released the 2010 Data Breach Report. I'm out of the office today, so for now I'll just refer you to two thoughtful analyses. One is Branden Williams' blog which has highlights and his insights, and another is Brian Krebs' Krebs on Security.

Lots of interesting reading.

User Training and Spam

I recommend you take a look at a post at the SANS Storm Center on using common sense when reading email that appears to be spam, but may not be.

PCI requires that users receive some form of security training. When I address this kind of training, I like to use some phishing examples. This post has another good example along with a thoughtful analysis.

From: Comcast

"This is a courtesy reminder that your Comcast Billing Information needs to be verified.

In order to continue using comcast services, click the link below, sign in and and follow the provided steps:

Regards,
Comcast Billing Department"

So, let's look at this and see how easy this is to detect:

1. I'm not a Comcast customer. So right there, it was easy to detect.
2. "comcast" in the second line is not capitalized. A real Comcast email would have capitalized their own companies name.
3. Usually an email like this (from Comcast corporate) would tend to have all kinds of disclaimers and other nonsense at the bottom of the email.
4. The link that I removed was not to "comcast.com"

Now, if we get into the weeds a bit more, we can look at the headers and see where it came from.

It came from a server at a .edu. I don't want to talk about which .edu (but it was in the United States), as I am going to try and get in touch with their security department after I get done writing this Diary.

I wonder if you or someone at your school is who SANS is contacting...?

Oh, I almost forgot the punchline. Where would this email send you or your users if they clicked on the link? They were taken to a site run by the bad guys that collects usernames and passwords. Not good.

Think about including some live examples like this in your security training. It is interesting, guessing phish from real can enliven the discussion, and it works.

Visa Publishes Guidance on Tokenization, Data Retention

Visa today released its latest two of its "best practices" documents dealing with very important topics. You should download them (below) and read them.

The first is Visa's best practices for tokenization. Tokenization is the process whereby you replace a payment card number with a surrogate value or token. A processor or other trusted third party maintains the ability to reverse the token (e.g., a card data vault). The idea is that the token cannot be reversed, and you use it for all subsequent transactions. If done properly, tokenization can reduce your PCI scope.

While not giving you a complete "how to" guide, the paper has some good implementation guidance if you are considering tokenization. Visa titled the paper "Tokenization Version 1.0" and it is open for comment until the end of August. Presumably we may see a revised/clarified version after all comments are in.

The second paper I recommend to you is Visa's Best Practices for Primary Account Number Storage and Truncation. This is my personal favorite. It repeats (and repeats) what I have been saying for years: as a merchant, you have no need to retain a payment card number for exception items like chargebacks and refunds. I could not say it better than Visa's own words:

Due to misinterpretation of Visa dispute processing rules, some acquirers require their merchants to unnecessarily store full Primary Account Numbers (PANs) for exception processing to resolve disputes. The unnecessary storage of full card PAN information by merchants has led to incidents of data compromise, theft or unintended disclosure during disposal. Additional confusion exists due to inconsistent dispute resolution practices by issuers and acquirers in use across different geographies, leading some merchants to conclude that PAN data must be retained for all transactions.

To clarify, Visa does not require merchants to store PANs, but does recommend that merchants rely on their acquirer / processor to manage this information on the merchants’ behalf. Visa also recommends that acquirers / processors evolve their systems to provide merchants with a substitute transaction identifier to reference transaction details (in lieu of using PANs).

Couldn't have said it better myself! If you are storing PAN data for dispute resolution, I hope you are getting something back from you acquirer because you are doing their work.

I regularly run into this urban myth that merchants "Have to retain the PAN for xxx years/months/whatever." Thank you, Visa. Now maybe we can get on with PCI.