PCI Tokenization Buyer's Guide Available

I am very pleased and excited to tell you about a project I just completed. That project was to write a buyer's guide for tokenization. The project was sponsored by Intel Corporation. While they got to look at the draft, I (and my colleagues at 403 Labs) had complete editorial independence and control. The result is a vendor-neutral, technology-neutral discussion of tokenization, how it might reduce your PCI scope, how to evaluate alternative vendor products, and what you can expect.

Together with the guidance from the PCI Council, I hope this Buyer's Guide will help merchants determine if tokenization is right for them, and if it is how they should evaluate their options. If your bookstore, food service operation, parking garages, or other auxiliary organization has any retail-type payment activities, they likely are (or should) be looking at tokenization as a way to reduce their PCI scope. This guide was designed for them.

You can download a pdf of the white paper at Intel's website. I hope you find it useful.

Visa on How to Detect a Security Breach

Visa just released a very interesting slide deck entitled Identifying and Detecting Security Breaches. You can see it by clicking here. The presentation illustrates some of the signs of a potential incident among other things.

The presentation makes interesting reading, and you may want to read it along side your own incident response plan.

I particularly like the emphasis on logs and logging. Having a good logging system is critical to detecting security breaches, and Visa emphasizes this point. They also discuss the basics of incident response management (which is why you may want your own plan nearby).

I suggest you download the material, and while your at it, surf over to Visa's website and download their excellent What to Do If Compromised document. I always send a copy to clients before starting a new engagement.

PCI DSS Point-to-Point Encryption Guidance Soon?

Like many of you, I am looking forward to the PCI Council's guidance on point-to-point encryption. A lot of schools are talking to vendors about POS devices that promise to take their systems out of scope. Some schools are buying these terminals, and I have to admit they seem attractive. Before you go too far, though, I recommend you take a look at what the Council is saying, and what they might say, about how P2PE (the unfortunate acronym) can reduce your PCI scope.

The place to begin is to download the excellent "Initial Roadmap: Point-to Point Encryption Technology and PCI DSS Compliance v 1.0." This document came out last October. It lays out a lot of the details and what to look for in a P2PE system. What we are all eagerly awaiting, though, is the follow-on document promised before the end of this year: the actual "Validation Requirements for Point-to-Point Encryption." The Council promises:

It [the Validation Requirements] will define requirements and the process for validating effective P2PE solutions. Its intended audience is vendors, assessors, and labs that may evaluate the testing procedures associated with key management, segregation of duties, access controls, and other necessary criteria.

Here are some things to keep in mind as you look at solutions in the market today.

First, please understand P2PE only affects the transmission of cardholder data. It says nothing about storage or processing. The Roadmap document makes this clear in several places. Second, keep in mind that this is an integrated hardware-software-provider solution, and all three parts have to work for it to be effective.

Then look at the advice on how to implement the system:

• Encryption is performed immediately after reading the data through contact-based (EMV), magnetic stripe, contactless, PAN key entry or Near Field Communication [NFC] methods.
• The portions of the merchant environment that no longer require validation have no access to: plaintext CHD, cryptographic keys, or a decryption function that would allow encrypted data to be decrypted.
• CHD (including any sensitive authentication data) cannot be decrypted until received by a validated decryption point such as a segmented portion of the merchant network or processor/acquirer network.
• P2PE solutions including devices, key management practices, and encryption and decryption environments are independently validated.

