PCI, the New Kid in the Block (not the only kid)

I just finished two days at a PCI conference in Delaware and I’m writing this as I fly back to Vegas – technology is great now-a-days. The Payment Card Industry Compliance in Hospitality Conference held at the University of Delaware Courtyard by Marriott Hotel – it’s a training hotel for students looking for careers in hospitality management. The University of Delaware were great hosts.

The conference was targeted toward hotel and restaurant merchants. I’ll be honest; I thought the conference was going to be just another “PCI is great, you must comply” event where speakers ramble off a bunch of FUD. I was pleasantly surprised to find my preconceptions were wrong – so much so that I’m suggesting to my company that we become a sponsor for a future conference.

I think what surprised me the most was the format. The format was closer to a round table discussion than a lecture like I’m used to seeing. Audience questions were encouraged, not just at the end of each session, but throughout each session. One interesting session was a real life experience from the eyes of a Director of a hotel merchant chain. He detailed the five stages of grief his organization went through when PCI compliance, actually DSOP (AMEX’s version of PCI) was brought to their attention and how they became compliant.

Another nice change was that there was a lot of focus on multiple security and privacy laws and programs, not just PCI. The theme was to create one set of goals to comply with all the laws and programs that might apply to a particular merchant: HIPAA, FACTA, SOX, GLBA, PCI, etc., etc., etc. The only real FUD was the fact that while parts of PCI overlap one or more of these laws, if you’re breached, the fines and consequences associated with PCI may be the least of your worries.

There was a couple product/service demos to round things out. I was impressed that tokenization was actually mentioned by a few of the speakers (including Bob Russo, General Manager of PCI SSC). I guess the word is getting out.

The one big thing I’ve come to realize is that many level 4 merchants are going to have a difficult, if not impossible time fully complying with PCI. Not directly because of a security weaknesses, but indirectly because of process management in the payment application environment. One big problem I noted was that PCI requires that all patches be tested prior to implementation. The literal interpretation of this, which forensic analysts are taking in the event of a breach, is that every O/S and third-party vendor application patch must be tested by the merchant in a testing environment prior to roll-out. Most level 4 merchants I know don’t have the money, time, or resources to fulfill this requirement. This requirement will be difficult for all merchants to comply with, but level 4’s just because of their smaller sizes, are going to feel the pain the most. I think something will need to be adjusted here because if a significant percentage of these merchants can’t or won’t comply, then what the point?

I always say focus on security and compliance will follow. I still firmly believe this but for level 4 merchants, my recommendation would be to be as secure as possible to prevent the breach. If you can accomplish this, then you won’t have to cross your fingers for the forensic interpretation of your processes.

I recommend this conference if and when it is held again. For information on the conference, try here: http://www.hospitalityitcompliance.org

2008 Annual ETA Meeting & Expo -- Been There, Done That, Got the T-Shirt

Another ETA annual meeting has come and gone. For at least the third year in a row, PCI is the buzzword – not “a” buzzword, “THE” buzzword. I find it strange that while the various payment security programs like CISP, PCI, PCI-DSS, PABP, PA-PED and now PA-DSS have been evolving for years, the confusion level among the attendees stays consistent. I’m not sure the reason. Some of my thoughts on possible reasons are (in no particular order):

• Maybe new people are entering the industry faster than the industry can educate?
• Possibly the initial confusion level was higher than it appeared and this confusion is being rationed over time?
• Maybe this is normal when attempting to apply security terms and techniques to a mostly non-technical community?
• Maybe the evolution process of these programs is happening at a faster pace than the education of the industry that must abide by the programs?
• Maybe I’m just totally misreading the confusion level of the attendees and it’s the exhibitors that are confused?

Whether or not any of these are true or multiple factors are involved, a focus of the entire meeting was on education and in this regard the ETA hit a home run. Keep up the good work.

