Payment Tidbits

Debit Card Fees - Simply another front in the ongoing class war

2011-12-05T14:42:00.001-08:00

I just read this commentary in the Washington Post: In cutting debit card fees, Fed should use Congress’s standard. I could not disagree more. I have not got a clue where the author is getting his numbers? My guess is that he is calculating the $7B vs. $14B based the campaign marketing numbers used to sell the bill to congress and the public. There are flaws in this type of thinking and I'll get into that below, however, this did get me thinking of a related but bigger problem.

I'm sure by now everyone reading this has heard about the class warfare arguments in politics. Whether you believe the "rich" should pay more or not is one issue but to me, the bigger issue is the class warfare campaign. This is a slippery slope. Take for instance the Dodd-Frank Wall Street Reform and Consumer Protection Act. This is another battle of the same war being fought under the guise of "consumer protection."

I've briefly touched on the Dodd-Frank Act before. I think that this entire bill is a big can of worms that many proponents don't understand or choose to blindly ignore. Some of the provisions of the act that has generated buzz in the payments space are the restrictions it places on debit card transaction fees. Merchants have been told they will receive huge cuts in fees due to this bill. The NRF jumped on this bandwagon early in the process. I have not fully researched their involvement, but I would not be surprised if they provided parts to create this wagon.

There is one key component that the NRF and other merchant advocates blindly missed - the title of the act. Note the last two words just before Act: "Consumer Protection!" Not "Merchant Protection." Definitely not "Bank Protection." While today having the word "bank" in your name is synonymous to "rich", who's to say that tomorrow "merchant" won't be as offensive as "bank" to politicians? Currently the Dodd-Frank Act does not specify that merchants, or consumers for that matter, will receive one dime from the restrictions as there are many hands in the fee structure pie (not to mention various carved out exceptions). I can easily see a scenario where politicians realize that consumers are not reaping the rewards they were so generously promised so out pops "[insert name(s) here] Main Street Reform and Consumer Protection Act." Since politicians are so good at adding language to fix prior failures, one can expect a generous heaping of price controls for merchants to swallow, all under the same guise of "consumer protection."

As I said, this is a slippery slope. I've warned of side effect of price controls before this Dodd-Frank Act was implemented; we are seeing them now (see my previous post). One of the latest is that Visa and MasterCard have increased credit card fees: New Visa, MasterCard rates take effect. While not publicly stated, I have to imagine that this is to compensate for the loss of debit card fees. Since credit card usage rates are still higher in the US than debit card usage, this will mean a wash or an increase in fees even if the merchant does receive the debit card "rewards."

Just to clarify, I am not anti-merchant, and I am not pro-bank fees; instead I am very pro-merchant. I am against the government controlling prices for any industry. I feel allowing the government to dictate the price of any product or service is dangerous. Yes, there is precedence for government dictated price controls and some might argue this to be a good thing, and throw out some examples. But I would argue that these price controls have caused as much or more damage and problems than they fixed -- just to someone else (the politically out of favor class at the time).

Until next time...

Tokenization IS Encryption - NOT!

2011-11-01T12:03:00.000-07:00

Recently I found a blog post by Ramon Krikken entitled I'll go ahead and say it: Tokenization IS Encryption. If you have read any of my posts on tokenization, or more specifically TrueTokenization (tokenization by it's original definition), you know I disagree. Here are links to a three part post I wrote on 4titude -- Shift4's voice with attitude:

Tales From the Inbox - Iwueke

2011-10-24T15:42:00.000-07:00

Dear Mrs. Iwueke,

Thank you very much for bringing this to my attention. I didn't even know I had a $1.8m ATM card and it very much concerns me that it is about to expire! Please act immediately upon my behalf to claim the outstanding balance and send me the proceeds via a certified check ASAP -- or better yet, exchange it for solid gold or silver and have it shipped. Please deduct the shipping costs from the proceeds. Also, in exchange for your kindness, please deduct an additional $500 from the proceeds for your time.

Again, thank you very much!

--Steve

From: Mrs. Elizabeth Iwueke [mailto:xxxxx.xxxxxxxxx@yahoo.com.ph]
Sent: Monday, October 24, 2011 11:37 AM
To: undisclosed recipients:
Subject: Contact Global Express Shipping Company Benin Repub.

ATTN, PAYMENT NOTIFICATION

This is to bring to your notice that, I have paid the re-activation and the delivery of your ATM, I paid it because the ATM Card ($1.8m),has less three days to expire and when it expires, the money will go into Government purse. With that I decided to help you pay the money so that the ATM will not expire, because I know when you get your ATM definitely you must pay me, my money back and even compensate me for helping you.

Now I want you to contact The Shipping Company Benin with your Full Contact information’s so that they can deliver your Card to your destination address without any delay. Like i stated earlier, The delivery charges has been paid but i did not pay their official keeping fees since they refused.

They refused and the reason is that they do not know when you are going to contact them todat before dumourage might increase. They told me that their keeping fees is USD$25 per day and i deposited it yesterday .

Below Is the Shipping Delivering Company Contact Information’s,

Contact Person: Dr.James Nelson.

The Director General Global Express
Shipping Company Benin Republic
E-Mail:(xxxxxxxxxxxxxxxxx@w.cn)
Contact Number: +229-########

Contact Today to avoid increase of their keeping fees and let me know once you receive your Card.

Best Regards,
Mrs. Elizabeth Iwueke

Is PCI Even Legal?

2011-10-17T09:30:00.000-07:00

Back in September 2008 I put myself on PCI SSC's dung list as well as a separate entry on Bob Russo's personal ignore list with my post "PCI SSC Show Their True Colors -- Regulate for Profit". Recently I found an interesting post on Magtek's website: Fraud Mythology in the Payment World. It details a speech by Magtek CEO Mimi Hart where she rips into PCI, calling it "one of the more dangerous 'false gods' in payments." Now finally I have company on the dung lists! I have one small criticism about her speech though, every false GOD is dangerous so "dangerous" in that sentence is redundant. ;-)

Within the speech, Mimi Hart states "PCI has rapidly become a self-perpetuating, self-aggrandizing, profit-motivated authority", this got me thinking, is PCI even legal? Antitrust laws prevent the card brands from getting together in a room to set rates or make common rules for members, merchants, and customers. But before I go further, let me give a brief history lesson...

In the early days, prior to cardholder data security (pre-9/11/2001), the card brands, for the most part, relied on trust that cardholder data was being securely stored and properly used by merchants and applications. Sure, there was fine print in merchant agreements and various unpublished rules stating that merchants must do this or don't do that, but for the most part, there was no mechanism to enforce these hidden rules and fine print. After 9/11, the government decided payments needed better security and told the card brands to get it under control or they would step in.

Each of the card brands rapidly scrambled to create their own set of security mandates for merchants and vendors to follow. Visa had CISP, MasterCard had SDP, American Express had DSOP, Discover had DISC, and JCB had "security standards" (hmm, very creative!). While there were many common and compatible requirements, there were many that were unique to each, and worse, there were a few mandates that contradicted or deviated from mandates of other brands. In all this turmoil, PCI SSC was formed to unite all the security mandates and create one ring to control them all.

Ok, back to my question -- Is PCI legal?

Per the PCI SSC website: "The Council's five founding global payment brands -- American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. -- have agreed to incorporate the PCI DSS as the technical requirements of each of their data security compliance programs." Then a little further down on the same page, "All five payment brands share equally in the Council's governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organization."

I'm not a lawyer but to me this seems to imply that while PCI SSC is a separate organization, it is controlled by a round table of the five card brands. And because this is a "for profit" organization, this seems to have antitrust implications that may threaten PCI SSC's legal legitimacy.

PCI SSC was created as a way for the card brands to conspire to create a common set of security mandates without breaking antitrust laws. The problem is, PCI SSC is setup as a "for profit" limited liability corporation controlled by the card brands. If this was setup as a non-profit organization (as I assumed it was because of the .org domain name - silly me, another future rant) and a true standards committee like ANSI or ISO, I feel there would not be an issue. But as a "for profit" organization under the direct control of the card brands, there seems to be an issue here.

My recommendation: restructure as a non-profit organization, make the books public, and become a real open standards board eliminating the antitrust concerns.

If any antitrust attorney happens to read this, I would love to get your take on this question. Until next time...

P.S. For another take on the same speech, see the post in StorefrontBacktalk: Federal Reserve Listens to Security Vendor CEO Rip into PCI

P.S.S. Mimi, welcome to the list!

House Democrats Ask Justice Department to Probe Debit Fees

2011-10-14T13:36:00.000-07:00

This is an interesting and quick read in Bloomberg Businessweek: House Democrats Ask Justice Department to Probe Debit Fees

If you don't have the time and need a Reader's Digest version: Lawmakers are crying because banks are making them look like incompetent boobs. That's about it.

Swipe Fees Revisited

2011-10-13T17:27:00.000-07:00

I hate to say I told you so but:

With a $1.67 Average Ticket, Vending Processor USAT Predicts Pain from Durbin Rate - A vending-machine payments processor highly dependent on debit cards is bracing for a 247% increase in its average cost for accepting big-bank debit cards as a result of new Visa Inc. and MasterCard Inc. interchange schedules set to take effect Saturday...
Durbin Casts a Wary Eye on Rising Small-Ticket Debit Interchange - U.S. Sen. Richard Durbin on Tuesday said he is aware that new Visa and MasterCard interchange schedules will cause some merchants to pay much more in interchange when a consumer uses a debit card from a big bank to pay for small purchases...
New BofA Fee May Hasten Debit's Demise - Bank of America Corp., the largest bank by assets, plans to start charging its checking customers $5 per month, or $60 annually, if they use their debit cards to make purchases...
Durbin Attacks BofA's Decision - Sen. Richard Durbin, D-Ill., author of the debit-interchange regulation, attacked BofA's decision, charging the money-center bank is "trying to find new ways to pad their profits by sticking it to its customers."...
National Retail Federation also denounced BofA’s Decision - The National Retail Federation also denounced BofA’s debit card fee.
Bill Would Repeal Debit Fee Cap - ...Although the bill is expected to face resistance, Chaffetz and Owens believe it will gain momentum as consumers begin to see the consequences of the new price cap...

Oh, by the way, while I agree with most National Retail Federation stances, I believe they were dead wrong on this one. I have to imagine that someone over there is smarter than I and could have predicted side effects like these -- I guess not! Asking the government to step in and regulate costs and fees for an industry cannot ever end well. If someone arrives on your door and says "I'm with the government and I'm here to help", RUN! But in this case, the NRF invited them in with open arms.

Tokenization and Relevance

2011-08-26T08:58:00.000-07:00

I recently came across an interview in ISO&AGENT with Bob Russo on PCI's Tokenization Guideline: PCI Council Reveals Secrets of Tokenization

Much of the interview is standard talking points that I have seen in press releases and other stories from various sources, but it's worth a read if you follow tokenization.

The last paragraph of this story caught my attention though: "'When vendors first introduced tokenization, companies selling other fraud-security techniques were concerned about becoming obsolete,' Russo says. But over time, it has become apparent various layers of security are needed to keep data safe."

Tokenization was released to the public domain by Shift4 back in 2005 so "companies selling fraud-security techniques" really had nothing to be concerned about; all they had to do was incorporate tokenization into their solutions. Russo is absolutely correct in his assertion that various layers of security are needed to keep data safe, so even without tokenization, what cause did these companies have for concern?

Are we certain that the fear which Russo references was actually from fraud-security companies and not from PCI council members and QSAs? Some might think that the more you remove components and systems from PCI scope, the less relevance PCI and QSAs become. Personally, I think this fear of having less relevance was part of the motivation to redefine tokenization to include "high-value tokens" and defer token scoping to QSAs.

The primary goal of tokenization was to improve security by removing sensitive data from the merchant environment and a byproduct is a reduction of PCI scope. Similarly, PCI compliance should be a byproduct of solid security. As long as PCI acts as a liability shield for the card brands, PCI will have relevance. As long as QSAs focus on security and not compliance, QSAs will be have relevance. Neither should have feared tokenization by it's original definition, without the inclusion of "high value tokens."

Tokenization, the Newest Horse - err, Camel - in the Stable

2011-08-24T16:30:00.000-07:00

As the old saying goes, "a camel is a horse designed by a committee." This saying perfectly describes the recently published PCI DSS Tokenization Guidelines from the PCI SSC. While the original intent of the document was a noble one, the final version fell way short.

