Mobile Payments Update from PCI Council

The PCI Council has released their plans for PA-DSS validation for mobile commerce applications. In an announcement to Participating Organizations, they stated:

In November 2010 the Council announced that it would no longer accept mobile payment acceptance applications for PA-DSS review or validation until a thorough review was completed. Understandably, this was met by mixed reactions in the industry. While some applauded the decision - recognizing the very real complexity and security concerns these applications present - many of you eager to take advantage of the benefits of mobile payment processing, were frustrated as to why this step was taken.

This was the first and necessary step that has allowed us to confidently give you clear direction now as to what types of applications can allow you to accept and process payments securely and support PCI compliance.

[Friday] the Council will publish an updated statement on PA-DSS and mobile payment acceptance applications, accompanied by a fact sheet designed to help in identifying and determining which payment applications can be reviewed and validated by the Council as secure for accepting and processing cardholder data and support merchant PCI DSS efforts.

In evaluating these applications in light of our standards, we've determined that the major risk is the environment that application operates within, and whether or not it can it support a merchant's PCI DSS security efforts. Based on this evaluation, we've now identified the types of solutions that can meet PA-DSS requirements and support a PCI DSS compliant environment.

We've also determined the area where solutions can't currently meet PCI requirements - and now we are looking at this closer to see if and how these can be secured, collaborating with industry subject matter experts to produce additional guidance by the end of the year.

We recognize that you have been eagerly awaiting an update from the PCI Security Standards Council on how you can be sure the mobile payment applications you're deploying can accept and process payment cards securely, and we hope you'll take advantage of this first step with these resources today.

You can download a copy of the release by clicking here.

The good news is that for new mobile payment applications for their Category 1 (using PCI PTS devices) and Category 2 ("bundled" hardware and software devices), the door for PA-DSS validation is open. Unfortunately, I'd plan on about a year before there are PA-DSS versions of apps to run on your smartphones.

Meantime, another realistic option is to go for a hardware solution. This is in two parts. First, you will need a secure, likely PTS-listed device to read the mag stripe on the cards. This could be a "sled" or a Square-like plug-in attachment. Then (here's the big part) using the guidance expected soon on point-to-point encryption, a vendor can combine the device with encryption to take the phone itself out of scope. While the merchant won't have the functionality of a full payment app (which is what everyone really wants), they will be able to take cards securely using a mobile device.

There will be more developments in the coming months. Stay tuned...

How Good is Your HR Policy?

The second part of the headline is: "...and Why You Should Care."

What I'm talking about is what happens when you dismiss someone or they decide to leave? How long does it take your HR and IT departments to cancel their user IDs and privileges?

PCI actually has a bit to say about your procedures, and even if you fill out a simplifed SAQ, you should take a look. For example, Requirement 3.5.6 says that if the employee who leaves happens to be an encryption key custodian, you change your encryption key(s). It sounds pretty simple and obvious when you think about it, but will you know of this rather important detail when that happens? Does HR? Does IT know to tell HR (or vice versa)?

Then again, there is our old friend 8.5.4 which requires you to revoke immediately (the Council splits that infinitive, but ...) the password of any terminated employee. But what does "immediately" mean? To me, it means certainly no later than close of business the employee's last day. If you want a classic example of what can happen, you might want to check out this post from SANS.

You may want to terminate the user's ID the day before when the termination is "for cause." And it may be a good idea either to terminate privileges two-weeks (or whenever notice is received) in advance for an employee who is leaving voluntarily. In this last case, you might at least restrict severely the permissions the employee has.

In these difficult times, it makes sense to look all aspects of where PCI can protect your institution.

How the Stolen Card Market Works

There were a couple of interesting reports on NPR today. Each covers much of the same ground, but they provide some interesting background for all of us in the card business.

Here are a couple of links:

How to Buy a Stolen Credit Card

The FBI Agent who Broke the Black Market

Also, here is a podcast from PlanetMoney with Keith Mularski (same guy) on dark market and the how credit cards get stolen and fenced.

The bad guys are out there. They go for credit cards because (of course) that's where the money is.

PCI Virtualization Guidance Published

The PCI Council's Virtualization Special Interest Group (SIG) just released their report. You can download it here.

I'd recommend it to any school looking at or implementing virtualization in their PCI network.

News From the PCI Council

As all of you know (I hope), NACUBO is a Participating Organization with the PCI Security Standards Council. As NACUBO's representative, I get a periodic newsletter from the Council with updates and news. Often, these newsletters are pretty dull, but the current one has some interesting information I -- in my role as your representative to the PCI Council -- want to share with you.

There is good news (I hope) for all of you looking at virtualization as potential technology that can make PCI compliance easier and less costly. The good news is that the Virtualization Special Interest Group has delivered its report, and the Council will be releasing it soon. Here are some details from the newsletter:

I know you've all been eager for the Council to release the findings of the Virtualization Special Interest Group (SIG). Thanks to their hard work and collaboration with the Council's Technical Working Group, guidance on the use of virtualization in accordance with the Payment Card Industry Data Security Standard (PCI DSS) will be released this month! We'll be hosting a webinar at the end of June to provide greater detail on the information supplement and address your questions.

To register for the Tuesday, June 28th session, click here.

To register for the Thursday, June 30th session, click here.

Another piece of good news is that the Prioritized Approach 2.0 (to match PCI DSS v 2.0) has been released. There are some good improvements in this version. If you are interested in this or if you wish to use it with the current version of PCI DSS, you can download a copy at the PCI Council's website.

The Council is offering a range of PCI training options. You can view the schedule (and pricing) for their instructor-led and online PCI training courses here. I guess I'd be remiss if I didn't also mention the Treasury Institute's own PCI training. The two are different: the Council focuses on the PCI DSS itself, where the Institute's workshops emphasize hands-on case studies of what other schools have done to become compliant (along with a PCI briefing). The training sessions are complimentary, so even if you have been to the Treasury Institute workshops, it may make sense to check out the Council's offerings.

Lastly, for all you PCI fanboys, you now can follow the comings and goings of the world of PCI on LinkedIn. Click here to follow the Council.

Visa Chargeback Publication: More than Meets the Eye

I recommend every one of you who is responsible for payments, card processing, PCI for your campus download a copy of Visa's Chargeback Management Guidelines for Merchants (click here). It's a long pdf, but it is worthwhile.

Here are some of my favorite parts, and you'll notice this document (which I first learned about from Branden Williams' excellent blog) has a lot more than just Chargebacks. Actually, it's a pretty good primer on payment cards.

