PCI, "Safe Harbor" and Hannaford

This Computerworld article was some issues: Hannaford may not have to pay banks' breach costs under PCI, says Gartner

This key part of the article is problematic:

“If true, Hannaford has a safe harbor under PCI and will not be required to reimburse banks and credit unions for any breach-related costs they may incur, according to information that Gartner analyst Avivah Litan said she has previously received from Visa Inc. Typically under PCI rules, if a company is noncompliant at the time of a beach, it faces two potential costs: fines from the payment-card companies and reimbursements of breach-related costs sustained by card-issuing banks and credit unions. Those costs can include payment of fraud losses resulting from the use of compromised payment-card data as well as breach notification and the costs associated with reissuing cards.

The fines and the reimbursement costs are not collected directly from the breached entity but through the "acquiring bank" that authorizes a company such as Hannaford to accept payment-card transactions. Under PCI rules, it is these acquiring banks that are directly responsible for ensuring that their merchants are PCI-compliant.

In Hannaford's case, while its acquiring bank may still get hit with a fine, "the buck stops there," Litan said. "Under the guidance Visa gave me, the acquiring bank wouldn't be able to take it back to the retailer," she said.”

It appears that Litan is referencing the VISA CISP “Safe Harbor.” Interestingly, if you go to VISA’s CISP website, the reference to the Safe Harbor has been removed. Here is what it used to say (as late as August 9, 2007 according to the Internet Archives) :

Safe Harbor

Safe harbor provides members protection from Visa fines in the event its merchant or service provider experiences a data compromise. To attain safe harbor status:

1. A member, merchant, or service provider must maintain full compliance at all times, including at the time of breach as demonstrated during a forensic investigation.
2. A member must demonstrate that prior to the compromise their merchant had already met the compliance validation requirements, demonstrating full compliance.
3. It is important to note that the submission of compliance validation documentation, in and of itself, does not provide the member safe harbor status. The entity must have adhered to all the requirements at the time of the compromise.
   

Link Here.

That language has been replaced on VISA’s website with this:

Visa may waive fines in the event of a data compromise if there is no evidence of non-compliance with PCI DSS and Visa rules. To prevent fines a member, merchant, or service provider must maintain full compliance at all times, including at the time of breach as demonstrated during a forensic investigation. Additionally, a member must demonstrate that prior to the compromise the compromised entity had already met the compliance validation requirements, demonstrating full compliance.

Link Here

A few things to say:

(1) Safe Harbor for Fines Only. According to VISA’s website the Safe Harbor (whatever version is applicable) only applies to fines. Therefore, unless there is information out there that says it applies to reimbursing banks, it would appear that the Safe Harbor is limited. Litan indicates that she has seen some information; it would be excellent if she shared that.

(2) Safe Harbor at Visa's Discretion? As you can see, the VISA website has gone from “to attain safe harbor status” to “Visa may waive fines.” Its not clear from this language whether safe harbor is “automatic” if a company can establish PCI compliance and VISA validation requirements, or whether its at VISA’s OPTION to (e.g. “may waive”) to waive fines if the merchant can establish compliance and validation.

(3) PCI Compliance and Validation Required. The safe harbor requires not only a demonstration of PCI compliance, but also requires (in both versions) that the merchant meet “compliance validation requirements.” So, by this language, a merchant may have been PCI compliant, but it is unclear whether or not the safe harbor would be available if the merchant it did not “validate” that compliance with VISA (basically do a bunch of paperwork: link here)

(4) Safe Harbor Limited to Visa; Not Other Card Brands. Visa’s safe harbor on its face would not provide protection from the other card brands, including MasterCard, Discover, AMEX, etc. If there is a side agreement between the card brands to honor compliance with VISA’s safe harbor, I have yet to see it. This article gives the impression that compliance with VISA rules will somehow protect you from other card brands.

(5) Article Misidentifies "PCI Rules." As a follow up to (4), the article refers to the contractual arrangements between banks, credit card companies and merchants as “PCI Rules.” In fact, those relationships are governed by each of the card brand’s security programs. VISA’s program is the Cardholder Information Security Program. Mastercard’s is the Site Data Protection Program. So if a merchant deals with all five card brands it must comply with not only the PCI Standard (a security standard) but also five security programs. These programs have different definitions, procedures and requirements. To avoid confusion, people need to be careful to not conflate “PCI” with the card brand security programs.