Exhibitor wise, this show goes in cycles – probably not unlike most industries. What is in today will be old tomorrow and what was old will be new again. Ignoring PCI (because that’s been a consistent vendor buzzword for years now), from what I remember, three years ago the buzz was Dynamic Currency Conversion or DCC. Two years ago terminals seemed like the hot item – terminal hardware manufacturers, terminal software developers, and terminal deployment & support vendors. Last year virtual gateways seemed to be in vogue – everyone and their brother had some form of a virtual terminal implementation and a few offered POS integration. This year terminals seemed to make a come back although due to industry “consolidation”, less terminal manufacturers but the terminal software developers picked up the slack. Will DCC be next year’s new thing? (GOD I hope not) I guess we’ll have to wait and see…

Ooo, look at my muscles – I’m So PCI Compliant

The big myth right now that many merchants face is that PCI compliance means security. Unfortunately for merchants that are spending thousands, and hundreds of thousands and sometimes millions of dollars upgrading their systems for compliance, this is not the case. Compliance does not equal security. In fact, even a successful PCI audit only reflects a point in time so technically a merchant is only “certified compliant” at that specific point in time.

Hannaford did everything they could to be PCI compliant. From what I have read, they did not cut corners or go the cheap route with compliance. IMHO the problem was too much, maybe exclusive, emphasis on compliance and possibly not enough emphasis on security. I’ve said it before and I’ll say it again, focus on security and compliance will be a byproduct.

One last point I would like to drive home about why security is so important. Over the years I have had the opportunity to speak with various people in the industry. One ex-MasterCard mucky-muck told me that the card associations view EVERY breach as a compliance failure by the merchant. In other words, if you are breached you will be found out-of-compliance and fined – period. If you are focusing on compliance to reduce your risk of a fine, give it up; focus on security instead.

PCI: Compliance vs. Security

Last week Shift4 Corporation hosted the 2007 Real Security Summit. There were many sessions on various topics given by speakers with a wide range of expertise. Most of the information given was anywhere from interesting to scary, and all was useful. The range of topics included security, privacy, liability and compliance -- most everything you must know if you do anything with payment or privacy information. The two of the scariest topics were the link between credit card fraud and terrorist funding and the full liability to a merchant in the event of a data breach.

While all the information I would consider valuable, one quote by Heather Mark, stands out in my mind dealing with how many merchants and vendors deal with PCI: "Teaching to the Test." I’ve known what this phrase meant ever since my high school days but have never thought of it in terms of PCI. For anyone who has never heard the term, this is when an instructor does not teach the fundamentals and concepts of a subject but instead focuses on the answers to the test. This is a side-effect of the "No Child Left Behind" program -- many teachers are teaching to the test instead of teaching the subject at hand. Teaching to the test is depriving our kids from a rich education just like teaching to the test will deprive our industry from the overall goal of PCI -- security. Both programs, No Child Left Behind and PCI, are good programs with good intentions but they fail from the same problem, what I call "the compliance factor." If you are only looking at PCI as checkboxes required for compliance, then you are missing the point of PCI.

I’ve always addressed this topic as Security through compliance vs. Compliance through security. Some might think these two terms net the same end result but in reality they do not. Think of compliance as the very minimum that must be met to be considered "secure enough." With Security through compliance, the minimal was done to make the application or data center secure. With Compliance through security, your application or data center is already secure, you allocate resources to security and privacy, you have trained your personal on security and compliance is almost a side-effect of this security.

Sure, go through the PCI requirements and make sure you have every checkbox checked but then go further. Look at your data requirements. The easiest and best way to keep sensitive data out of the hands of hackers is to not store it. Encryption will fulfill some of the PCI checkboxes but if you don’t absolutely need the data, not storing it is a more secure alternative. There are people out there that want your data. What would happen to your company’s reputation in the event of a data breach? Again, think beyond checkboxes.

Yes, privacy and security can be difficult and an ever changing target but I urge everyone to look at this as more than checkboxes. Be vigilant.

Until next time…

PCI Confusion

