Visa Best Practices for Payment Applications

Visa has just come out with its latest in what I hope will be a continuing stream of Best Practices documents. This one is Visa Top 10 Best Practices for Payment Application Companies. You can click here to download a pdf copy.

This document is not just for application developers. It also is for any school (or other organization) that buys software applications. As such, I really recommend you read it.

PA-DSS, like PCI DSS, is a baseline. It is the minimum you need to do to protect your application. PA-DSS addresses how the app is developed. It doesn't address things like training users and not storing cardholder data in the first place. This latter point is one I often find that users don't understand. Because an application is PA-DSS validated does NOT mean the application doesn't store cardholder data. It only means that if it does, it treats it securely. Therefore, don't assume because you are looking at a PA-DSS application you are automatically saved from the joys of SAQ D.

As Visa says on it's website:

While many payment application vendors have deployed PA-DSS compliant payment applications, there is growing concern that updates to payment software are not being consistently developed to ensure that known vulnerabilities are not being reintroduced. In addition, there is concern that payment software is not being securely implemented at customer sites. Merchant and agent compromises reveal that a number of payment application companies have poor software practices when installing payment applications and systems, support customers using weak, shared or default access credentials, and manage customer sites using poorly implemented remote management tools. Criminals exploit these poorly guarded entities by gaining easy entry into cardholder environments.

To stay on top of these trends, Visa has developed a set of best practices to help payment application companies address critical software processes.

When you are looking at a payment application, by all means first go to the list of PA-DSS validated applications maintained by the PCI Council. Then as you are assembling your RFP or looking at vendors, use the 10 Best Practices to guide your decision.

PA-DSS is a baseline, and it is a good one. Visa has gone one step beyond this in recommending its 10 Best Practices to software vendors (and resellers and OEMs). You should use these same Best Practices in your evaluations, too.

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.