(6) No Proof that Issuing Banks Bound to Honor Safe Harbor. the article appears to suggest that attaining VISA safe harbor will somehow prevent a merchant from having liability to issuing banks for the costs to reissue credit cards. It is not clear how an issuing bank would be bound by VISA’s safe harbor; (a) as discussed below the safe harbor only deals with fines; and (b) the issuing bank is not in a contractual relationship with a merchant with respect to PCI so a merchant would have no basis to enforce the safe harbor against the issuing bank. If there is a document that requires all VISA issuing banks to respect the safe harbor it should be shared publicly so everybody can assess their liability.

(7) The Buck Only Stops if the Contract Stops It. The article suggest that in terms of fines, if safe harbor is attained, “the buck stops” at the acquiring bank. I would maintain that where the buck stops between a merchant and its acquiring bank is dictated legally by the terms of their contract and you cannot make a blanket statement.

On the broader issue, claiming PCI compliance and even actually achieving it does not automatically mean immunity in a lawsuit setting by any stretch

It is entirely possible to be PCI compliant and still have “unreasonable security” for purposes of negligence suit by consumers or banks. Its possible to state you are PCI compliant and not actually be compliant. Moreover, it’s even possible for the PCI Standard itself to be “unreasonable” (although that is obviously a more difficult argument to make to the extent the PCI Standard is “industry standard). A case that every security professional should know about: T.J. Hooper In short, the issues around PCI are much more complex then being presented here and I think people need to be careful since there is already enough confusion out there already.

Much, much more to come...

Are the PCI Council's FAQs Incorporated and Part of the PCI Standard?

This is the basic question I posed to Bob Russo, General Manager of the PCI Council, during an online PCI forum put on by SC Magazine:

Are the FAQs incorporated into and automatically made part of the PCI Standard when published? If so, is there a document or some sort of proclamation indicating that the FAQs are part of the PCI Standard?

Mr. Russo orally indicated "yes," the FAQs are intended to become part of the PCI Standard when they are published. Mr. Russo, however, was not aware of any document or proclamation that indicated that the FAQs were incorporated/made part of the PCI Standard. He indicated that he was making a note on that point to see about creating such a document.

What does this potentially mean in terms of legal liability issues? Well at least with FAQs, if they are made part of the PCI Standard, merchants and QSAs will have a stronger argument of the authoritative weight of the FAQs if ever challenged on the issues addressed in the FAQ. However, this still does not mitigate potential risk around receiving "informal" advice on ambiguities from the PCI Council, processors or merchant banks. Since this type of informal advice is not officially made part of the PCI Standard, its ability to be relied upon as interpretative authority in court or otherwise is arguably weaker. More on these issues to come.

Correction Re: Connecticut Retailer Liability Law

All, I have to issue a correction concerning my reference to a Connecticut law in the article entitled "The Legal Implications of PCI." In that article I indicated that Connecticut had passed a law allowing banks to sue retailers. I received information from a source that turned out to be erroneous. In fact, Connecticut considered a bill with retailer liability in it, but ultimately the provisions providing for retailer liability were stricken. The only State with a specific law providing relief to financial institutions for a security breach involving cardholder data is Minnesota. The updated/corrected article is here: Legal Implications of PCI. I apologize for the mistake.

Hannaford Class Action Update

Looks like four were filed last week (click on each to get a copy of the complaint):

Ryan v. Delhaize Am. Inc., D. Me., No. 1:08-cv-00086JAW, complaint filed 3/18/08;

Dobryniewski v. Delhaize Am. Inc., M.D. Fla., No. 2:08-cv-00235-JES-DNF, complaint filed 3/18/08;

Doherty v. Hannaford Bros. Co., D. Me., No. 2:08-cv-00089-DBH, complaint filed 3/19/08; and

Major v. Hannaford Bros. Co., D.N.H., No. 1:08-cv-00106-JL, complaint filed 3/20/08.

These pleadings may be a little sparse considering the lack of public knowledge of what happened at Hannaford. I have not read through them yet, but will try to do so later to see how the plaintiff attorneys are approaching this situation.

The "Circle of Blame"

I prefer the "Chain of Blame" because of the better rhyme scheme... all kidding aside, Andrew Conry-Murray has done some good reporting on this story.

One money quote:

While PCI provides more concrete guidelines than, say, Sarbanes-Oxley, merchants are quick to complain that it's both too specific and too vague. For instance, the standard requires use of stateful packet inspection firewalls. "What if I choose to use another technology that I believe is equivalent?" says Michael Barrett, chief information security officer of PayPal, a Level 1 merchant. "You have a whole big fight with your auditors or you hold your nose and do it."

Level 1 merchants also clash with QSAs over issues such as "compensating controls"--technologies or processes used in place of specific requirements on the PCI checklist. "We believe our controls are adequate, but they are different from how the standard is written," Barrett says. "So you argue with auditors. Those kinds of things make you want to tear your hair out."

There's also a level of subjectivity in PCI that many find disturbing. The training for QSAs provides few guidelines for resolving this subjectivity. One PCI expert, who requested anonymity, says of the training: "When you ask if X or Y would be acceptable, or how to apply X in situation Y, they always answer 'Use your best judgment.'" He says that when others in the class pointed out how wildly their opinions could differ in a given situation, the instructor "had no answer other than to say 'do your best.'"

"It's a question of interpretation of the auditor, and the sophistication and skill set of the auditor," says Jay White, global information protection architect at Chevron, also a Level 1 merchant. "PCI was more painful than it had to be, but we've learned we have to help the auditors understand how we meet their objectives, even if they don't at first see it."

This lack of guidance can lead to significantly different approaches to compliance, even among auditors at the same Qualified Security Assessor. In one case, a company brought in a PCI expert to monitor a QSA's recommendations. The expert says the QSA had insisted the company deploy a million-dollar technical control when a simple change in operational procedure would have addressed the issue. "The assessment company then sent out someone completely different," the expert says, "and he disagreed with the recommendations of the prior QSA from his own company!"

This inconsistency can have significant repercussions for Level 1 merchants. If a merchant exposes card data, Visa dispatches a team of forensics security consultants to determine if the merchant was compliant with PCI at the time of the breach. "If a 'compliant' merchant gets compromised, I can guarantee you I can find at least one thing in the compliance report I could argue about," says the PCI expert. "This provides just enough wiggle room for the brands to point at the merchant or QSA and argue the standard was interpreted wrong."

Being judged noncompliant can result in substantial fines for the merchant and its acquiring bank, including higher per-transaction card processing fees. A judgment of noncompliance would also be useful to law firms contemplating action against the merchant.

More interesting points:

One major clothing retailer we spoke with said auditors examined four out of 1,000 stores, a sample size of just 0.4%. The retailer says all its stores share the same configuration and are centrally managed, but it's all too easy for security problems to go undiscovered with such small samples. "I could hide a multitude of sins from a QSA," says the PCI expert.

And while some retailers complain that auditors are too strict, the current system lets retailers seek out QSAs who may apply the standard less rigorously than others. "I've read several compliance reports that have been provided to us after the fact, and I wouldn't consider them appropriate," says the PCI expert. "They passed, but I don't know how." When asked if merchants are shopping for QSAs that provide an easy assessment, he says: "I can guarantee you that. Why wouldn't they?" Even the PCI Security Standards Council, which trains and certifies QSAs, admits that quality levels may not be consistent among the more than 100 active QSAs.

"It's a competitive game," says Bob Russo, general manager of the council. "One QSA might do an on-site assessment for X number of dollars, and another QSA will do the exact same assessment for less. A merchant thinks, 'If this guy is charging me $50K and this guy charges me $10K, there's a question there.'"

In response, the council is introducing a quality assurance program, due later this quarter, to ensure that all QSAs are performing assessments with the same rigor. "The goal is to make sure it's a level playing field so we don't have accusations from QSAs or merchants that some people are rubber-stamping," Russo says.

The question of rubber-stamping ties to the issue of liability. If a compliant merchant is breached, does the QSA bear any responsibility? It's a question that makes QSAs uncomfortable.

"Who's to say a retailer doesn't take what we say and toss it into the garbage?" says Barbara Mitchell, manager of security product marketing at Verizon. Along with Internet Security Systems and TrustWave, Verizon wins much of the assessment business for Level 1 merchants. "We should have some skin in the game, but if a retailer decides to not listen to our recommendations, it's a murky area," Mitchell says. "If we assume liability, we want to review all the stores, all the servers. That shoots the cost up to a prohibitive degree."

