Info Law Group : Technology Lawyers & Attorneys : Information Law Group : Privacy, Security & Intellectual Property 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.

Security Incident Response Planning

As mentioned above, a Customer should think of a Service Provider’s security as an extension of its own internal security. This applies not only to the controls the Service Provider maintains, but also how a Service Provider responds to a security incident. The key here is to impose obligations on the Service Provider that provide the Customer with the most control possible in responding to, and mitigating the impact of, a security incident.  In addition, in the event litigation or a regulatory action is a possibility, Customers should attempt to secure rights that allow them to collect and preserve evidence relevant to their defense (or in some cases a suit against the Service Provider).

On the front end, Customer should investigate the Service Provider’s security incident response procedures. In particular, the Customer should ask:

• Does the Service Provider have controls and policies in place to detect an incident?

• Once detected is there a chain of communication that escalates the incident to appropriate personnel?

• Are there procedures for ascertaining the risk and potential impact posed by a security incident?

• What processes exist to allow for the quick remediation of a security breach?

Moreover, since a forensic analysis or security assessment will often be necessary post-breach, the Customer should investigate what information is retained by Service Provider, and the Schedule should obligate the Service Provider to retain certain information that may be relevant to a breach (e.g. logs, error reports, planning documents, security policies, etc.)

Beyond that the Customer should consider how the Service Provider and Customer will interact in the event the Service Provider suffers a security breach impacting the Customer’s information, systems or ability to conduct business. The Schedule should require the Service Provider to identify an incident response coordinator to serve as the communication point for the Customer. Communication obligations can also include a point of contact within Customer’s organization, including in some instances a security breach emergency "hotline" phone number. The Schedule may include “deadlines” for providing notice of security breaches to the Customer (e.g. “immediately” or “within twenty-four hours” of discovery, etc.). The Schedule should include a general cooperation clause, and where appropriate specific incident response procedures between the Service Provider and Customer.

In addition, the Schedule should require the Service Provider to provide reports and information concerning the security incident, including information concerning what went wrong, what information or systems were impacted, and the remediation taken and planned by the Service Provider. The Schedule should also provide the Customer with the ability to conduct its own independent forensic analysis and security assessment after a breach. Since litigation or regulatory action is possible after a breach, the Schedule should include mechanisms for initiating a litigation hold and preserving information that may be relevant in a litigation context, as well as procedures for responding to information requests by regulators or litigants.

Risk of Loss

While most of the items discussed above are rather unique to the information security and privacy realm, risk of loss provisions are common to most contracts. These terms include warranty disclaimers, consequential damages disclaimers, limitation of liability clauses and indemnification clauses. Risk of loss terms should also address information security and privacy risk.

First, it is not unusual for a security incident to yield “consequential damages” in addition to “direct damages," including loss of profits, lost customers, attorney fees, breach notice costs and other similar costs. If the overall contract contains a consequential damages disclaimer, the Customer should endeavor to get an exception for consequential damages arising out of a security incident and/or breach of the Schedule.

Second, the Customer’s damages arising out of security incident can be enormous. They can include loss of profits, expenses to defend litigation (often multiple lawsuits for large breaches), regulatory defenses, damages, fines and penalties arising out of litigation, costs to provide notice to individuals whose personal information was breached, credit monitoring expenses, call center expenses and third party forensic analysis expenses. If a limitation of liability clause is in the contract, Customers should consider whether the liability cap would be sufficient to make them whole in the event of a security breach. If not, Customers should attempt to negotiate an exception to the limitation of liability (or perhaps a different limit of liability) for loss arising out of security incidents or breaches of the Schedule.

Last, enhanced indemnification/reimbursement language should be considered. As discussed throughout, it is not unusual for litigation or a regulatory action to arise out of a security incident. In the event the a breach of the Service Provider leads to litigation a regulatory action, the Schedule should include an indemnification or reimbursement clause that pays for the defense of these actions and indemnifies Customer for all damages, fines, penalties and other costs arising out of such actions.

