Thursday, April 10, 2008

PCI: "Follow the Standards to the Letter"

An interesting quote from Bob Russo on how the PCI standard should be followed:

Bob Russo, the general manager for the PCI Security Standards, a group that devises data security measures for the five major credit card companies, said almost all data breaches are the fault of the merchant.

"Everybody that has been breached has been noncompliant with the standard," he said, noting that the circumstances of the Hannaford breach are still too murky for him to render a judgment about. "If you follow the standards to the letter, it puts enough of a hard shell around the data that it is hard to get to."

Full story here.

My question, what about all those emails from the PCI Council, the card brands, acquiring banks and payment processors that purport to resolve ambiguities and which may not be "to the letter" of the PCI Standard? And that question reveals the potential problem from a legal standpoint.

Thursday, April 3, 2008

More Evidence of Hannaford-like Exploits?

While I will have to defer to my tech/security-oriented friends, we have reports of exploits that may be similar to the one suffered in Hannaford: Vermont ski area reports Hannaford-like theft of payment card data.

This exploit may be more common than just Hannaford:

And Hannaford and Okemo may not be the only businesses disclosing breaches involving payment card data in transit between systems. According to McPherson, law enforcement authorities who are investigating the breach at Okemo told resort officials that they currently are looking into about 50 reported incidents of the same sort in the Northeast alone.


So what does this all mean? Do the controls required under the PCI Standard address this issue? What about encryption under 4.1 and the language concerning "networks that are easy and common for a hacker to exploit." In general, has the security community anticipated this sort of attack? Is it reasonably foreseeable that hackers would exploit the point-of-sale systems? Legally, is failure to address this type of exploit "unreasonable" for purposes of negligence claim?

Friday, March 28, 2008

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

Tuesday, March 25, 2008

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.

Monday, March 24, 2008

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.

Saturday, March 22, 2008

The "Circle of Blame"

I prefer the "Chain of Blame" because of the better rhyme scheme... all kidding aside,

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?