Retailers we spoke with were unclear about the liability question. "I think it would depend on whether our controls were deficient and on the audit process," says the network architect at the major clothing retailer. "I think there would be some level of liability, but we've not dug into that. There may be language in the contract I'm unaware of, but my focus has been on controls to prevent a breach rather than where we will point a finger." Unfortunately, finger-pointing is inevitable if credit card data gets stolen. "When a breach happens, if they see something out of whack, they will go back to the auditor, like Enron and Arthur Andersen," says Teri Quinn-Andry, product marketing manager for Cisco Security Solutions.

Then there's the problem of depending on what is, essentially, an honor system for Level 2, 3, and 4 merchants. There is no outside validation of a company's responses to the self-assessment questionnaire. "The reality is, you don't have to be compliant, if your business wants to take that risk," says the IT director of a Level 2 cruise ship operator.

"A lot with PCI is left to your interpretation," agrees Alan Stukalsky, CIO of Church's Chicken restaurant chain, also a Level 2 merchant.

So what does it all mean. I think it means a very volatile system with a lot of liability risk and uncertainty. I think it means that taking shortcuts could get both merchants that self-assess and QSAs into hot water (including hot water of the "going out of business" type for smaller merchants and QSAs). I think it means probably more comprehensive and expensive assessments when QSAs start getting hit with lawsuits.

So what can be done to smooth out the risk? More on that later from me... any thoughts from others?

Article Exploring PCI-related Risks in the Hannaford Breach

Interestingly, some reporters are digging deeper to explore the implications of a PCI-compliant company suffering a payment card breach: see here.

I think we don't have all the information so we everybody is engaging in various levels of speculation. However, we do know two facts: (1) compliance with PCI was represented in Hannaford's privacy policy (last visited 3-21-2008); and (2) there was a breach exposing cardholder data. In my view, here are some of the possibilities (in no particular order of likelihood, and by no means an exclusive ilst):

(1) the qualified security assessor (QSA) (or internal assessor) may have misinterpreted or loosely interpreted a section of the PCI standard (and the reality was there were security weaknesses);

(2) the PCI compliance may have been old or outdated (e.g. they may have been PCI compliant 9 months ago, but perhaps added new systems that were not secured consistently with PCI);