In addition, the Schedule should also include a duty for the Service Provider to indemnify (or pay for) certain breach notice-related expenses. To date approximately 45 states have passed breach notice laws that require companies to provide notice to individuals whose person information may have been compromised. There are many expenses that arise out of the legal requirement to provide notice, including forensic expenses, attorney fees and mailing costs. In addition, some Customers may also want to provide affected individuals with a call center and credit monitoring. Many of these expenses have a “multiplier” component that can result in enormous damages. For example, one year of credit monitoring could cost anywhere from $10 to $360 per year per individual. If credit monitoring is provided to 1 million affected individuals a low-end estimate of the cost would be about $10 million. Therefore, the Customer should attempt to include language in the Schedule that requires the Service Provider to pay for or indemnify the Customer for these costs as well. If possible, all such indemnification costs should be outside the limit of liability.

Finally, organizations should consider another method for transferring risk of loss: insurance. “Cyber” insurance is available that can cover many of the types of loss that arise out a security or privacy breach, including loss of income, remediation expenses, data restoration, attorney fees, damages, fines and penalties, forensic expenses, breach notice expenses, credit monitoring expenses and call center expenses. The Schedule should require the Service Provider to carry both errors and omissions and “cyber” risk coverage with appropriate limits of liability. The Customer should attempt to mandate that it be named as an additional insured under the Service Provider’s policy (this option, however, may not be available as it will depend on whether the insurer is willing to provide “additional insured” coverage). In addition, Customers should consider purchasing their own cyber policy to provide direct coverage. Many carriers will provide coverage to the Customer for security and privacy breaches arising from a Service Provider security incident.

Conclusion

An information security and privacy schedule that sets forth Service Provider security and privacy obligations, and Customer rights with respect to the same, is an increasingly important and necessary part of an information technology, outsourcing or cloud computing transaction. Lawyers charged with developing such terms should be aware that Schedules serve several simultaneous purposes that are specific to the compliance and liability risk associated with data security and privacy. As a final point, the Schedule is a classic example of where “hybrid” knowledge of the law and security is required. A large part of the Schedule involves “translating” legal compliance and risk issues in a manner that can be understood by security and privacy professionals (and vice versa). As such lawyers should work closely with their client’s information security and privacy teams to develop security assessment processes, draft the terms of a Schedule, and negotiate Schedule terms with Service Providers.

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

Dark Opaque Storm Clouds or White Fluffy Transparent Clouds?

When it comes to relationships is the Cloud more like a dark storm cloud that one cannot peer into, or is it more like a fluffy, light and transparent cloud that allows one to see what is happening within? Unfortunately, the current forecast in some areas is for dark Clouds that make it difficult for Cloud Users to understand exactly with whom they are dealing and who is storing and processing their data.   Transparency may be elusive and the very nature of the Cloud computing architecture may be the cause of this. In other words, even if an attorney wants to discover who is actually processing their data, the nature of the Cloud may make it very difficult for Cloud providers to provide definitive information on that point. This is in stark contrast to most traditional outsourcing relationships involving a single vendor and dedicated computing resources or software.

Moreover, even if all the Cloud players are known, it may be difficult for Cloud Users to manage and shift responsibility to a party that it has no direct relationship with, and no direct contractual legal rights or remedies. 

In a traditional dedicated outsourcing model (e.g. web or data hosting, ASP model, etc.) organizations often deal with a single service provider that provides computing resources. That service provider typically would own or control the computing resources that support the outsourcing transaction. Oftentimes those computing resources would be dedicated solely to a particular client. To clarify and solidify this one-to-one relationship the outsourcing contract might have a clause prohibiting the use of sub-contractors to provide the services. In terms of legal risk, the organization utilizing the service provider would be able to conduct its due diligence (e.g. privacy compliance, “reasonable security,” etc.) on a single entity. Moreover, the organization would be able to negotiate a contract shifting risk between it and the service provider knowing that the service provider in essence directly “controlled” the risk by virtue of its control of the computing environment. Even in cases where a service provider uses a sub-contractor, in the typical case, the organization could fairly easily discover the identity of that party and perform its due diligence. More rare are instances of generic unidentified sub-contractors, or sub-contractors utilizing sub-sub-contractors.

Relationships in the Cloud: Who is processing my data?

It can be very different in the Cloud (click here to view one version of the Cloud landscape). This is not to say that Cloud relationships are not/cannot involve one-to-one relationships like traditional outsourcing. They can. At the base of the Cloud stack, it would not be unusual for IaSS providers to have direct relationships with some of their end-clients. For example, if an organization contracts directly with Amazon Web Services, a Cloud Platform (Infrastructure as a service – IaaS), to allow the organization to build its computing resources in Amazon’s Cloud, it would have a degree of confidence that it was dealing with the party that directly controlled and was responsible for maintaining the Cloud Platform. However, there are service-oriented organizations (integrators) that will actually help to build computing resources on a particular Cloud Platform. In that case a client would not necessarily have a direct relationship with the Cloud Platform, and yet would be subject to the limitations and problems of the Cloud Platform.

