The Curious Case of EMI v. Comerica: A Bellwether on the Issue of "Reasonable Security"?

Security breaches in the online banking world continue to yield interesting lawsuits (you can read about three others in this post). The latest online banking lawsuit filed by Experi-Metal Inc. (“EMI”) against Comerica (the “EMI Lawsuit”) provides some new wrinkles that could further illuminate the boundaries of “reasonable security” under the law. Brian Krebs has a good article summarizing the case. In addition, bankinfosecurity.com has a recent article on this matter (in which yours truly was quoted). In this post we take a look at the EMI Lawsuit, consider some legal questions that the case raises, and analyze how it might impact the question of what constitutes “reasonable security” under the law.

The Allegations

On a general level the EMI Lawsuit involves a basic fact pattern that is similar to several online banking security breach cases: criminals were able to obtain the login credentials of a bank’s business customer and wire transfer large sums of money from the customer’s account (in the EMI lawsuit approximately $560,000 was allegedly wired). Like other online banking cases, the bank in this case (Comerica) did not reimburse EMI for the unauthorized wire transfers, and this lawsuit was eventually filed.

However, the EMI Lawsuit differs in two substantial ways from the online banking cases InfoLawGroup previously reported on. First, unlike the other online banking breach suits, in the EMI Lawsuit, Comerica had implemented (and EMI was using) 2-factor authentication.  In particular, Comerica had implemented a token-based 2-factor system. It appears that Comerica online banking customers where provided with a physical token that generated random numbers at various regular time intervals (e.g. the token number was always changing at regular interval). To utilize online banking, Comerica customers would have to input their username and password as well as the random number showing on their token. Without all three pieces of information, logging into Comerica's online banking would not be possible.

Second, in other the lawsuits, it was not known (or at least unclear from the compliant) how the criminals obtained the banking customer’s online banking credentials. In the EMI Lawsuit, however, the bad guys allegedly obtained EMI’s login credentials through a “phishing attack.”  EMI alleges that one of its employees was tricked into giving those login credentials to the criminals via a spoofed email that purported to be from Comerica. This fake email was allegedly similar to those sent by Comerica to EMI in the past.  Apparently the EMI employee would have provided not only user name and password, but also the random number from the token. The complaint alleges that the thieves were able to conduct about 97 money transfers over a period of approximately 6 ½ hours.

Analysis

This case raises several interesting legal issues. In fact, this case could ultimately illuminate how courts view the scope of a “reasonable security” duty.

Existence and Scope of a “Reasonable Security” Duty.

One of the issues that will be key in this case is whether the bank has a legal duty to prevent these types of phishing attacks. The Shames-Yaekel case has recognized a general duty to protect a customer's online banking accounts. In that case, however, it is unclear how the bad guys obtained the banking customer's online credentials. This case is a little different because phishers were able to trick the customer into volunteering its online banking credentials. Assuming a general duty exists, the question is whether that duty extends to preventing (or reducing the risk of) its customers from being duped by social engineering attacks like phishing.

On that issue, In the EMI Lawsuit (like many of the other online banking lawsuits) the plaintiffs allege that Comerica failed to comply with the “commercially reasonable” security procedure requirement under Michigan’s version of UCC 4A202 (MCLA 440.4702(2)), which provides in relevant part:

(2) If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer. The bank is not required to follow an instruction that violates a written agreement with the customer or notice of which is not received at a time and in a manner affording the bank a reasonable opportunity to act on it before the payment order is accepted.

Subsection (3) explains how “commercial reasonableness” is to be determined under MCLA 440.4702(2):

(3) Commercial reasonableness of a security procedure is a question of law to be determined by considering the wishes of the customer expressed to the bank, the circumstances of the customer known to the bank, including the size, type, and frequency of payment orders normally issued by the customer to the bank, alternative security procedures offered to the customer, and security procedures in general use by customers and receiving banks similarly situated.

Significantly, the existence of a duty and whether Comerica's security procedures were commercially reasonable under MCLA 440.4702(2)) are questions of law, and will be decided by the Court, not a jury. Also of note, some of the plaintiffs’ allegations track to the factors laid out in MCLA 440.4702(3), including allegations that EMI had only performed two wire transfers in the two years prior to the attack.  From a legal standpoint, assuming this case does not settle, since this is a question of law, we could see some actual briefings and a court decision on the issue of reasonable security.

One of the factors that courts look to in order to determine whether a duty exists and its scope is forseeability -- was this attack and/or the resulting harm foreseeable by the bank? In fact, EMI alleges that the secure token technology was one that was already known to fail. On this issue, in general, we know that phishing attacks have been around for awhile. We also know that banks and other organizations have developed approaches to try to prevent these types of attacks. Finally, security professionals tell me that use of phishing to foil two-factor authentication is also a risk that has been discussed in the past. In fact, a similar phishing attempt spoofing a Citibank online banking portal was reported back in 2006.  As such, we will likely see significant arguments from both sides on this issue.

“Reasonableness,” Industry Standards and Tug Boats

This case is interesting because Comerica was actually using 2-factor authentication. In the Shames-Yeakel matter, the court ruled that the failure of the bank to use two-factor authentication as suggested by FFIEC guidance created a question of fact appropriate for a jury. Thus, unlike Shames-Yeakel and other online banking cases, at least with respect to authentication, it appears that Comerica was meeting what some would call the "industry standard.”

However, at this point in time it is possible that a court could rule that 2-factor authentication only serves as a floor, and industry standards for online banking security may have evolved further. In other words, to the extent this “man in the middle” type of attack was known and there are methods for addressing it (especially in the phishing context), the “industry standard” for online banking may be 2-factor authentication PLUS other security measures. Again, plaintiffs allege several other measures they believe should have been in place, including verifying the computer sending the wire transfer instructions, security testing and fraud monitoring programs.  The key issue here will be determining what other similar banks are doing to address this risk.

Moreover, even if 2-factor authentication is considered the “industry standard,” under the law an entire industry may not be implementing reasonable security. The rationale for this was explained by Judge Learned Hand in the famous (for first year law students at least) T.J. Hooper case. In T.J. Hooper, the plaintiffs were shipping two barges full of cargo when the ships encountered a storm. The barges were accompanied by two tugboats owned by the defendants. Unfortunately the tugs were unable to safely pull the barges from the storm and the cargo they carried was lost. The plaintiffs asserted that the defendants were negligent because their tugboats were not equipped with effective radio sets capable of receiving warning of the storm. The defendants argued that they did not owe the plaintiffs a duty to carry such a radio because they were a new technology and it was not a common practice in the tugboat industry to carry such radios. Judge Learned Hand disagreed:

Indeed in most cases reasonable prudence is in fact common prudence, but strictly it is never its measure. A whole calling may have unduly lagged in the adoption of new and available devices. . . . Courts must in the end say what is required. There are precautions so imperative that even their universal disregard will not excuse their omission.

What is the import of this? Under the law for purposes of negligence, a defendant can avoid liability even if a plaintiff suffered harm as long as the defendant did not breach its duty of care. In this context if the bank's security measures where "reasonable" under the law it would not be liable. I think the fact that the bank used 2-factor authentication and can point to the FFIEC guidance will help its cause in this respect. Nonetheless, it is possible the court will rule either that industry standards have evolved further or that the entire online banking industry was “lagging” behind in its reliance on 2-factor authentication. From a legal perspective it will be very interesting to watch the court’s analysis on the issue of reasonableness as it relates to industry standards (and hopefully it will provide more guidance for lawyers and banks going forward).

What about EMI’s fault?

There is a concept in the law called contributory negligence (or comparative negligence). You can read more about it here. Essentially this concept recognizes that a plaintiff (the bank customer in this case) may have also been negligent and may have contributed to the harm it allegedly suffered. In some States if the plaintiff was more than 50% responsible, it would be barred from any recovery. Other states, including Michigan (where the EMI Lawsuit was filed) employ a “modified comparative negligence” approach. Using this approach, if the plaintiff was 60% negligent and the bank 40%, the bank would be responsible for only 40% of the plaintiff's loss. I think there is likely a good argument to be made that EMI should bear some of the responsibility for the unauthorized use of their online banking accounts. In fact, if you read Comerica’s answer to EMI’s complaint you will see that Comerica appears to be taking that position:

16. Denied that the alleged website “appeared to be a Comerica website” to any reasonably alert person who was responsible for safeguarding EMI’s financial records and digital credentials.

26. Denied that any perpetrators infiltrated EMI’s bank accounts. Valid credentials assigned to an EMI employee were used to authenticate a logon for purposes of online banking transactions. If some unknown criminals used those credentials, rather than the EMI employee to whom they had been entrusted, this was caused solely by the actions of that EMI employees.

Whether EMI bears some responsibility will be a very fact-intensive inquiry that will include an analysis of the spoofed email, Comercia's previous practices concerning requests for login-credentials and the actions and decision-making process of the employee that provided the credentials to the criminals.

Conclusion

In general, I believe that these online banking cases have more legs than other types of security breach lawsuits because the plaintiffs have suffered actual damages/harm. Evidence of this is the Shames-Yeakel case, which proceeded past a motion for summary judgment. Contrast this with the numerous security breach cases brought by consumers that have been dismissed relatively early in litigation. In those cases, the plaintiffs whose information was stolen have argued that they suffered harm because they had to pay for credit monitoring. Courts have more or less consistently rejected this argument. For online banking cases, plaintiffs don’t have that problem. In this case the plaintiff is out hundreds of thousands of dollars, so damages are clear.

So if a plaintiff can get past the motion to dismiss phase on the issue of damages, do the defendants have an opportunity to get a summary judgment (rather than risk having to present their case to a judge and jury – something every company likes to avoid, if possible). The problem for banks is that the issue of whether a bank’s security measures were “reasonable” is likely a “question of fact.” Courts are typically not willing to grant summary judgment where questions of fact exist for a jury to decide.

That said, this case is a little different than those in my other blog post because of the phishing issue and because the issue of commercial reasonableness is a question of law under MCLA 440.4702(2). Whether a duty exists under the law is typically a question of law that Courts (as opposed to juries) typically decide. I think there will be a battle at both the pleading and summary judgment phase with the banks trying to argue that they have no duty under the law to prevent their customers from being duped and that their practices were commercially reasonable 440.4702(2).  If Comerica does not win these argumenst then this case could go to a jury, which poses legal risk.
Tags: , , , , , , , , , , , ,

Online Banking and "Reasonable Security" Under the Law: Breaking New Ground?

