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?

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…

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

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

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

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:

1. The card brands make up the entire executive committee


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

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


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


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

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)

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