The problem is more prevalent as one moves up the Cloud stack. Companies that offer software as a service (SaaS) may have built their application within a particular Cloud Platform (examples can be found here, here, here, here and here). The Cloud User again would typically be dealing solely with the SaaS provider despite the fact that the Cloud User’s data is actually being stored and processed (in part or whole) by the Cloud Platform (at the PaaS or IaaS layer). In fact, it is possible that a particular Saas may actually serve its application on multiple Cloud Platforms. Those Cloud Platforms again are one step removed from the Cloud User and each may pose different legal risks. For example one Cloud Platform may have servers across the globe thereby potentially exposing a Cloud User to multiple privacy laws in various jurisdictions, while another may be purely domestic (thereby limiting the jurisdictions to which it the Cloud User may be exposed). In fact, there may be significant economic incentives for SaaS providers to switch between Cloud Platforms that are more efficient or less expensive (thereby improving the SaaS profit margin).

To make the situation more complex, it is also possible for a particular SaaS to use more than one Cloud Platform for an individual Cloud User client. In these cases, data processing might alternate between multiple Cloud Platforms (either because it provides for better efficiencies or perhaps a particular Cloud Platform provides the SaaS with a better price/profit margin). Again, in the legal context this can be problematic. If a SaaS decides to move processing to a Cloud Platform with weak security for example, it could significantly increase the liability risk of a Cloud User if the platform suffers a security breach. It would be very difficult to perform adequate “due diligence” where data is constantly shifting between multiple Cloud Platforms.

Cloud Service Aggregators

Unfortunately, this may be just the tip of the iceberg. In the foregoing example the Cloud User was at least dealing with a single Cloud SaaS provider on the front end. This would not be the case when dealing with Cloud service aggregators. Aggregators essentially bundle (and possibly integrate) multiple SaaS services into a “single” service (examples of aggregation models are here and here). For example, one could envision an aggregator bundling multiple Cloud SaaS offerings for use by travel agents (you can search for examples of SaaS providers serving industry verticals here). The bundle might include a customer relationship management application, a booking and reservations application, a credit card processing application, a billing platform, an international time zone translator application and an electronic signature/e-commerce application. To the Cloud User this bundle would appear to be a single seamless consolidated application. 

The reality is that each of the applications may be operated or created by separate SaaS providers. It is also possible that each of these SaaS providers might serve their application on a different Cloud Platform. There may be variations in each application in terms of reliability and security. Moreover, as discussed above each SaaS provider might be using multiple Cloud Platform’s and that use may not remain static (e.g. it’s a moving target). While aggregation models appear to be just gaining traction they could become more prominent going forward, and legal and security/privacy impacts of these models need to be carefully scrutinized.

The Legal Conundrum

The scenario described above poses significant legal challenges for Cloud Users’ transactional and compliance counsel (as well as security and privacy professionals). Due diligence and contracting are potentially much more difficult when the Cloud is involved.

In some cases the Cloud User may be two or three levels removed from the organizations actually processing and storing the Cloud User’s data.   For example, without a direct relationship with the lowest level Cloud Providers, organizations will not be able to directly analyze compliance issues around privacy and security compliance and reasonableness. As such Cloud Users will have to somehow confirm that the direct party they are dealing with engaged in proper due diligence. It almost becomes a meta analysis: due diligence might involve a Cloud User analyzing whether a Cloud Provider’s due diligence process itself was adequate. This would likely include receiving any reports or other types of analysis performed by the higher and lower level Cloud Providers.  As discussed below it should also include a review of the contracts the higher layer Cloud Provider has with the level below it. 

Of course it more than two levels are involved or there are multiple service providers or Cloud Platforms involved on a particular level, one must have confidence that each of the players also performed adequate due diligence on the providers it utilizes, and so on. So in essence, the Cloud User would be seeking to somehow validate that the Cloud Provider performed adequate due diligence of the due diligence process of the Cloud providers in the level immediately below it. In essence, the Cloud User would want to see a “Chain of Due Diligence.”   This requires that the providers on each level of the chain think ahead and anticipate the needs of the Cloud provider or Cloud User in the layer immediately above it.