The problem with having multiple blogs is to post onto multiple blogs. To avoid content duplication, please go here to read my post: http://www.shift4.com/blog/post.cfm/tokenization-the-newest-horse-err-camel-in-the-stable

My take on Swipe Fees

2011-06-30T12:19:00.000-07:00

There is an ongoing debate in the restaurant and retail industries about swipe fees for debit cards. There are bills being written and debated in congress that address swipe fees and I see trade associations from both industries cheering on these new regulations. My advice:

Quit crying for government regulations and

start fixing the problem yourself!

There is no regulation that I'm aware of that says a business must accept plastic -- credit or debit. If merchants think the card brands are charging too much, organize something that would get your point across. Have a "no plastic day" or "no plastic week". If enough merchants participated, this would send a strong message to the card brands and with little risk of unforeseen consequences. To me, this debit swipe fee trivial, a much bigger issue are the different rates for reward cards vs. non-reward cards and not knowing the fee up front, during the authorization event. It seems strange to me that the reward card rates are rarely, if at all mentioned by these same trade groups and the reward rates are much more significant than the debit rates.

It’s a cliché of mediation, uttered by every mediator trying to push two unhappy parties to reach agreement on a resolution, that "a good settlement is one where both sides are unhappy." The problem is when politicians create regulations, having both sides unhappy does not buy votes so one side or the other is going to be ecstatic, while the other side is going to get screwed. In this environment things will change because both sides need to be profitable and this is where unforeseen consequences enter the picture. Many times (I would say most times when it comes to government regulations), these unforeseen consequences can be worse than the original problem that was being addressed. I strongly believe that it much better to keep politicians out than to suffer the unforeseen consequences that will ensue.

Some Recent PCI Results

2011-05-04T09:53:00.000-07:00

I just read a report on a PCI survey quoting some PCI statistics: PCI DSS compliance generates results. According to a recent survey performed by Imperva and the Ponemon Institute, businesses tend to perceive PCI compliance as something that does not have a positive impact on their security systems. However, the survey's results indicate companies that maintain PCI-compliant systems are significantly more secure than their non-compliant counterparts.

While I think PCI is a good thing because in a round about way it forces merchants to recognize security, I question statistics like this -- particularly the first number quoted: "...64 percent of PCI compliant respondents did not experience a data breach involving credit card data during the past two years."

In the past Visa has stated "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." Based on this statement I question whether or not the 36 percent of the PCI compliant respondents that were breached were "PCI compliant?" A catch-22. The report should have said 100% of PCI compliant respondents were not breached vs. some percentage of the non-compliant respondents were breached.

Nit-picky I know, but as my blog byline states, random thoughts.

Beware Mac users - as popularity grows, so does the target on your back

2011-05-03T10:20:00.000-07:00

It's been a while since my last post. I hope to start posting somewhat regularly again in the near future. It's been a madhouse around here as we have been building a new data center from scratch; new hardware, more hardware, new O/S, more memory, new software, new, new, more, more, better-stronger-faster everything, etc., etc. In the last few weeks we've been migrating various services and customers to it; throw in our annual PCI audit and presto -- no time. You'll hear more about this entire project in the next few weeks. For now, suffice it to say it's been a busy time.

Over the years I have posted on several forums my belief that no operating system is inherently secure simply because it is not Windows. Many anti-Windows zealots tout that Linux or Mac or whatever is much more secure based on the number of reported hacks and vulnerabilities: "Hey, simply look at the number to prove my point." And this argument always has a reference to some vulnerability report showing Windows (some big number), their O/S of choice (some little number). I always point out a very similar report showing market share: Windows (some big number), their O/S of choice (some little number). My argument is that hackers go to where the money is -- the market leader.

Well an interesting read that just came out the other day: Coming soon to a Mac near you -- serious malware. When I read this article I had to check back to the author a few times to make sure it was not me as an alias. Give it a read if you have some time.

From Europe with Love

2011-02-14T11:45:00.000-08:00

The Peoples Republic of California is looking more and more like Europe everyday. In case you missed it: California retailers can't ask patrons for ZIP Codes, court rules.

In reading the story, the courts ruling seems like a noble one -- protect consumer privacy. But I feel this blanket decision totally ignores the rates merchants are charged processing these transaction with vs. without address verification information and all but ignores the security aspect for merchants requiring a ZIP code. To me, a ruling that merchants could not use any information associated with the processing of the payment for marketing or purposes, then it would have been fine. When I saw the headline, it was screaming: "CALIFORNIA WELCOMES ALL SCAMMERS AND FRAUDSTERS WITH OPEN ARMS!"

As to the rate difference, California card-present merchants will need to decide what to do in the event a card cannot be swiped: Don't ask for the ZIP code and accept the higher cost and higher potential for a fraudulent transaction OR ask for another form of payment. My advice with be the latter, but this may not be the optimum advice for all merchants.

The court touched on the security aspect, but it does leave a big hole: "....allows ZIP Codes to be collected under certain circumstances, such as at gas station pumps where the information is requested for security reasons..." -- why wouldn't all merchants fall under this "certain circumstance?"

And then the biggest little line in the entire story: "The court said retailers may still ask consumers to produce a driver's license for identification purposes but may not record the personal information on it." This advice from the courts goes against most (maybe all) merchant agreements. I'm not sure if this was a simple oversight by the courts showing lack of knowledge in payment processing regulations, or if this was an intentional warning shot over the bow of the card brands?

Forced Password Changes - good or bad?

2011-02-09T14:48:00.000-08:00

For years now there has been a debate in the security community as to whether or not users should be forced to change password at regular intervals and if so, how often. On one side there is the argument that changing passwords frequently makes it harder for hackers to acquire a users password and limits the exposure if a hacker were to acquire a user's password. On the other side you have the argument that forcing users to change password increases the chances for forgotten passwords and more dangerous, the chance that users will write down passwords on paper or post-it notes stuck to their monitor or under their keyboard.

I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.

A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:

“PCI DSS 8.5.9 Change user passwords at least every 90 days.

8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.
8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”

“PA-DSS 3.1.4 The payment application requires changes to user passwords at least every 90 days. (aligns with PCI DSS Requirement 8.5.9)”

The 2005 OWASP best practice included the following:

“Passwords are trivially broken and are unsuitable for high value systems. Therefore, ...

Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.”

This tells me that in 2005 the OWASP people were leaning to the side of the first argument. Now, the latest 2010 OWASP states:

“Password Guidelines...

Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely...”

While “frequently” is somewhat vague, I interpret this as OWASP is leaning toward the latter argument now.

The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:

“However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.”

But, these notes appear to have limitations, in the case of PCI DSS:

“The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published...”

and in PA-DSS:

“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”

So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.

I welcome your thoughts.

Beware your inbox!

2010-12-15T17:12:00.000-08:00

I just received the following highly sophisticated virus in my inbox:

DEAR RECEIVER,

You have just received a Taliban virus. Since we are not so technologicaly advanced in Afghanistan, this is a MANUAL virus. Please delete all the files on your hard disk yourself and send this mail to everyone you know.

Thank you very much for helping us.

Thanks & Regards
Miss Helen

Added humor: The originator is so techno challenged that they can't even spell technologically. Then again, maybe this was planned by the originator to make us think he was technologically challenged -- clever...

Is Disco making a comeback?

2010-11-10T11:53:00.000-08:00

I certainly hope not. But there are a few in the payments and POS industries attempting to bring back those glory days of the 80's, when Disco the dance and disco (as in abruptly disconnected) dialup terminals were all the rage. Since my blog primarily focuses on payments and POS related tidbits, I'll leave the return of Disco, as in the dance, to social bloggers.

Let's take a quick tour in history: I remember the 80's, the days when Tranz-330 was stat-of-the-art. The Tranz-380 was the future and bankers and ISOs were giddy -- the sky was the limit, no merchant was too big. (Yes, there were other terminal manufactures at the time, but my experience is in the US marketplace and Tranz represented probably about 80% of the marketplace, quite possibly more.) Then along comes the dreaded 90's, when POS integration corrupts this terminal Utopia. Then the turn of the century when hackers start corrupting the reputation of the POS integration market. To fix this, Visa launches CISP, MasterCard launches SDP, AMEX and Discover launch their programs (sorry, I'm drawing a blank on their acronyms). A few years later, along comes PCI to combine all these programs into a single program and now you're up to date (albeit Cleft Notes of a Reader's Digest version of the payments history).

Of late I have seen POS vendors and ISO's recommending to merchants to abandon integration and install dial-up terminals -- back to the 80's. Some assume that this route removes the merchant from the burdens of PCI compliance. This could not be farther from the truth. All merchants must comply with PCI DSS if they process, transmit or store credit card data -- via terminal or otherwise. My guess is that this misassumption stems from some PCI wording that excludes stand-alone terminals from specific portions of PCI. But it never excluded the merchant from PCI.

Some argue that these devices are not susceptible to viruses, keyboard loggers, Trojans, or other malware -- I argue they are. Malware requires a CPU, an operating system, and communication ports and stand-alone CC terminals have all these requirements. So far the only thing saving these devices from the headlines is the lack of a deviant programmer with nothing better to do from writing some malware.

Enough on malware, the scariest vulnerability with this retro alternative is that most (all that I'm aware of) dial-up modem traffic from these devices to the processor is unencrypted. Insert a sniffer in the mix or update a phone number in the terminal, and the hacker has free flowing unencrypted payment information. To me, a properly secured network transmitting encrypted card information to the processor is less vulnerable to hackers than a dial-up device transmitting unencrypted card information to the same processor (and I totally ignored the other cons of returning to the 80's and using a non-integrated solution).

Is it an Audit or Assessment?

2010-10-20T10:28:00.000-07:00

From time-to-time I see or hear someone getting bent out of shape because another person makes a reference to "PCI audit." Many times the reference is made within a heated debate about the validity of something and this obvious total lack of education opens the door for incorporating into the debate the heredity of the poor sole that mentioned "audit." Well I beg to differ -- it is an audit, not an assessment.

The basis for this mislabeling of the audit process is the title the PCI SSC gave to the auditors -- Qualified Security Assessor (QSA). But as happens often in business, titles do not always match the role.

One of these poor misguided people tried to explain it to me this way: "Assessors do not make judgments as to the validity of something, they are simply documenting and reporting their findings to the PCI SSC whereas auditors make judgments." But QSAs are judging pass or fail for each line item in the PCI DSS or PA-DSS specification and once everything passes based on their opinion, they write up a ROC for PCI SSC's final approval. Based on this definition, QSAs are performing audits.

Then you have the definitions found on Dictionary.com:

Assessment deals with assessing or appraising the value of something. Audit, on the other hand, deals with official examination, inspection or verification of something. Based on these definitions, the Assessor is doing an audit as well.

I know that most people don't care what the "A" in QSA stands for and they care even less whether it's called an audit or assessment. I'm only writing this so I can easily reference my position when someone brings in my heredity into a heated debate.

Can Never Be Too Safe

2010-10-08T13:40:00.000-07:00

This is totally off topic but very funny. Put this in the random thoughts category:

Plaxico Burress On Gun Safety

Gift Card Act of 2009

2010-08-27T15:37:00.000-07:00

With much fanfare, the US House of Representatives and Senate passed the Credit Card Accountability Responsibility and Disclosure Act of 2009. For the average consumer and merchant, the full benefits and ramifications have yet to be felt. One section that was mostly overlooked, was a section that specifically addressed general-use prepaid cards, gift certificates and store gift cards. Here it is:

Credit Card Accountability Responsibility & Disclosure Act of 2009

This is a portion of H.R. 627: Credit Card Accountability Responsibility and Disclosure Act of 2009 that relates specifically to gift cards and the like:

TITLE IV--GIFT CARDS

SEC. 401. GENERAL-USE PREPAID CARDS, GIFT CERTIFICATES, AND STORE GIFT CARDS.

The Electronic Fund Transfer Act (15 U.S.C. 1693 et seq.) is amended--

by redesignating sections 915 through 921 as sections 916 through 922, respectively; and
by inserting after section 914 the following:

SEC. 915. GENERAL-USE PREPAID CARDS, GIFT CERTIFICATES, AND STORE GIFT CARDS.