The Roadmap has four conclusions: the technology is immature (meaning don't necessarily believe everything you might be promised); P2PE can move only the transmission part of your transactions out of scope (if properly implemented and validated, of course), meaning your payment application may still be in scope depending on where the two "points" are; P2PE does not make PCI DSS compliance go away (i.e., silver bullets are still outlawed); and you need independent validation of the P2PE solution, particularly the encryption/decryption process.

It is this last part where I expect to see the Council announce a program modeled on PCI PTS. That is, there will be independent testing labs that will validate devices (and their underlying software) for compliance, much like they test encrypting PIN devices today. This will give vendors a clear path to get their devices approved, and it will give you confidence that what you buy and install will reduce your PCI scope.

Let me make it clear I have no inside information. I am not part of the task force, and I have no insights into the Council's deliberations. However I do expect a guidance document to be issued soon (it is getting late in 2011, after all).

P2PE is an exciting and promising technology to reduce PCI scope for many merchants operating in a card-present environment. Like tokenization, there will be lots of issues to address in any implementation. In the meantime, if you have any interest in point-to-point encryption (and I expect almost all of you dear readers will), download the Roadmap and read it carefully. It may help you with your intermediate decisions, and it will help you understand the final guidance document when it comes out.

I'm Here For Another Year

Earlier this month I took my annual QSA re-training and then the re-qualification exam to continue being a QSA (for my third year). For those of you who don't know, the PCI Council requires all QSAs to go through this process each year. The good news is it looks like I'll keep doing this for a while.

The re-qualification training has changed quite a bit. It is computer-based, and it has improved each year. This year there was a lot of focus on PCI version 2.0 changes as well as the supplementary guidelines issued by the Council. The refresher on the actual PCI DSS Requirements was pretty cursory, as you would imagine for a current QSA, but there was some additional material that was quite well done.

The test was a series of multiple choice questions on everything PCI and payment cards. My biggest problem was arguing with the test because I could make a case in a couple of instances that several answers were true. I know talking back to a computerized test is neither very useful nor productive, but I felt better. All of which is to say I likely didn't score 100%.

I'm looking forward to another year of blogging, working with my clients, and definitely another year of the Treasury Institute's PCI Workshop. I hope to see many of you there next April.

Passwords Don't Have To Be That Hard

One of the issues that most frustrate users is passwords. They have to be long, they have to be complex (i.e., upper and lower case, numbers, symbols), and they have to be changed regularly. PCI Requirement 8 has an amazing number of detailed requirements for passwords.

So how do you enforce a compliant password policy without everyone either (a) writing their passwords on yellow sticky notes attached to their screens, or (b) threatening you when you show your face in their office? Here are some thoughts.

Personally, I use 1Password to manage my (strong) passwords. There are also various other programs, many of which are free. I just like that one (along with a lot of other security pros for whom I have a lot of respect).

I saw this article a while ago in the New York Times. The author contends:

MAKE your password strong, with a unique jumble of letters, numbers and punctuation marks. But memorize it — never write it down. And, oh yes, change it every few months.

These instructions are supposed to protect us. But they don’t.

Part of the reason is that it is tough to follow those instructions.

But there are other approaches. For example, please take a look at this great column from the New York Times. The author emphasizes that it is the length that is important in passwords:

Here’s a little quiz: Which is the stronger password? “PrXyc.N54” or “D0g!!!!!!!”?

The first one, with nine characters, is a beaut. Mr. Gibson’s page says that it would take a hacker 2.43 months to go through every nine-character combination offline, at the rate of a hundred billion guesses a second. The second one, however, is 10 characters. That one extra character makes it much, much stronger: it would take 19.24 years at the hundred-billion-guesses-a-second rate. (Security researchers have established the feasibility of achieving these speeds with fairly inexpensive hardware.)

Don’t worry about the apparent resemblance of “D0g,” with a zero in the middle, to the word in the dictionary. That doesn’t matter, “because the attacker is totally blind to the way your passwords look,” Mr. Gibson writes on his Web site.

Wowsers. If I can remember the number of exclamation points (or ^s or &s or whatever), then I can have a strong password that I might be able to have users remember.

But for genuine wisdom (and I do not use that term lightly!), you have to see the blog post by my colleague Jeff Zellman at the 403 Labs blog. He writes:

What many people fail to realize is password cracking is done by automated computer programs. These programs are fairly sophisticated and try all the characters on the keyboard (not just letters!). Shorter passwords are easier to guess since there are less characters to match. Just like a 3-ball lottery is easier to win than a 7-ball one.

Now imagine the difficulty of winning a 44-ball lottery.

You actually have to see the accompanying cartoon (talk about wisdom!) to get it, but the point is that we can help users create strong passwords (high entropy) using passphrases that they can remember.

Computers can crack passwords (eventually), but people have to remember them. Too often when we are working on PCI compliance we forget that humans have to implement the requirements or they won't stick. Passwords are no different.

Let's see... "correct horse battery staple"... Read Jeff's post and you'll get it.

Maybe your users will, too.

Tokenization Guidelines Released

Friday, the PCI Security Standards Council released it long-awaited tokenization guidelines. You can click here to get a copy.

I wrote about it on the 403 Labs blog , so I won't repeat myself. Also, Evan Schuman did a great job summarizing the implications on StorefrontBacktalk.

If you are contemplating tokenization at all, do yourself a favor and download and read carefully the Council's guidelines (along with the blog posts above). Especially see the very end of the guidelines where they talk about "high value tokens." In a lot of cases, your tokens might be these "high value" ones, and if so, they may be in scope for PCI...!

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.

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.