Thursday, August 11, 2011

Visa Supports EMV Cards - Can You Skip PCI Revalidation?

The two thoughts in the headline. While they might seem to be unrelated, actually are part of the same idea.

In case you missed it, Visa released four (!) bulletins on Tuesday about their plans to accelerate the acceptance of chip technology for both card and mobile device transactions. What follows is a brief discussion of each of the releases, links to the original docs, and a few editorial comments (as if you had to ask...).

The first bulletin describes Visa's plans to "accelerate the migration to contact and contactless EMV [named after the three organizations behind the standard: Eurocard, MasterCard, and Visa] chip technology in the United States." It is a great overview of Visa's strategy, explains the technology a bit, and links to the following three bulletins.

In a second bulletin, Visa describes the details, particularly incentives for merchants to upgrade their POS devices to process chip transactions. The carrot: "Visa will waive Payment Card Industry Data Security Standard (PCI DSS) compliance validation requirements to encourage merchant investment in contact and contactless chip payment terminals."

Wowsers...did Visa just say they were waiving PCI compliance!?! No, the did not say that. What Visa said was that effective October 2012, if a merchant (1) had validated its compliance in the last 12 months, (2) didn't store sensitive authentication data (like the security codes or mag stripe), (3) was not involved in a cardholder data breach, AND (4) processed at least 75% of their transactions on "dual-interface EMV chip-enabled terminals", they could participate in the Technology Innovation Program (TIP).

Under TIP, the merchant does not need to RE-VALIDATE compliance each year. You still have to be compliant, and if you get breached the same penalties presumably will apply, but you don't have to re-validate your PCI compliance.

This TIP program (already available in Europe) is what has lots of people buzzing. What does it mean for Higher Ed? I've got some thoughts (naturally!), and they are a bit further down.

Who ever heard of a carrot without a stick? Certainly not Visa, and the "stick" is in a third bulletin. This one describes a liability shift. Simply put, after October 2015 (note the different date) the rules for who is responsible for POS fraud shifts: "This policy assigns liability for counterfeit fraud to the party that has not [Visa's emphasis] made the investment in EMV chip cards (issuers) or terminals (merchants' acquirers)."

Many observers and blogs are missing this liability shift. Read it carefully. It looks to me like Visa wants everybody in the US to have a chip card by 2015.

Therefore, if a merchant and/or acquirer (or processor) doesn't buy POS terminals and upgrade their back office systems to process chip transactions, they eat any and all POS fraud.

The fourth bulletin is the acquirer/processor mandate, and it mainly contains technical details on Field 55 and other message elements.

What does this mean for Higher Ed? Should you go out and start pricing EMV chip-enabled POS terminals for everybody? Do you have to? How much will TIP save you if you qualify?

Good questions all. First some full disclosure: I am a QSA, so I might be biased in some of this; also I used to work for Visa, and those were some of the happiest years of my professional life, so again I might be biased. Given all that, here are some thoughts to get us started...

Kudos to Visa for showing leadership. The US is far behind the rest of the world in terms of card technology. As a cardholder I applaud what they are doing. Even if fewer companies need QSAs, I'm willing to start polishing my resume. Besides, nobody waived PCI compliance, just the formal re-validation (once you have validated). I hope I don't have to wait until 2015 to get my chip card.

Will the other brands follow suit? When will we see MasterCard's, Amex', or Discover's chip acceleration plan? If they don't, any benefit from TIP will be reduced to about zero since those brands will still require PCI compliance re-validation.

Speaking of a carrot...what carrot!?! I don't see how anyone but the biggest (Level 1 and some Level 2) merchants get any benefit from TIP. Smaller merchants don't hire QSAs to prepare a Report on Compliance (ROC), they hire QSAs as consultants. So not requiring one is no big deal. Also, in the past the card brands offered incentive (i.e., lower) interchange rates to offset the cost of merchant technology investment mandates. Here, there is no incentive. Think about it: the card brands introduce a "tax" on all merchants called PCI compliance; one brand then offers to waive the tax if you spend money on technology. To me, that's just giving you back your own money. TIP seems to cost Visa and its issuers not a penny.