Definitions- In this section, the following definitions shall apply:
1. DORMANCY FEE; INACTIVITY CHARGE OR FEE- The terms ‘dormancy fee’ and ‘inactivity charge or fee’ mean a fee, charge, or penalty for non-use or inactivity of a gift certificate, store gift card, or general-use prepaid card.
2. GENERAL USE PREPAID CARD, GIFT CERTIFICATE, AND STORE GIFT CARD-
  1. GENERAL-USE PREPAID CARD- The term ‘general-use prepaid card’ means a card or other payment code or device issued by any person that is--
    1. redeemable at multiple, unaffiliated merchants or service providers, or automated teller machines;
    2. issued in a requested amount, whether or not that amount may, at the option of the issuer, be increased in value or reloaded if requested by the holder;
    3. purchased or loaded on a prepaid basis; and
    4. honored, upon presentation, by merchants for goods or services, or at automated teller machines.
  2. GIFT CERTIFICATE- The term ‘gift certificate’ means an electronic promise that is--
    1. redeemable at a single merchant or an affiliated group of merchants that share the same name, mark, or logo;
    2. issued in a specified amount that may not be increased or reloaded;
    3. purchased on a prepaid basis in exchange for payment; and
    4. honored upon presentation by such single merchant or affiliated group of merchants for goods or services.
  3. STORE GIFT CARD- The term ‘store gift card’ means an electronic promise, plastic card, or other payment code or device that is--
    1. redeemable at a single merchant or an affiliated group of merchants that share the same name, mark, or logo;
    2. issued in a specified amount, whether or not that amount may be increased in value or reloaded at the request of the holder;
    3. purchased on a prepaid basis in exchange for payment; and
    4. honored upon presentation by such single merchant or affiliated group of merchants for goods or services.
  4. EXCLUSIONS- The terms ‘general-use prepaid card’, ‘gift certificate’, and ‘store gift card’ do not include an electronic promise, plastic card, or payment code or device that is--
    1. used solely for telephone services;
    2. reloadable and not marketed or labeled as a gift card or gift certificate;
    3. a loyalty, award, or promotional gift card, as defined by the Board;
    4. not marketed to the general public;
    5. issued in paper form only (including for tickets and events); or
    6. redeemable solely for admission to events or venues at a particular location or group of affiliated locations, which may also include services or goods obtainable--
      1. at the event or venue after admission; or
      2. in conjunction with admission to such events or venues, at specific locations affiliated with and in geographic proximity to the event or venue.
3. SERVICE FEE-
  1. IN GENERAL- The term ‘service fee’ means a periodic fee, charge, or penalty for holding or use of a gift certificate, store gift card, or general-use prepaid card.
  2. EXCLUSION- With respect to a general-use prepaid card, the term ‘service fee’ does not include a one-time initial issuance fee.
Prohibition on Imposition of Fees or Charges-
1. IN GENERAL- Except as provided under paragraphs (2) through (4), it shall be unlawful for any person to impose a dormancy fee, an inactivity charge or fee, or a service fee with respect to a gift certificate, store gift card, or general-use prepaid card.
2. EXCEPTIONS- A dormancy fee, inactivity charge or fee, or service fee may be charged with respect to a gift certificate, store gift card, or general-use prepaid card, if--
  1. there has been no activity with respect to the certificate or card in the 12-month period ending on the date on which the charge or fee is imposed;
  2. the disclosure requirements of paragraph (3) have been met;
  3. not more than one fee may be charged in any given month; and
  4. any additional requirements that the Board may establish through rulemaking under subsection (d) have been met.
3. DISCLOSURE REQUIREMENTS- The disclosure requirements of this paragraph are met if--
  1. the gift certificate, store gift card, or general-use prepaid card clearly and conspicuously states--
    1. that a dormancy fee, inactivity charge or fee, or service fee may be charged;
    2. the amount of such fee or charge;
    3. how often such fee or charge may be assessed; and
    4. that such fee or charge may be assessed for inactivity; and
  2. the issuer or vendor of such certificate or card informs the purchaser of such charge or fee before such certificate or card is purchased, regardless of whether the certificate or card is purchased in person, over the Internet, or by telephone.
4. EXCLUSION- The prohibition under paragraph (1) shall not apply to any gift certificate--
  1. that is distributed pursuant to an award, loyalty, or promotional program, as defined by the Board; and
  2. with respect to which, there is no money or other value exchanged.
Prohibition on Sale of Gift Cards With Expiration Dates-
1. IN GENERAL- Except as provided under paragraph (2), it shall be unlawful for any person to sell or issue a gift certificate, store gift card, or general-use prepaid card that is subject to an expiration date.
2. EXCEPTIONS- A gift certificate, store gift card, or general-use prepaid card may contain an expiration date if--
  1. the expiration date is not earlier than 5 years after the date on which the gift certificate was issued, or the date on which card funds were last loaded to a store gift card or general-use prepaid card; and
  2. the terms of expiration are clearly and conspicuously stated.
Additional Rulemaking-
1. IN GENERAL- The Board shall--
  1. prescribe regulations to carry out this section, in addition to any other rules or regulations required by this title, including such additional requirements as appropriate relating to the amount of dormancy fees, inactivity charges or fees, or service fees that may be assessed and the amount of remaining value of a gift certificate, store gift card, or general-use prepaid card below which such charges or fees may be assessed; and
  2. shall determine the extent to which the individual definitions and provisions of the Electronic Fund Transfer Act or Regulation E should apply to general-use prepaid cards, gift certificates, and store gift cards.
2. CONSULTATION- In prescribing regulations under this subsection, the Board shall consult with the Federal Trade Commission.
3. TIMING; EFFECTIVE DATE- The regulations required by this subsection shall be issued in final form not later than 9 months after the date of enactment of the Credit CARD Act of 2009.’

SEC. 402. RELATION TO STATE LAWS.

Section 920 of the Electronic Fund Transfer Act (as redesignated by this title) is amended by inserting ‘dormancy fees, inactivity charges or fees, service fees, or expiration dates of gift certificates, store gift cards, or general-use prepaid cards,’ after ‘electronic fund transfers,’.

SEC. 403. EFFECTIVE DATE.

This title and the amendments made by this title shall become effective 15 months after the date of enactment of this Act.

A complete summary and full text of the entire H.R. 627: Credit Card Accountability Responsibility and Disclosure Act of 2009 can be found at http://www.govtrack.us/congress/bill.xpd?bill=h111-627.

The Steve Sommers' Readers Digest version of the federal law is as follows:

If you use expiration dates with your gift cards:
1. the expiration term cannot be less than 5 years from the time of purchase or last recharge; and
2. you must fully disclose the expiration date policy on the card and inform the purchaser prior to the purchase of the gift card.
If you charge service fees to your gift cards:
1. you cannot charge more than a single fee per month (for most merchants, no big deal),
2. the fees can only be charged after one year of dormancy; and
3. you must fully disclose the fees on the card and inform the purchaser prior to the purchase of the gift card.

If you are using gift certificates instead of gift cards, reread my above summary substituting “certificate” every place I mention “card.”

Now a possible gotcha here is the term dormancy -- the law states “there has been no activity with respect to the certificate or card in the 12-month period ending on the date on which the charge or fee is imposed.” Nowhere do I see a definition of “activity.” I know that California considers a balance inquiry as activity; other state only consider adding funds or purchase usage as activity. I'm sure we'll be hearing about this in court.

My recommendation: Don't use card expiration dates and instead charge a monthly service fee sometime after one year of dormancy. To be safe, I would interpret dormancy as any activity including balance inquiries.

I've always recommended not using expiration dates because many states have laws that "expired funds" are to be turned over to the state. Also, some states like California do not allow merchants to use expiration dates. If you still want to use expiration dates, I recommendation would be to not allow recharging the cards as each recharge will add a minimum of five years to the expiration date of the card.

In either case, fully document and prominently display your terms to the purchaser prior to selling the gift card. Any and all card carriers and displays should have the terms. Your web site should have a dedicated gift card page with the terms and conditions and your card stock or gift certificates should have the URL printed on it. The more places you disclose this information, the better. You don't want to be on the receiving end of a “they didn't warn me” accusation.

This Readers Digest version and recommendation, for the most part, only considers this specific federal law. You will need to incorporate any state or local laws that also apply. On the ConsumersUnion.org I did find a summary of various state laws regarding gift cards I thought useful: State Gift Card Protection Laws

Hope this info helps someone.

Side Rant - Formatting
I'm hoping that the topic numbering scheme used in this Act was simply a translation screw-up between the source where I found the document and the real document. Otherwise, someone in our government doesn't know how to follow a numbering standard. I was taught the Harvard format which I assume is the standard since most documents I read follow the same or very similar format:

Topic
1. Subtopic
  1. Major Detail
    1. Minor Detail
      1. Subdetail

Whereas this document is using the following:

Topic
1. Subtopic
  1. Major Detail
    1. Minor Detail

Maybe this is some standard attorney format to separate common language from lawyer speak? Or just is this part of the change we were promised?

Au Contraire - Latest Gotcha from PCI SSC

2010-07-29T17:46:00.000-07:00

Several month back many forums and blogs were discussing the (at that time) up and coming July 2010 sunset of Windows 2000. Many of these discussions included other already sunsetted operating systems. There were some heated debates over whether or not proper lock-down and compensating controls could keep a merchant compliant. Most of these discussions were settled by a posting in the PCI SCC FAQs:

PCI SSC FAQ

Would older operating systems that are no longer supported by the vendor be deemed non-compliant with the PCI DSS?

Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance. Compensating controls could address risks posed by using older operating systems. Exploit of legacy code is the main risk posed by an older operating system. Since well-known exploits are typically included as signatures to anti-virus, IDS/IPS and firewall filtering, a compensating control to consider is performing an exhaustive search to ensure that all known exploits for that operating system are identified, and that anti-virus, IDS/IPS and firewall rules are all updated to address those exploits. Other compensating controls could include monitoring IDS/IPS and firewall logs more frequently than required (for example, the requirement is for daily log reviews, so more frequently may be continuously and automated), or isolating and segmenting their POS systems via firewalls from the Internet and other systems in the cardholder data environment. The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so. For more help with compensating controls, and for questions about whether a specific implementation is consistent with the standard or is 'compliant', please contact a Qualified Security Assessor.

Fast forward to today. Now, for many merchants and vendors, comes the first Windows 2000 post sunset scan from a prominent ASV - FAIL. Reason given: One or more scanned servers determined to be running Windows 2000. Upon referring this prominent ASV to the above FAQ on the PCI DSS site, they refer to the Technical and Operational Requirements for Approved Scanning Vendors (ASVs) on the same PCI DSS site:

Technical and Operational Requirements for ASVs

Obsolete environment

The ASV must report and determine as non-compliant any identified obsolete software (for example, application software or operating systems (OSs) no longer supported by the respective manufacturers. Obsolete software may expose the infrastructure to a security-related vulnerability.

The FAQ that many merchants and vendors use takes a risk assessment perspective whereas the Operating Requirements for ASVs takes a MUCH harsher authoritarian perspective -- "FAILED!" It's no wonder there is still so much confusion about PCI even after years educating the masses about PCI; people are still just as confused and pulling their hair out. I sure hope PCI SSC irons this one out quick.

An interesting side note is the wording of the Operating Requirements for ASVs: "Obsolete software may expose the infrastructure to a security-related vulnerability," yet PCI has deemed it non-compliant -- so is it vulnerable or not? If not, why is it not compliant? But this is straining at gnats -- the bigger issue is assuring people that obsolete O/Ss are not necessarily out-of-compliance while telling ASVs that obsolete O/Ss must be deemed out-of-compliance.

If you read any of my previous posts, I always harp on lowering your risk profile by eliminating card holder data from your environment. This emphasizes my belief that if you suffer a breach of card holder data, you will be found out-of-compliance no matter how compliant you thought you were. Using this as an example, if you were using Windows 2000 (post sunset) in your payment environment and your PCI assessment was based on the PCI SSC FAQ, the ASV document would deem you out-of-compliance.

Pondering the Possibilities

2010-05-25T12:22:00.001-07:00

Currently the PCI SSC is pondering the possibility of including language that would exclude encrypted cardholder data from the merchants PCI scope if, and only if, the merchant does not have access to the encryption keys used in the process. This is to make it easier for end-to-end encryption (E2EE) solution providers to promote their wares. Security wise, I think this would be a mistake.

I've argued many times on different forums about how tokens (provided they are "true" tokens that are not derived from the PAN) and tokenization are more secure than E2EE data -- format preserving or otherwise. E2EE proponents almost always quotes some report that states a brute force attack on the encrypted data will take umpteen million years of CPU time to crack. There are a few problems with this argument. For starters, I imagine similar arguments were being made back in the single DES days; but then CPU speeds increased exponentially and umpteen million years of CPU time became months, then weeks, then days, and eventually minutes. Another issue is the potential for a yet to be discovered inherent vulnerability in the encryption algorithm or key hashing; SSL1 comes to mind, as well as MD5.

A final issue with the "umpteen million years to crack " argument is that this assumes a brute force attack. If the key is ever compromised by any means -- yes, a brute force attack is one means, but also poor key storage, memory sniffers, disgruntled ex-employee, etc. -- the encrypted data is vulnerable.

Ponder this:

PCI SSC adopts some form of language that removes E2EE data from PCI scope.
One or more middle men handle this E2EE data between the starting end point and the final end point: POS application, merchant LAN, Internet service provider, routers, gateway, processor(assuming the gateway is not the end point), etc.
One or more of these middle men log all this E2EE data in the clear -- since E2EE data is already encrypted, this data is out of PCI scope and therefore has no requirement for additional encryption, data retention periods, etc.
Everything works securely and flawlessly for weeks, months or years.
The E2EE key is compromised by whatever means (brute force, encryption algorithm vulnerability, disgruntled employee, whatever).

While the key was cracked or acquired outside the scope of the merchant, how will this play out for the merchant or any of the middle men in #2 above if it is determined that the source of the breached data was the logs containing the out-of-scope E2EE data?

Now with true tokenization, tokens cannot be cracked; no keys, no possibility of inherent tokenization algorithm vulnerability (assuming true tokenization where the token is not derived PAN). Any middle men storing or logging tokens could and should be removed from the liability equation provided they never touched the real cardholder data.

I hope the PCI SSC carefully consider this issue in it's entirety before adding any out-of-scope wording for encrypted data.

You found me!

2010-03-19T17:01:00.000-07:00

Congratulations, you found me!

For any new viewers, I recently moved from shift4sms.blogspot.com to here, paymenttidbits.blogspot.com.

Stand Up and Be Heard

2010-03-19T09:14:00.000-07:00

While not directly "payments related," this is something that affects all industries. Don't let the bad guys win. Stand up and let your voice be heard. In November, vote out the corruption -- from both parties.

If your politicians believe they are smarted than the people they supposedly represent - then stand up and let them know how naive¹ they really are. If your politicians believe processes defined in the Constitution are only there as barriers for the unimaginative - then voice your concern. If your politicians believe ramming things through by any means, including bribes, kick backs, favors, arm twisting, threats of prosecution - then vote them out in November. If your politicians believe that the national debit is someone else's problem so spend while the spending is good - then definitely let them know now and vote them out in November.

Lastly, if you think that government is the solution for all problems and the free stuff politicians are promising to provide is truly free, then stay at home on election day - because nothing is truly free. As the famous quote goes: "Government is not the solution to our problem; government is the problem."

¹ Ongoing theme from a previous thread; but this time I am mean the www.dictionary.com definition.

Hitler and Cloud Computing Security

2010-03-04T09:09:00.000-08:00

Ok. I found this You Tube video via a post on Evan Schuman's StorefrontBacktalk blog which was found via a post on Bruce Schneier's blog which was found via who knows. Anyway, it's funny and a must see -- if you're a Internet nerd/junky like me:

Hitler and Cloud Computing Security

Security Hole -- Coming to a store near you!

2010-02-16T13:29:00.000-08:00

Over the last few years Cambridge University has uncovered a few weaknesses in the EMV technology (a.k.a. Chip & PIN). Just recently they uncovered the biggest flaw yet: EMV is susceptible to a man-in-the-middle attack.

The BBC story can be found here along with a video showing the vulnerability in action: http://www.bbc.co.uk/blogs/newsnight/susanwatts/2010/02/new_flaws_in_chip_and_pin_syst.html

This latest vulnerability appears to be a devastating blow to the primary supporters of the technology -- the banks. Banks are always keeping an eye out for shifting liability from the banks, to, well anyone but the banks. Chip & PIN was the perfect vehicle for this liability shift. Virtually overnight (relative term, overnight in bank time is a 4-8 years in real time) the banks in Europe shifted fraud liability from them to the card holder or the merchant, depending on whether or not the merchant used EMV technology.

After some consumer complaints, bank regulators put some of the liability burden back onto the banks, at least requiring them to provide some proof in the event of a cardholder report of fraud. Now with this latest man-in-the-middle vulnerability, it appears that the liability is firmly back onto the banks.

Most likely a patch will be found for the latest vulnerability, but at what cost to the merchant? They just spent a big chunk of change when they were forced to upgrade to EMV. What will the fix cost them and how long will they have to implement the fix? Canada is currently in the process of forcing their merchants to implement EMV technology. How will this affect the rollout? All big unknowns.

Round 3, Tokenization vs. End-to-End Encryption

2010-02-12T16:57:00.000-08:00

Before I get started, a disclaimer. I am a firm believer in a layered security approach. I have said several times, end-to-end encryption (E2EE) has a very important roll in the "optimum" payment security environment. E2EE, by itself, is not a silver bullet. Similarly, tokenization, by itself, is not a silver bullet either. However, if for some reason you are evaluating tokenization OR E2EE, I argue that a properly implemented front-end tokenization solution will reap more rewards than an equivalent E2EE solution.

Round 1: Tokenization enters the payment space. Shift4 releases tokenization to the public domain in October 2005. Initial document described back-end tokenization to address data storage. Since that time, technology has evolved to include front-end tokenization, which addresses data in flight as well as storage.

Round 2: End-to-End Encryption enters the payment space. In March 2008, VeriFone announces it joint end-to-end solution with Semtek. In June 2009, Heartland Payment Systems announces its entry into the E2EE arena with Voltage and E2EE, at least how we know it in the payments space is born.

Round 3: End-to-End proponents lobby PCI to deem E2EE data out-of-scope for PCI, similar to tokens. Recently PCI SSC appears to have conceded in a FAQ entry: "However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it." I believe security wise, this is a mistake and this is an example where "security" and "compliance" go separate routes.

So we are all on the same page, let me first briefly explain the difference between tokens and encrypted data. True tokens (I specify "true" because some tokenization vendors do not follow the definition of token) are not derived from the data it is protecting. A true token is simply a reference to the card data that is stored within a fully PCI compliant system. The token can be a sequential number (1=first card number swiped, 2=second card number, etc.), or it can be a time stamp, a random number, or any combination. The key is that the token is in no way derived from the card number and instead is only a reference to the card information.

Encrypted data, on the other hand, is directly derived from the original data – the card number. A key is used to encrypt the data, and either the same shared key or a related public/private key is used to decrypt the data. What keeps the data safe is the strength of the encryption method used, and the keys themselves. If the keys are ever compromised, the data is no longer safe.

The issue for me here is the decree from PCI SSC, "encrypted data may be out-of-scope." Many will read this statement and a light bulb will pop on: "silver bullet!" This type of thinking can be detrimental to the overall security risk of the card holder data.
Encrypted data can always be decrypted. Whenever I mention this, it triggers an immediate response from various encryption experts about how brute force attacks will take hundreds to billions of years to crack based on today’s technology. Maybe true, if you are only talking about brute force attacks and ignore any possibility of a encryption algorithm weakness (MD5 comes to mind). Also, a brute force attack is not the easiest way to get an encryption key. Key storage and key management are the weakest points of most encryption solutions. My point is, if the key is ever compromised by any means, the encrypted data can be decrypted and is therefore vulnerable.

Now we go back and look at how PCI SSC’s decree affects security. If E2EE data is out of scope, this information can be stored, logged and freely distributed – after all it is out-of-scope. Does this sound secure – especially if you consider encrypted data can always be decrypted?

One aspect where the jury might still be out: Will the card brands take the same stance? If and when this out-of-scope data is ever compromised, this stance would in effect be a safe harbor clause; the card brands have avoided safe harbor clauses for merchants like the plague. Breach equals fine and I don't see the card brands honoring any out-of-scope decree from PCI SSC as a safe harbor.

As I stated in the beginning, a layered security approach is the best. If it’s a one or the other decision, you know my recommendation. If you decide to go the E2EE route, my recommendation would be to ignore PCI SSC in this case and instead treat E2EE data as in-scope.

Until next time…

What a Rip!

2010-02-02T12:37:00.000-08:00

For the most part, you can file this post in the who cares category -- Steve is just being a cry baby -- but I thought I would take a break from ticking off POS vendors, and instead tick off a competitor. If you don't have time to waste reading non-important stuff, simply come back later and I'll be sure to have a more important topic posted. Notice the byline above, "random thoughts" and "simply vent" -- this qualifies for both.

Do you ever get that feeling you're being watched? Not watched as in big brother is watching (but come to think of it, I think they are!). But more watched like in a little Chihuahua staring at you from the ground below while you are eating. But then the little rodent gets impatient, it tries whatever it can to either get your attention, or better yet, distract you in the hopes you drop some crumbs it's way.

I get that feeling with one of Shift4's competitors, X-Charge by CAM Commerce Solutions. In the past they have covertly hired employees from Shift4 -- not for their technical skills, sales prowess, or expertise, but simply for their knowledge of trade secrets and customer lists (it's strange, how these ex's move on after their information ceases to be relevant due to time). Imagine my surprise when Shift4's marketing director sends me a link to their site and now the covert is actions have switched to overt actions by ripping content straight from Shift4's site and putting it onto their site. But I'm not talking features and benefits, or even catchy phrases or graphics; ripping off stuff like this is far too often common on the Internet. No, they rip partner lists for republication and don't even have the time to reorder them or remove little asterisks that signify something on Shift4's site but not on theirs. Talk about "me too" marketing!

Shift4: http://www.shift4.com/pos_pms.htm
X-Charge: http://www.x-charge.com/products/listHospitality.asp (cut & paste the URL yourself, I don't want to give them the benefit of a search engine boost)

Some interesting points of fact, many of the partners listed on both sites have exclusive partner arrangements with Shift4. Several listed are custom interfaces that only interface to Shift4's DOLLARS ON THE NET. Some listed are no longer in business and are only listed on Shift4's site because there are customers still using the applications. Lastly, if you were to call most of the vendors on the list you'll find they never heard of X-Charge and will confirm there is no existing interface. If you call CAM Commerce, they will most likely tell you that they will work with any of the vendors listed (as opposed to they currently work with the vendors).

In a prior post, I prematurely used labeled a vendor as "unscrupulous" without considering all the possibilities for the vendor's action. In this case I don't think I would be out of line using this word -- I think this vendor is unscrupulous (not to mention lazy). If you are in the market for a payment gateway, you may want to cross these guys off your list.

Merchants beware when shopping for something as important as a payment gateway provider. If the provider gives references or lists interfaces, do some fact checking for yourself. Call some and if facts don't agree, dump them. Beware of weasel words, or more importantly, discrepancies in phrases like "we work with" vs. "we will work with." Make sure what salesmen tell you verbally or via email agree with the information on their site, "we work" vs. "we will work" is a big red flag. Make sure any reference list is their reference list. Good luck.

POS Ending Event - Redux II

2010-01-27T13:10:00.000-08:00

In my prior POS Ending Event posting and it's Redux, some read them as a vilification of a POS vendor. The intent of the posts were to warn merchants that they need to do their own research and just because materials reference PCI does not make it fact. In the original post I used one vendor's letter as an example and some interpreted this as an attack on this vendor as opposed to this is something vendors, or marketing departments sometimes do. I gave some reasons for this but even my reasons were misinterpreted as "stupid vendor."

Apparently I was naive in that my definition of naive was wrong. My understanding of naive was "an innocent misunderstanding or innocently believing incorrect information." In referencing dictionary.reference.com, their closest definition is "having or showing a lack of experience, judgment, or information" -- well, now I've really stepped in it as that was not my intention. Sorry. Someday I hope to have this English stuff down.

Anyway, I'm hearing second hand that this particular vendor has written proof from PCI SSC that clearly states that "they (PCI SSC) will immediately deem any products that only operate on an O/S that is no longer supported by the O/S vendor as non compliant." I'm also told this was backed up by one of the major card brands and the vendor's QSA.

I'm hoping to get a copy of this letter because if so, this changes everything. I can see an incorrect interpretation by a QSA, after all, this was the seed that started me on this topic. I can also see one of the major card brands stating something like this -- these are huge organizations and many times you'll get a variety of answers based on who you happen to ask. But PCI SSC?! If this is what they are telling their members and QSA's, then this is a real POS Ending Event and this vendor is simply an innocent victim of PCI. Stay tuned...

POS Ending Event - Redux

2010-01-25T11:07:00.000-08:00

Over the weekend I received several emails on my prior blog entry, POS Ending Event - July 1, 2010!!! Based on the response, this posting appears to be my most popular thus far. Most were favorable and many had guesses: "was it this vendor or that vendor because I have received similar letters." An interesting point is that of all the guesses, none guessed the vendor that I used in my example. This confirms my belief that marketing campaigns like this one are as wide-spread as I thought.

The vendor who I used as the example also contacted me and in hind sight, I may have been a little harsh in use of the word "unscrupulous." Instead, what I should have said was that letters like this could be the result of either unscrupulous, ill-advised, or simply naive marketing departments with a cursory knowledge of PCI. Heck, I've had to do some postmortem clean-up after some naive statements from a prior marketing department of my company, and I would not have classified their intent as unscrupulous. Anyway, the intent of Friday's post was not to finger point to one particular vendor as there are many in the same situation. The real intent was to make merchants aware of some of the misconceptions that plague PCI.

The reason for my ire last Friday dealt with this exact same topic. We (the company I work for) were having several days of debate with a QSA (again, who shall remain anonymous) about the July 1, 2010 patch cutoff date by Microsoft. The QSA's corporate party line was that as of 7/1/2010, Windows 2000 will no longer be compliant under PCI. We obviously did not agree and didn't know if they realized the scope or magnitude of their interpretation: A majority of the POS merchants are currently out-of-compliance because there are many POS applications running on non-current operating systems: old Unix, old Linux, old Windows. I would venture to guess that a large percentage of existing firewalls use old o/s as well and would also be deemed out-of-compliance based on this same interpretation. On 7/1/2010 another huge segment of merchants would be out-of-compliance overnight as Microsoft stops patching Windows 2000. Take all those pats on the back that the cards brands and PCI-SSC have been giving themselves about industry wide PCI acceptance and compliance percentages and throw them out the window. After several to and fro emails and walking up the chain of command, using the same references given in my post, we finally got our point across. At the end of this, I felt I had to write something about this experience and this vendor's letter happened to be within my reach. I apologize if my posting came across as anti-XYZ vendor.

As I ended my last post, do your research. The correct information is out there. With Friday's example, the information was not all that hard to find.

POS Ending Event -- July 1, 2010!!!

2010-01-22T14:05:00.000-08:00

"Effective July 1, 2010, Microsoft will discontinue their support of the Windows 2000 operating system. The Payment Card Industry Payment Application Data Security Standard (PA-DSS) requires all components of the payment processing system to be supported by the vendors with security updates. Therefore, effective July 1, 2010, any payment processing products operating only on the Windows 2000 operating system will become non-compliant with the terms of PA-DSS.

"Merchants who are processing, storing or transmitting cardholder data as part of authorization or settlement are required to comply with the terms of the Payment Card Industry Data Security Standard (PCI-DSS). The PCI-DSS requires Merchants to use only PA-DSS compliant payment processing applications. Therefore, any Merchants using a payment processing application that is not PA-DSS compliant are also not PCI-DSS compliant. Any Merchants who are compromised and found not to be PCI-DSS compliant at the time could be subject to significant fines and penalties by the Cardholder Industry. For more information on the PA-DSS, please refer to the following link on the Payment Card Industry Security Standards Council (PCI-SSC) web site: https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml. For more information on the PCI-DSS, please refer to the following link on the Payment Card Industry Security Standards Council (PCI-SSC) web site: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml."

Holy crap Batman, is this saying what I think it is saying? All point-of-sale applications running on older non-current operating systems out of compliance! Think of the scope: All POS's running on Windows 2000 as of 7/1/2010, all applications running on prior version of Windows are already out of compliance. Come to think of it, the requirement does not mention Windows specifically; the scope is even bigger: All POS's running on various older Unix flavors, PIC O/S, even older Mac O/S (albeit, I'm not aware of any POS running on Mac O/S).

The above quote was from a POS vendor's letter to it's merchants. It is blunt, to the point, and details dire consequences of being out of compliance when Microsoft stops patching Windows 2000. The problem is, it's crap and nothing more than a FUD marketing campaign. To prove my point, let's refer to the documents that this vendor referenced. The PA-DSS document states the following on page iv under the section "Scope of PA-DSS":

The following list, while not all inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not need to undergo PA-DSS reviews):

Operating systems onto which a payment application is installed (for example, Windows, Unix)
Database systems that store cardholder data (for example, Oracle)
Back-office systems that store cardholder data (for example, for reporting or customer service purposes)

Hmm, operating systems are specifically stated as "out of scope" for PA-DSS compliance purposes. Let's continue this expedition and look at PCI-DSS:

6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.

6.1.a For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security patch list, to verify that current vendor patches are installed.

6.1.b Examine policies related to security patch installation to verify they require installation of all critical new security patches within one month.

A little vague -- "latest vendor-supplied security patches." If a vendor is no longer supplying patches, as long as you have the latest patch, aren't you compliant? I'm so confused. Let's check the PCI-SSC web site for clarification. On the web site we find a FAQ:

Would older operating systems that are no longer supported by the vendor be deemed non-compliant with the PCI DSS?

Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance. Compensating controls could address risks posed by using older operating systems. Exploit of legacy code is the main risk posed by an older operating system. Since well-known exploits are typically included as signatures to anti-virus, IDS/IPS and firewall filtering, a compensating control to consider is performing an exhaustive search to ensure that all known exploits for that operating system are identified, and that anti-virus, IDS/IPS and firewall rules are all updated to address those exploits. Other compensating controls could include monitoring IDS/IPS and firewall logs more frequently than required (for example, the requirement is for daily log reviews, so more frequently may be continuously and automated), or isolating and segmenting their POS systems via firewalls from the Internet and other systems in the cardholder data environment. The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so. For more help with compensating controls, and for questions about whether a specific implementation is consistent with the standard or is 'compliant', please contact a Qualified Security Assessor.

So PCI-SSC states specifically that unsupported operating systems are not automatically deemed out of compliance. In other words, this vendor letter is nothing more than a FUD marketing letter designed to scare merchants into upgrading to the latest version of the vendors software and paying the associated fees.

This is an excellent example of what some unscrupulous, ill-advised, or naive marketing departments do to generate revenue. What makes this even more disturbing is that this vendor, who's name shall remain anonymous, sits on the PCI board -- It's no wonder that there is so much confusion about PCI and why so many merchants cringe at mere utterance of those three letters. While here I zeroed in on one vendor's letter, this vendor is not unique as I've seen several.

To merchants that receive letters like this from their POS vendor: Do some research. Talk to you a QSA if you're unsure. A little research time may save you thousands of dollars.

¹Correction -- see follow-up post POS Ending Event - Redux.

Yet Another Conflict in the PCI World

2010-01-21T12:31:00.000-08:00

I'm really getting tired of all the conflicts in the world; there are conflicts everywhere. But there is one that does not get much press attention. You don't hear about this on Fox News, CNN or other media outlets, at least not yet. It's a secret conflict that for the most part, only has one side! Huh? you ask. How can a conflict only have one side? Well here is the latest conflict I am referring to: Trustwave acquires BitArmor. The conflict? Interest -- QSA's selling security solutions.

Thus far, the PCI Security Council has all but ignored the conflict of interest in QSA's selling security wares. I predict that this will eventually give PCI a big black eye. If I'm not mistaken, wasn't it similar conflicts that toppled Enron and WorldCom -- CPA's auditing the books as well as maintaining the books? I don't see much of a difference in this example with CPA's vs. QSA's for auditing security compliance while providing the security services and solutions being used.

My prediction is that these conflicts will make headlines in the near future. I have to imagine that if Heartland or TJ-Max were not only stamped as PCI compliant by their QSA, but were also relying on their QSA's products or services to become compliant, that this little conflict of interest would gained as much attention as the breach itself.

What went wrong with First Data?

2009-12-31T11:55:00.000-08:00

There is an interesting article in TheDeal.com, "What went wrong with First Data?"

Under the challenges that First Data faces, one BIG challenge that was not addressed in the article is that First Data definitely falls under the current administrations definition of "Too big to fail." While absolute numbers aren't published, an estimated 50-65% of all US credit and debit card transactions go through a First Data host somewhere along the line. To me, power hungry politicians stepping in and taking over First Data in their "challenging time" makes all the other challenges moot.

Anyone else have thoughts on this topic -- even just to tell me I'm a paranoid schizophrenic?

Heartland Lawsuit Dismissed - Secure Enough

2009-12-10T09:57:00.000-08:00

A lawsuit initiated by shareholders against Heartland Payment Systems was dismissed on Monday. The judge ruled that the plaintiffs didn't prove their case that Heartland lied about their security measures that were in place. The story can be found on the StorefrontBacktalk blog "Heartland Lawsuit Dismissed, 'Insufficient Evidence' Of Weak Security."

There is a very interesting quote by the judge on the third page of this article: "The fact that a company has suffered a security breach does not demonstrate that the company did not ‘place significant emphasis on maintaining a high level of security.’ It is equally plausible that Heartland did place a high emphasis on security but that the Company’s security systems were nonetheless overcome..." Juxtapose this statement to comments from Adrian Phillips, Visa International’s Deputy Chief Enterprise Risk Officer and Regional Head of Risk for North America: "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." I go further in stating that when push comes to shove, in one way or another, all breaches will be found to be compliance failures. Not because companies are ignoring PCI, but because the fact that PCI is so all-encompassing that it's impossible to be in compliance 100% of the time. Hackers are like terrorist in the fact that hackers only need to be successful one time whereas merchants need to be secure 100% of the time.

The reason I found this interesting is that it appears that the judge in this case is distinguishing between security and compliance, and rightfully so. I think "best effort" is what is missing with PCI, at least in terms of compliance. There should be some "best effort" allowances otherwise some unscrupulous stakeholders in the industry will view PCI as nothing more than a revenue generation scheme upon a breach (a breach, cool, free money!). Unfortunately, I think there are some in the industry already treating breaches this way.

Now that there is precedence separating security from compliance, will this change the landscape? Or will it just change the wording of the plaintiff's complaints; instead of "did not do all they could to be secure," you might see "did not do all they could to be compliant."

Go Carr

2009-12-01T12:13:00.000-08:00

I've not always agreed with Heartland Payment System's CEO Bob Carr but in a recent article that appeared on Bank Technology News (The End of the World), Carr mentions with disdain that vendors (referencing payment gateways, banks, payment processors, possibly even POS providers) want to charge merchants additional fees for encryption services; "First Data says it thinks encryption technology should demand a higher price point." To me, this would be a disgusting practice and I fully agree with Carr's distain. Providers that handle credit card data MUST handle it securely and charging merchants additional fees as though it's a luxury is despicable.

Bottom line, whatever solutions you choose, make sure your vendors are not charging additional fees for the luxury of securely handling cardholder data.

Your encryption sucks - here, use mine

2009-11-02T12:41:00.000-08:00

I just read an amusing article on SearchSecurity.com: Heartland CIO is critical of First Data's credit card tokenization plan. In this article, Steven Elefant claims front-end tokenization solutions are less secure than end-to-end encryption solutions because front-end tokenization solutions depend on encryption. Huh? "Front-end tokenization, where you take a credit card number and send it up to a token server and then send it back to the terminal, is not good because you are totally exposed from the time you swipe the card until it gets to the token server," Elefant said in an interview with SearchSecurity.com. "If you are not encrypting with very strong crypto and hardware, you don't have security." I like the idea of end-to-end but let’s get some perspective. The end-to-end encryption technology that Elefant endorses uses unproven "hidden" or "format preserving" encryption. Could this be the case of the pot calling the kettle black?

If you're reading this trying to decide on end-to-end vs. front-end tokenization, here are some things to consider. Security should be thought of as layers. A solution that provides or allows for overlapping of end-to-end and tokenization would be the best approach. In lieu of that, true tokens (where the token value is in no way related to the card number other than as a reference) are not considered cardholder data and are not in scope of PCI whereas encrypted cardholder data is still considered cardholder data. Tokenization solutions may be adjusted to allow for repeatability (depending on provider) whereas end-to-end cannot and should not be able to provide repeatability – this comes into play when presenting recurring transactions are using cardholder data for loyalty lookups or risk analysis. End-to-end, in most cases, can work better in remote offline locations whereas most tokenization solutions require online access (but Shift4 does provide offline tokenization capabilities). Most end-to-end solutions use a "keys-to-the-kingdom" approach and therefore require tamper resistant hardware security modules; if these keys are ever breached, all the systems that store this "encrypted" data are vulnerable whereas true tokens are useless even if the token generation logic is known to the world.

PCI SSC Community Meeting and Emerging Technologies

2009-09-24T18:06:00.000-07:00

The PCI SSC Community Meeting just concluded. I only attended one of the three days and that was enough for me. I fully admit I have a lot of nerd like tendencies, but apparently not enough to make a three day event on security exciting. To me, there were four highlights: the food did not kill anyone, the cocktail event was hosted, Bob Russo does a decent Elvis, and the Emerging Technologies session.

Highlights 1, 2 & 3, I'll just leave it at that. If you want more details, I urge you to attend the next community meeting.

The Emerging Technologies session had several points of interest but it left me wanting more. In a nutshell, PCI SSC contracted PricewaterhouseCoopers (PwC) to evaluate and create a report on emerging technologies and how they impact PCI. The summary given at this meeting was a 100,000 foot view of various emerging technologies – yes, 100,000 foot view, not the more common 50,000 foot view. While they made it a point that the report in no way endorsed any one technology and the report was not intended to rate the technologies, they did detail the four most popular technologies: End-to-End Encryption, Tokenization, Virtual Terminal, and Magnetic Swipe Authentication.

Magnetic Swipe Authentication technologies address card present fraud, but do not really address any PCI security or scoping issues so I'll skip that one. The other three; yeah and it's about time! While I don't agree with some details of the how they rated cost vs. reward vs. impact in different categories, I gave PwC a little leeway because they were bundling multiple vendor solutions into fairly broad categories.

The only category rating that really stuck out like a sore thumb was the business impact of end-to-end encryption vs. tokenization – they gave end-to-end a less business impact rating (more favorable) than tokenization. Shift4 provides solutions that straddle all three technologies (end-to-end, tokenization, and virtual terminal) and from experience, tokenization has far less impact to the business flow than end-to-end. Reason being, the merchant systems never have access to the card number. While security wise, this is a plus for end-to-end, business impact wise there are a lot of gotchas. One example is that many risk and customer loyalty systems use the card number (or more preferably, a hash of the card number) as a key to look up the customer. Stronger forms of encryption produce non-repeatable results when the same information is encrypted so this simple process of a customer lookup becomes problematic.

All in all, just the fact that the PCI SSC is seriously looking at these emerging technologies is promising whereas heretofore, they have always brushed this off as a risk/compliance judgment call for the acquiring banks. I can't wait to see what PCI SSC does with this information and I hope they publish the PwC report.

I will mention one note that I feel was a lowlight: Some of the questions in the Q & A sessions, I'm pretty sure, were asked in similar events three and four years ago. The root cause of the biggest areas of confusion stems from the gap between security and compliance. Bob Russo is the first to state the PCI SSC has nothing to do with "compliance" – instead, PCI is the keeper of the security standards. Yet the card brands dictate that PCI compliance is mandatory.

Payments Industry Prodigies

2009-09-17T10:21:00.000-07:00

WARNING TO THE READER: I guess I'm in a bad mood today so pardon my rant. I'm just airing dirty laundry in this posting so if that's not your cup of tea, skip to the next posting.

The payments industry never ceases to amaze me. My latest amazement is how our prodigies are chosen when it comes to security. Here are three examples and if anyone has any explanation why, please feel free to post your thoughts:

(I'll keep the company and personal names out of this; if you're familiar with the industry, you know who I'm talking about)

First on my hit list, a prominent payment processor promoting a new security technology was a victim of one of the largest data breaches exposing credit card information. This by itself is not an issue because a breach can happen to anyone. What baffles me is that proper deployment and use of existing encryption technology could have prevented their breach. This seems like a deflection tactic: instead of shoring up our security gaps, we'll head up the development of a new theoretical technology where no one needs to be secure. This is the example of a perfectly executed public relations campaign.

Next on my list, the Visa poster child for how a POS company should tackle security is probably the biggest factor in requiring CISP and later PCI. Security was all but completely ignored in all pre-2003 versions of their software; card holder data was stored in plain text in various files, remote access with administration level privileges all shared the same login credentials across the entire merchant base, system level administration access was required for all stations and the installation of anti-virus software was frowned upon (all practices that directly oppose security best practices). Then overnight – presto-chango – the model POS vendor for security (even though their application was not truly PCI compliant out-of-the-box until 2008).

Last on my list is a large merchant and victim of a breach that is now doing the "learn from our mistakes" tour. Don't get me wrong; someone who's been on the breach hot seat is the best speaker for convincing merchants to be secure. But let's get all the facts out. Less than two years earlier the decision makers at the company nixed a proposal that could have prevented their breach. Nixing a proposal is not the issue here, it's the reason given: "we don't need that technology, our systems are already secure." I've not heard this little fact on the "woe is me" tour, instead "we were just an innocent victim."

I promise, I'll be in a better mood next time. ;-)

A FIRST LOOK: Tokenization & End-To-End Technologies Combined

2009-08-21T11:57:00.000-07:00

On August 12th, EPX (a third party payment provider) announced that it is joining end-to-end encryption with tokenization. I applaud their effort because I've stated, and I strongly believe that combining these two technologies is the strongest way to secure cardholder data. In the announcement, Matt Ornce, Chief Operating Officer for EPX is quoted: "There maybe are a few entities that have tokenization as a real product today, and there are a bunch of entities talking about doing end-to-end encryption for the merchant, but we haven't heard of anybody combining the two, much less delivering the product to the market." News flash, Shift4 prototyped this in late 2005, the same time they released tokenization to the public domain, and released a product to market in early 2006.

Who Breached Me?

2009-08-10T17:47:00.000-07:00

In my last posting "Yet Another...", I wrote about a breach notification from Network Solutions, a payment service provider. Soon after the original posting, Evan Schuman from StoreFrontBacktalk.com pointed me to the actual notification, which prompted a correction to my posting. While my initial ire was based on false assumptions, the final notification letter to consumers still included the merchant name even though Network Solutions was the entity breached and the service provider was accepting the blame.

During this discussion we had a brief debate about whether or not the merchant name should have appeared in the notification. This discussion gave me an idea to have a simple sparring session debating our different points of view using a simple 100 word or less argument for, argument against, rebuttal for, rebuttal against format. Before we begin, I want to thank Evan for participating and spending the time to put his viewpoint down. Here is the final result:

Should the merchant's name appear in breach notifications if the breach occurs upstream from the merchant and beyond the merchant's control?

ARGUMENT FOR the Merchant Name Appearing in the Notification - The retailer's name needs to be on that notification letter for two reasons. First, consumers only know the retailer's name. Give them a letter that doesn't say something they recognize and it will be thrown out. Secondly, a small retailer will be inclined to go with the lowest cost service. If they don't feel some pain if that service screws up, proper choices will never happen. This will insure that retailers make the best available choices, balancing cost versus security. Breach letters aren't supposed to be fun, but can be functional. Some good can be served.

REBUTTAL to Argument FOR the Merchant Name Appearing in the Notification - Consumers do need to know their card number was compromised but the merchant's name does not need to appear for the consumer to take notice. A notification from the consumer's bank is more credible than from TransUnion, the merchant or the provider that was breached. Second, price does not guarantee security. Case in point, Network Solutions is not known as the low price leader yet they were breached and their name appears in Visa's Global List of PCI DSS Validated Service Providers. This list should be of some value to the merchant beyond "you're required to use one of these." The card brands cannot expect the average merchant to spend days vetting providers.

ARGUMENT AGAINST the Merchant Name Appearing in the Notification - The card brands dictate that merchants must be PCI compliant and to be PCI compliant, merchants must use PCI compliant practices, applications and service providers. Visa publishes a Global List of PCI DSS Validated Service Providers. Since merchants are required to use vendors from this list, the card brands should provide some form of safe harbor, even if it's nothing more than not disclosing the merchant's name in the event that the service provider is breached. The card brands shouldn't expect all merchant to physically tour and spend days vetting these providers; the card brands should have done this when preparing the list. The merchant should not have their brand tarnished due to a security breach completely beyond the control of the merchant.

REBUTTAL to Argument AGAINST the Merchant Name Appearing in the Notification - The Safe Harbor concept is a wonderful theory, but in payment security, it doesn't exist, never has existed and truly can never exist. Retailers normally (the Network Solutions situation is the exception) have tremendous day-to-day influence on security, in the same way that a car can pass a state safety inspection but that doesn't mean the driver won't remove his brakes the day after the inspection. Given the influence a retailer has day-to-day, the merchant must assume responsibility. Besides, the breach letter needs to notify in a meaningful way.

Based on the arguments and rebuttals presented here, hopefully you can decide for yourself where you stand. My guess is your stance will be determined by whether you are looking at the issue from the merchant's perspective or the consumer's perspective. Either way, hopefully this gives you insight to the other side of the argument.

That was fun. I enjoyed sparring with Evan and I hope he enjoyed it as well. I'm sure this argument/rebuttal format will be used again to debate other issues. Until next time...

Yet another...

2009-07-30T11:30:00.000-07:00

Yet another big name breach -- or is it?
Yet another PCI compliant provider breached -- or was it?
Yet another reason PCI compliance needs an overhaul -- or does it?

On July 27th, it was learned that Network Solutions was breached and 574,000'ish customer records were possibly compromised. Network Solutions supplies payment services, among other things, to thousands of small merchants and is a big name. The full details of the breach, the how's and why's are not yet known as the investigations are still ongoing (and may never be known by the public, but that's another story). The fact Network Solutions was breached does not really surprise me because I know there is no such thing as absolute 100% security and the next breach is just waiting for a name to be associated with it.

Big name?

What caught my eye here was how Network Solution informed the consumers. In an effort to comply with the tangled mess of privacy reporting laws, Network Solutions contracted TransUnion to notify the end-user consumers or cardholders. But instead of saying "we're Network Solutions, we take security seriously but unfortunately...", they sent a letter opening with "TransUnion is contacting you at the request of XYZ Merchant..." where "XYZ Merchant" was a merchant that Network Solution was providing payment services for. To me, this is pure slime intended to protect Network Solutions' brand name at the expense of the merchants they serve. The merchant did not have to be mentioned at all, Network Solutions was breached, not the merchant.
I stand corrected. My original ire was based on feedback from affected merchants about the Network Solutions notification letter sent by TransUnion. Reading the complaints, I got the impression that Network Solutions was hiding their brand name behind that of the merchants. After the original blog posting, Evan Schuman (from StorefrontBacktalk) linked me the proposed notification that the merchants were discussing. In the notification, Network Solutions was clearly taking the blame so as the famous Saturday Night Live line goes -- ...never mind.

Compliant?

Who really cares? According to Visa, "no PCI compliant organization has ever been breached." So it's fait accompli that Network Solutions was not PCI compliant. To me, this means one thing: PCI compliance is not truly attainable.

I never can seem to harp on this enough: Focus on security as PCI compliance is a myth. Reduce your risk profile to reduce the chance of a breach. If you are harder to breach than the guy next door, chances are your name will not be associated with the next breach and compliance will never come into play (after all, if you are breached, it will be determined that you were not compliant).

PCI Overhaul?

PCI is a great list of best practices and it should be used as just that, best practices. The card brands should stop trying to use a list of best practices as definition of black or white, secure or insecure, compliant or non-compliant. Since security is never 100%, Visa's quote highlights the biggest flaw: equating compliance to security.

Since the card brands have essentially stated that only non-compliant companies are breached, I think the whole "compliance" factor should be removed. Instead, simply state, "companies that are breached and found to be not taking prudent steps to secure the data or negligent, will be fined." The PCI Best Practices can be used when deciding prudent or negligent. But I don't expect to see anything simple like this anytime soon. After all, there is too much money to be made by the card brands and banks if they stay focused on compliance.

References:
StorefrontBacktalk: Network Solutions Data Breach Hits 574,000 Consumers
CNET: Network Solutions Breached For 574,000 E-Commerce Account Records

I Hate to Say I Told You So…

2009-04-02T17:05:00.000-07:00

Back in 2007, Shift4 held a Security Summit for its customers. One of the topics discussed was the link between credit card fraud and terrorism. Most people were surprised to hear this information and most attending this Summit were grateful that there security endeavors were making a bigger impact than they ever imagined.

Some people however, were appalled to hear this information. An interesting fact is that most of the naysayers were PCI security experts. But these PCI experts weren't the only one appalled. One of the major card brands (who shall remain nameless) was going to speak at this Summit but backed out at the last minute when they got wind of this topic. “That's just a fear tactic that Shift4 uses to sell their wares,” was a common theme when discounting any terrorism ties. The funny thing is, we were not “selling” anything at this Summit -- this was a security awareness event for our customers. In fact, the new products we debuted were and still are free for our customers.

Now fast forward a year and a half, The Green Sheet publishes an article on February 23, 2009, Data breaches, more than bad publicity which links credit card breaches with (drum roll please…), international terrorism. One snippet from the article: “The card scheme of choice: ‘carding.’ Carding is an umbrella term used to describe the theft and sale of personal financial information via the Internet for card or identity fraud.”

On March 31, 2009, the House Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology, which is part of the Homeland Security Committee, chaired by Yvette Clarke (D-NY) held a hearing titled “Do the Payment Card Industry Data Standards Reduce Cybercrime?” You'll never guess what one of the topics discussed in this hearing.

Hmmm, I think there are some appalled experts in this industry that need to open their eyes. I'm fine being called out when I'm wrong about something. I just don't like being told I'm wrong just because someone does not want to hear what I'm saying. Ok, I got that off my chest. Now I'll be the mild mannered programmer my mother raised.

I Am Still Alive

2009-03-25T10:58:00.000-07:00

I'm currently writing a next blog posting, hopefully to be posted by the end of the week. In doing some research, I noticed that some sites have linked this blog when referring to tokenization. I do have published a white paper on this topic and I should have published a link to it from this blog at the same time. Sorry, better late than never:

Tokenization in Depth (PDF)

The white paper is distributed by Shift4 Corporation. It does require a registration and once complete it will be mailed to you directly and automatically.

Do as I Say, Not as I Do

2009-02-09T13:07:00.000-08:00

The latest breach involving Heartland Payment Systems is all the buzz. Some are surprised and/or appalled “yet another high profile breach.” Others question the timing of the announcement theorizing some public relations attempt to hide the announcement within the presidential anointment, oops, inauguration ceremony. What caught my eye is the latest campaign: Heartland CEO Calls For Industry Cooperation To Fight Cyber Criminals And Adoption Of End-To-End Encryption. While I agree with end-to-end encryption, I feel this is nothing more than a case of “do as I say, not as I do.”

My issue is the last paragraph of the above linked press release: “For the past year, Carr (Robert O. Carr, Heartland’s founder, chairman and CEO) has been a strong advocate for industry adoption of end-to-end encryption — which protects data at rest as well as data in motion — as an improved and safer standard of payments security. While he believes this technology does not wholly exist on any payments platform today, Heartland has been working to develop this solution and is more committed than ever to deploying it as quickly as possible.”

The technology already exists, just not in the terms that Carr may be implying. I think Carr is referring to chip cards of one sort or another, but there is nothing stopping a company from doing end-to-end encryption within their own network. While PCI does not currently require end-to-end encryption within a LAN, PCI is meant to be a “minimum” security standard – it is not a be-all, end-all blueprint for secure payments.

I try not to advertise for Shift4 within my blog, but Shift4 internally does end-to-end encryption within its network. The weakest point in the whole chain is the final hop to the bank or processor (which we have compensating controls in place to isolate and minimize the exposure at these points – but this is beyond the scope of this rant). Here, I would argue side-by-side with Carr to force all banks and processors to require application layer encryption at this hand-off point instead of solely relying on VPN encryption. Shore up the weakness of this layer, problem solved provided that the banks and processors internally do end-to-end encryption and you don’t have to wait for PCI rule change, nor do you have to toss out the baby with the bath water by switching to chip cards.

Switching to chip cards may solve some issues, but viewing chip cards as a panacea, I feel, will be a big and extremely costly mistake for merchants if other layers in the end-to-end data path are ignored. If merchants think PCI is expensive now, wait until they need to purchase and deploy all new hardware and fork out the POS software upgrade fees required to support this new hardware platform.

Regulate for Profit – Part 2

2008-10-07T15:01:00.000-07:00

Here are a few more random thoughts I would like to add to my previous posting “PCI SSC Show Their True Colors – Regulate for Profit!”

PCI SSC’s Justification

Although not posted here, I had some feedback on a couple forums and second hand information from someone that attended the latest PCI Community Meeting in Orlando, Florida. PCI’s justification for the fee is that they want to be self sufficient and independent from the card brands. This is good in theory if you ignore two glaring obstacles:

The card brands make up the entire executive committee

A majority of the General Managers and Working Group Chairpersons (possibly all, some titles are missing) are people that represent the card brands

Independence cannot be achieved until these two obstacles are addressed.

Why List?

Reading some of the latest notifications from Visa, Visa is not requiring applications to be “listed.” Visa’s wording on their mandate notifications is “PA-DSS compliant applications,” with no mention of a listing requirement. I’ve also heard that QSA’s are being taught that they cannot rely on any PABP or PA-DSS list and instead should do their own assessment of applications used by merchants. This means that PCI SSC does not have any faith in the PA-DSS assessments or the list they are maintaining (for $1250 a pop!).

So if the card brands are not requiring any list and PA-DSS has no faith in the assessments on file or their list, what’s the point of the list? Oh yeah, I forgot – PCI SSC’s independence.

Make It Useful

Ok, I’ll pause from my slamming and throw out some ideas to make this list useful.

PCI SSC should have faith in their own program. If there are areas of concern like assessments of varying degrees of quality, then fix the program to have more quality assurance – with all the SDLC requirements in PA-DSS for application vendors to promote some level of QA, why shouldn’t the QSA’s have some of the same checks?

PCI SSC should allow and encourage QSA’s to refer to “the list” to streamline merchant assessments. QSA’s should give all applications a quick peek to make sure the applications are properly configured but they should not have to do a complete assessment of every application from scratch.

The card brands should allow “safe-harbor” for fines in the event of a breach if a listed application was breached and was properly configured.

Parting Shot

PA-DSS list should provide benefit to merchants and various other parties involved. As it stands right now, the PA-DSS listing fee is nothing more than a revenue stream for PCI SSC with no benefit. I think if my “make it useful” suggestions were implimented, then the list becomes useful and the $1250 would not be considered simply a tax or tribute.

PCI SSC Show Their True Colors -- Regulate for Profit!

2008-09-05T12:38:00.000-07:00

PCI compliance for merchants has always been costly. PABP compliance and certification for POS vendors has always been costly as well. Earlier this year, PCI DSS announced a deal with Visa to bring under PCI DSS's wing the Payment Applications Best Practices or PABP program. Now with PCI DSS taking over the PABP program, it is morphing into PA-DSS. So far, so good, no issues – same program, a different acronym – or so we thought.

In concert with this program transfer, Visa recently published a timetable forcing merchants to only use PA-DSS approved applications. This mandate included various deadlines based on different factors and 100% compliance by July 1, 2010. This means that by July 2010, every point-of-sale (POS) application that touches credit card data must be on the PA-DSS approved list. Well, now a little nervousness sets in but for the most part, no big deal – or so we thought (unless of course, you're a merchant using legacy POS applications).

Well, the other shoe dropped today when the PCI Security Standards Council notified payment application vendors that there will be an annual listing fee attached to being on the PA-DSS approved list. My company received the following notification today from PCI-DSS:

Dear Steve,

On April 15, 2008, the Payment Card Industry Security Standards Council (PCI SSC) launched the PA-DSS program (Payment Application Data Security Standard). This program was formerly under the supervision of Visa Inc. and known as the Payment Application Best Practices (PABP). The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, other sensitive authentication data or PIN data, and ensure their payment applications support compliance with the PCI DSS. PA-DSS requirements apply to payment applications that are sold, distributed or licensed to third parties.

Your application is currently listed on the Visa website as PABP approved. On October 1st, 2008, Visa's list will be transitioning over to the Council. Each individual application grandfathered over to the Council's list will be given an expiration date based on the version of PABP it was validated against. There will be an annual listing fee will be $1,250.00 for each application. Please see the attached chart for more information about this date. We have attached an invoice with all of your PABP applications. Please send the PA-DSS Program Manager, Nina Beardsley, an email at pa-dss@pcisecuritystandards.org if you do not want all or some of your applications on the new list or if you have any further questions about this transition.

Sincerely,

Nina Beardsley
Nina Beardsley
PA-DSS Program Manager
401 Edgewater Place, Suite 600
Wakefield, MA 01880

Attached to this notification was an invoice demanding payment by 10/1/2008 or be removed from the list. The problem here is that Visa and MasterCard have mandated that merchants only use payment applications on the approved list so paying this fee is mandatory. My feeling is that this is nothing more than an extortion letter.

Upon reading this notification, I immediately responded to PCI DSS asking for a justification of the fee. So far, no response and I really don't expect one. I also called PCI SSC directly to verify the notification because it had such a scam smell. Much to my surprise and dismay, they confirmed it was legit. Now the program I have been promoting as “good for the industry” reeks of a scam. Let's do the math:

While Visa's current PABP list may only have a few hundred approved applications (under 1000), once the various deadlines approach, the PA-DSS approved list could easily exceed ten's of thousands of applications. If you conservatively estimate 5000 applications to be on the list by 2010, that's 5000 x $1250 = $6,250,000 in annual recurring fees! For what?

Maintaining a list of approved applications on a spreadsheet
Maintaining a security document that paying members debate about what gets added and changed in the requirements
Moderating these member forums
Setting up various “for fee” events to discuss changes among the paying members
Publishing this PA-DSS approved list and security document on a website

This revenue does not account for the fees PCI DSS receives from training and annual certification of the QSA's and ASV's – the people required to do the security assessments and security scans. This also ignores the revenue for the PCI-PED side of the PCI DSS house where all payment terminals are certified. Hmm, if it walks like a duck, swims like a duck and quacks like a duck, it must be a cash cow!

I would not be surprised if Bob Russo and several behind-the-scenes puppet masters will be getting a significant pay hike and bonuses over the next few years. I think the card brands need to scrutinize this entire relationship and program. At best, they have created a monopoly situation. At worst, they have enabled a scam.

As you can tell from my tone, I’m ticked. I now feel I have been promoting a scam. A program I thought was good for the industry now has to be scrutinized to determine the true intentions. This is going to stifle innovation. How many small and start-up software development companies are going to be able to afford the $5-50K for a PA-DSS audit of their application? Once approved, how many will be able to afford the $1250 annual listing fee? What is going to happen with many of the open source POS projects that are starting to gain traction in the industry? Who is going to pay these fees?

I welcome your thoughts especially if you are a POS vendor.

Since the original posting, this related story was published on StoreFrontBackTalk:

http://www.storefrontbacktalk.com/story/090908shakedown

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

2008-05-03T18:49:00.000-07:00

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

2008-04-18T12:50:00.000-07:00

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

2008-04-11T10:12:00.000-07:00

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

2007-10-05T09:30:00.000-07:00

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

2007-03-16T16:22:00.000-07:00

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?

2006-10-16T17:35:00.000-07:00

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

2006-10-16T16:53:00.000-07:00

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?

2006-07-07T18:06:00.000-07:00

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.

A Better Mousetrap - Tokenization - Part 2

2006-06-23T13:00:00.000-07:00

This is Part 2 of a three part series on tokenization and how it can be used to help secure payment processing. Part 1 described what tokenization is and how it is stronger than encryption for storing card information. This part details which sections of the various card association security programs tokenization addresses and how it simplifies compliance. Part 3 wraps it all up with real world examples on how tokenization is used.

Here I will detail three security programs (actually one or two depending on how you look at it, read further): Card Holder Information Security Program (CISP), Payment Applications Best Practices (PABP) and Payment Card Industry Data Security Standard (PCI/DSS). While other card associations may have their own security programs, most of the major associations recognize these three security programs as the standard.

I'll note that I am detailing the USA version of these security programs and where tokenization applies. There is also an International equivalent, Account Information Security (AIS). From what I have read, the programs are similar, but I have not directly compared the differences between the two but the same advantages should apply. Please note that the advantages described here are from the viewpoint of the POS application vendor or provider, though merchants reading this post will see the benefits of using tokenization techniques.

Card Holder Information Security Program (CISP)

CISP is an all-encompassing, ever-changing, security program. PABP and PCI/DSS are parts of CISP. I originally mentioned CISP as a separate program because of the confusion in the industry. Many people see "CISP" come in from one direction and "PABP" or "PCI/CSS" from another direction so in their minds, these are simply "Additional security mandates I must comply with." In reality, they are all requirements of the same program focusing on different aspects but with a common theme: cardholder information security.

Payment Applications Best Practices (PABP)

This part of CISP focuses on application and merchant security best practices. While these are called "best practices," in reality, they are requirements that the applications used by the merchant and the policy set by the merchant must meet or exceed.

For brevity, I will only detail the top-level requirements and I will highlight the requirements that tokenization either fully addresses or helps address. Each of these top-level requirements is a group of rules pertaining to the topic and I encourage you to read the complete PABP requirements. A fully certified Shift4 API addresses many of these requirements but, for the purposes of this article, I will only highlight the items addressed by tokenization

PABP Requirements

Do not retain full magnetic stripe or CVV2 data.
Protect stored data.
Here is where tokenization excels. As I hope I have shown in Part 1, tokenization is stronger than encryption.
Provide secure password features.
Log application activity.
Develop secure applications.
Protect wireless transmissions.
Test applications to address vulnerabilities.
Facilitate secure network implementation.
Cardholder data must never be stored on a server connected to the Internet.
With tokenization, you are not storing card information so you are free to store tokens anywhere, either encrypted or plain text.
Facilitate secure remote software upgrades.
Facilitate secure remote access to application.
Encrypt sensitive traffic over public networks.
Encrypt all non-console administrative access.

Payment Card Industry Data Security Standard (PCI/DSS)

This part of CISP focuses on data center and merchant security. These rules are divided into 12 sections and are sometimes called the digital dozen. All merchants should strive to meet the requirements of these rules but only certain merchants (like processors and gateway providers, larger merchants and merchants that have been hacked) must undergo a third party audit for compliance, usually annually. As a merchant, if you are a widely known national or international merchant, I recommend that you have annual audits to offset some potential risks if your security is breached. With tokenization these risks are reduced even more, possibly eliminating the risk altogether.

For brevity, I will detail the top-level of the digital dozen and where and how tokenization addresses them. Each of these top-level requirements is a group of rules pertaining to the topic and I encourage you to read the complete PCI/DSS requirements. As I did when detailing the PABP requirements, I will highlight the requirements that tokenization either fully addresses or helps address. And just like with PABP, a fully certified Shift4 API addresses many additional requirements, but I will only highlight the items addressed by tokenization

PCI/DSS Requirements

Install and maintain a firewall configuration to protect data.
Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect stored data.
Same requirement as in PABP so the same advantage - Here is where tokenization excels.
Encrypt transmissions of cardholder data and sensitive information across public networks.
Use and regularly update anti-virus software.
Develop and maintain secure systems and applications.
Restrict access to data by business need-to-know.
Many of the "need-to-know" requirements are met if only the tokens are stored as they do not contain sensitive cardholder information nor can they be used to access this information.
Assign a unique ID to each person with computer access.
Restrict physical access to cardholder data.
If only tokens are stored, then restricting access to cardholder data is moot - there isn't any cardholder information.
Track and monitor all access to network resources and cardholder data.
As with #9, the cardholder data side of this requirement is taken care of when using tokenization.
Regularly test security systems and processes.
Maintain a policy that addresses information security.

Conclusion

While the highlighted items don't seem like much, the non-addressed requirements are mainly common sense or most likely already addressed. The peace-of-mind in knowing that you are not storing cardholder information should be enough to justify the need for implimenting tokenization. Otherwise, throw in the cost of developing and implimenting need-to-know access levels, data usage monitoring and reporting to the POS application and helping merchants define user access policies as required by PABP and PCI/DSS, then the need for tokenization should be evident.

An additional marketing advantage of tokenization is a friendly explanation of how your application secures cardholder data. "The application does not store cardholder information and instead uses tokenization" is much easier to explain or put on a brochure than "The application uses 128-bit Triple DES to encrypt all cardholder data and the encryption keys are securely stored using a hard coded encryption key in the registry" (huh, how is that secure?). Or you simply don't mention key storage and hope no one asks!

I have shown you where tokenization fits in the CISP requirements and how it can simplify the compliance for POS vendors and merchants. Please check back for Part 3 of this series where I will give real-world examples of tokenization in action, with pictures! If you have any comments or questions on this topic, feel free to post them. Until next time…

A Better Mousetrap - Tokenization - Part 1

2006-06-15T14:36:00.000-07:00

Back in October 2005, Shift4 announced "tokenization" capabilities in its $$$ ON THE NET product and at the same time release the tokenization technology to the public domain (Shift4 Releases New Technology to Insure the Security of Its Merchants' and Partner's Payment Processing). Two months later, Dr. Heather Mark, Ph. D., CISSP, published a white paper on the difficulties and weaknesses of encrypting data and the benefit of using a "tokenization" technology (Storing Credit Card Data: A Look at the Business Needs, Regulations and Solutions Surrounding the Issue). In this posting, Tokenization - Part 1, I'll try to define exactly what tokenization is and the benefits it has over data encryption (the primary benefits were covered in Heather's white paper but here I'll try to provide a shorter version). Part 2 will cover how tokenization can ease the burden on POS vendors and merchants to comply with many of the payment security regulations like CISP, PABP, PCI/DSS, etc. Part 3 will give real world examples on how tokenization was implemented in POS and other applications and again reemphasize how tokenization is more secure than storing encrypted data. Other parts may follow based on the how these first three go...

Tokenization - Huh?

Webster's defines token as "Something serving as an indication, proof, or expression of something else". We are using "tokenization" as the process of substituting a unique identifier (a token) for a card number. This token, for all intents and purposes, is a random unique value and has no way to be deciphered to gain knowledge of the associated card information. Instead, the token is used to initiate payment requests or updates of an already existing payment transaction (voiding a sale, flagging an auth only transaction as a sale, etc.).

I use strong industrial strength encryption – Where's the weakness?

There are several very strong encryption technologies available: triple-DES, AES, Blowfish, RSA, etc. Ignoring any inherent known or unknown weaknesses of one encryption method over another, all these technologies have the same weakness: key storage. The theory behind securing data using encryption is simple: scramble the data to make it unusable for unauthorized use. Encrypting the data (making it unusable) and decrypting the data (returning the data to it's original & usable state) requires keys - a key to lock the data, a key to unlock the data. With most of the encryption techniques, the same key is used to lock and unlock the data. The problem is: How do you secure these keys in the POS application? Once these keys are compromised, the "secured" data is no longer secure.

This problem of securing the keys is very difficult in a compiled POS application and is all but impossible in a shared web-hosting environment that many web sites use. A common technique that POS vendor's use to secure the keys is to encrypt (a catch-22) these keys using a hard-coded password that "only the application knows". In a compiled application, obfuscation (hiding) techniques can be used to give a reasonable level of confidence that the keys are secure. On the other hand, most web sites use scripting languages and hiding the hard-coded encryption keys in these scripts is very difficult.

How is tokenization stronger?

The best way to secure data is to not store the data. This is the theory behind tokenization. The token can be used for initiating new transactions or modifying existing transactions, but beyond this context, it is useless data and there is absolutely no chance it can be used to gain knowledge of the real card information.

Let's assume a worst case scenario: Your Xyz Application data files are not secured in anyway, no encryption techniques have been used, and these files have been given to the world. Obviously, if full card information were stored in these files, you would be in a world of hurt with your customers, your bank, the card associations and quite possibly government and/or law enforcement officials.

Keeping with the worst case scenario: Even if Xyz Application encrypted the card information in these data files that were distributed worldwide, the card associations as well as several states have enacted laws that would require you to notify your customers of the breach because the data can potentially be decrypted. Sure, the data might be securely encrypted, but how confident are you that given enough attention by a dedicated hacker, the decryption keys won't be compromised? In other words, even if encryption techniques are used, merchant reputation wise, you are still in a world of hurt.

Continuing with the worst case scenario: Your Xyz Application stores the token instead of the sensitive card information and these data files are again distributed, it does not matter if they were encrypted or not, no card information was compromised. Your customers do not need to be notified of a breach based on the compromise of card information. Obviously, you may still have to notify your customers or officials based on other sensitive or personal information stored in these files, but not as far as the payment regulations are concerned.

Conclusion

Shift4 released the tokenization concept to the public domain in the hopes that other gateways and possibly even the card associations will embrace the technology, making for a more secure industry as a whole. This posting, part 1, is very generic and non-Shift4 specific. With parts 2 & 3, I'll try to be a generic as possible but they will most likely include sections that detail Shift4's implementation of tokenization.

Here I've tried to briefly describe what tokenization is along with how & why it is stronger than encryption when it comes to the storage of credit card or any payment information. If you have not already done so, I urge you to read the white paper by Dr. Heather Mark - she has a lot more experience writing on the topic of security so she might explain concepts better than I.

Please feel free to comment. Check back later for parts 2 and 3 and maybe more…

2006-06-14T12:52:00.000-07:00

At last. I finally made the step to start my own blog. I have posted my unsolicited opinions on many forums and have now decided to create my own spot to spew forth these payment tidbits. Enjoy!

Payment Tidbits

Debit Card Fees - Simply another front in the ongoing class war

Tokenization IS Encryption - NOT!

Tales From the Inbox - Iwueke

Is PCI Even Legal?

House Democrats Ask Justice Department to Probe Debit Fees

Swipe Fees Revisited

Tokenization and Relevance

Tokenization, the Newest Horse - err, Camel - in the Stable

My take on Swipe Fees

Some Recent PCI Results

Beware Mac users - as popularity grows, so does the target on your back

From Europe with Love

Forced Password Changes - good or bad?

Beware your inbox!

Is Disco making a comeback?

Is it an Audit or Assessment?

Can Never Be Too Safe

Gift Card Act of 2009

This is a portion of H.R. 627: Credit Card Accountability Responsibility and Disclosure Act of 2009 that relates specifically to gift cards and the like:

TITLE IV--GIFT CARDS

SEC. 401. GENERAL-USE PREPAID CARDS, GIFT CERTIFICATES, AND STORE GIFT CARDS.

SEC. 915. GENERAL-USE PREPAID CARDS, GIFT CERTIFICATES, AND STORE GIFT CARDS.

SEC. 402. RELATION TO STATE LAWS.

SEC. 403. EFFECTIVE DATE.

The Steve Sommers' Readers Digest version of the federal law is as follows:

Au Contraire - Latest Gotcha from PCI SSC

Would older operating systems that are no longer supported by the vendor be deemed non-compliant with the PCI DSS?

Obsolete environment

Pondering the Possibilities

You found me!

Stand Up and Be Heard

Hitler and Cloud Computing Security

Security Hole -- Coming to a store near you!

Round 3, Tokenization vs. End-to-End Encryption

What a Rip!

POS Ending Event - Redux II

POS Ending Event - Redux

POS Ending Event -- July 1, 2010!!!

Yet Another Conflict in the PCI World

What went wrong with First Data?

Heartland Lawsuit Dismissed - Secure Enough

Go Carr

Your encryption sucks - here, use mine

PCI SSC Community Meeting and Emerging Technologies

Payments Industry Prodigies

A FIRST LOOK: Tokenization & End-To-End Technologies Combined

Who Breached Me?

Should the merchant's name appear in breach notifications if the breach occurs upstream from the merchant and beyond the merchant's control?

Yet another...

Yet another big name breach -- or is it?Yet another PCI compliant provider breached -- or was it?Yet another reason PCI compliance needs an overhaul -- or does it?

Big name?

Compliant?

PCI Overhaul?

I Hate to Say I Told You So…

I Am Still Alive

Do as I Say, Not as I Do

Regulate for Profit – Part 2

PCI SSC’s Justification

Why List?

Make It Useful

Parting Shot

PCI SSC Show Their True Colors -- Regulate for Profit!

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

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

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

PCI: Compliance vs. Security

PCI Confusion

Merchant Fines?

Payment Tidbits

Does ABC POS System have hidden fees?

A Better Mousetrap - Tokenization - Part 2

A Better Mousetrap - Tokenization - Part 1

Yet another big name breach -- or is it?
Yet another PCI compliant provider breached -- or was it?
Yet another reason PCI compliance needs an overhaul -- or does it?