With the report of another data security-related lawsuit involving online banking (another 2009 lawsuit referenced here involved an alleged loss of over $500,000), and a recent victory for a plaintiff on a summary judgment motion in a similar online banking data security breach case, the question arises whether online banking breaches will yield some substantive case law on the issue of “reasonable” security procedures as a matter of law. Ironically, this question may be answered by reference to a 20 year old model code (UCC 4A) originally drafted to address technological advances from that era. This post explores two complaints recently filed against banks for online banking  (Patco Construction Co. v. People’s United Bank ("PATCO”) and JM Test Systems, Inc. v. Capital One Bank ("JMT")) and a court’s ruling on a motion for summary judgment in similar lawsuit (Shames-Yeakel v. Citizens Bank Memo and Memo Order on Motion for Summary Judgment – “Shames-Yeakel” case).  In short, since the Shames-Yeakel case proceeded past the "damages" pleading phase, it (and possibly these other online breach suits) reveals how some courts view security "standards" and approach the question of whether a company has achieved "reasonable security."  I also believe they demonstrate the difficulty defendants face if they have to defend their security measures in a litigation context after a security breach.

Plaintiffs’ Allegations

In general, these matters involve a fairly consistent general set of allegations: 

  • the bank allowed a small business to utilize online banking, including ACH transfers;
  • nefarious third parties somehow gained access to the plaintiffs’ online banking account (e.g. login credentials such as username, password, “secret question”, etc.), which allowed them to use the online banking system to transfer (a.k.a. steal) funds out of the plaintiffs' bank account;
  • the bank failed to provide notice to the plaintiffs of unusual or suspicious activity; and
  • the bank’s security measures did not prevent the fraudulent transfers and were not commercially reasonable.

In addition, the following facts were alleged in one or more of the three cases:

  • the bank failed to block a transfer request from an IP address that was previously unused by the plaintiff (e.g. an IP address was different than typically used by the plaintiff);
  • the bank did not utilize multifactor-factor authentication (e.g. “token-based” authentication or fax confirmation);
  • the allowable daily transfer limit vastly exceeded the plaintiffs’ average/maximum daily transfers (e.g. in PATCO, the daily maximum limit was $750k, but the most PATCO ever needed to transfer was $36.6k);
  • the funds were transferred to individual accounts to which the plaintiffs had never transferred funds before; and
  • despite having been informed of unauthorized transactions by the plaintiff, the bank did not close the account in order to prevent more fraudulent transactions (JMT case only).

Alleged Legal Theories

Based on these facts the plaintiffs asserted various causes of action against the banks relating to security practices. In both PATCO and JMT, the plaintiffs referenced the bank’s failure to comply with section 4A-202 (ISSUE AND ACCEPTANCE OF PAYMENT ORDER) of the Uniform Commercial Code (in PATCO the plaintiffs cited MRSA 4-1202 and in JMT they cited RS 10:4A-202). Under 4A-202, as long as the bank and its customer have agreed that the customer will be verified pursuant to a “security procedure”, a payment order received from the customer will be considered an effective order by the customer, whether it was actually authorized by the customer, but only if the security procedure was “commercially reasonable” and followed by the bank.   In PATCO, for example, the plaintiffs alleged that 4A-202 had been violated for the following reasons:

  • failure to offer/use multi-factor authentication to authenticate the plaintiffs’ identity for online transactions;
  • use of an unreasonably low trigger for “challenge question” authentication;
  • failure to provide and IP address block that would block orders originating from unapproved IP addresses;
  • failure to detect fraud because the amounts of the payments were the largest ever made under the account, were sent to accounts to which funds had never been transferred, originated from an IP address that had never previously been used and occurred on days that the plaintiff normally did not may payments;
  • failure to offer a dual control option requiring two people to log on in order to complete a payment transaction;
  • allowing a transfer limit that exceeded the needs of the plaintiff;
  • failure to manually review ACH payment batches prior to submission for payment; and
  • failure to provide email alerts concerning unusual transactions.

In addition to a UCC violation, all of the cases included allegations of negligent security and breach of contract. In Shames-Yeakel, the plaintiffs alleged that the bank’s failure to implement multi-factor authentication did not comply with a document put out by the Federal Financial Institutions Examination Council (“FFIEC”) entitled “Authentication in an Internet Banking Environment” (the FFIEC Report), and therefore presented questions of fact as to negligence. The JMT plaintiff, in support of its negligence claim, alleged a failure to meet the security standards of “similarly situated” national banks,  a failure to implement security procedures that were “commercially reasonable,” and a failure of the bank to comply with its own existing security procedures.

The Judgment on the Shames-Yeakel Motion for Summary Judgment

While the PATCO and JMT complaints have not yet been tested on motion, the Shames-Yeakel plaintiffs have survived a summary judgment motion. In addition to other statutory claims that were particular to the fact pattern at hand, and relevant to this blogpost, the plaintiffs alleged that the bank was negligent in failing to protect the plaintiffs’ online account, and in particular breached its duty to sufficiently secure its online banking system. 

As such, the threshold question the court addressed was whether a duty to “sufficiently secure” its online banking existed for the Bank.   On that point, the court extrapolated a duty to secure based on a bank’s general duty to refrain from disclosing its customer’s information:

A number of courts have recognized that fiduciary institutions have a common law duty to protect their members’ or customers’ confidential information against identity theft. Although this court could not find an Indiana case addressing the matter, Indiana courts have held that a bank “has a duty not to disclose information concerning one of its customers unless it is to someone who has a legitimate public interest.” If this duty not to disclose customer information is to have any weight in the age of online banking, then banks must certainly employ sufficient security measures to protect their customers’ online accounts.

(citations omitted; emphasis added). Apparently, according to the court, the bank-defendant did not dispute the existence of a duty to protect the plaintiffs’ account from fraudulent access. However the bank did contest the plaintiffs’ allegations that the bank breached its duty and that the breach caused harm to the plaintiffs.

On that issue, the court focused on the FFIEC Report. According to the court, the FFIEC  Report indicated that single-factor identification was “inadequate” for securing online transactions of financial institutions. Moreover, a vice president of the bank admitted that the bank did not implement additional security measures beyond single factor identification until after the breach at issue. Thus, the court held that a reasonable finder of fact could potentially conclude that the bank breached its duty. Moreover, since the bank had not reimbursed the plaintiffs for their economic loss, the court ruled that a jury could find that the bank’s failure to secure caused such economic loss (as well as mental and emotional anguish).

Analysis

The Shames-Yeakel case (as well as potentially the PATCO and JMT down the line) is very interesting from a data security breach liability perspective. First, most data breach cases (typically involving suits by consumers or banks issuing credit cards) are dismissed early on for lack of damages or based on the economic loss doctrine. With online banking the damage component is clear (e.g. lost money) and since the main loss of money arguably constitutes “direct damages” (rather than purely economic damages), the economic loss doctrine may not bar an action. As such the court must rule on substantive issues such as the existence a duty to provide “reasonable security” and whether that duty was breached and caused damages. This is what happened in Shames-Yeakel.

The approach taken by Shames-Yeakel was also very interesting. In essence, the Court took a non-binding, completely voluntary “guidance” document and allowed it to serve as the standard of care for “reasonable security” in this context. This FFIEC Report was not an official “standard” and did not reflect any statutory requirements (for purposes of establishing a negligence per se theory). I am sure that the FFIEC and other bodies have put out a lot of papers (formal and informal) on various security and privacy issues, and if other courts are willing to accept these guidance documents as establishing standards (or better stated creating a question of fact for juries) then defendants of data breach cases may  face some significant liability in the future. While this particular FFIEC Report may be the appropriate benchmark in this case, I would have liked to see the court explain its rationale in more detail for converting this guidance document into the standard of care (e.g. Why this particular document? What other kinds of documents reports may establish the standard? If it was a report from a non-governmental body would it have the same weight? Must the standard reflect some sort of consensus? What opposing guidance or opinions exist, how much weight are they given in determining or discarding a particular alleged standard?, etc.)

Beyond the court’s decision to arguably elevate the importance of the FFIEC Report, it is not even clear that the report stands for the very broad proposition that single-factor authentication for online banking is inadequate. The following excerpt from the FFIEC Report summarizes the authors' views on the inadequacy of single-factor identification:

The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Financial institutions offering Internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services. Account fraud and identity theft are frequently the result of single-factor (e.g., ID/password) authentication exploitation. Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

Note that the FFIC Report indicates that single-factor authentication may be inadequate if it is the only control mechanism or where a risk assessment indicates that the use of single-factor authentication is inadequate. The FFEIC Report then lists layered security or multi-factor authentication as potentially compensating for single-factor authentication (while I will let my security friends weigh in on this issue, as well as identify other potential compensating controls). In short, the FFEIC Report on its face seems to indicate that it is possible to utilize single-factor authentication with other controls such that risk is adequately mitigated. In contrast, the court in Shames-Yeakel stated the following: 

In [the FFEIC Report] the Council described single-factor identification (username/password) as “inadequate” to secure the online transactions of financial institutions. 

Despite overstating the conclusion of the FFIEC report, however, overall the court’s decision to deny the motion for summary judgment may be okay. It is likely that both parties have contradictory expert testimony on the issue of reasonable security. Second, some testimony existed from the bank's vice president hat appears to establish that only single-factor authentication was used by the bank (although this seems contradicted by the banks’ expert testimony that the bank employed reasonable security measures). Moreover, in general, whether single-factor authentication plus additional security adequately reduced the risk appears to be a factual question. I think the court could have come out with the same ruling without overstating the conclusions of the FFIEC report simply by accurately citing the FFIEC report, the vice president’s testimony, and indicating that both sides had contradictory opinions on the overall issue of whether the bank’s security was reasonable. 

Conclusion

The Shames-Yeakel ruling highlights potential significant difficulties for defendants if plaintiffs are able to proceed past the motion to dismiss phase in a data breach lawsuit. Despite the court’s inaccurate description of the FFIEC Report, when the question of whether security controls were adequate to reduce risk to an appropriate level is posed, it will be difficult for defendants to win on summary judgment. Like many other types of lawsuits, it will come down to a “battle of the experts”, and for these cases a “battle of the standards” (e.g. which standards should the defendant have complied with and did they comply with them). As such, for data breach defendants the pleadings phase will be where the street brawl will take place. Defendants will want to (and should) aggressively attack the early “questions of law” (e.g. does a duty exist at all, did the plaintiff suffer legally cognizable harm). If plaintiffs can get past this phase, it seems that it will be a challenge for defendants to win a motion for summary judgment and avoid the prospect of a jury trial (I think, for many data breaches, causation will be the most likely candidate for a defendant victory on summary judgment).
Tags: , , , , , , , , , ,

Mastercard Changes to their PCI Compliance Rules

Under Mastercard's new rules concerning merchant level definitions, apparently companies that were previously level 4 merchants (and did not have to do a PCI assessment unless requested by their acquiring bank) have been converted to level 3 merchants (which do need to conduct at least a self assessment).   More details here.

Mastercard announces fine regime for PCI non-compliance:  details here from Branden Williams of Verisign: LINK.

Tags: ,

Nevada's Security of Personal Information Law Post Four: Encryption and PCI Compliance Requirements

The following FAQs address the encryption and PCI compliance requirements of Nevada's Security of Personal Information Law, which were added pursuant to a recent amendment to the law.  The rest of the FAQ is linked to here.

 

(5) ENCRYPTION and PCI COMPLIANCE (SB 227 - Amendment to NRS 603A)

Does the Nevada Security Law mandate compliance with the Payment Card Industry Data Security Standard ("PCI")?

Yes, certain data collectors must comply with the "current" version of PCI.

Some observations:

  • PCI is always changing. One of the biggest problems with the PCI compliance requirement under the Security Law is that PCI is constantly being changed and updated. PCI is currently on version 1.2 (the third version in 4 years) and is currently soliciting comments concerning potential modifications. This literally makes the Security Law a moving target. On a certain level this makes sense - the PCI standard and good security evolves as the risks and technology changes. However, from a compliance standpoint constant vigilance is required to ensure compliance. Previously, non-compliance could result in a contract breach claim, but under the Nevada law it can result in an attorney general action and statutory liability.
  • PCI is ambiguous. Unfortunately the PCI standard is ambiguous as written in many sections and as applied in many circumstances. This is due in part to the one-size-fits-all nature of the standard. The problem is exacerbated, however, because there are multiple sources of interpretation, including the PCI Council, merchant banks, the card brands and qualified security assessors. Even within the PCI Council itself multiple methods of interpretation exist, including guidelines, FAQs, prioritized approaches, and email answers to questions. Moreover there is no set interpretative hierarchy between potentially competing interpretations. For example it is not clear whether PCI Council guidance document would trump an FAQ, or the interpretation of a merchant bank.
  • PCI is contractual in nature. This is a corollary to "PCI is ambiguous." PCI compliance is normally mandated by contract. Typically a merchant will enter into a "merchant agreement" with a merchant bank or processor so it can accept credit cards. That merchant agreement will mandate compliance with PCI. If there is an ambiguity, since the merchant's obligations are derived by contract, naturally the "best" source to resolve those ambiguities is with the merchant bank that is party to the agreement. If the merchant bank "gets it wrong" or agrees to an interpretation that is not compliant, under the Nevada law that could result in a violation of law.
  • PCI is one-size-fits-all. PCI is made up of over 200 individual requirements/sub-requirements. For small businesses it may be difficult, if not impossible, to comply with (from a resource standpoint). Yet neither the PCI standard nor the Nevada Security Law make any exception or allowance for this. As a result, on day one thousands of businesses are likely to be non-compliant with the Nevada law.

Who must comply with PCI under the Nevada Security Law?

Data collectors doing business in Nevada that accept a payment card in connection with the sale of goods and services.

Some observations:

  • Do service providers have an independent and direct obligation to comply with PCI under the Security Law? Typically, under the PCI regulatory scheme, service providers that store, handle or transmit cardholder only have a direct obligation to comply with PCI if they are contractually required to do so. They have no independent legal duty to comply with PCI under normal circumstances. The Nevada law, however, may provide a direct duty for service providers to comply with PCI. Service providers appear to fall into the definition of "data collectors" because they typically "handle, collects, disseminates or otherwise deals with nonpublic personal information."

The issue becomes whether a service provider "accepts a payment card in connection with a sale of goods or services." Could this language extend beyond the "merchant?" If the language read "accepts a payment card in connection with for a sale of its goods or services," then it would appear to be limited to merchants. However, the "in connection" language arguably extends the duty to service providers. For example, some payment gateways directly "accept" payment card numbers from customers online on behalf of merchants in connection with the merchant's sale of goods and services. The merchant may not ever receive any payment card data. Could this render the service provider directly responsible for complying with the Nevada Security Law? Without more research the answer is unclear.

  • No "data collector" status means no compliance obligations. Companies that do not maintain "personal information" are not "data collectors" under the Security Law, and are therefore not subject to the law. "Personal Information" under the law is defined to include first name or first initial and last name, in combination with any of the following data elements, when the name and data elements are not encrypted: (1) SS#; (2) driver's license number or identification card number; and/or (3) account number, credit card number or debit card number, in combination with a security code, password or access code that would permit access to the person's account. A business would not be a "data collector" in the following scenarios and therefore the Security Law would not apply to it:
    • An organization that accepts credit cards, but encrypts either the name or data elements (or both) does not have to comply with PCI under the Security Law because it is not a data collector. 2. An organization that for some reason does not maintain the first name/first initial of its customers it would not be a data collector. 3. An organization that does not maintain credit card numbers and security codes associated with those credit card numbers (assuming no SS# or driver's license/ID number is present) would not be a data collector. So a company that only maintained first/last name and credit card number, but not security codes (CVV, CVS, full stripe data, etc.) would not be a data collector subject to the law. Please note that just because a company is not a "data collector" under the Security Law does not mean that it does not have an independent contractual or common law obligation to comply with PCI. PCI applies typically to companies that have entered into a merchant agreement to accept payment cards where they store, transmit or process payment card data. The PCI standard can also be used to establish the standard of care in a negligence suit.
  • Nationwide Scope for Online Companies. Under this section of the Security Law the data collector must be "doing business" in Nevada. While this section may appear to create a smaller subset of companies, since the concept of "doing business" may include simply running a website that is accessible by Nevada residents, the practical effect may be a nationwide scope for many companies selling goods and services online.

What version of PCI must applicable data collectors comply with?

The Security Law indicates that applicable data collectors must comply with the "current" version of PCI. It is not clear whether this means the current version of PCI in existence at the time this bill went into law or the current version of PCI in existence at the time of a transaction involving payment card data. However, reference to due dates for PCI compliance set by PCI or the PCI Council suggest the latter.

An observation:

  • Ambiguity Concerning Setting PCI Compliance Dates. Compliance dates for PCI are set by the card brands, not the PCI Council. Moreover, there are no such dates in the PCI standard itself. Those dates are contained in each card brand's security program or operating regulations.

Does the Nevada Security Law require encryption of personal information transmitted electronically?

Yes, data collectors doing business in Nevada, subject to exceptions discussed below, may not transfer personal information outside of its secure systems through an electronic transmission unless encrypted.

Does the Nevada Security Law require encryption of personal information on data storage devices?

Yes, if the data collector desires to move a data storage device containing personal information beyond the logical or physical controls of the data collector or its storage contractor, it must use encryption to ensure the security of the personal information.

What kind of encryption technologies and practices must be used to comply with this section?

To be compliant with the Security Law, data collectors must use an encryption technology that renders such personal information indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data, whichhas been adopted by an established standards setting body, including for example, the Federal Information Process Standards published by the National Institute of Standards and Technology.

In addition, data collectors must utilize appropriate management and safeguards with respect to cryptographic keys in order to protect the integrity of its encryption process. The data collector's key management procedures and safeguards must be consistent with guidelines set forth by an established standards setting body, including for example, the National Institute of Standards and Technology.

What exceptions exist to the encryption requirements under the Nevada Security Law?

The electronic transmission encryption requirement does not apply to electronic voice transmissions or facsimile transmissions. None of the encryption requirements of the law apply to telecommunication providers conveying communications of other people. Finally these encryption requirements do not apply to data transmissions over secure private communications channel for: (1) approval or processing of negotiable instruments, EFT transfers or similar payment methods; (2) issuance of reports regarding account closures due to fraud, substantial overdrafts; or (3) abuse of ATM machines or related information regarding a customer.

If a data collector complies with the encryption requirements or the PCI mandate can it be held liable for a security breach involving personal information? (Does the Security Law provide a safe harbor)?

No, as long as the breach was not caused by the gross negligence or intentional misconduct of the data collector, its officers, employees or agents. Yes, it appears that the Security Law provides a limited safe harbor. However, it is uncertain how far this "safe harbor" extends.

Some observations:

  • Scope of "Safe Harbor" - Different Legal Theories. Some may argue that the safe harbor protects the organization from all damages no matter what legal theory is alleged (e.g. negligence, contract, fraud, etc.). Support for this theory can be found where the law references "gross negligence and intentional misconduct," which arguably implies that other theories of liability can be barred by the safe harbor. Others may contend that this safe harbor only extends to liability under the Nevada Security Law itself. The law does not explicitly clarify the scope of the safe harbor.
  • Scope of "Safe Harbor" - Choice of Law. Assuming the safe harbor does apply to legal theories above and beyond violations of the Security Law, can it be utilized to block liability if a case is brought in another State? This comes down to a choice of law analysis. If Nevada's law is deemed to be the choice of law then the Security Law safe harbor may bar liability. However, if Nevada law is not the law applied by a court, other claims will likely not be barred. It would not be surprising to see breach defendants transferring cases to Nevada and arguing for Nevada as choice of law in order to try to take advantage of the safe harbor.
  • PCI safe harbor easy to lose? As most PCI security professionals know, especially with respect to large organizations, it is not difficult to find a violation of one of the over 200 sections/subsections of PCI. Unfortunately the Security Law does not provide a safe harbor for "material" compliance with the law. As such, technical violations or minor violations, as well as interpretative differences, can result in a loss of safe harbor protection. The PCI incident response procedures can also pose risk that PCI compliance will not be found. Some companies therefore, may view the safe harbor as illusory.

Up Next: Blog Post Five: Remedies, Penalties and Enforcement

Please note, while I am an attorney this post does not in any way constitute legal advice or a legal opinion, and should not be relied upon to take any action or be the basis for any inaction. The this law is complex and additional research is necessary. If you are interested in a full legal analysis please contact me directly at djn@davidnavetta.com.

 
Tags: , , , ,

Merrick Bank v. Savvis: Merrick Files its Response to Savvis' Motion to Dismiss

On July 7, 2009, Merrick Bank filed its response to Savvis' motion to dismiss.  I have not had a time yet to analyze the brief, but will do so in the near future.  In the meantime, if any readers would like to share their insight, please submit a comment!

Tags: , ,

FAQ on Nevada's Security of Personal Information Law (NRS 603A)

InfoSecCompliance ("ISC") was recently asked by a prospective client to provide a summary of Nevada's Security of Personal Information law (NRS 603A) and a recent amendment to the Security Law that incorporated the Payment Card Industry Data Security Standard ("PCI"). ISC decided to try something new and create a Frequently Asked Questions document around the PCI requirements contained in the Security Law. For better or worse (after sinking in 15 - 20 hours) ISC ended up doing FAQs for the entireNevada Security Law. This turned out to be a much bigger work than originally anticipated, so ISC is going to do a five-part blog post series breaking down the Nevada Security Law into (hopefully) digestible parts.

 

This FAQ is broken down into six sections that will be posted over five posts over the next week or so. The postings will be broken down as follows:

Post One: The Basics of Nevada's Security Law and Destruction of Records
Post Two: Security Breach Notice
Post Three: Required Security Measures
Post Four: Encryption and PCI Compliance
Post Five: Remedies, Penalties and Enforcement

I will update this page with new links to each post as the post is made. This is the first time I have tried to convert a complex law into an FAQ format and I am not certain how it turned out. The goal was to make the law digestable by not only lawyers, but also security and privacy professionals. If you have the time, please leave a comment or send me an email and let me know if it worked for you or what could be improved. If this format is effective, ISC may do it for other laws as well (where possible).

Please note, while I am an attorney this post does not in any way constitute legal advice or a legal opinion, and should not be relied upon to take any action or be the basis for any inaction. This law is complex and additional research is necessary. If you are interested in a full legal analysis please contact me directly at djn@davidnavetta.com.

 
Tags: , , , , , , , , , ,

TJX Settles with State Attorneys General for $9.75 Million

The TJX breach saga came a little closer to an end (excluding of course the still-pending case being pursued by a couple of issuing banks) with the announcement of a settlement with 41 State attorneys general that brought actions under their State's respective consumer fraud and deceptive practices laws (a copy of the settlement document can be found:  HERE).  This is a summary of the TJX settlement.

Monetary Settlement Breakdown

    The total monetary settlement amounted to $9.75 million, which is broken down as follows:

    • $5.5 million to the Attorneys General for State consumer protection activities related to data security or otherwise, including consumer education and outreach, prevention or monitoring programs, consumer protection enforcement, litigation, local consumer aid funds, consumer protection enforcement funds and public protection funds

    • $2.5 million to develop a "data security fund" to be used by the States to research the benefits of data security technology and develop best practices, protocols, policies or model legislation or regulations concerning data security or data security technology, develop and implement programs, education and outreach for consumers with respect to data security, and for other efforts to examine data security matters and to protect consumer privacy

    • $1.75 million in fees and costs associated with the States' investigation of the TJX breach

    This brings the total reportedly paid out for settling various actions against TJX to approximately $75 million (this does not include forensic expense, attorney fees, etc.).

    Information Security Program

    In addition to monetary payments, the settlement also requires TJX to "implement and maintain a comprehensive Information Security Program reasonably designed to protect the security, confidentiality and integrity of Personal Information."  The general description of the mandated program essentially matches the information security program required pursuant to TJX's consent order with the FTC.

    However, this settlement goes beyond the general requirements of the FTC's consent order and mandates specific information security controls and actions, including:

    • Replacement of all WEP based wireless systems with WPA wireless systems (or equivalent)

    • No storage of sensitive authentication information related to payment cards (e.g. magnetic stripe track data, PIN numbers/PIN Blocks, and CVC2/CVV2/CID numbers)

    • Segmentation of TJX networks storing, processing or transmitting Personal Information (including Cardholder Information) from the rest of TJX's network

    • "Security password management" for the portions of the TJX computer system that store, process or transmit Personal Information

    • Implementation of a security patching protocol for the portions of the TJX computer system that store, process or transmit Personal Information

    • Use of Virtual Private Networks/encryption for transmitting Personal Information

    • Anti-virus software

    • Intrusion detection systems

    • Access control measures

    The order indicates that the previously mentioned requirements alone do not necessarily amount to reasonable actions to protect Cardholder or Personal Information.  The settlement sets a 120 day deadline for TJX to implement the required information security program.  TJX must also have a third party security assessor to create a report certifying compliance.  The first report of the third party assessor is due 180 days after the settlement agreement date, and subsequent assessments must occur on a biennial basis (although TJX does not need to provide them to that AGs unless requested).  TJX's obligations with respect to the information security program (and other requirements of the settlement) are to last for 20 years.

    Breach Notification

    The settlement requires TJX to provide notice to the relevant attorney general 10 days after it has provided notice to its customers of any breach of personal information.  The settlement sets forth several categories of information that must be provided to the attorneys general.

    TJX Payment Card Security Advocate

    This is where the settlement agreement gets more interesting.  As a condition of the settlement, TJX essentially has to advocate for improvements in the security of the payment card system.  In particular, TJX must contact Visa and Mastercard and its acquiring bank and volunteer to participate in pilot programs for testing new security-related payment card technology (such as chip-and-PIN technology).   TJX also must take steps encourage the payment card industry to achieve "end-to-end" encryption of cardholder data (all the way through the bank authorization process).  TJX must take such steps within 180 days and must submit a report to the Attorneys General indicating TJX's progress.
    Tags: , , , , , ,

    Merrick Bank v. Savvis Update: Savvis Files Motion to Dismiss

    As reported previously, the CardSystems security breach has resulted in a lawsuit brought by a merchant bank (Merrick Bank) against CardSystem's security assessment company (Savvis).  The suit alleges that Savvis negligently certified CardSystem's security as compliant with Visa's Card Information Security Program ("CISP"), and negligently represented that CardSystems was compliant.  Earlier this month Savvis filed a motion to dismiss this case.  This post summarizes and explores that motion.

    Choice of Law

    The threshold issue addressed by Savvis is which States' law applies to this case (the choices appear to be Utah, Missouri or Arizona).  This question is extremely important with respect to Savvis' statute of limitations argument.  Under Arizona law, the time limit for filing negligence and negligent misrepresentation claims is two years.  It may be longer for other States, such as Utah and Missouri which will be Merrick's counter-argument (note, Savvis contends that Merrick Bank's filing of this lawsuit originally in Missouri was a blatant attempt to avoid Arizona's two year statute of limitation). While this post will not go into the intricacies of the choice of law analysis, it will point out one fact that could hurt Merrick Bank.  Both Merrick Bank and Savvis were sued previously by Cumis Insurance Society because of the CardSystem's breach (Cumis represents credit unions acting as issuing banks that allegedly incurred expenses because of the breach -- the Cumis case is still pending and the subject of a future post).  In the Cumis case Merrick Bank previously took the position that Arizona law applied to the CardSystem's breach, and a Federal court in California agreed with Merrick.  While this circumstance is not the ultimate determining factor on this issue, it will make it more difficult for Merrick Bank to avoid the imposition of Arizona law.  It will be interesting to see what Merrick Bank comes back with in its reply brief.

    Statute of Limitations

    Savvis' first argument for dismissal is procedural in nature.  It argues that Merrick Bank failed to file its lawsuit within Arizona's two year statute of limitations ("SOL").   The SOL analysis involves determining when the causes of action "accrued" and calculating how much time elapsed since the accrual date.  In Arizona, the SOL begins to run when the plaintiff knew or by reasonable diligence should have known of the defendant's alleged tortious conduct.   In this case, Savvis has on its face what appears to be a very favorable timeline: Savvis argues that Merrick Bank's claims accrued no later than July 2005, and its filing of suit on May 12, 2008 was more than three years after that date.

    Savvis' contention is based on Merrick's allegation that it knew that CardSystems was not CISP compliant "immediately" after CardSystem's May 2005 breach.  In addition, the post-incident forensic report allegedly indicated that CardSystems was not CISP compliant at the time Savvis issued its June 2004 Report on Compliance. Savvis also points to Merrick Bank's January 20, 2006 lawsuit against CardSystems as evidence that it should have known by reasonable diligence that it had a potential claim against Savvis.  In other words, if Merrick Bank knew it had a claim against CardSystems in January 2006 why didn't it reasonably know of Savvis' alleged tortious conduct at that time?  Note, that even if the January 2006 date it the accrual date, Merrick Bank still would not make the two year SOL.

    In addition to its SOL argument, in the alternative, Savvis claims that Merrick's complaint failed to adequately allege negligence and negligent misrepresentation.

    Dismissal of Negligence and Negligent Misrepresentation

    Savvis argues, that even if its position on the SOL is wrong, Merrick Bank's negligence and negligent misrepresentation allegations are flawed and should be dismissed.  Savvis first addressed the negligent misrepresentation claim, citing Restatement section 552(2) which limits negligent misrepresentation liability to loss suffered:

    (a) by the person or one of a limited group of persons for whose benefit and guidance he intends to supply the information or knows that the recipient intends to supply it; and

    (b) through reliance upon it in a transaction that he intends the information to influence or knows the recipient so intends or in a substantially similar transaction.

    Based on the comments associated with section 552(2) and Arizona caselaw, Savvis maintains that it can only be liable where the maker of the representation intends to reach a particular person or group known to Savvis, and distinct from the larger class who might reasonably be expected to have access to, and take action in reliance upon, such information.   Savvis maintains that Merrick was not part of a defined group for whose benefit Savvis provided its representation of CardSystem's CISP compliance.   Savvis argues that Merrick's claim should be dismissed because Savvis did not make any representation directly to Merrick intending to influence its behavior "distinct from the much larger class" of acquiring banks involved with the Visa and Mastercard systems.  Rather, Savvis made its representation directly to CardSystems and the card brands.  Savvis also pointed to the Court's prior decision in the lawsuit filed by Cumis against Savvis.  In that case the same Court dismissed a negligent representation claim because no representations where made to Cumis or its insureds (issuing banks) distinct from the larger class of participants in the Visa and Mastercard systems (as stated above,  this blog will have more on that decision soon).  Finally, from a public policy perspective, Savvis indicated that interpreting section 552 more broadly would expose it to limitless potential exposure.

    In addition, Savvis made quick work of Merrick's negligence claim.  According to Savvis, under Arizona law "providers of professional information" such as Savvis may be sued only for negligent misrepresentation.  Savvis contends that plaintiffs are not permitted to avoid the limitations set forth in section 552 simply by alleging a general negligence claim.  Signficantly, Savvis did not directly attack the merit of negligence claims on the basis of whether it owed any duty to Merrick Bank.  (UPDATE -- 062409: as one reader points out, by claiming that the negligence claim is subsumed into the negligent misrepresentation claim, one could say that Savvis is indicating that they owe no duty under a pure negligence theory.  I have not read the citations within the case so I don't know if that is the case).

    Conclusion

    The procedural aspects of this case, including the previous transfer of this matter from a Missouri court, as well as the choice of law, will have a significant impact on the case moving forward.  Considering Merrick Bank's prior indication that Arizona law applies, it appears that Savvis has a solid statue of limitations argument that could kick the case out before any hearing on the merits occurs (which will keep the rest of the world in the dark on the substantive merits of this case).  On this issue it will basically come down to when Merrick Bank knew, or reasonably should have known, it had a case against Savvis.  Obviously Savvis is going to argue for the earliest date possible.  Expect Merrick to come back with its own analysis on how it took longer for it to "discover" a valid claim against Savvis (e.g. perhaps the "necessary" facts of Savvis' alleged culpability only came out after depositions or other discovery in the CUMIS case).  To the extent there are any factual issues wrapped into this analysis the Court might passe on a motion to dismiss an allow the litigants to engage in some discovery (at least limited to this issue).

    On the merits, as previously predicted, the main issue is whether Merrick Bank is a "person" or a "one of a limited group" for whose benefit Savvis supplied the CISP certification information.  This is going to be a close question.  Unlike issuing banks or their insurers (as referred to by Savvis in relation to the Cumis lawsuit), processors like CardSystems have a direct contractual relationship with acquiring banks.  That relationship requires processors, before acquiring banks can retain them, to certify compliance with payment card standards such as CISP.  It is difficult to argue that security assessors in this space do not know this.  In addition, it can be argued that these assessments are intended for the direct benefit of acquirers.  Not only does it give acquiring banks and indication that the risk of credit card fraud is decreased, it also allows them to avoid contractually mandated. fines, penalties and recovery costs in the event of a security breach or otherwise.

    It will be interesting to see Merrick's response on this matter.  Note that even if this lawsuit does survive a motion for summary judgment there are other fact-based arguments that may allow this case to be dismissed on a different motion (e.g. motion for summary judgment).  Not only will the issue of intended class of persons be attacked by Savvis, but also the matter of whether Merrick Bank relied on Savvis' assessment (and not some other factor) will be tested.  More to come in the next few weeks.  Stay tuned.
    Tags: , , , , , ,

    Nevada Law Incorporates PCI and Provides a Liability Safe Harbor

    Nevada appears to be the second State to incorporate the Payment Card Industry Data Security Standard (PCI) into its personal information security law. Minnesota is the other State that incorporated part of PCI into its law. 

    In contrast to the Minnesota law (which only partially incorporated one subsection of PCI), the Nevada amendment requires "data collectors" doing business in Nevada to comply with the entire PCI standard:

    If a data collector doing business in this State accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the Payment Card Industry (PCI) Data Security Standard, as adopted by the PCI Security Standards Council or its successor organization, with respect to those transactions, not later than the date for compliance set forth in the Payment Card Industry (PCI) Data Security Standard or by the PCI Security Standards Council or its successor organization.

    Unfortunately there is a built in ambiguity in the law since neither the PCI standard itself, nor the PCI Security Standards Council set the PCI compliance date.  Rather, that is done by each card brand.  Ignoring that glitch, obviously, by incorporating PCI into its law, Nevada has explicitly given the PCI "the force of law."  This could have significant legal implications:  see more HERE and HERE.

    The Nevada amendment also appears to create a partial "safe harbor" for compliance with the law (and by extension PCI):

    3. A data collector shall not be liable for damages for a breach of the security of the system data if: (a) The data collector is in compliance with this section; and (b) The breach is not caused by the gross negligence or intentional misconduct of the data collector, its officers, employees or agents.

    While it is apparent that this language precludes liability for damages under the Nevada statute itself, it may also have wider application.  In other words, would this language bar a "regular" negligence lawsuit arising out of a security breach as long as the data collector was PCI compliant?  "Damages" in a breach of contract lawsuit? The broad language used ("shall not be liable for damages") suggests a solid argument exists for a "safe harbor" (even if compliance with the PCI standard itself was not "reasonable security") against any cause of action not involving "gross negligence" or "intentional misconduct."  More research, and potentially case law, will be necessary before the scope of this safe harbor is clarified.
    Tags: , , , , , , ,

    PCI Service Provider Contracting

    (NOTE:  cross-posted at  Branden Williams' Security Convergence Blog)

    As an attorney focusing on information security and privacy issues, I often get called in to assist companies to understand their legal liability risk around the PCI (self) regulatory system.  One of the key areas I get involved in is service provider relationships, and in particular section 12.8 of PCI and service provider contracts.  There are many aspects of 12.8 (and its subsections) that are potentially ambiguous and open to interpretation, but this particular article is not going to focus on those.  This post concerns the "written agreement" referenced in 12.8.2, which provides in full:

    12.8.2.  Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.

    We could debate whether a "written agreement" is the same of as a "contract" as referenced in version PCI v. 1.1 (under the law there is not much difference between a "contract" and an "agreement").  However, rather than concentrating on mere PCI technical compliance, this blog post will discuss the contract terms merchants should consider in their service provider agreements to actually manage their security risk.  Of course service provider agreements should address the PCI requirements, but for merchants concerned about truly mitigating their risk, much more is involved.  Coincidentally, I am in the middle of writing a book on payment card contracting that will be released through the American Bar Association, this post summarizes some of the ideas/concepts that will be in that book. 

    Pre-Contracting Activities

    In general, as most understand, organizations cannot "outsource" compliance with PCI.  That is to say, while merchants work with service providers that do some or all of the merchant's storing, processing or transmission of cardholder data, interested parties will still attempt to hold the merchant responsible for the service provider's non-compliance with PCI, and the impact of a service provider's payment card security breaches.  The service provider contract is one of the key places where this risk can and must be dealt with (the other mechanism for managing service provider risk is insurance, but that is another topic for another day). 

    The first step in the process is understanding what the merchant has legally obligated itself to.  This requires an analysis of the merchant's "upstream" contracts:  the various "merchant agreements" it has in place with payment processors and/or merchant banks.  If a merchant deals with more than one card brand there could be multiple contracts.  In essence, the goal here is to identify the merchant's upstream obligations and transfer those obligations down to any service providers utilized by the merchant.  For example, if the merchant agreement requires the merchant to indemnify the payment processor for fines and penalties imposed by card brands, the service provider agreement should require the service provider to do the same. One thing to note.  Most modern merchant agreements require merchants to adhere to the relevant payment card brands' operating regulations.  As such, merchants should understand those obligations (e.g. Visa's Account Data Compromise Recovery process) as well in order to transfer risk to their service providers.

    The second step is attempting to understand the risk posed by the particular service provider the merchant is dealing with.  What is the transaction volume the service provider is handling?  What controls does the service provider have in place or not have in place?  Has the service provider's security been independently assessed (e.g. by a QSA)?  What would happen to the merchant's business if the service provider went down (e.g. not all the risk is liability risk)?  If the service provider suffers a breach, does it have an incident response plan to mitigate harm and provide notice to the merchant?  In addition to general security requirements, depending on the nature of the transaction, this risk assessment may result in specific service provider contractual obligations.

    Security Contract Terms

    So what security-related terms should be in service provider contracts?  This answer to this question will vary depending on many factors (e.g. the type/purpose of the transaction, the data at issue, the laws that apply, the upstream contractual obligations of the merchant, etc.), but the following should be considered:•

    (1)    Definitions.  The payment card world relies on particular definitions and terminology.  To avoid confusion, where warranted, some definitions should be incorporated into the contract (e.g. PAN, sensitive authentication information, etc.).  This can be achieved in part for some key terms by referencing the PCI standard and/or the PCI glossary.

    (2)   "Preventative" Contract Terms -- Compliance and Controls.  The overall purpose of these terms is to contractually obligate the service provider to certain controls and practices with the hope of preventing non-compliance and/or a security breach (or at least to decrease the risk of those events).  In these sections the service provider should be required to comply with the requirements of the PCI regulatory system.  This includes, but goes beyond, the PCI standard itself.  Other elements of the PCI regulatory system include card brand security programs, FAQs, Guidance papers and other documents issued by the PCI Council, and the card brand operating regulations themselves. 

    In addition, if there any specific controls or security measures that the merchant wants the service provider to implement and maintain, that should be indicated.  Merchants can also draft other standards into the contact, such as ISO 27001, if desired.  Last, regardless of the specifics, the service provider should have an obligation to maintain "reasonable security" to protect the sensitive data that is the subject of the agreement.  By broadening the duty to "reasonable security" the hope is to avoid cases where technical compliance with PCI was achieved, but the service provider's systems were not actually secure.  The reference to "reasonable" establishes an "objective" standard under the law that allows for scrutiny in a litigation context.  Note that all duties in this section should be made ongoing and continuous (none of this PCI compliance only matters on the day the contract is signed), and the service provider should be required to comply with changes to the PCI Standard.

    (3)   Monitoring and Reporting.  These contract terms should provide the merchant with the right to monitor and enforce compliance with the service provider agreement, the PCI standard, payment card company security programs, etc.  There are many ways this can be achieved, including imposing reporting requirements on the service provider, providing the merchant with security assessment rights or actually requiring a periodic third party audit.  With respect to PCI, the agreement should require the service provider to allow the merchant (or third parties selected by the merchant) to conduct quarterly network scans, as well as QSA assessments. 

    What are the consequences of non-compliance with the agreement or PCI?  Monitoring is good, but if non-compliance is found the merchant must also have enforcement rights.  Without enforcement mechanisms the service provider's promises may be hallow.  Contractual penalties may be put into the contract, indemnification rights (discussed below), termination rights and other remedies may be considered.  The key here is to have some leverage to get the service provider to actually comply instead of having to abandon the relationship and find a new service provider.  .

    (4)   Security Incident Response.  Service providers and outsourcers act as an extension of the merchant's operations.  However, if their incident response procedures are out of sync it could be problematic.  Merchants need to understand their service provider's internal incident response procedure and then build contractual obligations that allow the merchant's incident response procedure to seamlessly meld with the service provider's.  This section may require service provider to identify a response coordinator to act as a liaison and cooperate fully with the merchant.  In addition, it may require an investigation, remedial action, notice and reporting to the merchant and payment card network, collection of evidence, documenting incident response and access to service provider systems, logs and data. 

    One of the key considerations here is identifying the party responsible for complying with breach notice laws.  Arguably, based on the statutes themselves, the primary duty would rest with the merchant, and the merchant would have to pass it on contractually to the service provider (note the primary duty would still reside with the merchant, so if the service provider refused, the statutes still require the merchant to comply).

    (5)   Rights, Remedies & Indemnification.  These terms transfers risk of loss between the merchant and service provider and provide other rights for breach of the service agreement or in the event the service provider suffers a security breach.  These terms are amongst the most important in the agreement, and are also the most contentious to negotiate.  However, they are also the most important and truly establish the baseline for the merchant's liability in the event the service provider makes a mistake.  The following should be considered.  Indemnification rights should require the service provider to pay for/reimburse the merchant for claims, attorney fees, lawsuits, fines, penalties and other costs associated with the service provider's non-compliance with the agreement and other requirements of the PCI regulatory system, as well as security breaches (whether compliant or not).  If there is a limitation of liability clause, exceptions should be considered for security breaches, fines and penalties due to non-compliance and other issues.  The same holds true for any consequential damages limitation clause that finds its way into the contract.  Additionally, termination rights should be built into the contract based on service provider non-compliance or security breaches.

    (6)   Insurance Clause.  An insurance clause requiring the service provide to purchase insurance covering security breach notice law compliance, liability arising out of security breaches and other professional errors or omissions should be considered (especially when utilizing smaller vendors).  If possible, the merchant should be named as an additional insured on the policy so that it can tap directly into the policy proceeds.  This clause should specify required limits and should require the insurance to be primary.  In addition, the contract should note that insurance proceeds are not intended to limit the amount of the service provider's liability.

    To implement these terms, what I often do is create a security schedule or exhibit that contains all/most of the security-related obligations of the contract.  Oftentimes a merchant will be forced to work with the service provider's contract.  If the security terms are in a pre-established exhibit, that exhibit can be incorporated into the contract (with some careful drafting of course).  On a final note, please understand that while this post has focused on PCI, a framework similar to that described above could be used for other statutory or security requirements, including GLB, HIPAA, EU Data Protection Directive and others.  In fact, for organizations with multiple security standards or laws to comply with, a security exhibit or schedule can be an efficient way for addressing all of the requirements at one time and in one place.

    Conclusion

    At this point in time when reliance on service providers and outsourcers to handle payment card information is high, while the legal liability risk associated with payment card security breaches is significantly growing, the security terms in a service provider contract have increasing importance. 

    In fact, I counsel my clients to raise some of the terms they want (especially indemnification) at the RFP phase instead of waiting until later. The key here is to create competition between potential service providers not only on price and scope of services, but also acceptance of risk and contract terms (those willing to accept more risk being potentially better candidates than those not so willing).  Organizations that wait to request protective contract terms until after they have selected a vendor may find those terms watered down during negotiations, and may be stuck holding all the risk of a service provider mistake (and you know that for most service providers the default is contract terms that completely insulate them from risk - don't settle for that!).  As it currently stands the focus of risk mitigation with respect to security are technical controls and other security measures, and the importance of the contract as a risk mitigating tool is overlooked.  As litigation increases in this area, for risk-conscious organization, the protections (or lack of protections) in the service provider contracts are going to become very important.
    Tags: , , , , , ,

    Merrick Bank v. Savvis: Analysis of the Merrick Bank Complaint

    The Merrick Bank v. Savvis lawsuit has the potential to change the liability dynamic of the PCI regulatory system.  The Savvis case is one of the first known instances of a payment card security assessor being sued by a merchant bank ( the merchant bank is a third party relative to the Savvis-CardSystems relationship).    The Merrick Bank compliant alleges that it relied on Savvis' certification of CardSystems  as Visa CISP compliant (this matter pre-dated the PCI standard), and that certification was false.  After CardSystems suffered a breach exposing up to 40 million payment card records, Merrick allegedly incurred $16 million in payments to the card brands (which was ultimately transferred to issuing banks who suffered losses arising out of the CardSystem breach).

    If Savvis is held liable (or even if this case makes it past motion to dismiss or a motion for summary judgment) it has the potential to significantly modify the relative risk of PCI qualified security assessors, and in turn modify the PCI regulatory scheme.  This post discusses the two theories of liability alleged by Merrick:  (1)  negligence; and (2) negligent misrepresentation.

    Please note, while I am an attorney this post does not in any way constitute legal advice or a legal opinion, and should not be relied upon to take any action or be the basis for any inaction.  The law related to this case is complex and varies from jurisdiction to jurisdiction, and over time.  If you are interested in a full legal analysis of potential security assessor liability in a particular jurisdiction, please contact me directly at djn@davidnavetta.com

    One further note, the basic rules and general information in this document was derived from various legal research sources.  However, one book in particular provided excellent information on the liability of service providers to third parties.  Please check it out, and purchase it: Professional Liability to Third Parties (Jay M. Feinman).

    UPDATE:  Other bloggers/mags are putting together some nice analysis of this case as well:  here, here

    Relevant Allegations

    In order to understand the theories of liability alleged by Merrick, it is important to spot the specific allegations that will ultimately support those allegations.  The key allegations, which are repeated throughout the complaint, include:

    • Merrick would not allow CardSystems to process Card Transactions until it was certified as CISP compliant

    • Savvis was specifically retained to certify CardSystems as CISP compliant, and did so pursuant to a Report on Compliance issued to VISA

    • Upon learning of the results of Savvis's Report on Compliance (after CardSystems was listed by Visa as CISP compliant) Merrick allowed CardSystems to serve as its processor

    • According to a post-incident forensic analysis, at the time Savvis issued the ROC, CardSystems had been improperly and continuously storing unencrypted cardholder data

    • Savvis provided the ROC to VISA for the express purpose and with knowledge that Visa would publish the ROC, and that merchant banks would rely on it to determine whether CardSystems met the CISP standard

    • It was reasonably foreseeable to Savvis that merchant banks would rely on its report

    • Savvis knew or should have reasonably known that its certification of CardSystems was directly for the benefit and guidance of merchant banks

    Analysis

    The key threshold issue in this case is whether Savvis owed any duty of care to Merrick with respect to the security assessment it provided to CardSystems, and if so the extent of those duties.  Note that the typical method for establishing a duty in a professional services context is via a contract (and when two parties are bound contractually they are said to be in "contractual privity").  In this case, Savvis likely had a contract with CardSystems to perform an assessment, but did not have a direct contractual relationship with Merrick.  The lack of contractual privity is main legal obstacle faced by Merrick.  Are there other non-contractual theories of liability that apply to Savvis in this context?  Merrick Bank has alleged negligence and negligent misrepresentation against Savvis.

    Negligence

    In the professional service provider/client relationship, negligence is typically a valid theory of liability.  For example, it is the basis for many malpractice claims against lawyers, doctors, accountants and architects.  The validity of a negligence claim is trickier when it is a third party alleges it.  The key analysis is whether the service provider owed any duty to a third party to perform its services in a reasonable and competent manner.  Unfortunately, this is not an easy question to answer under the law.  There are several different tests courts consider to make this determination, and different jurisdictions may apply different tests or apply the same test in a divergent manner.  In addition, whether a duty exists will also rest heavily on the particular facts of the case at hand.  That said, in general, some Courts are wary of circumstances that will result in unlimited liability down the line for service providers.   The following represents a brief description of some of two of the main tests:

    • Foreseeability. In the most basic approach to determining whether a duty exists, the Court asks whether the defendant's actions create a foreseeable risk of harm to the third party plaintiff.  Typically both the plaintiff and the risk of harm must be foreseeable.  This approach is criticized by some on the basis that the concept of  "forseeability" is unbounded and can extend extremely far.

    • Balance of Factors Test. This test considers foreseeabilty of harm to the plaintiff as only one of several factors to determine whether a duty exists.  Other potential factors include:  the extent to which the transaction was intended to affect the plaintiff; the degree of certainty that the plaintiff suffered injury; the closeness of the connection between the defendant's conduct and the injury suffered; the moral blame attached to the defendant's conduct; and the policy of preventing future harm.  After argument by the parties,  all of these factors are weighed by the Court which then determines whether a duty exists.

    Other jurisdictions employ variations of these tests.  In Wisconsin state courts, for example, if it is foreseeable that the service provider's actions could harm a third party, then a duty will not exist only if there are overriding public policy considerations.  Some courts employing the balance of factor test focus on the relationship between the parties, and specifically if there was any indication that a third party was the intended beneficiary of the professional services rendered.

    One more important factor with respect to negligence: even if a duty is found to exist as to a third party, the "economic loss doctrine" may bar recovery of any "economic loss" (loss that is not a personal injury or property damage).  This doctrine is also complex and applied differently depending on the jurisdiction.  In some jurisdictions it does not apply when services are at issue (as opposed to products).  In other jurisdictions, "professional services" such as those provided by lawyers or accountants are not protected by the rule.  However, if the rule does apply, it can wholly eliminate the type of damages being claimed by banks like Merrick (and in fact has been used to dismiss negligence claims by issuing banks for security breaches in the TJX case and BJ Wholesalers cases).

    Negligent Misrepresentation

    Similar to the accountancy field, the payment card security assessment field involves an act of attestation.  That is, an opinion/representation as to the status of a company's financial statements (for accountants) or security status against a particular standard (for security assessors).  If these "representations" are purposely false or simply incorrect because of mistakes, plaintiffs may have an action for fraud or "negligent misrepresentation."  Merrick alleged in this case that Savvis's certification of CardSystems was a negligent misrepresentation because in reality CardSystems was not CISP compliant.  Similar to negligence claims (which often overlap with negligent misrepresentation claims because they require proof of a failure to meet the standard of due care), the approaches employed with respect to this theory varies by jurisdiction.

    The original position adopted by most courts concerning negligent misrepresentation was that third parties not in privity of contract (or "near privity") could not utilize this theory of liability (see Ultramares v. Touche, 1931).  The sixty year reign of the Ultramares case began to erode in the 1960s based on new case law and the eventual adoption of Section 552 of the Restatement (Second) of Torts, which represents the modern approach to service provider negligent misrepresentations to third parties.  Section 552 states in relevant part:

    (1) One who, in the course of his business, profession, or employment, or in any other transaction in which he has a pecuniary interest, supplies false information for the guidance of others in their business transactions, is subject to liability for pecuniary loss caused to them by their justifiable reliance upon the information, if he fails to exercise reasonable care or confidence in obtaining or communicating the information.

    (2) * * * liability in Subsection (1) is limited to loss suffered (a) by the person or one of a limited group of persons for whose benefit and guidance he intends to supply the information or knows that the recipient intends to supply it; and (b) through reliance upon it in a transaction that he intends the information to influence or knows the recipient so intends or in a substantially similar transaction.

    Interestingly, if you read the Merrick complaint (or the relevant facts laid out above) you will see that many of the words used in section 552 are copied verbatim.

    In the typical situation, many of elements in subsection (1) are satisfied in a typical attestation situation.  In this case it is not a stretch to say that security assessors supply information that is relied upon by third parties.   However, plaintiffs may have to establish that their reliance was justified - the more direct the reliance the better their chances.  So if there were other factors that impacted Merrick's decision to hire CardSystems and CISP certification was secondary, the issue of reliance may be more difficult to establish.

    In addition, in some cases it may be difficult to establish that the information was "false" (especially when there are gray interpretative areas involved).  Likewise, in some cases it may be a challenge to establish that the security assessor violated his or her duty of care. If a security assessor's opinion was reasonable the plaintiff may not be able to establish this element.  Of course, if there are obvious ("black and white") mistakes, such as the failure to encrypt cardholder data or the storage of track data, this element will be less difficult to establish.

    The elements in subsection (2) of section 552 require both that the service provider have knowledge of the person or group of persons that will be receiving benefit or guidance from the opinion, and that the service provider (or recipient of the information, e.g. CardSystems of VISA) intends the information to influence the plaintiff with respect to a transaction.  These knowledge and intent issues often ultimately impact the failure or success of plaintiff's case.

    The application of these knowledge and intent requirements may vary by jurisdiction.  Some may take a narrow view and require that the service provider specifically intended to induce the plaintiff's reliance for a particular transaction (e.g. the service provider would have had to have known of the transaction, and known that their opinion was the key information that was inducing the plaintiff to go through with the transaction).  In some cases, the plaintiff may only need to know of the potential users of the information and the potential use of the information.  In addition, some courts may require actual knowledge of the potential users of the information, while others may allow this element to be satisfied if the service provider has reason to know of potential users/uses of the information.

    One item to note again with respect to the economic loss doctrine.  While it often blocks plaintiffs from recovering under negligence theories, in some jurisdictions the doctrine is inapplicable to fraud and negligent misrepresentation claims.  So if plaintiff can establish a negligent misrepresentation claim, it may have a good route to recovery.

    Lastly, it must be noted that the negligent misrepresentation claim, in general, has been utilized by issuing banks against merchants already in the TJX case.  Although the context is different (TJX involves a merchant's misrepresentation as opposed to a security assessor's  misrepresentation), an appellate court refused to dismiss a negligent misrepresentation claim based on indirect representations of CISP compliance.  Thus, it may be that the negligent misrepresentation claim against Savvis could have some legs.

    Conclusion - Observations of the Merrick Case

    The Merrick case represents a potential watershed moment for the payment card security assessor industry (and security auditors in general).  If liability is found in this case, and especially if case law is created that goes against Savvis, security assessors will be entering the world of lawyers, doctors, accountants and architects.  This world will involve much higher potential for liability, more need to purchase professional liability insurance, increased costs for merchants employee assessors, more rigorous ethical obligations and potentially a higher level of skill and scrutiny applied to security assessment engagements.  Over time, this world could start to look more like the world of accountants.

    Unfortunately for security assessors, since there is no ability to gain contractual protection through limitations of liability or consequential damages disclaimers, it may be difficult to deflect liability.  Significantly, as one can ascertain above, whether plaintiff's claims are valid in this context may involve a fairly fact intensive inquiry.  In many instances, legal matters that are highly fact intensive are allowed to proceed past a motion to dismiss or motion for summary judgment -- factual disputes are for juries to decide typically.  What this means is litigation leverage for the plaintiffs - with good fact patterns the pressure to settle these cases may be great since victory may come down to who has the better facts and who can argue those facts the best.  Moreover, regardless of the facts, arguing in front of a jury always poses a risk.

    Based on the foregoing it is very difficult to make any predictions concerning the Merrick Bank case.  However, the fact pattern in this case appears favorable to Merrick based on alleged severe violations of CISP and the magnitude of the breach.  Merrick has gone out of its way to tailor its allegations to match the legal elements discussed above.  Whether those allegations are substantially true remains to be seen.  For instance, was the CISP compliance truly the make or break factor that Merrick relied on to enter into a transaction with CardSystems?  The complaint mentions MasterCard's security program.  Was it justifiable and reasonable for Merrick to rely on CardSystems CISP certification as a proxy for compliance with Mastercard's security rules?  Will the court require that Savvis have actual knowledge and intent to induce the particular transaction at issue?

    Please note that a potential analogue for security assessors are lawsuits by investors against accountants.  Both engage in attestation services that are known to some degree to be relied upon by third parties.  There are numerous cases going both ways (some finding liability/some not) with respect to accountant liability to investors who relied on inaccurate financial statements.

    Finally, one thing to be aware of with respect to negligent misrepresentation.  If a security assessor is made aware that its assessment will be relied upon by a particular third party as the key factor in it deciding to engage in a transaction, the more likely a negligent misrepresentation claim will be valid.  QSAs brought into an engagement for this purpose should pause and consider the implications of making a mistake.

    Regardless of the outcome, this case will be very interesting to watch and it will surely wake the QSA community up.  Once we have more information we will put it up on the blog.  In the meantime, feel free to contact me with any questions on this matter.

    Tags: , , , , , , ,

    Hannaford's Motion to Dismiss: Victory for Merchants (Part 2)

    As detailed in ISC's first post on the Hannaford case, I detailed the District Court's rationale for either dismissing or generally recognizing various legal theories around payment card number security breaches.  The net result of the Court's analysis was the existence of three possible theories of recovery for the consumer plaintiffs: 

    1. Breach of implied contract
    2. Negligence
    3. Violation of Maine's Unfair Trade Practices Act ("UTPA")

    While the partial recognition of these theories of liability might be viewed as a positive development for plaintiffs, based on the Court's analysis of the "cognizable harm" (e.g. damages) elements of each theory, this decision ends up being bad for plaintiffs (or better stated plaintiff law firms desiring to pursue class actions in the wake of a payment card security breach).  This post explains the Court's rationale and indicates aspects that may present difficulties for Hannaford on appeal.

     

    "Cognizable Harm" (a.k.a. "damages") While the Court did recognize three causes of action (e.g. implied contract, negligence and the UPTA claim), to recover under each claim the plaintiff must establish that it suffered an injury, either damages or injunctive relief.  The plaintiffs had alleged various damage components, including:

    (i)  customers' "debit cards and credit cards were exposed and subjected to unauthorized charges;"

    (ii) their "bank accounts were overdrawn and credit limits exceeded;"

    iii)  they "were deprived of the use of their cards and access to their funds;"

    (iv)  they "lost accumulated miles and points toward bonus awards and were unable to earn points during the interval their cards were inactivated;"

    (v)   those customers "who requested their cards be cancelled were required to pay fees to issuing banks for replacement cards;"

    (vi)  those customers "who had registered their cards with online sellers were required to cancel and change their registered numbers;"

    (vii) their "preauthorized charge relationships were disrupted;"

    (viii)  they "expend[ed] time, energy and expense to address and resolve these financial disruptions and mitigate the consequences;"

    (ix)   they "suffered emotional distress;"

    (x)    their "credit and debit card information is at an increased risk of theft and unauthorized use;" and (xi)   some customers "purchased identity theft insurance and credit monitoring services to protect themselves against possible consequences." The Court ultimately rejected each of these damages components, except for a partial recognition of (i).

    Court's Analysis

    The Court's analysis was very interesting.  It first started off by grouping the plaintiffs into various categories. The first category is those plaintiffs that did not have a fraudulent charge actually posted to their account, and only allegedly asuffered emotional distress that their accounts might be in peril.  These plaintiffs could not recover under the  Maine's Unfair Trade Practices Act because only loss of money or property is recoverable under that Act.  In addition, under Maine law emotional distress is not recoverable under a breach of contract claim except in a few limited exceptions.  Finally, while emotional distress is recoverable generally under Maine law, it is not recoverable with respect to negligent misrepresentation claims.  Maine courts have held that the damages associated with negligent misrepresentation claims are essentially economic in nature and serve to protect economic interests, rather than emotional distress.  The Court held that the same applied in this case. Moreover, in a rather conclusory fashion the court held that any preventative expense and time the plaintiffs say they spent "to resolve their emotional distress" are also not recoverable. There may be some problems with the Court's analysis on this count.  First off, while the Court recognized that emotional distress was not recoverable for "negligent misrepresentation," it did not address the plaintiff's general "negligence" claim.  In fact, the Court indicated that in general emotional distress damages are recoverable under Maine law in most tort actions.  Since plaintiffs' negligence claim went beyond failure to notify (and also alleged for example negligent failure to safeguard the plaintiffs' credit card data).  Secondly, rather than addressing the alleged preventative measures of each plaintiff  (e.g. credit monitoring and identity theft insurance) as individual damage components, the Court characterized those items as "expenses and time that plaintiffs say they spent to resolve their emotional distress by protecting their accounts."  By wrapping these items in with emotional distress, the Court was able to dismiss them as unrecoverable emotional distress damages.   The mistake may be that these damage  components stand on their own, and the Court should have considered them individually (other courts have indicated that such expenses are incurred in anticipation of future harm, and not cognizable harm.  It is not clear why the Court did not engage in a similar analysis). The second category, made up of only one consumer, are those consumers with fraudulent charges that have not been reversed or reimbursed.  Hannaford argued that this should not be recognized as a cognizable injury because under typical payment card agreements issuing banks agree to remove such charges.  The Court rejected this argument indicating that a consumer's potential claim for recovery against issuing banks do not excuse Hannaford's negligence.  In addition, such fraudulent charges also equate to a loss of money or property under the UTPA. The last plaintiff category is made of consumers with fraudulent charges that were reversed and are no longer outstanding.  The Court indicated that these plaintiffs were complaining about various consequential expenses (see the following alleged damage components identified above:  iii, iv., v., vi., vii., xi.).  With respect to this category of plaintiff the court held that they were not entitled to any recovery.  Under both contract and tort, the court reasoned, these damage elements were not "reasonably forseeable" under Maine law, and were therefore speculative and unrecoverable.  This type of rationale is more or less in line with other cases refusing to recognize these damages as anything more than expenses incurred in anticipation of future harm. The court also commented on its rationale for some of the specific damage components. The Court described plaintiffs' time and effort to deal with fraudulent charges and to talk to bank representatives as "ordinary frustrations and inconveniences that everyone confronts in daily life."  The court rejected identity theft insurance premiums as a cost component because there was no risk of identity theft from cardholder data that did not include personally identifying information.  Fees to open new accounts were held to be unnecessary prophylactic measures when the banks indicated that new accounts were not required. Finally the court analyzed the plaintiffs' plea for injunctive relief.  The plaintiffs had asked for Hannaford to identify for each plaintiff what private and confidential financial and personal information had been exposed to theft and to provide credit monitoring for each plaintiff.  The court rejected this injunctive relief because all of the individuals had already canceled their cards and therefore had no need for an injunction.

    Conclusion

    At best, the Court's partial recognition of various causes of action represents a pyrrhic victory/defeat for the plaintiffs' bar.   The Court managed to widdle down the potential class size to a small number:  those individuals that actually remain responsible for the credit card fraud done using their card number.  Considering that in most cases the issuing banks will waive such fraud and not hold the cardholder responsible, it is doubtful that many consumers will fall into this category. What this means practically speaking is that the plaintiffs' bar may have less financial incentive to pursue these cases.  A fairly solid foundation of cases has arisen that dismissed consumer class actions based on the damages issue early in the litigation.  Surprisingly there has not been a meaningful break through yet.  While this case is likely to get appealed, each time another court agrees with the conventional wisdom it gets more difficult for that breakthrough to happen.  Unless new laws are passed, consumers may not have a route to recovery after a payment card breach.  In all, I am sure this is not the end of the story for the Hannaford case.  ISC will stay on top of it.
    Tags: , , , , , , ,

    Security Assessor Sued in CardSystems Breach: Merrick Bank v. Savvis

    I had missed the original filing of this complaint, but have now been able to obtain a copy of it.  Essentially a lawsuit by a bank against Savvis for allegedly making a mistake in certifying CardSystems as CISP compliant.  The complaint alleges $16 milion in damages, which essentially are the amounts that Merrick (acquiring bank) paid to the various card associations to satisfy claims by issuing banks arising out of the CardSystems breach. The compliant was filed in May 2008, so it is somewhat odd that news outlets are just now reporting it.

    Tags: , , , ,

    The TJX Case: It Lives! With a New Theory of Liability: "Unfairness"

    The last two plaintiff-banks still breathing after 1st Circuit Appeal
    Little know (or at least discussed) fact: despite announcing settlements with VISA and Mastercard in 2007, the TJX data security litigation is still going. In fact most of the issuing banks impacted by the TJX breach are no longer pursuing TJX and/or have settled via VISA and Mastercard dispute resolution processes.

    However, two financial institutions (Amerifirst Bank and SELCO Community Credit Union - hereinafter "Issuing Banks" or plaintiffs) have pressed forward with an appeal of various dismissals and class certification motions to the U.S Court of Appeals for the First Circuit (the "Appellate Court"). The 1st Circuit's opinion sheds some more (high level) light on the liability risk of payment card data breach security cases. Ultimately, the Appellate Court allowed three theories of liability to proceed, including a previously dismissed theory alleging that TJX's inadequate security amounted to an unfair business practices under Massachusetts's unfair and deceptive business practices law.

    The main issue on appeal was the ruling on a motion to dismiss by the U.S District Court for the District of Massachusetts (the "District Court"). TJX and Fifth Third Bank (TJX's merchant bank; collectively referred to as "defendants") had asked the District Court to dismiss all of the counts alleged in the Issuing Bank's complaint, including: (1) negligence; (2) breach of contract; (3) negligent misrepresentation; and (4) unfair or deceptive business practices under chapter 93A (Massachusetts's consumer fraud statute). The District Court dismissed the negligence and breach of contract claim, but allowed the negligent misrepresentation claim and the 93A claim (which was based on negligent misrepresentation) to proceed.

    Negligent Misrepresentation

    The Appellate Court ultimately refused to dismiss the plaintiff's negligent misrepresentation claim. However, the Court took a different path than the District Court. First, the court noted that the plaintiffs were not alleging any actual misrepresentation, but rather the plaintiff's "negligent misrepresentation" was based purely on the defendants' conduct in performing credit card transactions (in fact, the Appellate Court also referenced the defendants' conduct in the form of entering contracts requiring certain credit card security measures). While conduct can be part of a misrepresentation, the link between the conduct and the implication must be "tight." This link may be established by a combination of words and conduct concerning the alleged misrepresentation.

    The Court then pointed to another Massachusetts's State credit card breach lawsuit (Cumis Ins. Soc. Inc. v. BJ Wholesale Club, Inc. 23 Mass. L. Rep. 550 [Mass Super. 2005]) that granted a defendant a motion for summary judgment on the issue of negligent misrepresentation. In that case, the motion was granted because the implied misrepresentation was based purely on conduct.

    Based on this the Appellate Court refused to dismiss the negligent misrepresentation count on a motion to dismiss. In its view, the claim was properly pleaded in the complaint, and the proper method for dismissal of the case would be a motion for summary judgment (assuming the plaintiffs could not provide evidence to support their allegations). In its parting words, the Appellate Court ultimately indicated that the claim was "on life support." (e.g. likely to be dismissed on motion for summary judgment).

    The Appellate Court also considered the District Court's denial of class certification with respect to the negligent misrepresentation claim, and ultimately upheld the District Court's denial. As such, even if the plaintiffs can establish negligent misrepresentation it appears they will have to do so for each individual plaintiff (rather than a class of plaintiffs).

    Chapter 93A "Unfair" or "Deceptive" Trade Practices

    The Appellate Court's ruling on the Issuing Banks' 93A claim was actually a bit surprising. The non-surprising aspect was the court's decision to uphold the plaintiff's 93A claim based on negligent misrepresentation. Since the base negligent misrepresentation claim was allowed to stand, the 93A claim based on the misrepresentation also stood, albeit with the same defects according to the Court.

    The surprise was the Appellate Court's reversal of the dismissal of the plaintiff's other 93A claim. 93A provides a claim for "unfair" or "deceptive" trade practices as between businesses, and "unfairness" can be established by reference to other appropriate sources of law The plaintiffs had alleged that the defendant's lack of security measures, based on various consent decrees issued by the FTC, amount to a violation of the Federal Trade Commission Act, and therefore an "unfair" practice under 93A. The District Court disagreed and held that consent decrees are not appropriate sources of law for purposes of 93A.

    In reversing the dismissal, the Appellate Court recognized that the plaintiffs allegations went beyond consent decrees and relied on an actual FTC complaint against TJX for the very breach at issue, as well as two other security breach complaints alleging that the lack of appropriate security measures equated to an unfair act or practice. The court noted that use of FTC precedent was directly referenced in 93A itself, and that at least one other Massachusetts court had allowed FTC complaints to serve as the basis of 93A actions. The court also noted that "adjudicated" FTC cases were even more potent (although did not clarify whether a "consent decree" amount to an adjudicated FTC case).

    Moreover, the Appellate Court rejected TJX's argument that it did not have a close enough business relationship to the Issuing Banks. The Court also refused to limit a 93A actions to "egregious conduct" or "deliberate wrongdoing" at this stage. Rather, this issue was one that would have to be resolved after discovery in the District Court.

    Negligence

    The District Court dismissed the plaintiffs' negligence claim based on the "economic loss doctrine", which holds that "purely economic losses are unrecoverable in tort and strict liability actions in the absence of personal injury or property damage." On this claim the plaintiffs argued that they had suffered property damage because they had a property interest in the payment card information which the breach rendered worthless. The Appellate Court disagreed. It recognized that electronic data can have value and that value can be lost, but the loss must be as a result of the physical destruction of property. That was not the case for this security breach, and the District Court's dismissal was upheld.

    Breach of Contract - Third Party Beneficiary Theory

    The Appellate Court upheld the District Court's dismissal of the plaintiff's breach of contract claim. Under this theory, the Issuing Banks argued that they were the intended beneficiary of the contract between Fifth Third and TJX. That contract, however, contained the following express provision disclaiming third party beneficiaries:

    This Agreement is for the benefit of, and may be enforced only by, Bank [Fifth Third] and Merchant [TJX] . . . and is not for the benefit of, and may not be enforced by any third party.

    The plaintiffs argued that this provision was superseded by the Visa and Mastercard Operating Regulations. The court noted that those regulations do indicate that they prevail in any conflict with the provisions of a merchant account, but in this case the court noted, those provisions did not conflict with the third party beneficiary disclaimer in the TJX merchant agreement. The Appellate Court construed the following language in the Mastercard agreement as disclaiming third party beneficiary rights: [Mastercard] "shall have the sole right to interpret and enforce" [its operating regulations]. The Visa Operating Regulations were more explicit, indicating that those regulations "do not constitute a third-party beneficiary contract as to any entity or person . . . or confer any rights, privileges, or claims of any kind as to any third parties." Note that it does not appear that this type of disclaimer existed in early versions of the Visa Operating Regulations (see the use of third party beneficiary theory in the B.J. Wholesaler's case)

    Class Certification

    One of the biggest risks for defendants, even where weak theories of liability exist that are likely to yield small recoveries, is the prospect of certification of large plaintiff classes. The District Court held that class certification was not appropriate for the surviving negligent misrepresentation claim and 93A claim (based on negligent misrepresentation). The District Court reasoned that class certification was inappropriate because negligent misrepresentation requires proof that each individual plaintiff relied on the misrepresentation.

    The Appellate Court, however, questioned whether the newly revived 93A "unfairness" cause of action would require an individual finding with respect to each plaintiff. The Appellate Court noted that the unfairness theory appears to consider what the defendants did (or failed to do) rather than the Issuing Bank's reliance on any misrepresentation. Ultimately, the Appellate Court did not issue an opinion on the certification of the 93A unfairness claim, and instead remanded the question back to the District Court.

    Conclusion

    For the most part the Appellate Court's decision represents a victory for TJX, but does open the door to some uncertainty. While the negligent misrepresentation claims (common law and the 93A claim) is viable, class certification has been denied. The plaintiffs have indicated that they will attempt to better define the classes to remedy this defect, but at this point it appears they would have a very difficult road.

    The "unfairness" theory under 93A, however, presents a wild card. The "unfairness" doctrine has been used by the FTC to allege that a company's security itself was inherently unreasonable and therefore "unfair." Those FTC cases resulted in consent decrees and therefore the unfairness theory has never been truly tested (one commentator believes it was improperly employed by the FTC). Yet it provides a potential hook, especially in this case where TJX was found to have been in non-compliance with 9 of the 12 PCI requirements. Even so, the question remains whether the Issuing Banks will be able to establish damages under 93A. Notably, considering that most States have a similar deceptive practices laws on the books (although not all of them with private causes of action), this "unfairness" theory could have wider application in the security breach context.

    Tags: , , , , , , , , , ,

    Credit Card Theives So Good They Have Too Much Data...

    Some interesting statistics from a new report from Verizon Business. The Washington Post security writer sums it up nicely in terms of the payment card data market:

    [Verizon] said it responded to at least 90 confirmed data breaches last year involving roughly 285 million consumer records, a number that exceeded the combined total number of breached records from cases the company investigated from 2004 to 2007. Breaches at banks and financial institutions were responsible for 93 percent of all such records compromised last year, Verizon found.

    This has resulted in a huge decrease in the price per credit card in the black market:

    As a result, the stolen identities and credit and debit cards for sale in the underground markets is outpacing demand for the product, said Bryan Sartin, director of investigative response at Verizon Business.  Verizon found that profit margins associated with selling stolen credit card data have dropped from $10 to $16 per record in mid-2007 to less than $0.50 per record today.
    Tags: , , , , , , ,

    Ruiz v. Gap: Increased Risk of ID Theft Not Damages

    In a previous post this blog noted that a California Federal District Court denied a motion to dismiss a data breach negligence claim based on a lack of "damages."  Despite the partial "victory," the Court had also suggested that the damages issue might not survive a motion for summary judgment.  Well, the Court made its own prediction come true in a recent ruling.

    On April 4, 2009, the court issued a decision indicating that an increased risk of identity theft did not rise to the level of harm necessary to maintain a negligence claim.  This was true despite evidence from experts indicating an increase risk that the plaintiff's personal information was exposed.  Without evidence of actual significant exposure of the plaintiff's personal information, the Court indicated that analogies to "medical monitoring" damages were not supported.

    This case is another in a line of case establishing that, absent identity theft, it is uncertain whether a consumer plaintiff of a data breach can win in court.

    Tags: , , , , , ,

    Who is Minding the Legal Risk Around PCI?

    An article I did for the ISSA Journal:  Who is Minding the Legal Risk Around PCI?

    Tags: , , , , , , ,

    Heartland Payment Systems Sued By Banks

    Heartland Payment Systems has been sued in multiple lawsuits by various banks or credit unions that have had to reissue payment cards in the wake of the Heartland breach.

    Significantly, it appears that at least some of the allegations include a breach of contract claim based on a 3rd party beneficiary theory.  Note, however, that in this case, since Heartland was likely not a party to a card brand's membership agreement, the banks are alleging that they are the third party beneficiaries of contracts between Heartland and various merchants and/or acquring banks.  Thus the viability of the 3rd party beneficiary theory will come down to the intent reflected in these contracts.  If fairly standard boilerplate disclaiming 3rd party beneficiairies is present it may be more difficult for the banks to proceed on this theory.

    Three bank complaints can be found here, here and here.

    More analysis to come... stay tuned.
    Tags: , , , , , , ,

    Another Processor Breach?

    Rumors abound that another big processor (not Heartland), may have recently suffered a security breach.

    Link.

    Stay tuned.

    Tags: , ,

    Is Something Wrong With PCI?

    A question being asked in various circles in the wake of the Heartland breach.  An interesting post by Michael Dahn over at the Aegenis Group.  I started to respond and kept going and going and going.   Read his post first and my (somewhat rambling/unpolished ) response is below.

    A couple points.

    (1)  Faulty Logic. You claim that it is faulty logic to conclude after one company getting hacked that the entire PCI program ineffective.  On the flip side, it is also faulty logic to conclude that the mere existence of a standard means better security.  It really depends on what the standard says, its scope/rigor and how it is applied.  Even for seatbelts, some studies have suggested that the existence of seatbelts may increase the likelihood of reckless driving. It is possible to implement a standard simply to give the impression that something is being done...

    (2)  It's the Risk, Stupid.  As you site in your post many individuals considering PCI compliance are only interested in doing "the minimum" to allow them to validate compliance for the year.  The problem is that there is no requirement under PCI that the level of risk posed by a given merchant or processor's operation dictate compliance.  How can the requirements of PCI be the same for a merchant that does 1000 cards a month and a payment processor that does 100 million cards per month?  It only can if the depth/rigor of compliance is higher for the 100 million processor.   You are right, there is a difference between having a firewall (check box!) and having a properly configured firewall and having a program in place to ensure/check that firewalls are properly configured.  Yet, some view the PCI Standard as not making a distinction between these situations - all are "compliant."  And, I contend that that is a problem with the Standard - that concept should be explicitly stated in and made part of PCI.  Not that GLB itself is a great standard, but at least it captures the idea of risk:

    (a) Information security program. You shall develop, implement, and maintain a comprehensive information security program that is written in one or more readily accessible parts and contains administrative, technical, and physical safeguards that are appropriate to your size and complexity, the nature and scope of your activities, and the sensitivity of any customer information at issue.

    (3)  The Incentives Are All Wrong. Let me partially take back some of what I said about not taking risk into account.  Merchants and service providers are taking risk into account, the risk that they will lose their ability to process credit cards if they are not PCI compliant.  That is the motivating factor in the PCI game.  With no other real carrot or sticks implemented within the system.  Thus the name of the game is getting an ROC as cheaply as possible.

    As long as you can find a QSA to validate, or one of your own IT employees for SAQs, you can continue doing business.  And of course, since there are hundreds of QSAs, meaning tons of competition, companies can leverage that competition to get an easy pass.  QSAs that want to do the right thing get marginalized.  In fact, since the QSAs get critiqued by their customers, those that play ball end up rising to the top of the ladder (another flaw in the system).  But isnt' the QSA assuming the risk if they rubber stamp, you ask?  Go read your contract with the QSA and see how much risk they are actually taking (look at the limitation of liability clause, disclaimer of consequential damages clause and indemnification clauses).  Meanwhile the ROC that is submitted is accepted without question.  We won't even get into the incentives around an in-house security  or IT professional (with perhaps no security training) who is completing a merchant or service provider's SAQ.

    So what could change the incentives/motivating factors:  carrots and sticks.  There is no enforcement unless you are not validated.  Nobody checks if you REALLY ARE PCI compliant or whether you ACTUALLY have reduced any risk.  There is no penalty if you are validated unless you suffer a security breach (discussed more below).

    What about carrots?  The benefit of validating PCI compliance is the ability to accept payment cards.  That benefit accrues to any company that has validated, whether or not they actually have reduced risk to a reasonable level.  What about "Safe Harbor"?  I don't think it exists.  Many companies I have spoken to are under the impression that if they are PCI compliant they will be immune from fines/penalties and liability.  I challenge anybody to identify a LEGAL RIGHT to immunity or a LEGAL OBLIGATION on anybody to provide a Safe Harbor.   In fact, Safe Harbor is no longer even identified on Visa's website:  VISA Merchant Page. You have to use the Internet Way Back machine to find information on what they used to call "safe harbor":  Old Safe Harbor Reference.

    Note the even under the old description of safe harbor, it only excused PCI-complaint merchants from fines.  It did not prevent an Issuing bank from suing a merchant for the cost to replace cards.    So clearly, for merchants that engage in rigorous PCI-compliance there is no carrot that comes their way if they happen to suffer a breach.

    Frankly, the lack of proper incentives and motivation around PCI compliance make me wonder about my last sentence in (1) above.

    (4)  The Ultimate Stick - Getting Your Pants Sued Off. Yes, high profile breaches and lawsuits can deter bad behavior in the PCI realm.  However, there are a couple issues here as well.  As set forth below it appears that some companies believe that if they validate PCI compliance they are in a Safe Harbor that protects them.  Therefore they (wrongly) may not fear lawsuits.  Secondly, for those that use QSAs, there is a belief that if they are validated PCI compliant and they really aren't, that it will be on the QSA.  Again read your contract with your QSA to see how much liability they are actually taking.  Perhaps more high profile incidents like Hannaford and Heartland will act as a deterrent, but I question how much it is now.  This is especially true because lawyers are often not involved in the PCI compliance process and those security pros that are do not have the experience pr expertise to gauge actual legal risk (unless they have law degrees and have practiced - which is a whole other post).  Therefore, it may not be fully taken into account.

    Thoughts?

    Tags: , , ,

    More Companies Validated as PCI Compliant Breached

    Despite the changes to PCI that went into effect in October 2008, more PCI-compliant entities are suffering security breaches.  Added to the list of Hannaford, Best Western and Forever 21 are Heartland Payment Systems and RBS Worldpay.

    The Heartland Payment Systems breach was reported on January 20, 2009 in the midst of President Obama's inauguration.  While the extent of the breach is unknown, some commentators are speculating that it could be the biggest breach in history.  Heartland reportedly processes 100 million transactions a month, but is not certain how many payment cards were exposed.  More information here.

    RBS Worldpay suffered a breach that reportedly exposed 1.5 million cardholders, and resulted in 100 instances of fraud.  The breach included not only cardholder data, but also involved the Social Security numbers of about 1.1 million account holders.  More information here.

    These incidents again raise the question as to the efficacy of PCI.  Of course it is possible that these processors made a mistake in validating their PCI compliance.  Nonetheless, premilimary reports indicate that the Heartland breach was caused by malware installed behind Heartland's firewall on its internal network.  Assuming PCI was complied with, the issue becomes whether or not encryption during transmission over Heartland's network would have prevented the exposure, and the further question will be whether failing to encrypt internally is "unreasonable" as a matter of law (getting to a T.J. Hooper rationale).

    More to come I am sure.  Lawsuits?  Regulatory scrutiny?  Will this be a Card Systems or TJX situation, or something less severe?  ISC will keep you posted.
    Tags: , ,

    Forever 21 -- Breached and PCI Compliant

    I anticipate we will be seeing a lot more instances of merchants suffering payment card breaches while PCI compliant. The question is, will they be held liable for those breaches. An article soon on that. For now, here is an article on Forever 21, which just reported a breach involving over 98,000 card numbers. Forever 21 claims that is has been certified as PCI compliant since 2007. However, all of the incidents happened from March 2004 to August 2007. Therefore it is possible that Forever 21 was not PCI-compliant at the time of the incidents, but became so in after August 2007.

    Tags: , ,

    Best Western: PCI Compliant and Hacked

    While the details are still murky on the number of records impacted (somewhere between 13 and 8 million), it appears that we have a security breach of another high profile corporation claiming PCI compliance at the time of breach. SC Magazine has the story here.

    Here is Best Western's statement on the breach:

    "We comply with the Payment Card Industry (PCI) Data Security Standards (DSS). To maintain that compliance, Best Western maintains a secure network protected by firewalls and governed by a strong information security policy. We collect credit card information only when it is necessary to process a guest's reservation; we restrict access to that information to only those requiring access and through the use of unique and individual, password-protected points of entry; we encrypt credit card information in our systems and databases and in any electronic transmission over public networks; and again, we delete credit card information and all other personal information upon guest departure. We regularly test our systems and processes in an effort to protect customer information, and employ the services of industry-leading third-party firms to evaluate our safeguards."

    Obviously, the facts are still murky, but it will be interesting to see what, if any, protection PCI compliance will have from a liability perspective and a "safe harbor" perspective.

    Tags: ,

    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.

    Tags: , , ,

    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?

    Tags: , , , ,

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

    Tags: , , ,

    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.

    Tags: , , ,

    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.

    Tags: , ,

    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.

    Tags: , , ,

    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?

    Tags: , , ,

    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 list):

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

    Tags: , , , , ,

    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.

    Tags: , , , ,

    The Legal Implications, Risks and Problems of the PCI Data Security Standard

    (**For an easier to read version of this article click HEREto download)

    While starting off as "just" an information security standard, the Payment Card Industry Data Security Standard, v. 1.1 ("PCI" or "PCI Standard") now presents serious legal challenges and risk for retailers. The PCI framework currently operates like a law without courts or regulators - there is no centralized body to resolve interpretative discrepancies in a consistent, precedental and binding manner. Moreover, in many cases PCI compliance is performed by security professionals with no attorney collaboration and little understanding of the legal risks involved. This article discusses the legal framework and implications PCI, the problems with the standard in the legal context, and actions that merchants should explore to reduce legal risk arising out of PCI.

    PCI Background.

    The PCI Standard is a grouping of six control objectives that a merchant, service provider or other entity subject to PCI must satisfy to secure cardholder data. The Standard has been universally adopted by the major payment card companies. However, each payment card company also has its own payment card security program ("Security Program"). The Security Programs are the definitional, procedural and enforcement rules and requirements of the payment card brands around payment card security. Examples include VISA's Cardholder Information Security Program (VISA CISP) and MasterCard's Site Data Protection. Security Programs dictate merchant level definitions, procedures, deadlines and documentation for validating PCI compliance, documentation requirements for security assessment, security incident response requirements and fines and penalties. So if a merchant deals with all the five major payment card brands, it must comply with not only the PCI Standard, but also each five separate Security Programs. All of this is enforced contractually.

    The Legal Foundation of PCI - The PCI Contract Chain

    Unlike security laws such as Gramm-Leach-Bliley, HIPAA and Sarbanes-Oxley, the PCI Standard and Security Program rules are not statutes or regulations enforced directly by the government. Rather, the PCI Standard and the Security Program rules are imposed and typically enforced contractually through the PCI Contract Chain.

    At the top of the chain are the payment card companies. The payment card companies establish merchant relationships by working through "merchant" or "acquiring" banks. The contract between merchant banks and payment card companies is the first contractual relationship in the payment card industry chain. The merchant banks (or payment processors working with the merchant banks) process the payment card transactions for the payment card companies they partner with. If a merchant wants to be able to accept payment cards to transact business, it must be vetted by a merchant bank (or payment processor) and enter into a contractual relationship with that merchant bank (or payment processor). Finally, merchants sometimes enter into relationships with service providers for the processing, storage or transmittal of payment card data. As the final link in the chain, merchants and service providers will enter into contractual relationships.

    This presents several legal issues:

    1. No Direct Contractual Relationship between Merchants and Payment Card Companies. The significance of the chain is that there is typically no direct contractual relationship between payment card companies and merchants. Therefore, generally speaking, merchants cannot be directly required to legally adhere to Security Programs or the PCI Standard by payment card companies. Rather, if any contractual obligations do exist they are passed through the contract that exists immediately upstream from the merchant (e.g. the contract between the merchant and merchant bank or payment processor). Nonetheless, in practical terms, payment card companies may be able force compliance by leveraging their relationships with merchants and access to payment card processing.

    2. No Direct Duty for Service Providers to Comply with PCI or Security Programs. There is typically no inherent duty for a merchant's service providers to comply with the PCI Standard Any duty for a service provider to comply with the PCI Standard will flow contractually from the merchant to the service provider (typically not from the payment card companies to the service provider). Therefore, unless merchants impose contractual obligations on their service providers, they may find themselves without leverage to force those service providers to become PCI compliant.

    3. A Merchant Compliance with PCI is Directly Contingent on Contractual Obligations Imposed on its Service Providers. Section 12.8 of the PCI Standard requires merchants to do the following:

      If cardholder data is shared with service providers, then contractually the following is required:

      12.8.1 Service providers must adhere to the PCI DSS requirements

      12.8.2 Agreement that includes an acknowledgment that the service provider is responsible for the security of cardholder data the provider possesses.

      If these duties are not contractually established then the merchant may not be able to establish its own compliance with PCI.

    5. Matching Upstream and Downstream Obligations and Risk. The scope of a merchant's PCI obligations (including compliance with the PCI Standard and Security Programs) is dictated by its upstream contracts with merchant banks or service providers. Merchants must protect themselves by imposing upstream PCI contractual obligations and risks downstream to their service providers. So if a merchant agrees to pay fines and penalties for failure to comply with PCI, it should also require its service providers to pay any fines and penalties imposed on the merchant because of the service provider's failure to comply.

    The contractual nature of PCI makes it necessary for a merchant's legal staff to understand and become involved in the PCI compliance process. Most of the issues outlined above require legal analysis, contract drafting and negotiation. Attorneys should develop strategies for limiting liability from upstream contracts, and passing liability downstream to service providers.

    One area of special difficulty is existing service provider relationships. If a merchant faces fines or the loss of processing capability because its existing service providers are not PCI compliant, it could be difficult to re-open negotiations and force service providers to invest the time and resources to become PCI compliant. As such, before fines and threats start coming in, a merchant's legal staff should be devising a strategy for addressing PCI contractually with existing service providers (as well as new providers). While these contractual issues are challenging, the transformation of PCI into a legal standard of care can pose even greater difficulties for an organization.

    PCI as a Legal Standard of Care

    The PCI Standard is transforming into the legal standard of care for merchants handling payment card data. As a result, merchants may find themselves liable to financial institutions and/or consumers if they fail to adhere strictly to the PCI Standard. Unfortunately, PCI compliance is often viewed purely as a security exercise without high (or any) involvement from a merchant's legal team. As PCI increasingly becomes a legal standard, attorney participation (including the use of attorney-client privilege) is a necessity in order to decrease liability risk. This section discusses how PCI is evolving into a legal standard, including: (1) under the common law in support of a "negligence" claim; and (2) explicitly in recently proposed and passed State legislation.

    PCI as the Standard of Care for a Negligent Security Suit

    Negligence is a legal theory of recovery that exists in "common law" - negligence claims do not involve laws passed by legislators or regulators. To prevail in a negligence suit, a plaintiff must establish the following: (1) a duty to use ordinary care; (2) breach of that duty; (3) a proximate causal connection between the negligent conduct and the resulting injury and (4) resulting damage. Negligence is a theory used to support liability actions as simple as slip-and-fall lawsuits to complex environmental disaster lawsuits.

    In the PCI context, plaintiffs can allege negligence by arguing that a merchant handling payment card data has a duty to protect such data, and the failure to comply with the PCI Standard represents a breach of "ordinary care" if the merchant suffers a security breach. However, even if a breached duty can be established, plaintiffs still must prove that a security breach suffered by a merchant caused them damages. As discussed further below, while it has been difficult for consumer and financial institution plaintiffs to establish damages, recently passed and future legislation may make it easier for financial institutions to recover from merchants.

    The use of the PCI Standard to support a negligence claim was recently demonstrated in the TJX matter. In that case several banks sued TJX for the costs to reissue credit cards (amongst others) in the wake of a massive security breach suffered by TJX involving millions of card numbers. To support their allegations of negligent security, the banks retained an expert to critique TJX's security posture. That expert relied on TJX's own PCI audit reports (performed by security firms hired by TJX) to argue that PCI breached its duty of ordinary care to protect payment card data. A copy of that expert opinion can be found by clicking here. The bank's expert noted that TXJ's auditors concluded that TJX satisfied only 3 of the 12 sections of PCI. In addition, the expert opinion noted specific security failures tied to the TJX breach that can also be traced back to PCI requirements. For example, TJX allegedly stored "Track 2" data which can be used to recreate the magnetic strip of a payment card, which would be a violation of section 3.2. of the PCI Standard. The end result was a $41 million settlement and tens of millions in legal fees and other costs

    It is uncertain to what extent TJX's legal team was involved in the post-breach response, whether TJX took steps to try to shield its auditor's actions with attorney-client privilege, and if so, whether it asserted that privilege in court. Nonetheless, it is clear that conducting a PCI audit and taking steps to comply with PCI has significant legal repercussions -- any adverse finding of non-compliance that is not shielded by attorney-client or attorney work product privilege can be used by plaintiffs against a merchant. These admissions of non-compliance can result in merchant liability, especially when used in conjunction with a new species of laws that requires adherence to PCI.

    Plastic Card Protection Laws - PCI Incorporated Into New State Laws

    Even more troubling for merchants of all sizes, are new proposed bills, and at least two passed laws, that provide banks with a right to obtain reimbursement from merchants that suffer a security breach exposing payment card data. In essence, these bills allow banks to get around proving the "damages" element of a negligence claim, and arguably provide for "strict liability" in the event a merchant suffers a payment card security breach. Prior to such laws, financial institutions lost some high profile lawsuits, in part, because of an inability to prove damages (see for example the B.J. Wholesalers' lawsuit: B.J. Wholesaler Summary Judgment Ruling and PSECU Motion to Dismiss).

    Some of these Plastic Card Protection bills/laws directly incorporate PCI as the requisite security standard for payment card data.

    Several States have proposed bills allowing banks to seek reimbursement for security breaches, including Massachusetts, Illinois, Connecticut, Texas, Minnesota, California, Michigan, Alabama, Iowa and Washington. While many of these bills are in limbo or may not pass, they demonstrate a willingness on the part of lawmakers to seriously consider relief for banks and incorporate PCI into law (TX, CA, MI, MN, IA and AL all tie PCI compliance to their bills).

    In fact, Minnesota has actually passed laws providing banks with a right to seek reimbursement after a merchant suffers a breach. This law represents a paradigm shift in terms of merchant liability and compliance. The multiplier effect of damages for a payment card security breach (e.g. $20-50 allegedly per card multiplied by thousands or tens of thousands of exposed payment card numbers) has the potential to literally wipe out small and medium organizations, and severely damage even large companies. These costs were previously unrecoverable (or at least very difficult to recover) because of the pre-emptive nature of reissuing cards to avoid potential future fraud.

    Minnesota's Plastic Card Protection Act ("Act") incorporates, in part, the requirements of Section 3.2 of the PCI Standard. To comply with the Act, companies accepting payment cards must destroy or delete sensitive authentication data (including the same "Track 2" data that TJX allegedly stored) within 48 hours of authorizing a transaction with such data (the "48-hour rule"). If a merchant violates the 48-hour rule and suffers a breach exposing payment card data, banks can recover reasonable costs associated with addressing that breach (including the costs of reissuing new payment cards, opening and closing accounts, etc.). This Act also applies to entities using service providers that store, process or transmit payment card data - a merchant that provides sensitive authentication data to a service provider will be in violation of the Act if its service provider does not comply with the 48-hour rule. The reach of the Act is potentially nationwide - merchants only need to be "doing business" in Minnesota for it to apply - the Act is not limited to the exposure of payment card data of Minnesota residents. "Doing business" in the legal context could be as simple as having a commercial website accessible in Minnesota.

    Section 3.2 of PCI, in fact, prohibits the storage of sensitive authentication data for any period of time. So, if an organization is strictly in compliance with section 3.2 of PCI, it should also not be in violation of the 48-hour rule. Significantly, some of the other bills incorporating PCI incorporate multiple sections of PCI, and in the case of Washington State and Texas, the entire PCI Standard.

    While these Plastic Card Protection laws do provide a direct path to liability, what is the problem for companies that consider themselves PCI compliant? As discussed further below, even for PCI compliant merchants, there are several problems that arise out of the PCI standard and framework, and the use of a private security standard as a public legal standard to be ruled on by judges and juries. The next section explains the problems with PCI as a legal standard both in terms of its administration by the PCI Council and payment card companies, as well as the risk of handling PCI as solely a security matter.

    PCI: A Law Without A Judge or Jury

    The overarching problem with PCI is that it is a security standard that is becoming a law. Unfortunately, the PCI Standard was not necessarily drafted like law; nor is it interpreted like a law. Rather it is interpreted by non-lawyer security professionals solely as a security standard - either qualified security assessors (QSAs) or a merchant's internal security team (in the case where a self-assessment is appropriate). There often may be no awareness as how security interpretations will be viewed by a court of law, and little to no lawyer involvement. In addition, unlike laws passed by lawmakers, there is no mechanism for resolving ambiguities or exceptions to the PCI Standard. No body similar to a court or regulator exists in the PCI context to create precedent or provide official guidance that can be relied upon by the merchant community to make compliance decisions.

    PCI Ambiguity

    During the September 2007 PCI Council Meeting in Toronto it was revealed that there had been hundreds of questions submitted concerning the interpretative uncertainty arising out of the PCI Standard. Unfortunately, as PCI becomes a legal standard, the ambiguities inherent in the PCI Standard could lead to legal liability. The problem is compounded because there is no official body within the PCI framework to resolve those ambiguities and provide merchants with guidance on how to comply with PCI.

    A good example is section 12.8 of the PCI Standard, which reads:

    If cardholder data is shared with service providers, then contractually the following is required:

    12.8.1 Service providers must adhere to the PCI DSS requirements

    12.8.2 Agreement that includes an acknowledgment that the service provider is responsible for the security of cardholder data the provider possesses.

    Although section 12.8 seems fairly straightforward, according to some QSAs and merchants this language is subject to various interpretations. The following represent the range of interpretations that may apply:

    1. Narrow interpretation: contract language indicates that service provider must adhere to the PCI Standard, which means that the minute the contract is effective the service provider must be PCI-compliant and the merchant should confirm such compliance;

    2. Middle-ground interpretation: contract language indicates that service provider agrees that it must adhere to the PCI Standard, which means that the minute the contract is effective the service provider must be PCI-compliant, but the merchant does not need to confirm such compliance, but rather can trust the service provider's representation that it is compliant; and

    4. Loose interpretation: contract language indicates that the service provider agrees that it must adhere to the PCI Standard, but the merchant has discovered that the service provider has some controls that need to be implemented to achieve full PCI compliance and imposes a deadline after the effective date of the contract to achieve such compliance in the future. Under this interpretation, the QSA would be effectively interpreting a merchant to be in compliance with 12.8.1 as long as the service provider contractually promises to adhere to the PCI Standard during the contract term by a certain reasonable date, even if not compliant at the inception of the contract. Stated differently, it is the "magic words" in the contract that matter not whether the service provider is actually PCI compliant.

    It appears that the middle-ground interpretation meets the literal requirements of the PCI Standard. However, if this was presented in a court of law, a plaintiff would argue for the narrow interpretation (e.g. is it reasonable or within the spirit of PCI to simply rely on a vendor's promises without confirming actual compliance). Herein lies the problem: unless a merchant adheres to the strictest interpretation of the various sections of PCI, plaintiffs will always have arguments (and therefore leverage in a lawsuit) that the merchant was not in compliance with PCI. Remember, these lawsuits arise because the merchant has already suffered a security breach that will likely put the merchant in a negative light in front of a judge or jury. If the breach is at all related to the failure to comply with a section of PCI (and in many cases even if its not) the merchant will have a difficult time in court.

    No Centralized or Official Binding Precedent Setting Body

    Unlike laws, which have courts and regulators to render opinions and issue interpretative guidance that is binding and can be relied upon for planning purposes, the current system for PCI is ad hoc, decentralized and inconsistent. It has no mechanism for rendering "binding" decisions on interpretive differences.

    The following personal anecdote underscores this problem. Interpretative issues also arise under Section 12.8 with respect to new versus existing service provider relationships. For example, despite the indication that contractual language must be in place, at least one QSA has that it will pass a merchant on section 12.8 if the merchant gets a letter from its non-PCI compliant service provider indicating that the service provider intends to comply with PCI some time in the future. The QSA that asserted this position informed me that this approach had been approved by the PCI Council and/or payment card brands in some sort of writing. I attempted to get that writing from the QSA as well as a sample of a proper letter so I could advise my clients on this short-cut, but the QSA could not produce the document.

    Therefore I attempted to communicate directly with the PCI Council on this issue. The PCI Council refused to answer my questions and confirm the short-cut despite the fact that this issue dealt directly with the PCI Standard (and not a payment card brand Security Program). Instead, the PCI Council told me I had to get an answer from each of the payment card companies. I followed through by sending the question to each of the five major payment card companies. Three companies simply did not reply (JCB, Discover and MasterCard). American Express replied, but indicated that it was not in a position to make that determination and that it was up to each merchant's QSA to make the decision. A representative from VISA, however, provided a partial answer to my question:

    In general, the Service Provider's legal counsel may provide the assessor documentation/letter that 12.8 requirement is being addressed in existing (or future) contracts despite not having the exact 12.8 language. The main goal is to stipulate the accountability for keeping the cardholder data secure and responsibility in any compromise event

    I asked for some further clarification on this answer, but there was no response to my follow-up e-mail.

    There are several problems with this approach now that PCI has effectively become the law. First, its clear that there is no centralized decision-making body to render decisions on PCI ambiguities. The PCI Council passed the buck to the payment card brands, and AMEX passed the buck to the QSAs. There are hundreds of QSAs, so potentially hundreds of different interpretations. Moreover, each payment card company may have a different view of how to interpret 12.8. This does not take into account payment processors and merchant banks that are also known to take their own positions on PCI.

    While VISA did provide an answer, it would likely not be binding upon any of the other card brands. In fact, since VISA's comment is outside of a contractual setting it may not even be binding against VISA itself (e.g. there is no direct contractual relationship between VISA and the merchant).

    Moreover, its typically consumers, payment card processors, issuing banks and merchant banks that would sue or fine a merchant because of a security breach. How would an email from VISA be binding on those organizations?

    As PCI is becoming the law a system without a centralized decision-making body to resolve interpretative differences poses significant liability risks. Under a legal system, courts resolve interpretative differences in lawsuits or regulators provide interpretative guidance (see e.g. the HHS and HIPAA and the FTC and GLB). While that system is imperfect for several reasons, at least at the end of the day legally binding precedent is created. Organizations can rely on the court's opinion or regulators' guidance to make their own decisions on various interpretations with some certainty that those decisions will be legally binding. Those decisions and guidance are available for the entire world to read and they end up creating consistency across the business community in general.

    Unfortunately, the PCI system is extremely decentralized and uncertainty abounds. The PCI Council reportedly may begin addressing this issue by issuing a series of "FAQs" to address interpretive issues. However, even with FAQs, the legally binding effect is uncertain. Are FAQs rendered by the PCI Council binding on merchant banks and payment processors that have contracts with merchants?

    The PCI Council should consider establishing an official centralized body that renders interpretative decrees that become part of the PCI Standard itself and that are binding on all of the participants in the PCI contract chain. In addition, merchants should take steps to have their attorneys deeply involved in PCI compliance efforts to reduce the risk of liability - the Standard needs to be viewed as a law, not merely a security standard.

    Security Analysis versus Legal Analysis

    The reality right now is that non-lawyer QSAs are making the essential decisions on PCI compliance for merchants. However, their interpretations of PCI are made through a security prism, not a legal prism. Moreover, some QSAs may accept looser interpretations of the PCI Standard because of economic incentives (e.g. preservation of client relationships) or pressure from their merchant clients to "pass" them. While looser interpretations may be fine in the security world in some areas, some of those interpretations may be ripped apart when scrutinized by a plaintiff's attorney and/or judge or regulator.

    From a legal standpoint, merchants should assume that the narrowest interpretation of the PCI standard will be used against them in a court of law. Plaintiff's attorneys will present expert witnesses who will testify in favor of the narrow and literal interpretations of PCI, and those experts will have the actual wording of the PCI Standard to back them up. In addition, those experts will use any and all adverse security assessment findings, including those made by the merchant's own auditors, against them. If PCI is not approached through a legal prism (in addition to a security prism) the liability risk increases. Attorneys should be used to attempt to shield adverse assessment opinions as well as to scrutinize the security team or QSA's interpretation of the PCI Standard. Attorneys should also be used to assist in the development of written policies and procedures, as well as documenting compliance with the PCI standard where appropriate. As the legal risks continue to grow, relying solely on security professionals for PCI compliance will not be an option.

    Action Items for Merchants

    As the PCI Standard increasingly becomes the law, merchants need to adjust their practices and develop a more legally-oriented approach to PCI compliance. On the security side merchants should consider the following:

    1. Choose QSA's wisely. Right now QSAs are the interpretative bodies of PCI. If a merchant uses a "fly-by-night" QSA it may be opening itself to risk. Merchants should use QSAs that are not afraid to give the merchant "bad news" and that understand how their interpretations may be viewed in a court of law.

    2. Insurance. Make sure that your QSAs are fully insured for their errors and omissions, and try to get named as an additional insured on their policies if possible. In addition, the merchant should check its own policies to determine whether it is covered if one of its service providers suffers a breach or if the merchant is required to pay a fine or penalty for non-compliance with PCI.

    3. Not a Rubber Stamp. Despite potential pressures to become PCI compliant quickly and at the least cost, merchants should not view their QSAs as "rubber stamps" of PCI compliance. QSAs, like all professional service providers, enjoy happy clients and will work hard to please their clients. However, if this causes them to take short cuts or apply loose interpretations, it could come back to haunt the merchant in the long run.

    4. Develop Relationships with General Counsel. The merchant's security team needs to engage the general counsel (or other members of the merchant's legal team). Many attorneys are intimidated by technology and security issues and may not be aware of the legal issues surrounding PCI compliance. Internal security professionals need to act as the expert advisors to the merchant's legal team and work together to translate security practices into legally compliant practices.

    5. Narrow Interpretations. To reduce risk of liability, security professionals should err on the side of interpreting the PCI Standard literally and narrowly. Of course this may conflict with other goals such as keeping expenses down and avoiding business disruptions. The security team should work with the merchant's business decision-makers and risk managers to achieve a balance that reflects the organization's risk tolerance.

    The merchant's legal team also needs to get involved in the PCI compliance process, including:

    1. Reaching Out to the Merchant's Security Team. Security professionals are often intimidated or uncertain about the law. Security professionals are not lawyers, and they need information to understand how the legal system scrutinizes and judges their activities and decision-making process. The merchant's legal team needs to translate legal and compliance concerns into terms that allow the merchant's security team to implement legally compliant security controls.

    2. Use Attorney-Client Privilege. Any adverse PCI compliance finding or assessment can and will be used against a merchant in court. Moreover, drafts of security and privacy policies, and documents (e.g. emails) surrounding the creation of such policies and practices, can be used against an organization in court. Some of the activities and documents of a merchant's internal and external security team may be shielded using attorney-client privilege or attorney work product privilege. While such privileges are not foolproof by any means, taking steps to preserve the privilege may at least pose an obstacle in litigation. Attorneys need to get involved early on in the compliance process to make this work.

    3. Analyze Upstream and Downstream PCI-Related Contracts. Much of the legal risk associated with PCI is contractual. Merchants cannot know their risk unless they know their contractual obligations and rights. Attorneys need to understand upstream contractual risk, and use their contracts to pass it on to service providers downstream.

    4. Draft Strong Service Provider Contracts. Attorneys should draft strong service provider contracts that require compliance not only with the PCI Standard itself, but also the specific Security Programs of each payment card company program that is applicable. These contracts should address section 12.8 of PCI, as well as providing assessment and audit rights, breach notice and remediation obligations, indemnification clauses and insurance clauses

    5. Develop a Service Provider Strategy. Service providers are likely to resist the imposition of additional PCI duties. A merchant's legal team should have contract language and a negotiation strategy developed ahead of time. The strategy should address both new service provider relationships and existing service provider relationships. For existing relationships, the merchant may be highly dependent on its service provider and may lack leverage to re-open contract negotiations. Nonetheless, an approach should be developed to persuade existing service providers to become PCI-complaint before the merchant is fined or receives threats to have its payment card processing privileges revoked because of the service provider's non-compliance.

    6. Strict Compliance - Upstream Waiver. If strict compliance with PCI is not possible, try to get a written waiver from the merchant's upstream contractor (e.g. payment processor merchant bank). The best case scenario is to get a formal amendment to the upstream contract reflecting the waiver. While this may not fully protect the merchant from third party suits, it may be helpful in contract disputes with the upstream contractor.

    Conclusion

    As the legal ramifications of PCI continue to develop and increase, PCI compliance will become an increasingly risky endeavor for merchants. Unfortunately, because the system is run privately by the payment card companies and does not have a centralized body to provide binding guidance and rulings, the system may pose more risk than a traditional governmental regulatory scheme. Regardless, now is the time for merchants to begin engaging their legal teams to address PCI compliance, and opening the lines of communication between the lawyers and security pros. It is also the time to start pressuring the PCI Council and payment card brands to develop a centralized body to provide publicly available and binding guidance and decisions resolving ambiguities within PCI. If these actions are not taken, the PCI Standard could present significant liability challenges for the retail community.

    Tags: , ,

    New Bills Concerning Encryption and Retail Liability

    The New Year is bringing renewed attempts to legislate data security. Michigan and Washington both have bills pending that would make retailers liable for payment card data security breaches (Michigan bill - Washington bill). The Washington bill explicitly requires compliance with the Payment Card Industry Data Security Standard to avoid liability.

    Both States also have bills that require encryption of personal data (Michigan bill - Washington bill). Both bills require encryption of stored personal data consistent with generally accepted industry standards (undefined). The Michigan bill sets forth criminal penalties for non-compliance, including imprisonment for up to 30 days and a fine of up to $1,000, or both.

    Tags: , , , ,

    Minnesota's "Plastic Card Security Act"

    A Direct Path to Merchant Liability for Payment Card Security Breaches

    As reported in ISC's March 2007 Newsletter, States like Massachusetts and a handful of others (five in total, including: MA, IL, CT, TX and MN) are considering bills that provide financial institutions (e.g. banks and credit unions) with the ability to sue organizations that expose payment card data due to a security breach ("Payment Card Breach Laws"). These proposed Payment Card Breach Laws provide banks with the right to reimbursement from merchants for costs associated with payment card security breaches, including for the cost to reissue credit cards (allegedly $20 - $50 per card). In short, under Payment Card Breach Laws, when a merchant suffers a breach it could be liable for thousands or even millions of dollars. Taking an extreme example, in the TJX matter, 45 million cards where allegedly exposed - the cost to reissue assuming $20 per card is $900 million. For smaller or medium companies that lose thousands or tens of thousands of card numbers, the impact could jeopardize their solvency.

    On May 21, 2007, Minnesota became the first State to pass such a law -- Minnesota's Plastic Card Security Act (H.F. 1758 -- the "Act") is a landmark statute that may radically increase the risk of liability and alter the security practices of retailers and service providers handling payment card data. In this issue, ISC summarizes the Act and outlines some of the issues and challenges arising out of it.

    1. The Plastic Card Security Act

    Subdivisions 1 and 2 of the Act, which prohibit the retention of certain payment card data for more than forty-eight (48) hours, first take effect on August 1, 2007. Subdivisions 3 and 4 of the law, which provides the right to reimbursement and allow financial institutions to file lawsuits to recover costs associated with a payment card security breach do not apply until August 1, 2008, and only apply to security breaches occurring after that date.

    A. "The 48-hour Rule" -- Payment Card Retention Limitations (Subdivisions 1 and 2)

    Subdivisions 1 and 2 of the Act attempt to address the problem of payment card security breaches by prohibiting companies that accept payment cards from retaining card security code data, PIN verification code numbers or the full contents of any track of magnetic stripe data ("Sensitive Authentication Data"), subsequent to forty-eight (48) hours after authorization of a transaction. Stated more simply, to comply with the Act, companies accepting payment cards must destroy or delete Sensitive Authentication Data within 48 hours of authorizing a transaction with such data (the "48-hour rule").

    This Act also applies to entities using service providers that store, process or transmit payment card data - a merchant that provides Sensitive Authentication Data to a service provider will be in violation of the Act if its service provider does not comply with the 48-hour rule.

    Coincidentally (or perhaps not so coincidentally) the Payment Card Industry Data Security Standard, v. 1.1 ("PCI Standard") also references and has rules surrounding Sensitive Authentication Data. Section 3.2 of the PCI Standard (as well as the Preface) prohibits the storage of Sensitive Authentication Data subsequent to authorization (even if encrypted). Unlike the Act, the PCI Standard does not specify a timeframe during which the merchant may retain Sensitive Authentication Data - by its silence, the PCI Standard arguably appears to require the destruction or deletion of Sensitive Authentication "immediately" after authentication. Therefore, as discussed below, PCI compliance (where there has been a tight interpretation of the section 3.2 requirements) may effectively act as a "quasi-safe harbor" from liability under the Act.

    B. Financial Institution's Right to Reimbursement

    The Act uses violation of the 48-hour rule as the trigger for financial institutions to recover when there is a security breach exposing payment card data. Subdivision 3 provides that when an entity that has violated the 48-hour rule suffers a security breach (or its service provider suffers a breach), any financial institution that issued payment cards affected by such breach is entitled to reimbursement of the costs of "reasonable actions undertaken by the financial institution as a result of the breach in order to protect the information of its cardholders or to continue to provide services to cardholders."

    Stated more simply, merchants holding Sensitive Authentication Data for more than 48 hours that suffer a security breach must reimburse "issuing banks" reasonable costs to protect cardholder information and continue servicing cardholders. Such costs could include (but are not limited to) costs in connection with:

    1. cancellation or reissuance of payment cards affected by the breach;

    2. closure of accounts affected by the breach;

    3. opening or reopening of accounts affected by the breach;

    4. refunds or credits to cardholders to cover the costs of unauthorized transactions; and

    5. notification of cardholders affected by the breach.

    In addition, such financial institutions are entitled to recover costs for damages paid by them to cardholders injured by the breach (e.g. essentially an indemnification right in the event the financial institution is sued or settles with a cardholder).

    Subdivision 4. of the Act (Remedies) provides financial institutions with a private right of under section 8.31 subdivision 3a. of Minnesota's laws (basically a consumer protection statute). In addition to a right to bring a suit to recover damages and equitable relief, subdivision 3a provides the financial institution with the right to seek costs of investigation and attorney fees. The Act states that the financial institution's private right of action is in the public interest and indicates that the remedies are cumulative and do not restrict any other rights or remedies available.

    2. Analysis

    This law presents some very interesting issues and challenges for companies accepting payment cards.

    A. Direct Path to Liability -- Low Harm Threshold - "Costs of Reasonable Actions"

    Where the worlds of data security and the law meet, to date and despite many lawsuits, there have been very few instances of courts finding legal liability for security breaches. In fact, issuing banks have previously tried to sue retailers for payment card data breaches, but the courts presiding over those cases rejected the banks' third party beneficiary, negligence, promissory estoppel and breach of fiduciary duty claims, and dismissed the cases (see e.g. B.J. Wholesaler Summary Judgment Ruling, PSECU Motion to Dismiss). In short, there was no legal theory that clearly provided a right for issuing banks to recover - that hurdle has been jumped by the passage of the Act.

    Now issuing banks have specific statutory rights to reimbursement and indemnity, as well as a private right of action to enforce those rights. The only requirements are as follows: (1) the entity is in violation of the 48-hour rule; (2) it suffers a breach of personal information affecting payment cards; and (3) the issuing financial institution incurs costs of reasonable actions to protect or continue servicing cardholders. There is no requirement that the merchant have acted intentionally, willfully, recklessly or negligently.In fact, it does not appear that the financial institution even has to establish that Sensitive Authentication Data was exposed.

    As far as reimbursable costs are concerned, the issuing financial institution need not establish that the costs it incurs are necessary, just that the costs arise out of "reasonable" actions. The issuing financial institutions are not explicitly required to show that they will suffer harm or fraud if they do not take the actions (although this would factor into what constitutes "reasonable actions"). Their actions can be completely precautionary in nature so long as they are reasonable. In addition, there is a high likelihood that a court would view the list of example provided in the statute as representing examples of "reasonable actions" and perhaps a minimum list of what financial institutions are entitled reimbursement for. With the costs to reissue cards allegedly ranging from $20-50 per card, the costs of reissuance alone could be substantial (e.g. banks, including Chase, Citibank, the Maine Credit Union and TD Bank North, have already reportedly reissued millions of payment cards based on the TJX breach).

    B. Nationwide Applicability -- Scope Beyond Minnesota?

    Does the Minnesota law have a nationwide applicability? The answer is "maybe" for persons or entities doing business in Minnesota and elsewhere in the United States. Unlike Minnesota's consumer-oriented breach notice law, which requires notice to Minnesota residents whose personal information may have been acquired by an unauthorized person (See H.F. 2121), the Act is not limited to Minnesota residents. Rather, it applies to "persons or entit[ies] conducting business in Minnesota" and unauthorized acquisition of computerized personal information (regardless of the residency associated with that information). Therefore, by the plain words of the statute, it may be possible that a company simply doing business in Minnesota, which suffers a breach in California, could trigger duties under the Act.Of course there may be jurisdictional issues that preclude suit in Minnesota or application of Minnesota law, but the issue is complex and far from clear.

    C. Service Provider Liability

    Unfortunately for merchants that use service providers to handle payment card data, the Act still applies if their service provider suffers a breach. What this means for practical purposes is that merchants must ensure that their service providers have processes in place to comply with the 48-hour retention rule. This may be problematic: if the service provider does not have those processes in place it may charge merchants to comply. Moreover, despite the August 1, 2007 start date for the Act, it may take some time to modify systems and processes to achieve compliance.

    Finally, the Act will require merchants to add new contractual duties to their service provider contracts that mandate compliance with the Act and most importantly, provide for indemnification. Significantly the Act makes the merchant responsible for the breach, and does not provide a direct route for banks to go after service providers unless "accepting an access device [payment card] in connection with a transaction." Merchants will have to add indemnification language to shift the risk of loss for breaches that are the service provider's fault. For existing relationships, merchants may have to reopen contract negotiations.

    D. Personal Information Requirement

    One potential limitation of the Act is the definition of "personal information." The Act requires the acquisition of personal information by an unauthorized person to be triggered. In this context, personal information includes an individual's first (or first initial) and last name, in combination with account number or credit or debit card numbers, in combination with any required security code, access code or password that would permit access to an individual's financial account. Therefore, if a breach occurs that only exposes payment card data, but does not expose the combination of data listed in the definition of "personal information," the Act may not apply. It is unclear whether companies can segregate this data to avoid the combination that triggers the Act - merchants should confer with their internal or external security professionals to further explore this and other risk-reducing measures.

    E. No Encryption "Safe Harbor"

    Unlike Minnesota's breach notice law applying to consumers (see H.F. 2121) which only applies to breaches of "unencrypted" personal information, the Act does not provide an "encryption" safe harbor. In other words, the Act applies even if Sensitive Authentication Data stored more than 48-hours is encrypted. It appears that the drafters have decided that the only way to avoid applicability of the law is to destroy or erase Sensitive Authentication Data. Significantly, section 3.2 of the PCI Standard also discounts encryption of this data.

    F. Relationship to the PCI Standard - PCI "Quasi-Safe Harbor?"

    Is compliance with the Act impacted in any way if a merchant or service provider is compliant with the PCI Standard. Strict compliance with the PCI Standard may effectively create a quasi safe-harbor to avoid liability under the Act. Both the Act and the PCI Standard prohibit the retention of Sensitive Authentication Data, however the Act allows retention of such data for 48 hours, while section 3.2 of the PCI Standard prohibits storage of such data completely after authentication (some qualified security assessors have said that VISA's time limit is 24 hours - however this is not explicitly stated anywhere). Therefore, if an entity is compliant with the PCI Standard, so long as section 3.2 of the PCI Standard has been strictly interpreted and followed (e.g. immediate deletion or destruction), they should also be in compliance with the Act's 48-hour retention rule.

    The problem of course is that it is possible that some entities (or their qualified security assessors) may have interpreted section 3.2 more loosely, potentially allowing Sensitive Authentication Data to be retained beyond 48 hours. Therefore, entities that are PCI Compliant should not automatically conclude that they are compliant with the Act. They should check with their internal or external security assessors to determine how long Sensitive Authentication Data is stored and how strictly they interpret rule 3.2. Moreover, for future PCI security assessments, entities should at least consider imposing a 48-hour retention limitation on Sensitive Authentication Data retention if they want to be aligned with the Act.<

    3. Conclusion

    The Plastic Card Security Act and similar Payment Card Breach laws are likely to significantly impact the data security risks and liability associated with handling payment card data. For one of the first times in U.S. history, a direct liability path exists for a large segment of U.S. businesses that suffer security breaches involving payment card data. The true impact will not be known until these laws are used, but, especially for small or medium companies heavily reliant on payment card transactions, a careful examination of security practices and service provider contracts is recommended to achieve compliance with the Act. In addition, for those merchants that have not yet complied with the PCI Standard, now is the time to get serious.

    As with many data security-related laws and regimes, compliance and risk management is a multi-disciplinary exercise. Entities should retain an attorney to assist with interpreting the Act and modifying service provider contracts to align with the Acts 48-hour rule. Security professionals should be asked to assist with achieving the data retention requirements, as well as working toward PCI compliance (and strict compliance with section 3.2). Finally, this is an area where information security and privacy liability insurance has clear and direct value. Companies should look at their current policies to determine whether coverage exists, and should consider security and privacy policies available in the market that are directly geared toward covering such liability. Taking these steps will provide a solid foundation to begin addressing the risk associated with the Act and other Payment Card Breach Laws that get passed.

    Tags: , , , , ,

    Proposed Massachusetts Security Breach Notice Law Creates Additional Liability for Companies Accepting Credit Cards.

    For companies that store or process credit card data, the legal landscape may be getting a little more risky.

    Similar to breach notice laws passed in thirty-five other States, a proposed Massachusetts bill (H. 213) requires notice to residents of the State if, as the result of a breach of system security, "misuse of information about a Massachusetts resident has occurred or is reasonably likely to occur." The bill also requires entities that do not own or license personal information (which appears to include service providers working on behalf of the company that originally collected the information) to report to the owner or licensee of the personal information.

    However, the bill goes a step further and requires organizations to reimburse banks for banks' "reasonable actions" in response to a data security breach where notice is required. Reimbursable costs include:

    1. the cancellation or reissuance of any credit card issued by any bank or access device;

    2. the closure of any deposit, transaction, share draft or other account and any action to stop payments or block transactions with respect to any such account;

    3. the opening or reopening of any deposit, transaction, share draft, or other account for any customer of the bank; and

    4. any refund or credit made to any customer of the bank as a result of unauthorized transactions.

    This new remedy may be related to recent unsuccessful lawsuits by banks seeking to recover the costs of reissuing credit cards exposed as the result of a security breach.

    In 2005 B.J. Wholesalers suffered a security breach and was sued by several "issuing banks" to recover costs to reissue credit cards (B.J. Wholesalers faced suits by four banks alleging millions of dollars in losses). However, the courts presiding over those cases rejected the banks' third party beneficiary, negligence, promissory estoppel and breach of fiduciary duty claims, and dismissed the cases (see e.g. B.J. Wholesaler Summary Judgment Ruling, PSECU Motion to Dismiss)

    More recently, TJX Companies (holding company of such retailers as TJ Maxx, Homegoods and Marshalls and headquartered in Massachusetts) was sued by an Alabama-based AmeriFirstBank Inc. bank in the wake of a security breach. AmeriFirstBank alleges that it costs the bank approximately $20 to reissue a single card. News reports indicate that the breach may have exposed more than 40 million credit cards and approximately 60 banks have been notified of potential exposure. Some of these banks, including Chase, Citibank, the Maine Credit Union and TD Bank North, have already reportedly reissued millions of credit cards based on the TJX breach.

    This Massachusett's bill may not be an isolated event -- other States and the Federal government are reportedly considering similar legislation according to this credit union source.

    What might this mean in terms of managing information security risk?

    For companies handling credit card information it means a fairly direct path to legal liability if a breach exposes credit card information. The legislation is not limited to a narrow definition of retailer, but applies to the "commercial entities" (broadly defined). Assuming damages of $20 for each card reissued, if a breach involves several thousands or millions of cards, the potential damages could be staggering. For smaller organizations a potential security breach could result in bankruptcy. For larger retailers with millions of credit cards stored, it could result in tens of millions of dollars in damages.

    Moreover, the standard of proof for banks is arguably not very high. First, there must have been a security breach that resulted in the misuse of information about a Massachusetts resident, or such a misuse is reasonably likely to occur. Second, the banks actions must have been "reasonable actions," which includes those broad actions listed above. Therefore, a decision to report arguably guarantees that the organization will have to reimburse some bank costs. Ironically, since consumers do not have a direct remedy in the statute, the law may produce a strong incentive to avoid reporting to consumers if there is uncertainty as to whether misuse has occurred.

    What should companies do to if a law like this is passed?

    From a risk management perspective, organizations should conduct a risk analysis to determine how much credit card information they are handling, and whether it is subject to being stolen in large quantities. Since the potential liability for a breach could be enormous, the justification for enhanced security should be present. Regardless, companies should work hard toward at least achieving PCI compliance if handling credit card data. Since companies may be liable if their service provider suffers a breach, they should work to assess the controls of those service providers (or only work with those that are certified as PCI compliant.)

    In addition, the existence of a law like this creates a very strong argument for insurance to transfer the risk of loss. Risk managers should check their insurance policies to determine if any coverage exists under their current forms, and should consider the purchase of information security and privacy policies. Some policies now provide coverage for liability arising out of a security breach and with respect to the costs of providing notice of a security breach.

    From a legal perspective, it appears that legal liability could arise out of a breach related to a third party service provider. Therefore, attorneys for companies collecting credit card information and passing it on to service providers for processing must make sure that there are contractual duties to maintain adequate security, report security breaches and potentially indemnify for losses (in fact the PCI Standard actually requires the development of contract terms that mandate compliance with the PCI Standard). In addition, attorneys need to be versed in the details of such laws so they can provide good counseling when a suspected security incident occurs.

    Conclusion.

    It is very interesting that the liability potential for security breaches is now being pushed from the commercial side (while being pushed more slowly from the consumer side). If a bill such as H. 213 is passed it has the potential to radically change the information security risk management dynamic for companies handling credit cards. There will be strong interests on both sides (banks versus retailers) that will push for and against a scheme like this, so it is unlikely that it will be passed in its current form. Nonetheless, it will be very interesting to see if and how these laws develop further, and it is important for risk managers to pay close attention to the progress of bills of this type.

    Tags: , , , , ,