Quickhits: Federal Judge Dismiss Aetna Data Breach Case Due to Lack of "Injury-in-fact"
A Federal judge in the U.S. District Court for the Eastern District of Pennsylvania dismissed a class action lawsuit arising out of a data security breach involving Aetna, Inc. (original compliant found here). The basis of the dismissal was the plaintiff's lack of standing due to its failure to allege an "injury in fact" (the dismissal was under section 12(b)(1) of the Federal Rules of Civil Procedure). In particular the court held that the plaintiff's alleged injury in the form of an increased risk of identity theft is far too speculative based on the factual allegations.
The following quote cited by the court (from another case), is indicative of the court's reasoning:
[f]or plaintiff to suffer the injury and harm he alleges, many ‘if’s’ would have to come to pass. Assuming plaintiff’s allegation of security breach to be true, plaintiff alleges that he would be injured ‘if’ his personal information was compromised, and ‘if’ such information was obtained by an unauthorized third party, and ‘if’ his identity was stolen as a result, and ‘if’ the use of his stolen identity caused him harm. These multiple ‘if’s’ squarely place plaintiff’s claimed injury in the realm of the hypothetical. If a party were allowed to assert such remote and speculative claims to obtain federal court jurisdiction, the Supreme Court’s standing doctrine would be meaningless.
Note that the basis of this dismissal was not a "failure to state a claim" under 12(b)(6). Rather this decision basically held that the plaintiffs could not even get a hearing in court on a 12(b)(6) motion because the court lacked subject matter jurisdiction to hear the case at all. Also note that other courts have found standing for data breach cases, including the Seventh Circuit in Pisciotta. However, those that have proceeded past the 12(b)(2) motion have often been dismissed under 12(b)(6). In all, no matter how it happened, it appears that plaintiffs still have significant challenges moving consumer data breach cases further toward trial.
More commentary can be found here.
Issuing Banks File Class Action Suit Against Acquiring Banks in Heartland Breach Matter
In an interesting development, a handful of issuing banks impacted by the Heartland breach have filed a class action lawsuit against two acquiring banks related to Heartland Payment Systems. According to this article, the issuing banks are unhappy with Heartland's proposed settlement with Visa. This appears and to be an attempted end-run around the proposed $60 million settlement with Visa. It also may demonstrate that issuing banks are not satisfied with the dispute resolution mechanisms under the Visa Operating Regulations (the Account Data Compromise Recovery process estimated the loss at $140 million, yet the settlement was for only $60 million), and their ability to be made whole under those mechanisms. We will have more analysis of the complaint at a later day. In light of the relative lack of success issuing banks have had in these types of cases, it will be very interesting to analyze the legal theories employed by the issuing banks and track the progress of this matter.
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).
Quickhits: Security in the Ether; Countrywide Settles Data Breach Case
Happy New Decade (2010)! Unbelievably another decade is gone. Information law developments continue to occur at an increasingly fast pace. The InfoLawGroup is catching up from a very busy December, so we will start out the 2010 blogging with a couple quick hits.
Security in the Ether. A very nice article by David Talbot on the security challenges, myths and misperceptions around Cloud computing. The challenge for security pros and lawyers: what is "reasonable security" in the Cloud, how do you perform your "due diligence," how do you document your due diligence process for use in the event of a breach, litigation or a regulatory action, and how do you draft and negotiate contracts for Cloud-based services?
Judge Preliminarily Approves Countrywide Data Breach Lawsuit Settlement. Faced with 35 lawsuits (many of them class actions) arising out of a security breach exposing the records of millions of customers, Countrywide Financial Corp. has chosen to settle. The settlement includes an offer of one year of credit monitoring for up to 17 million people. In addition, customers that suffered identity theft may recover up to $50,000, but only if they actually lost something of value, were not reimbursed and the theft stemmed from the Countrywide breach. Assuming a 20% redemption rate and a cost of $5-$15 per year for credit monitoring, the credit monitoring alone could cost from $17 million to $51 million (probably on the lower end of the scale -- Countrywide should be able to negotiate favorable credit monitoring rates considering the potential volume). Additional costs that Countrywide had to incur include legal fees and breach notice expenses (assuming breach notice laws were triggered). Does this settlement (and others I am aware of other settlements that have been less publicized) indicate a growing fear that the "damages" wall is weakening?
Quickhits: AMEX settles with Heartland Payment Systems for $3.6 Million
Read all about it: HERE.
The Merchants Strike Back?
With the recent news of several restaurants teaming up to sue point-of-sale system provider Radiant Systems (a copy of the complaint can be found here) for failing to comply with the PCI Standard, it appears that some merchants may be in a mood to strike back in the aftermath of a payment card security breach. This lawsuit comes in the wake of a couple lawsuits against payment card security assessor Savvis for allegedly failing to properly validate a processors' Visa CISP compliance (admittedly in this case it is the merchant bank suing the assessor, but a similar cause of action could exist for a merchant if its assessor makes a mistake in verifying PCI compliance). While two instances certainly don’t indicate a trend, they do indicate a potential route that merchants may consider to deflect liability arsing out of a payment card security breach.
It is possible that we will see more lawsuits by merchants against service providers, payment processors, and application/point-of-sale system providers in the coming months and years. Part of the reason is that the PCI regulatory system imposes a form of “strict liability” on merchants that suffer a security breach. Fines, penalties and the availability of recovery processes are contingent (in part) on whether or not a merchant was PCI-compliant at the time of the breach (see e.g. Visa’s ADCR). Thus, when a Qualified Incident Response Assessor ("QIRA") comes in after a credit card breach to do an audit one of its main tasks (if not its primary goal) is to ascertain whether the merchant was PCI-compliant.
Lost in the shuffle sometimes, however, is the issue of “causation.” The question that is not being asked is whether or not PCI compliance would have prevented the breach, or whether the lack of PCI-compliance was the cause of the breach. In other words would PCI-compliance have made a difference. In some cases the answer is obvious. For example, if a merchant is holding onto sensitive authentication information, clearly PCI compliance (which requires the deletion of such data after a transaction) would have precluded a payment card breach. In other situations, however, the answer might not be as clear cut.
Moreover, even where a merchant is found not PCI compliant, the question still remains whether any other party was fully or partially responsible for the breach itself. Was the merchant’s payment application the source of the breach? Was the merchant working with a service provider, gateway or processor that could have been the source of a virus or attack by a hacker? Unfortunately, with their focus on PCI compliance, a QIRA may not have cause to investigate further into these possibilities (and a separate forensic assessment by an independent forensic firm may be necessary). In fact, I have seen an audit report where the auditor literally indicated that it could not determine how malware got onto a merchant’s system or whether cardholder data ever left (and in the report decided to speculate that it may have been porn or file sharing sites).
Beyond the entities involved in storing, processing or transmitting payment cards, merchants may also begin to target companies assisting their efforts to achieve and validate compliance with PCI. Consultants that help merchants become PCI compliant or remediate PCI violations may be targets if they make a mistake. Moreover, as Savvis shows, qualified security assessors that make mistakes in their validation of PCI compliance are also potential defendants.
Despite sometimes having a variety potential targets to recover from, merchants still face obstacles to actual recovery post-security breach. The biggest obstacles are the contracts that merchants enter into with the entities mentioned above. In most cases these contracts contain terms that effectively limit the liability of these entities and make it very difficult to recover under any theory of recovery.
So is there an answer for merchants to these contract clauses? Thinking ahead might make all the difference in this case. When entering into a contract with any of the various entities described above, at the Request for Proposal phase, merchants should make indemnification and other favorable contract terms (e.g. no limit of liability/disclaimer of consequential damages for security breaches) part of the bidding process. Merchants' propsective service providers, assessors and application providers should be forced to compete on the issue of taking responsibility when they are fully or partially at fault for a security breach or inaccurate/improper PCI validation. Proper levels of cyber insurance should be in place to allow merchants to recover if there is a breach. If merchants don’t take these steps early on and in a disciplined fashion they may find themselves holding the bag even in situations where others may have contributed to their security breach.
Merchant Liability for "Time and Effort" Following Security Breach?
The Hannaford saga continues, with possible civil liability implications for retailers.
Earlier this year, a federal judge in Maine dismissed almost all claims in the consolidated class action lawsuit against Hannaford Brothers Co. (In re Hannaford Bros. Co. Customer Data Security Breach Litigation, MDL No. 2:08-MD-1954, USDC Maine). Hannaford had millions of payment card records hacked in 2007 and 2008. Judge Hornby ruled that the common law in Maine allows consumers to seek restitution only for unreimbursed fraudulent charges on their credit or debit cards. Since the card issuers reversed the fraudulent charges under their “zero-liability” policies, the cardholders suffered only “collateral consequences” such as the time and effort involved in changing cards and accounts, monitoring for fraud, and dealing with banks, merchants, and others following notice of the breach. Judge Hornby did not believe such collateral harms were cognizable injuries under state law.
This week the judge reversed that decision and certified to the Maine Law Court (the highest court in the state) the following question:
“Do time and effort alone, spent in a reasonable effort to avert reasonably foreseeable harm, constitute a cognizable injury under Maine common law?”
That question might well be raised in many states that, like Maine, require some form of “economic loss” to sustain an action for negligence. The answer from the Maine Law Court could be an important precedent. So far, plaintiffs in the United States have generally been unsuccessful in pursuing claims against merchants based on fear of identity theft and incidental expenses to protect against it, following a security breach incident. “Lost time and effort” may not be worth a great deal in damages to any single cardholder, but if Maine allows such claims to proceed, a class action with millions of class members could make “time and effort” claims daunting, as well as allowing plaintiffs to sustain an action in which emotional distress can also be asserted as grounds for damages.
This development should serve as an additional spur for retailers to take precautions against the kinds of attacks that resulted in Hannaford’s data losses. Adherence to applicable security guidelines, prominently the Payment Card Industry Digital Security Standard (PCI DSS), will go far to avoid such incidents and protect a company from fines and civil liability as well. The Hannaford hackers, one of whom is now in jail, used SQL injection to plant malware in the merchant’s servers. This is hardly a new technique, and it is one that retailers may be held accountable for neglecting.
In 2008 Hannaford, which operates more than 150 grocery stores in New York and New England, announced that its payment card processing servers had been hacked for several months, exposing millions of payment card records and resulting in thousands of fraud investigations in the Northeast. In August this year, a federal grand jury in Newark, New Jersey indicted a 28-year-old Florida hacker named Albert Gonzalez (formerly an informant for the US Secret Service) and two unnamed persons living “in or near Russia” as conspirators who allegedly carried out the Hannaford hack and several others, including massive attacks on Heartland Payment Systems and the 7-11 retail chain. Gonzalez is already awaiting trial on charges in connection with the TJX hack in 2007. Altogether, the ring is accused of stealing data on more than 130 million credit cards and debit cards. According to the TJX and Hannaford/Heartland indictments, the hackers used several methods, but primarily SQL injection, to gain access to the target networks and install sniffer malware that intercepted card details and transmitted them to computers controlled by the hackers.
The Federal Trade Commission has publicly taken the position that SQL attacks are “commonly known or reasonably foreseeable” (see, for example, the FTC Complaint against Guess?, Inc., and the FTC’s press release concerning Life is good, Inc.). Thus, the FTC has fined retailers following such attacks and in some cases entered consent orders imposing additional sanctions and requirements. This makes it relatively easy to assert negligence in a civil action on behalf of a class of cardholders following a successful SQL attack.