Doesn't waiving PCI compliance re-validation hurt security? Visa said their objective was increasing security by encouraging chip technology. I think we have to wait and see if waiving formal compliance re-validation causes merchants to get lazy and backpedal on security.

What about MOTO and ecommerce? Good question. These announcements only dealt with POS transactions. As far as I can tell, chip cards won't help much when the card isn't present. Plus, remember the cards still have mag stripes.

What does this mean for Higher Ed? My guess is it means very little in terms of incentives. However it does mean that you need to have the "dual-interface EMV chip-enabled" POS devices at least by October 2015. It might be time to talk to your acquirer/processor and look at your technology budgets. Then again, if you don't have much POS fraud, maybe you can skate along for a while. I wouldn't advise it, but...

For a great post and discussion, surf over to Securosis and have a read.




Tuesday, August 9, 2011

Don't Miss Patch Tuesday

Microsoft released quite a package of thirteen security patches today. You can check out the list at SANS (click here) and here's a link to Microsoft's Technical Bulletin.

This update has some patches you don't want to miss, particularly to Internet Explorer as well as your DNS servers. The IE patches are particularly important as there are known exploits available and in the wild.

Thursday, July 21, 2011

Data Breaches are Real

Your campus merchants are ripe targets of opportunity for hackers and phishers.

If you haven't seen this article in the Wall Street Journal online, I recommend you read it. It is about a small business that downloaded some malware (very easy to do; very tough to eliminate once you do), and as a result they suffered a major data breach. Well, maybe not "major" in the sense of making the headlines, but it nearly put one small business out of business.

The moral of the story is simple: this could happen to you...to your campus...to your auxiliary organizations like parking or bookstore or any other campus merchant.

Please give a thought to passing this link to your campus merchants. I'd also suggest you make stories like this a part of your security training.

The bad guys are increasingly targeting small and medium sized businesses. With the typical open networks and varying degrees of security on most campuses, you should consider yourself at risk every day. Which reminds me, have you taken a look at your latest vulnerability scans? When was the last time you updated anti-virus and installed patches on ALL your systems?

Please don't be the next one in a headline. It'll surely ruin your day.

Monday, July 11, 2011

Credit Card History

I'll admit it: I am a credit card junkie. For others similarly afflicted or those who might want to see what it is like, take a look at a post at MSN Money on "18 Fun Facts about Credit Cards". There is nothing new here, but it is a good collection of some historic milestones in the plastic payment business.

Higher Ed Credit Card Agreements

Does your school have a co-brand credit card agreement? Usually, it will be your Alumni Association, Foundation, or even the Athletics or an academic department that has partnered with a bank to issue one of these co-branded cards. If you have one of these, you may want to compare your program with your peers. Thanks to the Federal Reserve and the Credit CARD Act, this is possible.

The Federal Reserve has released its second "Report on College Credit Card Agreements." A copy is available for download at the Fed's site (click here to download a pdf version).

By way of background:
Section 305 of the Credit CARD Act and the Board’s implementing regulations, 12 C.F.R. § 226.57(d), require credit card issuers to submit to the Board each year a copy of any college credit card agreement between the issuer and an institution of higher education or an alumni organization or foundation affiliated with an institution of higher educa- tion (an “affiliated organization”) that was in effect at any time during the preceding calendar year. Issuers also are required to submit the following informa- tion with respect to each agreement: (1) the number of credit card accounts opened pursuant to the agreement (“college credit card accounts”) that were
open at year-end (regardless of when the account was opened); (2) the amount of payments made by the issuer to the institution or organization during the year;2 and (3) the number of new college credit card accounts that were opened during the year.

Issuers were required to make their second annual submission to the Board by March 31, 2011. This submission comprised college credit card agreements to which the issuer was a party during 2010 and information regarding payments and accounts as of December 31, 2010.
The document mainly contains tables of individual Higher Ed institutions' programs, but there is some text and lots of footnotes. There is also an online database of the agreements.

Compliments to the folks at Payments News for pointing out this information.

Friday, June 24, 2011

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...

Thursday, June 23, 2011

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.