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.

Does ABC POS System have hidden fees?

Recently I was involved in a thread where the question was asked, "Does ABC POS System have hidden fees?" (While the question posed is real, the names have been changed to protect the innocent). The dialog quickly went from "ABC dealers not disclosing that they use a gateway for payment processing (and the associated fees)" to "payment gateways are unnecessary." My opinion may be biased on this subject but bias or not, there are definite advantages for a POS vendor to use a gateway as opposed to a direct interface to a payment bank/processor.

Let me start my argument by stating that all payment gateways are not created equal. All the advantages I list here are gained by using a reputable, reliable, secure and full-featured gateway provider (hereafter referred to as "good gateway"). Obviously, I believe that Shift's $$$ ON THE NET offering meets this criteria. There might be others but that is another topic that can be discussed on someone else's blog.

In no particular order, here are some of the advantages for a POS solution to use a good gateway provider as opposed to a direct interface:

• Security - a good gateway can increase to level of security in a POS application ten fold. One security "best practice" is to only store what is absolutely necessary. Not storing payment details, like actual card numbers, greatly lowers the merchant's exposure to compromising sensitive data. In the event the POS application data files are ever stolen, even if the files are encrypted (which is required), current regulations require the merchant to notify law enforcement AND the customers (via their merchant bank) because the encrypted data has the potential of being decrypted. If the POS application does not store this information, notification is not required – saving both legal costs and reputation (although, Shift4 would still recommend notification of law enforcement).


• Auditing - a good gateway will allow for pre-settlement or pre-capture auditing. Pre-settlement auditing allows the merchant to make corrections to transactions in a batch before they are sent off to the merchant's bank account. There are several reasons for this including: 1) system or communication failures that resulted in missing or double posted transactions, 2) a layer of protection against trusted employee fraud, 3) a layer of protection against simple data entry or posting errors by clerks. Many people assume that accidentally posting a $100 sale and later posting $100 credit is a wash – WRONG. There are fixed transaction fees associated with both sale and credit transactions as well as a discount rate applied to sale transactions that you do not get back when the credit is issued. This $100 example will cost the average merchant about $2 (not including labor of charge-back fees if it went that far). If post settlement corrections are common, these fees can add up fast.


• Archives - a good gateway will provide a minimum of 90 days of archives. These archives can be used for charge-back defense, fraud control and even sales analysis or sales forecasting.


• Batch Resubmittal - while not common, occasionally batches of transactions get lost, have data content issues or merchants experience bank/processor setup issues that prevent submittals. Without a good gateway in the middle the only resolution is to rekey the entire batch. With today's security regulations where full card information should not be printed on drafts and vouchers, rekeying may be impossible resulting in a loss of funds.


• Bank & Processor Neutrality - with a good gateway, merchants can shop around for their best rates and services whereas direct interfaces lock you into a particular merchant service provider OR add substantial fees if the merchant uses a non-preferred provider. A good gateway will make a merchant service provider switch transparent to the POS application and should not burden IT staff or operations.


• Support - a good gateway can offer a much greater level of support than a POS vendor (who most likely does not have a great expertise in payment processing) and a Bank/Processor (who most likely does not have ANY expertise in POS applications). Good gateways will provider 24x7 support which can compensate for a POS provider that does not offer 24x7 or a Bank/Processor that does not offer 24x7 support. A good gateway provider has expertise in dealing with both POS vendors and Banks/Processors. Most POS vendors do not know the differences between EIRF and CPS Retail nor should they have to; this is something a good gateway knows and/or can diagnose. Processors provide very limited help in diagnosing qualification vs. non-qualification rate issues. Believe it or not, I've personally worked with several banks that could not help with these types issues.


• Merchant Advocate - this could be lumped into Support but a good gateway will have the merchant's best interest in mind, not the POS vendor and not the Bank/Processor. This could be in diagnosing an occasional POS interface issue to being charged excessive non-qualification fees by the merchant bank.

All things being equal, a POS application using a good payment gateway has much more value to a merchant than the same POS application using a irect interface to a Bank/Processor. Smarter POS vendors will focus on their forte – POS - and incorporate their gateway provider's expertise and features into the overall POS solution.