PCI has one glaring hole that needs plugging. This hole has nothing to do with a missing firewall definition or a some skipped procedure here or there; this issue is much bigger than that. The issue is that PCI does not define the intent of the various requirements and sub-requirements. Instead of stating an intent like "we need a road connecting Las Vegas to Los Angeles," PCI starts the process by stating "acquire umpteen million tons of asphalt and a steamroller and pave in a southwest direction." This leaves much to be interpreted by the reader. It also leaves the poor merchant that must comply with the requirements even more confused. If you don’t believe me, pick any single requirement and ask ten people in the credit card industry how it impacts you as a merchant. Be it banks, processors, security experts, even VISA or MasterCard, I can all but guarantee that you’ll get ten different answers.

In the latest version of PCI requirements, version 1.1, an entire appendix was added to allow for Compensating Controls. The definition of Compensating Control starts out as: "Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk." My problem is that since the intent or the risk associated with each requirement is not defined, what is the definition of "sufficiently mitigated the associated risk?"

Obviously, some of the requirements do not need much stated about intent. Firewalls for example, anyone with any technical knowledge about the Internet knows the intent of requiring firewalls. Other requirements though are not as straight forward in determining the intent: "6.5.7 Improper error handling," I know what I believe to be improper, but the average user probably would have another belief as would a banker or merchant. A brief intent would clarify this: "Verify that all error conditions are trapped and do not leave the application in an unknown or unstable state."

The Open Web Application Security Project guidelines (OWASP), which is referred to in PCI section 6.5, is very good at defining intent with each requirement. It clearly states "here is the problem that needs to be addressed" followed by "here are some solutions that address the problem." The current PCI iteration seems more "you will do this, sit down, shut up, and oh, by the way, we have this compensating control thing if you can’t (provided it meets our undisclosed 'intent')."

I know I sound like an anti-PCI fanatic. On the contrary, I fully believe PCI is a very good thing that the industry desperately needs and it should be required. I just think the intent of each requirement and sub-requirement needs to be defined. If and when this is accomplished, I think much of the confusion in the industry will be eliminated.

That’s my humble opinion. I welcome yours…

Merchant Fines?

Every now and then I come across someone wondering how fines work in the merchant service arena. Here is an example:

I keep seeing the mention of these fines. Who has the power to levy these fines on places that are non compliant? What makes them think they will actually be able to collect?

This is a good question. This is a very good question. In a security summit my company hosted last year, we put together a round table discussion with Visa, MasterCard, AMEX and the attendees, a similar question was posed. The answer was a little vague and it goes like:

VISA/MasterCard – The initial response was that Visa's and MasterCard's legal agreements are between them and the member banks, not the merchant so Visa and MasterCard does not have the ability to fine merchants, they can only fine the member banks. But, after some follow-up questions and prodding, they stated that their agreements with the member banks does not prohibit the member bank from passing the fine down the chain until it gets to the merchant. Most all agreements in this chain have some sort of "hold harmless" clause and it's this wording that end up placing the fines in the merchants lap. So while Visa and MasterCard do not fine the merchant directly, indirectly they are the one imposing them.

AMEX – American Express' agreements are much more straightforward, most AMEX agreements are between AMEX and the merchant. In this case, AMEX would be imposing any fines directly and hold harmless clauses are not in the mix.
Part two of the question above, what makes them think they will actually be able to collect? Well, merchant agreements are legal and binding contracts so not only can your merchant bank freeze your accounts to cover any fines, they can make your life legally miserable. In addition, many merchant agreements require personal guarantees, which can add to the miserable factor.

Bottom line: read your merchant agreements carefully and do your best to comply with all the requirements. Just like with the law (maybe more so), ignorance is no excuse.

Payment Tidbits

Well, I've been ignoring my blog long enough. I've been dragging my feet because part 3 of A Better Mousetrap series is a little larger than I anticipated, mainly because I want some pretty diagrams and I'm barely proficient at graphic programs. Anyway, I've decided it's my blog and I'm going to go slightly out of order – hopefully this won't kill anybody. I will be doing part 3, just not today.