• Starting on page 10 is a great "Payment Card 101" that describes how a credit or debit card transaction flows through the system. The graphics are a lot slicker than the version I developed when I was at Visa (after all, it has been about 15 years!), and there is good text, too.
• Page 14 offers a description of "convenience fees." The short answer is "the merchant must [Visa's emphasis] adhere to Visa rules." Want to know what the rules are? Simple... "please contact your acquirer."
• Also on page 14 is one of my favorite topics: transaction laundering. It says that "Depositing transactions for a business that does not have a valid merchant agreement is called laundering. Laundering is not allowed." That means you don't process for unrelated third parties using your merchant ID. In fact, I wouldn't even allow a third-party merchant on my network. Either it is laundering (I call this "LaunderNet") or you are a Service Provider, and each is bad news from a risk and PCI perspective.
• Page 15 tells you not to do cash or check refunds for card transactions. You are supposed to issue a credit back to the original card used. Even if it isn't a Visa requirement, this procedure is a good idea since it prevents another form of transaction laundering: charging a transaction with someone else's card (e.g., their parent's or roommate's, with or without permission) then getting a cash refund. Bad news all around.
• Page 17 talks about your third-party service providers.
• Check out page 22 for good advice on your POS receipts.
• Page 35, and later page 80 cover the CVV2 (the security code on the back of the card).
• And of course, if you actually want to learn more than you ever wanted to know about chargebacks and copy requests, that all starts getting serious around page 41.

That Visa released this to the broader merchant community is to be commended. Good job! so do your part and download it now.

Beware of Changes to SAQ C

Many schools use SAQ C for auxiliaries or other businesses. Sometimes, they will have a point of sale (POS) system that doesn't store cardholder data, but that accesses the Internet for authorizations. If that is you, read on, because a change to PCI v 2.0 may mean you no longer can use SAQ C.

SAQ C previously had five requirements:

• the payment system and an Internet connection had to be on the same device
• that device was not connected to any other system in the merchant’s environment
• the merchant kept only paper reports or receipts
• the merchant stored no electronic cardholder data
• remote vendor support was managed securely.

The payoff for meeting these requirements was that a school or campus merchant could qualify to use this simplified SAQ and avoid the much longer, more involved, and significantly more costly process of using SAQ D.

Unfortunately some of you will no longer qualify to use SAQ C. The reason is that SAQ C now includes an additional, sixth requirement:

• your company store is not connected to other store locations, and any LAN [local area network] is for a single store only.

This change means if your bookstore or food service operation or whatever supports a branch or second (or more) location(s) using their single POS system, they would need to use SAQ D.

The change to SAQ C will affect many universities that have retail or food service operations, and support multiple campus locations with a single POS system. I doubt cashiering operations will be affected very much.

We talked about this issue at the Treasury Institute's recent PCI workshop. I described the changes as part of covering what is new in PCI 2.0. It surprised me how many schools had not noticed the change in the SAQ. I admit it is a subtle change, but it is an important one for a lot of schools. It likely means they either have to license some additional POS applications so they have one for each location, or they are thrown into SAQ D.

If this situation describes your campus, I suggest you get to work on it now and not wait until the last minute. I hate to be the bearer of bad news, but better you should know than get caught up at the last moment