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.

A Bad Week for Higher Ed Security Breaches

This past week has been a bad one for security breaches in Higher Ed.

A few days ago I read about the University of Hawaii - Manoa data breach affecting about 53,000 people. Their parking office system was hacked, and they lost a lot of data from Social Security Numbers to payment cards (take a look at your school's parking permit application, and you get an idea of what was lost).

Then I learned about the breach at the University of Maine that was also announced this week. This didn't involved payment cards, but once again their security was found lacking.

Then to cap things off the whole topic of security in Higher Ed got more visibility with an article in Dark Reading entitled University Databases in the Bull's Eye. The author details these two breaches plus more.

All of this points up the importance of securing your data - all of it. Yes, I know this blog is about PCI DSS and protecting cardholder data, but you also have a lot of other personally identifiable information (PII) lurking in your computers, and you need to comply with HIPAA, too.

The bad guys are out there and they are targeting a number of industries including Higher Ed. That means you are in the "bull's eye." Make sure you are compliant all 365 days a year. You may have vulnerability scans quarterly to meet your PCI requirements, but remember you are being scanned by the bad guys a few hundred times an hour. The difference is they don't give you a report of your vulnerabilities, so maybe give a thought to more frequent (e.g., monthly) scans. Also make sure you reduce your scope. If you are storing cardholder data (like the unfortunate people at UH-Manoa) ask yourself: WHY!!! Is it worth the risk? When did you start putting your institution at risk under the false banner of "customer service?"

Lastly, watch out for data seepage. Most of you who retain cardholder data know where those data are...you hope! Often it is the faculty or staff workstation that has old data and was never purged that is vulnerable. Another risk is when the data are stored (against policy, but gosh, it sure was convenient...) and you don't know about it. Are you using a data discovery tool to find these data seepages?

Lots to think about during these summer months.