Another example to illustrate the point involves incident response contract terms. What happens when the Cloud transaction involves multiple layers and the lower layer suffers a data security breach exposing the PII of the Cloud User’s data? What happens when the Cloud User needs to implement a litigation hold to preserve data where the data resides in the lowest layer of the Cloud?

In a typical direct outsourcing relationship, the outsourcer and its client would build processes in to address these issues and the contract would provide for particular rights and remedies. While similar contractual rights and obligations may be built into a Cloud transaction, it is not clear how useful they would be when multiple layers are involved. For example, if a SaaS built on a Cloud Platform has itself failed to obtain certain rights and abilities to forensically analyze and preserve data processed in the Cloud Platform, the Cloud User may not be able to adequately build defenses in a security breach context or implement an effective litigation hold (regardless of what the contract between the SaaS and Cloud User provides).

A final example: data retention and destruction policies. What if the SaaS provider is working on a Cloud Platform that creates residual copies of data that the Cloud User has a legal obligation to delete? What if the SaaS provider works with a Cloud Platform that does not have the technology or capability to properly wipe data? Even if the Cloud Platform has these capabilities, what if the SaaS provider has not negotiated for the right to obtain these services? Again, to make this work it is incumbent on the SaaS provider to anticipate the end Cloud User’s needs and to only work with Cloud Platforms (or other Cloud providers) that have the capability (and willingness) to meet those needs.

Conclusion

We are very much at the start of the Cloud computing phenomenon, and luckily we have an opportunity to proactive identify and attack these issues now. However, it appears that Cloud is gaining significant momentum and time is running short to address these matters.  While the ultimate “solutions” will take time to develop, legal counsel (and the legal community as a whole) should begin developing strategies and approaches for handling Cloud transactions.

A key factor (and crucial first step) in addressing Cloud legal risk for a particular transaction is understanding the relationships of the Cloud. Legal counsel (with a huge assist from IT and security) should consider taking steps to achieve this understanding and limit risk, including without limitation: 

• Insist on and acheive transparency. Don’t allow the Cloud to be a black-box storm cloud. Identify the Cloud players involved in a transaction, identify where they process the Cloud User’s data, map the data flow between Cloud players and determine whether the Cloud players are static or dynamic (e.g. can/will the Cloud players change in the middle of the contract). Do this early so the organization does not need to play catch-up.

• Develop due diligence strategies and procedures, and follow and document them. Primary Cloud relationships should be directly scrutinized. Moreover, the due diligence processes of Cloud providers relying on lower layer Cloud providers should be analyzed to determine if they are adequate. Any validations (e.g compliance with standards such as ISO 270001 or SAS 70s II) or relevant reports from the various players should be obtained. The capabilities, limitations and processes of lower layer Cloud providers should be explored to ensure that they can satisfy the Cloud User’s legal obligations and do not pose additional, unanticipated legal risk or obligations.

• Confirm that Cloud providers have contractual rights to do what you need them to do. Contractually requiring an Cloud aggregator or SaaS provider to retain data, or obtaining the right to audit the security protecting the Cloud User’s data, is meaningless if the aggregator or SaaS itself does not have such rights with respect to lower layer Cloud providers. Cloud Users do not want to find this out when they have a need to exercise their contract rights (e.g. when a regulatory action, privacy breach of lawsuit happens). As such, it is important to analyze the contracts a higher level Cloud provider has with the Cloud providers it relies on to make sure the necessary rights flow through the contract chain.

• Think Way Ahead – Contractual Requirements Should be Part of the Request for Proposal Phase. Obviously performing a proper due diligence can be very time consuming, especially when multiple layers of Cloud providers are involved. It is much more difficult to achieve due diligence when the Cloud transaction has moved forward significantly (e.g. the competitors have been told they are no longer being considered and negotiations on key terms, like price, have occurred). The time to address these issues is in the RFP process. Organizations should plan ahead and identify the criteria necessary for the company and have Cloud providers confirm that they meet the criteria in their response to a RFP. At this point in time, I recommend that RFPs actually identify legal contract terms (e.g. indemnification, exceptions to limits of liability and consequential damage disclaimers) that Cloud vendors must agree to in order to get the business. Not only does this save time, but it also creates a competitive incentive for Cloud providers to take on more risk (so that they can win the business). 

