07
Dec
09

Louisiana Restaurants Follow Heartland’s Example

If you missed it, a half dozen restaurant companies based in Louisiana have sued their point of sale (POS) vendor and the POS vendor’s reseller over a security breach that was identified in 2008.  There are a number of troubling facts involved in this complaint that I think deserve to be discussed.  Unfortunately, these merchants are taking a chapter out of the Heartland breach playbook by saying it is entirely someone else’s fault.

My first problem with this case is the spelling errors and misrepresentations of some of the facts.  It is tough to take a lawsuit seriously when the law firm involved did not take the time to spell check and proof what they were writing or ensure that the historical facts are accurate.  With that said, let us take a look at this wonderful legal mess.

From the filing we get the start of their terrible tale of software gone awry.

“Notably, Visa identified [vendor]’s POS software as a payment application that stored prohibited data, such as full magnetic stripe data (including card verification and PIN data), after a transaction authorization was completed.

Around the same time, [vendor] was advertising that the [vendor]’s POS system was enhanced to comply with the PCI Data Security standards.

Plaintiffs all purchased the [vendor]’s POS systems from [reseller].”

Later in the complaint, they state:

“Plaintiffs would not have purchased the [vendor]’s POS systems had they known of the security defects contained in the software.”

They already knew that the software was not compliant and they admit it in the first part of the complaint.  Visa is the certification body and had listed the software from the vendor as non-compliant.  What more could you want?  Yet they still purchased the software.  This is why you conduct a formal software selection so as to avoid these types of problems.  Buying software is a sophisticated process requiring research and documentation of one’s requirements and matching those requirements to the various vendor offerings.  First key requirement in this case should have been is the software PCI compliant.  If not, it is not included in the selection process.  This just shows terrible due diligence and lousy business acumen on the merchants’ part.  Strike one against the merchants.

But it just gets better.  In 2008, these restaurants all get contacted by their local law enforcement agencies and are told that they are the source of a credit card compromise.

“Thereafter, Plaintiffs undertook their own research to determine whether their systems had been compromised.

Plaintiffs ultimately learned that keyloggers had been installed on their POS stations.”

As they say down South, “This dog just don’t hunt” and it does not hunt for a number of reasons.

First, after they do not do proper due diligence, I am supposed to suspend belief and believe that these merchants had the technological prowess to figure out that a keylogger had been installed on their systems?  The reason I have a problem with this is that later on in the filing it states that they hired outside consultants to remove the keylogger software.  Therefore I have to assume since it is not explicitly stated that no outside assistance was obtained in identifying the keylogger.  Bottom line – the merchants violated a key incident response principle by not getting a forensic examiner involved immediately.  Strike two against the merchants.

However, this points out another troubling issue.  Does this sound like a group of organizations that have an incident response plan in place as required by the PCI DSS?  Based on the complaint, it sure does not read that way.  So, guess who is not PCI compliant?  Strike three against the merchants.  Unlike baseball, PCI players are not out after three strikes, the strikes just continue to accumulate.

Let us assume that the vendor’s software these merchants installed was truly PABP or PA-DSS compliant and the keylogger claim is also accurate.  If the application stores cardholder data encrypted, then the only way that the keylogger could have allowed anyone access to the data is that one or more of the accounts had access to the data encryption keys.  There are a couple of things that could have caused this; (1) the reseller used the same administrative password for all systems they install, (2) the application is designed such that administrators have access to the encryption keys, and/or (3) the merchants assigned a number of users as administrators that had access to the encryption keys.  Everyone could have fault here and without extra information there is no way to know who is at fault.

Another thing that troubles me is the fact that every plaintiff had a keylogger on their POS system and I am assuming it was the same keylogger since the complaint does not say differently.  It just seems a little too coincidental that they all were attacked the same way.  If I were a betting man, I would say this is an inside job because the facts all point that direction as well as the statistics say that it is the most likely scenario.  Insider meaning someone that had knowledge that all the systems were configured the same.