(3) Hannaford may not have provided all of the information to the QSA (assuming one was used) that it needed to validate its decision (e.g. this could include mistakes in defining which parts of Hannaford's networks were in-scope/out-of-scope);

(4) Hannaford may have been 100% PCI compliant and reasonably secure in general and just got unlucky (e.g. there is no such thing as 100% perfect security). Under this scenario, Hannaford would argue that it was not negligent because it did all the right things and that unfortunately these things just happen.

(5) Hannaford and/or its QSA may have had a security weakness or questions about an ambiguity and may have had either the PCI Council, its upstream payment processor or its merchant bank give a bad interpretation.

The interesting issue will be, assuming that some sort of negligence is shown, who was/is ultimately responsible? Hannaford? The QSA? A merchant bank that accepted Hannaford's certification?

Much more to come on this one.

Update: well that was quick. The class actions come flooding in.

The Hannaford Breach and PCI Compliance

More on this yet to come, but the Hannaford breach may be the perfect illustration of where false reliance on "PCI Certification" could get a company in big trouble. See my previous post on the Legal Implications of PCI here.

More to come, but long story short, the company's chief executive said the data "was illegally accessed from our computer systems during transmission of card authorization." This means the data was likely not encrypted in transit.

In this case the ambiguity appears to be in section 4.1 of the PCI Standard, which requires "Encrypt transmission of cardholder data across open, public networks" and also states "Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit"

Section 4.1. provides examples where encryption is required, including, the Internet, WiFI, global systems for mobile communications and GPRS.

So the question is, does the encryption requirement include open "internal" networks of a merchant that may be "easy and common" for a hacker to intercept. Or did Hannaford get a rubber stamp of approval without actually complying with 4.1. or only partially complying with 4.1?

If all of the supposition is true, it appears that Hannaford (or its Qualified Security Assessor) interpreted 4.1 to mean that only transmission across "public" networks like the Internet required encryption of data before transmission.. and perhaps not its internal networks that may have been vulnerable...

More details here, here and here.

FACTA Class Action Certified (N.D. Illinois)

All, a link to a recent case that certified a class action under FACTA based on credit card receipts with more than the last five digits and expiration date: (Meehan v. Buffalo Wild Wings Inc., N.D. Ill., No. 07 C 4562)

Interestingly this case goes against rulings in the 9th, 10th and 11th Circuits, which ruled that the "superiority" requirement of Rule 23(b) had not been met because of the potentially staggering statutory damages available under FACTA ($100 to $1000 per violation).

In this case, the court followed 7th Circuit precedent that held that classes could be certified despite staggering damage potential. In this Circuit the issue of staggering damages, however, can still be challenged as a violation of due process rights after the certification.

In short, the certification provides the plaintiffs with more leverage because the class has been established and plaintiff's attorneys will have a large economic incentive to argue all the way through the due process arguments. Companies operating in the jurisdiction of the 7th Circuit should be very careful with their credit card receipts.

Legislative Update: 2 New Plastic Card Protection Bills Pending (Alabama and Iowa)

Plastic Card Protection laws continue to be proposed in state legislatures. This time its Alabama and Iowa that are jumping into the fray with bills that incorporate the Payment Card Industry (“PCI”) Data Security Standard and/or provide financial institutions with the legal right to seek reimbursement for costs associated with payment card security breaches. However, the Iowa and Alabama bill provide some new wrinkles.

Alabama SB 382. Here are some of the wrinkles in the Alabama bill:

(1) Personal Information Deletion Requirement. Requires the deletion/destruction of personal information that is “longer necessary to be retained.”

(2) PCI Tie-In – PCI Section 3.2.. The bill prohibits the storage “in either encrypted or unencrypted form, subsequent to authorization, the card security code data, the PIN verification code data, the full contents of any track of a magnetic stripe or data chip, card-validation code, or value, or any other security information in a manner that permits access to an individual financial account.” This is essentially the same duty as section 3.2 of the PCI Standard. Note this language appears to go beyond payment card security since it relates to “any other security information that permits access to an individual financial account.” This language could possibly include passwords for online banking sites, online payment sites and other access codes tied to financial accounts (beyond credit card accounts).

(3) Financial Institutions Recovery of Reasonable Costs. Like other Plastic Card Protection laws, in the event the of a violation of the law and a security breach exposing personal information, the Alabama bill provides bank with the right to reimbursement for the reasonable costs of actions taken “to protect the personal information and account information of the customer or to continue to provide financial services to the customer,” including the costs to reissue cards, open/close accounts, contacting cardholders and refunds or credits made to customers.

(4) Private Cause of Action. In a new twist the bill specifically provides a private cause of action for financial institutions against those that “are responsible for the security breach.” The financial institution may receive not only actual damages, but also incidental and consequential damages, as well as court costs and reasonable attorney fees. Significantly, this language may help financial institutions recover damage elements that would be very difficult to recover under a traditional negligence claim.

Iowa S.S.B 3183. Here are some of the wrinkles in the Iowa bill:

(1) PCI Tie-In – Entire PCI Standard. The Iowa bill requires compliance with the entire PCI Standard by any entity that accepts a payment card in connection with transactions in the ordinary course of business. However, the bill also indicates that the Iowa attorney general must adopt rules necessary to implement the bill, including identifying the payment card industry standards to be applied.

(2) PCI Certification. Financial institutions initiating an action must request a certification of compliance from the party that suffered the security breach. The certification must be made by a payment card industry approved independent auditor. It appears that an action cannot be commenced against an entity that has not been found in violation of the PCI Standard.

(3) Financial Institutions Recovery of Reasonable Costs. The bill provides for the right to recover similar damage components as those in the Alabama bill.

(4) Attorney Fees for Prevailing Party. The bill provides that the prevailing party in an action will be entitled to recover attorney fees. However, if the prevailing party is an entity that has refused to certify PCI compliance it cannot recover attorney fees.

BOTTOMLINE: the legal liability will change radically if these bills get passed (like the Minnesota and Connecticut laws, as well as the bill in Washington State that has passed one house).