What is Cloud Computing?

How about a picture to start off:

The National Institute of Standards and Technology (NIST) has provided a definition of cloud computing that is helpful, but not really in plain English.  Moreover, it does not really help to illuminate the legal aspects of cloud computing. So here is my attempt.

From a user's perspective, when utilizing cloud computing, rather than data processing and storage occurring on an individual's laptop or desktop computer (or a company's internal network), it happens on computing platforms run by third parties (such as Google, Yahoo, Amazon, etc). Services that may be available through those cloud platforms include data storage (e.g., infrastructure as a service (IaaS)), application development/deployment  (platform as a service (PaaS) and software hosting (e.g., software as a service (SaaS)). So rather than store data on an organization's own computer network, if purchasing IaaS, the data is stored on servers "in the cloud" and available on demand by the organization. Rather than installing and maintaining data/software on a network or desktop computer, the data/application is hosted on computers in the cloud and available on demand.

This can result in cost savings because companies using cloud services need not purchase their own infrastructure or software, need not hire people to maintain it, and need not regularly upgrade when necessary.  In addition, cloud computing is highly and cheaply scalable.  So rather than maintaining an over-capacity of computing power (e.g. extra servers only used for the holiday e-commerce rush) companies can maintain variable capacity levels to suit their immediate needs using the cloud.  Moreover, utilizing the cloud will allow companies to take advantage of the best and latest technology since they will not have to disassemble and rebuild their entire IT infrastructure in order to upgrade.  For more information on some of the technical aspects of cloud computing, please check out this white paper put out by Sun Microsystems.

That is all nice, and fairly understandable, but what IS the cloud? Right. Some analogies are in order. Think of airlines and how they sell seats. Sometimes seats are still available for a flight as the departure date gets closer and closer. From the airline's point of view it is better to sell those seats for a lower price then to let the plane take off with empty seats. As long as can sell the seat for a price that exceeds the cost of taking a passenger. Bring this same rationale to the e-commerce context. Amazon.com has huge server farms that can handle millions of transactions. During the 3 month holiday period its servers and processing abilities may be taxed to their limits because of high online sales volumes. Then of course, February rolls around and all those servers that hummed during the holiday season suddenly lay dormant. Yet Amazon still needs to maintain them so it can be ready for the next holiday rush. What to do? Rather than let that processing capacity go unused, why not sell it to third parties?  Allow an application service provider to host its application on Amazon's computers for a price. Allow an organization to store and process data on Amazon's servers.  In fact, since any additional funds received (above maintenance costs) are "gravy" perhaps Amazon could charge a lower price than other companies that provide capacity. This rationale can serve as a building block for companies to get into cloud computing.

The second rationale/building block is economies of scale. Going beyond the Amazon rationale of attempting to sell excess capacity that it had to have anyway, savvy IT companies began to realize that they could sell processing capacity as a business. In fact, computing processing prices have continued to drop more or less as predicted by Gordon Bell's corollary to Moore's Law. Beyond that, companies like Google have begun to realize that if they build massive server farms they can bring down their per unit of price for processing power even further. Moreover, with highly evolved technologies they realized they could create additional processing efficiencies and bring down the per unit price of processing even further. Based on these economies of scale, cloud platforms realized they could provide processing capabilities much cheaper than companies that did it all "in house."

Terrific, so how is this any different than a typical outsourcing relationship?  Why is this a Cloud? One of the key differences between a traditional outsourcing relationship and cloud computing is where the data resides or is processed.  For example, in the traditional outsourcing situation, a company looking to offload some of its data storage would create a dedicated data center and then sell the storage capacity to its clients.  The data center might be in another country, but for the most part the client knew where its data was going and where it would be stored and processed.

Enter the cloud.  In a cloud environment, geography can lose all meaning.  Cloud platforms may not be able to tell "where" data is at any given point in time.  Data may be dispersed across and stored in multiple data centers all over the world.  In fact, use of a cloud platform can result in multiple copies of data being stored in different locations.  This is true even for a "private cloud" that is essentially run by a single entity.  What this also means is that data in the cloud is often transferred across multiple borders, which (as discussed below) can have significant legal implications.

It gets more complicated when you begin talking about the "public cloud" or "hybrid cloud" and interactions between cloud providers.  In some public cloud set ups, the players in the cloud are essentially trading processing and storage capacity.  So if Google has excess capacity at a given point and time, and Amazon or Amazon's clients need more capacity than Amazon can provide, it can buy some capacity from Google.  Some refer to this as "surge computing." The analogy here is electricity companies and providers.  In warmer climates during peak electricity demand times, the local power company may not be able to generate enough electricity to meet increased demand, and will have to purchase it from other companies who are not at full capacity.  Under the cloud arrangement, data is like electricity, essentially fungible and able to be moved instantaneously to available servers and computation resources.  In fact, cloud computing providers will begin charging for the cloud the same way electricity is charged:  based on units of use (in this case computing cycles).  So in the cloud, while the data may have started out on an Amazon server in the European Union, when handed off to Google it may be processed in the United States, China or some other country where Google has servers (in fact countries like China and India are very keen to get into this business since they think they can provide these services for even cheaper).  Moreover, the parts of the data may be copied and sent for processing to other participants in the cloud.  To the Amazon user all of this movement of data and processing across multiple borders involving multiple entities and even multiple copies of data is invisible.  The Amazon user simply gets back the answer it expected when it began the processing transaction.

What are the legal issues?

Transborder Data Flow Triggering Legal Obligations in Multiple Jurisdictions. This sharing and transfer of data within the cloud, the inability for anybody to easily say where the data is or has been, is the key problem that creates legal issues.  An obvious problem is transborder data flow.  For example under the EU Data Protection Directive, unless they take certain steps, organizations are prohibited from transferring personal information to countries that do not provide the same level of protection with respect to personal information of EU residents (the United States is one such country).  A company that does its processing in the cloud may be violating EU law if data goes to servers outside of the EU to prohibited countries.  Unfortunately, contracts may not be too helpful because cloud providers will not be in any position to make any contractual promises to their clients because in many cases they cannot say which countries data will be transferred to or from.  So how can companies seeking the efficiency and cost savings of the cloud utilize it if, by its very nature, it leads to potential legal compliance nightmares?

"Reasonable Security" Under the Law. Then there is the issue of "reasonable security" in the cloud computing context, and potential liability arising out of security breaches in the cloud.  Generally speaking if a company outsources the handling of personal information to another company they may have some responsibility to make sure the outsourcer has some level of reasonable security to protect personal and confidential information.  What happens when the could is utilized? Service providers using the cloud platform essentially rely on the security of each of the cloud participants receiving personal information.  That could be name brand companies like Google who are likely to have some level of adequate security, but it could also be lesser players trying to engage in business as cheaply as possible and not implementing rigorous controls.  The bottom line again is that the organization seeking to do business in the cloud has no way to even perform a due diligence of "the cloud" to ensure that adequate security is in place.  Moreover, cloud companies and service providers that contract directly with such companies are not likely to make any contractual promises around security since they ultimately don't control it (or even know how good or bad it is within the cloud).  Ultimately, the legal question is, what liability does a company face when there has been a security breach in the cloud that has resulted in the theft or harm of valuable or protected data?

Electronic evidence/e-discovery. Utilizing the cloud can be problematic in the litigation context.  First off, when litigation ensues and a litigation hold is initiated, the organization will have to deal with a third party cloud provider in order to get at the information relevant to the litigation.  It may not be easy for that provider to actually preserve the data that is needed for several reasons.  For example, an organization may be using a third party software provider that itself utilizes the a cloud platform.  The data subject to the litigation hold therefore may actually reside in the cloud and may not be readily accessible/preserved by the software provider.  This could complicate gathering electronic evidence and responding to e-Discovery requests.  Moreover, it could lead to spoliation of evidence.  In addition, considering that multiple copies of data may be created, stored, recompiled, dispersed, reassembled and reused, the idea of what constitutes a "record" or a "document" for evidentiary purposes may be difficult to grapple with in the cloud.

What can lawyers do to address these issues?

Ultimately this is the big question.  Can the law wrap its head around cloud computing (when frankly, the cloud computing industry itself is having difficulty defining key components of the business)?  The first area to explore are contractual arrangements.  Lawyers have been involved in outsourcing transactions for sometime, and have been able to address issues of relative risk between the parties.  However, contracting may be much more difficult in the cloud environment because the players may not be in a position to make certain promises, and additional duties/obligations may destroy the cheap pricing model for cloud computing.  In part two of this series, we dive more deeply into the legal issues around cloud computing and the necessary involvement of lawyers in this context with respect to contractual arrangements.