Finally, where is law enforcement in all of this?  All of these systems are technically a crime scene, yet nowhere does the complaint mention anything about law enforcement seizing the compromised systems for a forensic examination.  You would have expected law enforcement to have seized these systems and the reseller having to supply new systems to replace them.  Apparently that never happened.  Strike one against the law enforcement agencies for not treating this for what it was, a crime.

As if it is not bad enough, things get worse.  The reseller was unable to remove the keylogger, so the merchants had to go out and get help.

“These consultants discovered that [reseller]’s standard practices violated numerous provisions of the PCI Data Security Standards.

In addition to incurring substantial costs for additional technicians, consultants, software, and network connections, news of the credit card number thefts were reported by local media, which resulted in loss of business to Plaintiffs.”

Well, here is a shock, the ‘hired guns’ find that the reseller wasn’t complying with PCI requirements.  This confirms an earlier strike against the reseller, so they get another strike as well for this lapse.

Here is something that any reseller or vendor that is providing managed services should worry about.

“Defendants failed to notify Plaintiffs that the [vendor]’s system was breached”

I am not sure how the software vendor was to have known this.  But, if the reseller was also providing managed security and/or network monitoring services to the merchants, then they are really on the hook for this one.  However, if the reseller was not providing any managed services, I would seriously question how a breach would be known by the reseller.

Finally, the complaint states:

“After the problems were identified and corrected, Plaintiffs were fined by credit card companies for failing to comply with the PCI Data Security Standards and/or their Payment Application Best Practices (PABP).”

At a minimum, these merchants were likely covered by SAQ C.  Requirement 12.5.3 in SAQ C very clearly states that the merchant is required to have developed a documented incident response plan.  As a result, these merchants were also likely not compliant with the PCI DSS.

The complaint also seems to indicate that the vendor’s software solution was not really PABP compliant.  This is another strike against the merchant for their lack of due diligence.  It may also be a strike against the reseller and/or vendor if they misrepresented the PCI compliance of the software.

In the end, the merchant wants the reseller and the vendor to take all of the blame for their poor decision making process.  If that sounds familiar, it is.  This is exactly the same rationale that Robert Carr used to justify the Heartland breach.  It was everyone else’s fault.  As with the Heartland incident, there is more than enough culpability for everyone involved.  But I leave the bulk of the blame to the merchants who created their own problem in the first place.

So, what are the lessons learned from all of this?

  • Conduct a formal software selection regardless of how ‘simple’ you may think the solution and process may be.  Formally document and prioritize your requirements.  If there are any ‘drop dead’ requirements, make sure that you use those to qualify all of your candidates before including them in your process.  Since most organizations do not regularly conduct formal software selections, this is a good project for an outside consultant who does such projects regularly.  Yes, it costs real money to hire an expert, but it pays dividends down the road by keeping you from making poor decisions that you will regret later.
  • Never take anyone’s word when dealing with compliance.  If the certification body’s documentation indicates that a given product or service is not compliant, then it is not compliant.  If you really must, get the vendor to provide you with a copy of their documentation that they have filed with the certification body and when it was filed.  Then contact the certification body and confirm that the documentation was received from the vendor and when the certification body will likely act.  If the granting of certification is too far out or you cannot go through this process, then the certification does not exist.
  • Make sure your reseller is complying with all relevant requirements when installing and maintaining your hardware and software.  This involves not only getting it in your contract with the reseller, but also setting up milestones that require your review and approval before the reseller goes to the next step.
  • Make sure you have an incident response plan.  It seems like ‘make do’ work until you really need it.  Incident response plans are very much like disaster recovery and business continuity plans, they are insurance policies against bad decision making during a crisis.
  • Obtain experienced assistance when you need it.  There is a lot of truth in the old adages, “You can pay me now or pay me later” and “Penny wise but pound foolish.”  I am sure these merchants thought that they were saving themselves a ton of money by skipping a formal software selection process.  But in the end, it came back in spades when they suffered the breach and the resulting drop in business.
Advertisements

0 Responses to “Louisiana Restaurants Follow Heartland’s Example”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

December 2009
M T W T F S S
« Nov   Jan »
 123456
78910111213
14151617181920
21222324252627
28293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,843 other followers


%d bloggers like this: