Published by Al Saikali

Data Security

Subscribe to Data Security

One of the most significant questions in data security law is whether reports created by forensic firms investigating data breaches at the direction of counsel are protected from discovery in civil class action lawsuits.  They are, at least according to an order issued last week in In re Experian Data Breach Litigation. 15-01592 (C.D. Cal. May 18, 2017).  This post analyzes the decision, identifies important practical takeaways for counsel, and places it in context with the two other cases that have addressed this issue.

Why Do Lawyers Hire Forensic Firms?

When a breach occurs, companies often retain legal counsel to advise them on legal issues like whether the company adopted “reasonable” security safeguards; whether the company is obligated to notify affected customers and, if so, when and how; whether notice to regulators is required; and, what remedial measures are required.  To properly advise clients on these issues, legal counsel needs to know whether personally identifiable information (PII) was affected by the incident, when the intrusion occurred, whether the PII was actually accessed or acquired, what safeguards were in place to prevent the attack, and how the vulnerability was remediated.  A good forensic firm will help you answer these questions so you can advise clients accurately.  The reports often contain information that plaintiffs’ lawyers would love to get their hands on – it can provide details about why the breach occurred, how it could have been prevented, and whether the company’s safeguards were consistent with standards of reasonableness.  It is important that the forensic firm be able to perform its investigation without fear that its reports will be subject to misinterpretation and criticism by a plaintiff’s lawyer or other third party.  Hence the need for protection of these reports in civil litigation.  For the time being, there is no statutory protection for these types of documents (though there should be) so we must turn to the attorney-client privilege and work-product doctrine for protection.

What Happened In Experian?

In October 2015, Experian announced that it suffered a data breach.  A class action was filed the next day.  Experian immediately hired legal counsel who in turn hired Mandiant, one of the world’s leading forensic firms, to investigate the data breach and identify facts that would allow outside counsel to provide legal advice to Experian.

The plaintiffs requested a copy of Mandiant’s report and documents related to that investigation.  Experian objected, arguing that the documents are privileged and protected by the work-product doctrine because they were prepared in anticipation of litigation for the purpose of allowing counsel to advise Experian on its legal obligations.  The plaintiffs moved to compel production of the documents.

The court held that the documents were protected from discovery by the work-product doctrine.  Plaintiffs had argued that Experian had an independent business obligation to investigate the data breach, and it hired Mandiant to do that after realizing its own experts lacked sufficient resources.  The court rejected this argument because Mandiant conducted the investigation and prepared the report for outside counsel in anticipation of litigation, “even if that wasn’t Mandiant’s only purpose.”  The court pointed to, among other things, the fact that Mandiant’s full report was not provided to Experian’s internal incident response team.

Plaintiffs argued that the report should not be protected because it was prepared in the ordinary course of business.  Plaintiffs cited the fact Mandiant had previously worked for Experian.  The court disagreed because Mandiant’s previous work for Experian was separate from the work it did for Experian regarding the subject breach.

Plaintiffs argued that even if the documents were created to allow counsel to advise Experian, plaintiffs were not able to obtain the information that was included in the Mandiant report by other means because Mandiant accessed Experian’s live servers to do its analysis, which plaintiffs’ experts would not be able to do.  The court disagreed, citing information in the record demonstrating that Mandiant never in fact accessed the live servers, but only observed server images to create its report.

Lastly, the plaintiffs argued that even if the information was protected by the work-product doctrine, Experian waived the protection by sharing the documents with a co-defendant (T-Mobile’s counsel).  In what I believe will be the most underrated yet arguably most important part of the order, the court ruled that the sharing of the report with the co-defendant pursuant to a joint defense agreement did not constitute a waiver of the work product doctrine.

There are some limitations to the court’s order:

  1. The court only ruled on whether the work-product doctrine applied to the Mandiant documents, not whether the attorney-client privilege applied.
  1. Mandiant delivered its report to outside counsel only, who shared the reports with in house counsel.  The full report was not shared with Experian’s incident response team (it is not clear who comprised that team).
  1. Mandiant performed an analysis of Experian’s systems two years before this incident. The court did not conclude that the 2013 report was privileged.  The court also did not conclude that any work Mandiant performed before outside counsel was hired is privileged. It is not clear from the order whether the court was ruling that the pre-incident and pre-engagement materials were not protected at all, not protected by the attorney-client privilege, or simply not ruling one way or the other.  My interpretation is that it is the latter.

How Have Other Courts Ruled?

Only two other courts have addressed the applicability of privilege or work-product protection to the production of forensic reports.  Both have applied privilege and/or work product to the documents.

In In re: Target Corporation Customer Data Security Breach Litigation, No. 14-2522 (D. Minn. Oct. 23, 2015), the court held that documents relating to a forensic investigation performed to provide legal advice to the company was privileged and work product.  Following its breach, Target established a data breach task force at the request of Target’s in-house lawyers and its retained outside counsel so that the task force could educate Target’s attorneys about aspects of the breach and counsel could provide Target with informed legal advice.  What makes the Target case different from Experian is that Target undertook two forensic investigations (both by the forensic firm, Verizon) – one as described (to enable counsel to advise Target in anticipation of litigation and regulatory inquiries) and a second was required by several credit card brands (commonly referred to as a “PFI” or payment card forensic investigation).  This second investigation, Target conceded, was not protected by privilege or the work-product doctrine.  The court allowed production of certain information (emails to Target’s Board of Directors which updated the Board on Target’s business-related interests), but held that information relating to Verizon’s investigation for the data breach task force was protected by the attorney-client privilege and work-product doctrine.  The court reasoned that there were forensic images and the PFI documents that plaintiffs could use to learn how the data breach occurred and how Target responded.

In Genesco, Inc. v. Visa U.S.A., Inc., No. 3:13-cv-00202 (M.D. Tenn. Mar. 25, 2015), the court denied Visa’s request for discovery related to remediation measures performed by IBM on Genesco’s behalf.  The court reasoned that Genesco retained IBM to provide consulting and technical services to assist counsel in rendering legal advice to Genesco. Therefore, the documents were privileged.

Experian came out the same way as Target and Genesco, but there are subtle differences that should be kept in mind whenever a company decides to retain a forensic company and expects privilege or work product to apply.  Experian is arguably the most important of the three because it is the far more common scenario.  Most companies will not spend money to hire two forensic firms (or one firm with two teams) to perform two separate investigations on the same incident.  So where only one investigation is performed, the company and counsel would be wise to read the Experian filings and order before commencing the engagement of counsel and a forensic firm.

Takeaways

Here are some practical takeaways if a breached entity wants to minimize the risk of disclosure of a forensic report:

  • The forensic firm should be hired by outside counsel, not by the incident response team or the information security department.
  • Create a record and think about privilege issues early in the engagement by doing the following:
    • ensuring that the engagement letter between the breached entity and outside counsel envisions that outside counsel may need to retain a forensic firm to help counsel provide legal advice;
    • the MSA and/or SOW between outside counsel and the forensic firm makes clear that the forensic firm is being hired for the purpose of helping counsel provide legal advice to the client;
    • limit the scope of the forensic firm’s work to those issues relevant to and necessary for counsel to render legal advice;
    • ensure that the forensic firm communicates directly (and only) with counsel in a secure and confidential manner;
    • not sharing the forensic firm’s full report with anyone other than in house counsel; and
    • incorporate the forensic firm’s report into a written legal memorandum to demonstrate how the forensic firm’s findings were used to help counsel provide legal advice to the client.
  • Work a forensic firm undertakes before outside counsel is involved will not be protected, so the breached entity should engage counsel immediately.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

The consequences of a data breach reached new heights last week when Yahoo announced the resignation of its General Counsel in response to a series of security incidents the company suffered.  A more fulsome explanation of the security incidents and Yahoo’s response can be found in item seven of the company’s 10-K, but here are the highlights:

  • Yahoo suffered three security incidents from 2013 to 2016, one of which involved the theft of approximately 500 million user accounts from Yahoo’s network by a state-sponsored actor in late 2014. The stolen information included names, email addresses, telephone numbers, dates of birth, hashed passwords and encrypted or unencrypted security questions and answers.  (Note that under most, but not all, data breach notification laws, unauthorized access of these data elements would not create a legal obligation to notify affected individuals).
  • An independent committee of Yahoo’s board of directors undertook an investigation with the assistance of a forensic firm and outside counsel.
  • The committee concluded that Yahoo’s information security team knew of the 2014 security incident at that time, but the incident was not disclosed until September 2016.
  • “[S]enior executives did not properly comprehend or investigate, and therefore failed to act sufficiently upon, the full extent of knowledge known internally by the Company’s information security team.”
  • Yahoo knew, as early as December 2014, that an attacker had acquired personal data of Yahoo users, but it is not clear whether and to what extent this information was conveyed to those outside the information security team.
  • The legal team, however, “had sufficient information to warrant substantial further inquiry in 2014, and they did not sufficiently pursue it. As a result, the 2014 Security Incident was not properly investigated and analyzed at the time, and the Company was not adequately advised with respect to the legal and business risks associated with the 2014 Security Incident.”  (Emphasis added).  The 10-K does not identify the “sufficient information” or explain what “further inquiry” would have been required (or why).
  • The committee found “failures in communication, management, inquiry and internal reporting,” which all contributed to lack of understanding and handling of the 2014 Security Incident.
  • The committee also found that Yahoo’s board of directors was “not adequately informed of the full severity, risks, and potential impacts of the 2014 Security Incident and related matters.”

It’s not clear from the 10-K exactly why Yahoo’s General Counsel was asked to step down.  It’s highly unusual that a General Counsel would be held directly (and publicly) responsible for a data breach.  Nevertheless, the outcome raises a couple of questions:  (1) will this represent a new trend for in house counsel generally, and (2) how will this outcome affect how companies approach investigations of data incidents in the future?

Regarding the latter question, a colleague at another firm suggested that this outcome may make corporate legal departments less inclined to involve themselves in breach response or direct investigations of suspected data breaches.  I disagree.  Looking the other way or sticking one’s head in the sand is never the right response to a data incident.  In fact, the legal department would create bigger problems if it did little or nothing.

So what can a corporate legal department do to minimize its own risks?  Here are a few suggestions:

  • Retain a forensic firm through the legal department or outside counsel in advance of an incident to ensure that resources are available to begin an investigation immediately, and to maximize the applicability of the attorney-client privilege and work product doctrine.
  • Engage outside counsel skilled in privacy and data security law and experienced in helping similarly situated companies prepare for and respond to data incidents. There is a growing glut of lawyers who hold themselves out as privacy experts, so I recommend asking for and contacting references.  Most clients are happy to speak about their level of satisfaction with their outside counsel while avoiding details of the incident that led to the engagement.
  • Prepare written protocols, with the cooperation of your information security department, to guide your investigation when an incident occurs. These protocols are different from incident response plans; they focus specifically on the process of initiating, directing, and concluding an investigation at the direction of legal counsel for the purpose of advising the company on its compliance with privacy and data security laws.  They include rules on communication, documentation, and scope.
  • Engage in real dialogue with the information security officer(s) before an incident occurs, in an effort to identify appropriate rules of engagement for when the corporate legal department should be involved in incident response. Some companies involve legal in every data incident (that’s too much), some don’t involve them at all and maintain that data incidents are entirely within the purview of information security (that’s too little . . . and create significant legal risks), but the challenge lies in defining the middle ground.  It is easy to say “legal gets involved when Information Security determines that an incident is serious,” but it is often difficult to know at the outset of an incident whether it will become serious, and by the time you’ve figured that out it may be too late.  There is, however, a way to strike that balance.
  • Test, test, test – regularly simulate data incidents to test the protocols, rules of engagement, and incident response plans. I’ve been involved in some phenomenal tabletop exercises, which clients have used to benchmark their response readiness against other similarly situated companies.  I’ve been consistently impressed with one particular forensic firm in this space.  Legal and information security departments can and should work together to undertake these exercises.

Information security officers will not be the only high-level executives to have their feet held to the fire when a data breach occurs.  I predict that C-level executives and boards of directors will increasingly hold corporate legal departments responsible (at least in part) for how the company investigates and responds to a suspected data breach.  So it will be important for legal departments to proactively educate themselves on the legal issues that arise when an incident occurs, identify their roles in the incident response procedure, and prepare to act quickly and thoroughly when the time comes.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

Earlier this year, Bloomberg Law reported that Edelson PC, a leading plaintiffs’ firm in privacy and data security law, filed a class action lawsuit against a regional law firm that had vulnerabilities in its information security systems.  This week, the identity of the firm and the allegations of the lawsuit were unsealed.  The case, Shore v. Johnson & Bell, LTD, No. 1:16-cv-04363 (N.D. Ill. Apr. 15, 2016), alleges that Johnson & Bell (“the firm”), a Chicago-based law firm, was negligent and engaged in malpractice by allowing information security vulnerabilities to develop that created risks to client information.  This blog post explains the alleged vulnerabilities, analyzes the merits of the lawsuit, and discusses what it means for other law firms, their clients, and service providers.

By coincidence, Fortune reported earlier this week that China stole data from major U.S. law firms:  “The evidence obtained by Fortune did not disclose a clear motive for the attack but did show the names of law firm partners targeted by the hackers. The practice areas of those partners include mergers and acquisitions and intellectual property, suggesting the goal of the email theft may indeed have been economic in nature.”  These developments are reminders that information security must be a high priority for all law firms.

The Johnson & Bell Lawsuit

The lawsuit is based on three alleged vulnerabilities in the firm’s information security infrastructure.  According to a court filing, the vulnerabilities have now been addressed and fixed.

First, the lawsuit alleges that the firm’s Webtime Server, an application attorneys use via any web browser to remotely log in and record their time, was based on the 2005 version of the Java application JBoss.  The Complaint alleges that the 2005 version of JBoss has been identified by the National Institute of Standards and Technology as having an exploitable vulnerability. Plaintiffs also allege hackers have taken advantage of the vulnerability in other situations to conduct ransomware attacks.

Second, the lawsuit alleges that the firm’s virtual private network (VPN) server contains a vulnerability.  Companies use VPNs to allow their employees to remotely access company information in an encrypted, secured manner.  The secured nature of a VPN connection allows companies to feel comfortable providing access to highly sensitive internal resources and databases.  Sometimes, a temporary disconnection occurs while an employee is using a VPN connection.  The Complaint alleges generally that when the firm’s VPN sessions were disconnected, the renegotiation (or re-connection of the VPN session) was insecure, making it vulnerable to a “man-in-the-middle” attack.  A man-in-the-middle attack is a cyberattack in which the hacker gains access to a system to eavesdrop on communications and steal confidential information.

Finally, the Complaint alleges that the firm’s email system was vulnerable because it supports version 2.0 of SSL.  Secure Sockets Layer (SSL) is a form of technology that creates an encrypted tunnel between a web server and a browser to ensure that information passing through the tunnel is protected from hackers. Version 2.0 was replaced by version 3.0 in 1996.  In 1999, Transport Layer Security (TLS) replaced SSL entirely.  Since then, TLS has been updated at least twice.  According to the Complaint, the use of SSL 2.0 made the firm susceptible to a DROWN (Decrypting RSA with Obsolete Weakened Encryption) attack that could allow hackers to access the contents of the firm’s emails and attachments.  The Complaint claims that the Panama Papers breach was a result of a similar attack.

Notably, the Complaint does not allege that the firm actually suffered a compromise of sensitive information, that a successful cyberattack occurred, or even that a cyberattack was attempted.  In other words, the lawsuit is based on the firm’s alleged state of security that may make it vulnerable to an attack in the future.

Who is the class?  Plaintiffs (Jason Shore and Coinabul, LLS) are former clients of the Johnson & Bell firm.  The firm defended Plaintiffs in a class action lawsuit alleging that Plaintiffs defrauded consumers by accepting payments in the form of bitcoins while refusing to ship gold or silver ordered by customers.  See Hussein v. Coinabul, LLC, No. 14 C 5735 (N.D. Ill. 2014).  Plaintiffs define the class as all of the firm’s clients within the statute of limitations period except insurance companies and clients operating in the healthcare industry. Why insurance and healthcare companies are not included in the proposed class is not evident from the allegations.  It could be that those industries are more highly regulated in privacy and data security and therefore would have had a greater duty to ask questions of the firm about its information security practices.  Though why financial institutions, the most highly regulated sector in data security, would not also have been included in this group is not clear.

The Complaint is based on four causes of action:

  1. Breach of implied contract – Plaintiffs allege that, as a term of the engagement agreement, the firm promised to keep a file for the work they performed on Plaintiffs’ matter.  The Complaint claims there was an implied promise that the firm would use reasonable methods to keep Plaintiffs’ information confidential, which was breached by the firm’s security vulnerabilities.
  2. Negligence – Plaintiffs claim the attorney-client relationship automatically created a duty to adopt industry standard data security measures, which was breached as evident by the alleged vulnerabilities.
  3. Unjust enrichment – Plaintiffs argue that a portion of the attorney’s fees they paid to the firm was for the administrative cost of data security to maintain the confidentiality of client information.  Plaintiffs seek return of that amount of the fees paid.
  4. Breach of fiduciary duty – Plaintiffs claim that the failure to implement industry standard data security measures and resulting vulnerabilities were breaches of the firm’s fiduciary duty to Plaintiffs.

What is the injury? Plaintiffs allege they were injured because the security vulnerabilities created (1) a diminished value of the services they received from the firm, and (2) a risk that their sensitive information may be compromised at some point in the future (which could result in damages from that theft).  Plaintiffs measure their damages as the portion of fees paid to the firm that were meant to be for the administrative cost of securing client information.  Plaintiffs have also asked the court to require an independent third-party security audit of the firm’s systems.

Is a Vulnerability by Itself Enough to Meet Standing Requirements?

In my opinion, the lawsuit is fatally flawed because there was no attack or attempted attack on Plaintiffs’ information, let alone actual unauthorized access or acquisition of the information.  The firm’s security system was analogous to an unlocked door to a home that nobody burglarized.  The plaintiffs indisputably suffered no financial damages as a result of the alleged vulnerabilities, and the vulnerabilities were identified (albeit by this lawsuit) and addressed before any actual harm occurred.

If the mere risk of harm at some point in the future is enough to allow a lawsuit to proceed, then every company in America should be concerned.  Most companies probably have similar unknown vulnerabilities in their systems.  The challenge with information security is that it is like a game of “Whack-A-Mole” — the fast-paced and constantly changing threats and defenses means that new vulnerabilities are always emerging so it is almost impossible to eliminate all vulnerabilities entirely.  The floodgates will be blown wide open if a lawsuit based only on the mere existence of a vulnerability is considered actionable.

That said, the Edelson firm is one of the most creative plaintiffs’ privacy and data security firms in the country.  They have made their name by doing things differently from their peers.  They are known for pushing the envelope and expanding the boundaries of liability in privacy and data security law.  For example, in Resnick v. AvMed they were the first firm to persuade a U.S. Circuit Court of Appeals to apply the unjust enrichment theory to data breach class actions.  Other courts have since applied that theory in allowing data breach class action lawsuits to proceed. The Resnick case subsequently settled for over $3 million.

In In re: LinkedIn User Privacy Litigation, No. 5:12-cv-03088 (N.D. Cal. 2012), at a time when other plaintiffs firms were pursuing data breach liability based on a failure to adopt reasonable security safeguards, they persuaded the court of a new theory:  that the gravamen was not the failure to adopt certain security safeguards, but the misrepresentations in consumer-facing statements about the safeguards that were actually in place.  The LinkedIn case settled for $1.25 million.

In Spokeo v. Robins, a case that was appealed all the way to the U.S. Supreme Court, the Edelson firm argued to the Court that the mere violation of a privacy statute without other damages or harm is sufficient to confer standing on a plaintiff.  The Court’s decision gave plaintiffs a roadmap for circumventing the standing problem.

But no case has gone this far – to hold that a mere vulnerability without a compromise of information, an attack, or an attempted attack, is actionable.  Doing so would essentially change the data security class action litigation “ball game” once again.

The Impact on Everyone Else

This lawsuit is important because of its potential impact to several key groups.  First, is other law firms.  Every firm should immediately determine whether it has the same vulnerabilities alleged in the Complaint.  Law firms should be concerned that similar vulnerabilities could lead to similar lawsuits, whether or not an actual attack has occurred.  They should be prepared to respond to client inquiries explaining what safeguards they have adopted to protect sensitive client information, consistent with their legal and ethical obligations. (For a discussion of these obligations, read my July 2013 blog post on the subject).  Firms should review and update their engagement letters for promises and disclaimers to their clients about information security.

This leads to the second group of impacted individuals:  the law firms’ clients.  Every company should have in place a vendor management program that incorporates information security as part of the due diligence process, and law firms are service providers like the rest of the companies’ vendors.  Companies should be asking their outside counsel as part of the due diligence process how they protect client data:  what administrative, technical, and physical safeguards are in place?  Has the firm obtained an independent third-party certification (like ISO 27001) or performed a risk assessment by an information security expert?  (I was pleasantly surprised to see the Complaint refer to Shook, Hardy & Bacon’s ISO 27001 certification as an example of what law firms should be doing).

Beyond asking questions, clients need to identify what they expect from their law firms in terms of specific security requirements and communication about vulnerabilities or notifications of data incidents.  This lawsuit may have been avoided if the engagement letter had required notice of material vulnerabilities.  The questions clients should be asking their law firms can (and will) be the focus of an entirely separate blog post.

The third group impacted by this lawsuit will be the service providers law firms use for information security services.  Small firms commonly outsource most or all of their information security to these providers.  Even large firms use service providers for information security services that include threat detection, data loss prevention, firewall implementation, and cloud storage.

Firms also purchase licenses for applications that may present security risks, similar to the alleged vulnerability in the Webtime service. These applications require a separate security vetting by the law firm before they can be used.

I suspect this is the first of what will be a series of lawsuits relating to law firm security brought by the Edelson firm and plaintiffs’ firms that follow their lead.  It will be interesting to see whether courts allow a lawsuit based on a security vulnerability alone to proceed or dismiss it for lack of standing.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

The SEC recently agreed to a $1,000,000 settlement of an enforcement action against Morgan Stanley for its failure to have sufficient data security policies and procedures to protect customer data. The settlement was significant for its amount. The true noteworthiness here, however, lies not in the end result but the implications of how it was reached: (1) the “reasonableness” of a company’s data security safeguards shall be judged in hindsight, and (2) almost any data breach could give rise to liability. The SEC has left no room for error in making sure that your cybersecurity procedures and controls actually and always work.

What Happened?

Morgan Stanley maintained personally identifiable information collected from its brokerage and investment advisory services customers on two internal company portals. Between 2011 and 2014, an employee unlawfully downloaded and transferred confidential data for approximately 730,000 accounts from the portals to his own personal data storage device/website. It is unclear whether the transfer of information was for the employee’s personal convenience or a more nefarious purpose. Soon thereafter, however, the employee suffered a cyberattack on his personal storage device, leading to portions of the data being posted to at least three publicly available Internet sites. Morgan Stanley discovered the information leak through a routine Internet sweep, they immediately confronted the employee, and voluntarily brought the matter to law enforcement’s attention.

The employee who transferred the information to his personal device was criminally convicted for violating the Computer Fraud and Abuse Act by exceeding his access to a computer, he was sentenced to 36 months probation, and ordered to pay $600,000 in restitution. He also entered into a consent order with the SEC barring him from association with any broker, dealer, and investment adviser for five years.

Morgan Stanley entered into a consent order with the SEC pursuant to which Morgan Stanley agreed to pay a $1,000,000 fine, but did not admit or deny the findings in the order.

SIDE NOTE TO COMPLIANCE OFFICERS READING THIS BLOG POST – if ever you need a way to deter your employees from sending corporate information to their personal devices or email accounts, tell them about this case.

What Does The Law Require?

Federal security laws (Rule 30(a) of Regulation S-P – the “Safeguards Rule”) require registered broker-dealers and investment advisers to adopt written policies and procedures reasonably designed to:

  1. Insure the security and confidentiality of customer records and information;
  2. Protect against any anticipated threats or hazards to the security or integrity of customer records and information; and
  3. Protect against unauthorized access to or use of customer records or information that could result in substantial harm or inconvenience to any customer.

Here, the SEC based Morgan Stanley’s liability on the fact that Morgan Stanley:

failed to ensure the reasonable design and proper operation of its policies and procedures in safeguarding confidential customer data. In particular, the authorization modules were ineffective in limiting access with respect to one report available through one of the portals and absent with respect to a couple of the reports available through the portals. Moreover, Morgan Stanley failed to conduct any auditing or testing of the authorization modules for the portals at any point since their creation, and that testing would likely have revealed the deficiencies in the modules. Finally, Morgan Stanley did not monitor user activity in the portals to identify any unusual or suspicious patterns.

In other words, the authorization modules did not work in this instance, nor was there auditing to test and possibly identify the problem, nor had Morgan Stanley invested in sophisticated monitoring applications that would have identified that the employee was engaging in suspicious activity.

Why Should Companies Worry?

The most concerning part of the Morgan Stanley consent order is this paragraph, which describes some robust safeguards Morgan Stanley had implemented before the incident occurred:

MSSB [Morgan Stanley] adopted certain policies and restrictions with respect to employees’ access to and handling of confidential customer data available through the Portals. MSSB had written policies, including its Code of Conduct, that prohibited employees from accessing confidential information other than what employees had been authorized to access in order to perform their responsibilities. In addition, MSSB designed and installed authorization modules that, if properly implemented, should have permitted each employee to run reports via the Portals only with respect to the data for customers whom that employee supported. These modules required FAs [Financial Advisors] and CSAs [Client Service Associates] to input numbers associated with the user’s branch and FA or FA group number. MSSB’s systems then should have permitted the user to access data only with respect to those customers whose data the user was properly entitled to view. Finally, MSSB installed and maintained technology controls that, among other things, restricted employees from copying data onto removable storage devices and from accessing certain categories of websites.

Lesson learned: it doesn’t matter how robustly designed your policies and procedures may be, if they don’t actually work as designed then you could be liable under the Safeguards Rule.

Commentary

The standard applied by the SEC in this enforcement action is higher than a “reasonableness” standard. It is easy, after the fact, to find a weakness that could have been exploited. Indeed, it is unusual if you cannot identify such a vulnerability after the fact. If a criminal or departing employee is set on unlawfully accessing sensitive information he can likely do so no matter what hurdles you place in his way. A company should not be held liable for failing to stop every data incident. Some may argue that a company like Morgan Stanley must be held to a higher standard because of the known threats to the financial services industry and the potentially significant consequences to consumers of a financial services company suffering a data breach. Nevertheless, the law as written requires policies and procedures that are only “reasonably designed” to protect sensitive information; the law does not require that these policies and procedures be perfectly designed nor that they be effective 100% of the time, nor could it.

Hindsight is 20/20 and regulators would be hard pressed to find any organization that could show their policies and procedures are always followed. Could audits and testing have detected the fact that Morgan Stanley’s authorization module was not preventing the type of unauthorized access and transfer of sensitive information in this case? Possibly, depending on the depth of the audit and foresight of the auditors. But little benefit appears to have inured to Morgan Stanley for the fact it actually had an authorization module, data security training for its employees, policies and restrictions regarding employee access of information, controls that prevented the copying of data onto removable storage devices, and the fact that it voluntarily brought this matter to law enforcement’s attention.

Is there a risk now that the SEC’s interpretation of “reasonableness” will be applied similarly by state Attorneys General, the Health and Human Services’ Office of Civil Rights, the Federal Trade Commission, or other regulators? All of this reminds us that the definition of reasonableness in the context of data security is subjective, and that subjectivity is a risk that companies must address.

Takeaways

There are some important practical takeaways for companies from this settlement: (1) perform a risk assessment to determine how your organization could suffer from a similar risk (employee transferring corporate information to a personal device); (2) implement an authorization module and other policies and procedures to limit access (and identify unauthorized access) to sensitive information to those who have a legitimate business need; and (3) make sure you audit and test these controls so ensure that they actually work. Additionally, CISOs, compliance officers, and in house counsel would be well served to ensure that the story of this enforcement action becomes part of their organization’s data security training as part of the onboarding and annual training process.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

 

A significant change is happening to payment card technology. Any company that accepts credit cards as a form of payment needs to know about it if they intend to continue accepting payment cards in the future. The technology is called “EMV” (EuroPay, MasterCard, Visa). The card brands hope that EMV technology will significantly reduce the amount of fraud in transactions where the payment card is present. This blog post will discuss how EMV works, why it was adopted, how merchants can comply with its requirements, the incentives to adopt (and penalties in failing to adopt) the technology, and the security pros/cons of EMV.

SPOILER ALERT: EMV is effective in reducing the risk of fraud from counterfeit payment cards used for in-person transactions, but the best way to minimize payment card fraud is through implementation of point-to-point encryption and tokenization. The liability shift is an appealing incentive to adopt the technology, but many merchants have been reporting difficulty finding EMV software that works properly with the EMV hardware.

What is EMV?  EMV (EuroPay, MasterCard, Visa) is a payment method that combines a plastic card with a microchip. Unlike your typical credit card, credit cards with an EMV chip generate a different code with every purchase a consumer makes. The code is shared with the issuing bank as part of the transaction to authenticate that the card is legitimate. Because the code changes with each transaction, even if a thief steals the information contained on the magnetic stripe of the credit card, he cannot create a counterfeit card because he cannot replicate the codes generated by the microchip. It is this inability to make counterfeit cards that makes EMV technology so important to the card brands and issuing banks.

Why was EMV created?  EMV was created because criminals/hackers were stealing credit card information, selling it, and using it to create counterfeit credit cards. Those counterfeit cards are then often sold or used as part of identity theft and dark web crime rings. By requiring a microchip that generates a random code for each transaction, card brands have made it almost impossible to create a counterfeit card. EMV technology, however, is only helpful in preventing fraud where the card is present. Online transactions, for example, do not benefit from the technology because an e-commerce transaction usually does not require that a card be inserted or swiped into a point of sale terminal (which would allow for the micro-chip’s unique code generation). There are, however, other technologies like point-to-point encryption and tokenization (discussed below) that could potentially eliminate payment card data breaches.

How does a merchant become EMV-compliant?  To become EMV-compliant, a merchant must install EMV-enabled point-of-sale terminals and obtain certification from its acquiring bank that its payment application for each card network is certified for EMV. The cost of a new EMV-compliant terminal can be between $250 and $500, depending on whether the merchant wants to purchase one that will also accept near-field communications payments like Apple Pay. The merchant also needs to ensure that EMV-compliant software is installed in these terminals. Several of payment card forensic contacts and merchant clients have told me that they are having issues implementing the software solutions.

What if a consumer wants to swipe her card instead of use the chip feature?  Assuming the consumer is using an EMV card at an EMV-enabled terminal, the terminal will require the consumer to use the chip instead of swiping the card.

Is a signature or PIN required to complete a transaction?  Each issuing bank will have different requirements. Visa has said that a signature accompanying the chip is sufficient. MasterCard, however, appears to prefer use of a PIN with the chip. If a merchant does not support the “Chip and PIN” system, but the subject transaction could have been performed with a PIN, then the merchant may be responsible for chargebacks related to those transactions.

Will merchants pay lower interchange fees if they adopt the EMV-compliant terminals?  No and there are no current plans to change that, though it is possible the card brands could change their mind if EMV is not adopted quickly enough.

What is the “liability shift”?  Until recently, issuing banks were responsible for card-present counterfeit fraud losses. As a way to encourage merchants to adopt EMV, the card brands have implemented a shift of liability as a “carrot” and “stick” approach. For most merchants, as of October 1, 2015, if they have been certified through their acquiring banks as EMV-compliant and they subsequently suffer a breach, they are not responsible for card-present counterfeit fraud losses. MasterCard requires that 95% of its transactions originate from EMV-compliant POS terminals for the liability shift to apply to 100% of the charges; the liability shift applies to only 50% of affected MasterCard transactions if only 75% of MasterCard transactions originate from EMV-compliant POS terminals. Merchants are not required to be EMV-compliant, but doing so gives them the protection of this liability shift. The liability shift likely applies to both magnetic stripe cards and EMV cards that are compromised, but the card brands have released public statements that create ambiguity.

Are there any exceptions to the October 1, 2015, deadline for the liability shift?  Yes. The liability shift does not apply to automated fuel dispensers (gas pumps) until October 2017. Also, MasterCard is shifting its liability to ATM owners in October 2016; Visa is shifting that liability in October 2017. The EMV software for fuel dispensers and ATMs has been particularly lacking, making it extremely challenging for merchants to fully implement EMV technology. For small businesses that accept mobile payments (like Square), merchants will need to purchase new EMV readers. (Square has been assuming the liability until its customers purchase the EMV readers). Unfortunately, these delays may harm these merchants because they could result in a spike in fraud for those companies as criminals shift their focus to these targets that are easier to compromise without the EMV technology.

Besides the liability shift, why else should merchants move quickly to become EMV compliant?  First, EMV has been shown to significantly lower fraudulent activity for card-present transactions. Second, fraud migrates to non-EMV compliant terminals. Third, if 75% of transactions are processed through EMV-enabled terminals and the terminals support contact and contactless transactions, the annual PCI DSS compliance validation with a QSA is no longer required. Fourth, you may be protected from assessments by card brands arising from a compromise of magnetic stripe cardholder information, if 95% of card-present transactions are from EMV-capable terminals 30 days before the start of the compromise event. Fifth, from a public relations standpoint, you do not want to be known as a company that doesn’t take customer security seriously. Finally, the EMV-capable POS terminals also allow the merchant to accept contactless transaction devices, which may be a feature the merchant does not currently offer.

Are there security weaknesses to EMV?  Yes. As mentioned earlier, EMV is only helpful in reducing fraud where the payment card is present during the transaction; online purchases and other e-commerce would not be protected by EMV (for the time being). Also, some payment card security experts have observed that an EMV-compliant merchant still possesses personal account numbers for credit cards because EMV merely attaches the randomly generated code to the personal account number, meaning that a hacker could still potentially access the payment card information by merely removing/scrubbing the code from the personal account number, assuming the hackers access unencrypted information.

Are there better ways to secure payment card transactions?  Absolutely. EMV is a “fraud-reducer,” but point-to-point encryption (P2PE) and tokenization is a “fraud eliminator.” P2PE encrypts the personal account number through the entire transaction process, so the merchant never possesses unencrypted personal account numbers and does not have the keys necessary to unlock the encrypted information. Tokenization takes security one step further by replacing the personal account number with a different number that is worthless to a hacker, so the merchant never possesses this valuable information. An example of tokenization is Apple Pay – when you pay for goods or services with Apple Pay you are not providing the merchant with your credit card number, but rather with a random number that would be useless in any other context.

In short, companies that accept credit and debit cards as a form of payment should move quickly to become EMV compliant. While EMV is not a panacea to protect against fraud, it can significantly reduce it and, more importantly, provide other benefits to a company, like the liability shift. Companies that want to take their security to the next level, however, should consider implementing P2PE and tokenization.

DISCLAIMER: The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients. Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients. All of the data and information provided on this site is for informational purposes only. It is not legal advice nor should it be relied on as legal advice.

 

In 2014, the Food and Drug Administration (“FDA”) articulated its expectations for how device manufacturers address cybersecurity premarket in Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. Recently, the FDA released complementary draft guidance in Postmarket Management of Cybersecurity in Medical Devices. In the new guidance, the FDA explains what constitutes an effective cybersecurity risk management program, how manufacturers should evaluate postmarket cybersecurity vulnerabilities, and when manufacturers must report to the FDA cybersecurity risks and improvements. Comments on the draft guidance are due by April 21, 2016.

Here are the key takeaways from the guidance:

  • Cybersecurity programs should be documented, systematic, and comprehensive.
  • Consider medical device cybersecurity throughout the device’s entire lifecycle.
  • When evaluating a medical device’s cybersecurity, consider a broad range of quality information and focus on cybersecurity threats that may compromise a device’s essential functions.

Components of an Effective Cybersecurity Risk Management Program

The new guidance exhorts manufacturers to create a cybersecurity risk management program that will address a device’s cybersecurity from the drawing board to the dustbin.

Premarket, manufacturers should account for cybersecurity by designing cybersecurity-related inputs for their devices and incorporating a cybersecurity management approach that determines (A) assets, threats, and vulnerabilities; (B) how threats and vulnerabilities may affect device functionality and end users/patients; (C) the likelihood of threats and exploitation of vulnerabilities; (D) risk levels and suitable mitigation strategies; and (E) residual risk and risk acceptance criteria. (The FDA gave the same recommendations in its guidance 2014 premarket guidance.)

Adequate postmarket cybersecurity management requires a program that is systematic, structured, documented, consistent with the Quality System Regulation (21 C.F.R. Part 820), and incorporates the National Institute of Standards and Technology’s (NIST) Framework for Improving Critical Infrastructure Cybersecurity (cybersecurity guidelines the NIST created pursuant to a presidential executive order and with input from public and private stakeholders). Key components include:

  • monitoring quality cybersecurity information sources—such as complaints, service records, and data provided through cybersecurity Information Sharing Analysis Organizations (“ISAOs”)—for identification and detection of cybersecurity vulnerabilities and risk;
  • establishing, communicating, and documenting processes for vulnerability intake and handling;
  • understanding, assessing, and detecting the presence and impact of vulnerabilities;
  • clearly defining essential clinical performance to develop mitigations that protect, respond, and recover from the cybersecurity risk;
  • adopting a coordinated vulnerability disclosure policy and practice; and
  • deploying mitigations that address cybersecurity risk early and prior to exploitation.

Assessing Postmarket Cybersecurity Vulnerabilities

Acknowledging that not all vulnerabilities threaten patient safety and that manufacturers may not be able to identify every threat, the guidance advises manufacturers to identify a device’s “essential clinical performance” and focus on identifying and resolving risks to that performance. Manufacturers should define a device’s essential clinical performance by considering the conditions necessary for the device to operate safely and effectively. Manufacturers should assess a vulnerability’s risk by evaluating its exploitability and health dangers resulting from its exploitation. The draft guidance recommends tools for each evaluation: the Common Vulnerability Scoring System v3.0 for exploitability and the standards in ANSI/AAMI/ISO 14971: 2007/(R)2010: Medical Devices – 442 Application of Risk Management to Medical Devices for health dangers caused by exploitation.

The guidance divides risks into two groups and recommends manufacturers do the same. Low or “controlled” risk exists when, after accounting for existing controls, there is an acceptable amount of risk that the device’s essential clinical performance could be compromised by a cybersecurity vulnerability. High or “uncontrolled” risk exists when insufficient controls and mitigations create an unacceptable amount of risk that the device’s essential clinical performance could be compromised by a cybersecurity vulnerability.

Reporting Mitigation

A risk’s classification affects whether a manufacturer may address the risk without reporting the risk and its remediation to the FDA under 21 C.F.R. Part 806, which obligates manufacturers to report to the FDA when they repair, modify, or adjust a device to reduce the device’s health risk. Manufacturers may ameliorate controlled risks without reporting the risk or enhancement under Part 806. (But for Class III devices, manufacturers must disclose the risk and the remediation in its periodic report to the FDA under 21 C.F.R. § 814.84.) Uncontrolled risks are a different matter: manufacturers must report them and their remediation unless (A) there are no known serious adverse events or deaths associated with the vulnerability; (B) within 30 days of learning of the vulnerability, the manufacturer identifies and implements device changes and/or compensating controls to bring the residual risk to an acceptable level and notifies users; and (C) the manufacturer participates in an ISAO.

What the Draft Guidance Means for Device Manufacturers

Device manufacturers should not delay assessing the strength of their cybersecurity management program. The U.S. Department of Health and Human Services, Office of Inspector General identified cybersecurity of medical devices as one of its priorities for 2016. And the draft guidance explains that the FDA may consider devices with uncontrolled risk to violate the FDCA and be subject to enforcement action.

To see how their program measures up to what the draft guidance describes, device manufacturers should start by ask themselves these key questions:

  • Is our cybersecurity management program addressing cybersecurity throughout each device’s lifecycle?
  • Is our program proactive?
  • Are there quality data security sources, such as ISAOs, we have not used but should?
  • Do we need to develop and deploy new training or messaging to colleagues about cybersecurity?
  • Are we using good cyber hygiene?

When deciding how to move forward with strengthening a cybersecurity program, manufacturers will want to keep in mind the need to safeguard devices against malicious and non-malicious attacks. Vulnerable devices may become infected by malware that cannot tell the difference between a personal computer and a pacemaker. That example is not farfetched: J.M. Porup recently reported for Slate that malware designed to steal credit card information infected and disabled vulnerable fetal heart monitors.

Ever wonder how your credit card gets compromised and how the bad guys get your information? This report on tonight’s episode of 60 Minutes provides an overview of what happens from the moment you swipe your card at the point-of-sale terminal to the moment when the card number is compromised and sold on a black market website to the moment when the bad guy who buys your credit card number online uses it to create a counterfeit card. The report also investigates why most companies learn of these breaches from third parties rather than their own information security team. I highly recommend it to anyone interested in learning about this risk as this year’s holiday season begins.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

My last post described what the recently passed Florida Information Protection Act (FIPA) will do.  This post analyzes how FIPA differs from Florida’s existing breach notification law and explains why those differences will hurt or help companies that maintain information about Florida residents.  Florida’s Governor must still sign the FIPA into law, but his signature is expected given the unanimous support of FIPA in the state legislature.  Once signed, the law will go into effect on July 1, 2014.  So what do businesses need to know about FIPA?

Attorney General Notification

The first significant difference between FIPA and Florida’s existing breach notification law is that, with some limited exceptions, breached entities will be required to notify Florida’s Attorney General within 30 days of any breach that affects more than 500 Florida residents.  Until now, Florida has been part of the majority of states that does not require notice of a breach to the state Attorney General.

The law also requires breached entities to notify the Attorney General’s office even when the entities decide notification to affected consumers is not necessary because the breach will not likely result in harm to affected individuals.  It remains to be seen whether this change in the law will result in a flood of “non-notifications” to the Attorney General’s office.

The FIPA provides teeth for the Attorney General’s Office to enforce it.  A violation of FIPA may be automatically considered a violation of Florida’s Deceptive and Unfair Trade Practices Act.  Though the FIPA does not create a private cause of action, we could see the Attorney General actively enforce the law against breached entities that fail to meet the law’s requirements.

Broader Definition of PII

Another significant change in Florida law as a result of the FIPA is the expansion of the definition of personally identifiable information (PII). PII will now include the username or email address in combination with a password or security questions and answer that would permit access to an online account.  This change is based on a realization that consumers are increasingly storing information online and, unfortunately, often using the same usernames and passwords.  The net result, however, will be an increased number of data breaches under the law.

Shortening the Breach Notification Period

FIPA also shortens the time a breached entity has to notify affected individuals of a breach.  Currently, breached entities must notify affected individuals “without unreasonable delay” but they have up to 45 days.  The new law requires breached entities to notify affected individuals “as expeditiously as practicable, but no later than 30 days after the determination of the breach or reason to believe a breach occurred,” unless a waiver or authorized delay is issued.

This change raises a couple of concerns for breached entities.  First, while in most instances 30 days may be enough time to notify affected individuals of a breach, in some cases that will not be enough time.  There are many steps that must take place as part of the notification process, including determining the source and scope of the instruction, identifying what information is affected, identifying who is affected and where they live, and ensuring that the threat is no longer in existence.  Adopting a bright line deadline may end up punishing breached entities that are working as quickly as possible to respond to a breach.

Second, it is not clear under the FIPA what starts the clock running on the 30 days.  When is “determination of the breach” triggered?  Is it when the breached entity reasonably believes an intrusion has occurred?  Is it when the entity knows that PII has been affected?  Is it when the entity knows whose PII has been affected?  I would argue that clock shouldn’t start running until the entity knows that the PII of a Florida resident has been affected, but we are left to guess how regulators will interpret this requirement.

Notification by Email

A welcome change that the FIPA will usher in is breach notification by email.  This will help significantly reduce the cost of breach notification in matters that involve a large number of Florida consumers.  It is also recognition that the best contact information a company may have for its customers is their email address.

Be prepared to turn over your incident and forensic reports

Perhaps the most significant change is that the FIPA purports to require breached entities to provide incident reports, data forensic reports, and the company’s policies in place regarding breaches, if the Florida Attorney General’s Office requests them.  These documents sometimes contain unintentionally damaging statements or proprietary information about a company’s security infrastructure that the company would not want to be made public.  And, once disclosed to the Attorney General’s office, the documents may become subject to a public records request, though this bill (which also awaits the Governor’s signature) tries to limit that risk?  As a result of this change, we could see breached entities either not requesting reports at all (out of concern that they will have to disclose them to third parties), or requesting two versions – a sanitized version that contains little information and can be produced to the Attorney General, and a more fulsome version for internal use.  Either result could not have been what the legislature intended when it passed this law.  It will also be interesting to see how the FIPA will affect the work product and self-critical analysis privileges that apply to data forensic reports prepared at the direction of counsel.

Proactive Security Requirements

The FIPA adds a new type of protection of PII:  it requires that an entity maintaining PII adopt “reasonable measures” to protect and secure the PII.  With this change, Florida joins the minority of jurisdictions that statutorily require entities maintaining PII to adopt safeguards regardless of whether the entity ever suffers a breach.  To be sure, adopting safeguards to protect PII is a good idea regardless of whether it is statutorily required, and the failure to adopt those safeguards could expose a company to an enforcement action by the FTC or state attorney general under the FTC Act or “little FTC Acts,” respectively, even in states where those safeguards are not required.  But the FIPA provides no guidance as to what is meant by “reasonable measures.”  Does this mean encryption?  Password protection?  Are written policies and training required?  Does it differ depending on the size of the breached entity?  Again, we are left to guess.

Some Final Observations

A few closing observations about the FIPA:

  • The definition of a breach is still limited to electronic personal information; so a breach involving purely paper records may not trigger the statute.
  • A violation of the statute is automatically considered a violation of Florida’s Deceptive and Unfair Trade Practices Act, but that violation appears to be enforceable only by the Florida Attorney General and not a private cause of action.
  • A breach now means unauthorized “access” of PII, where before it was defined as unauthorized “acquisition” of PII.  This change broadens the number of scenarios that could be considered a breach.

In short, the FIPA is generally a consumer-friendly law that will increase the number of breaches that require notification, shorten the time by which notification must take place, require that the Attorney General be included in the breach notification process, and demand that companies adopt security safeguards to protect PII regardless of whether they ever suffer a breach.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

The Florida Legislature recently passed the Florida Information Protection Act of 2014 (FIPA).  This post describes the FIPA and analyzes the advantages and disadvantages to businesses governed by the new law.  The FIPA must still be signed by the Governor, but the law received unanimous support in the legislature, so his signature is expected.  Once signed, the law would go into effect in a less than two months.

What is the FIPA?  The FIPA will replace Florida’s existing data breach notification law.  It has a reactive component (what companies must do after a breach) and a proactive component (what companies must do to protect personally identifiable information they control regardless of whether they ever suffer a breach).  The FIPA governs “covered entities.”  A covered entity is a commercial entity that acquires, maintains, stores or uses personally identifiable information.  A “breach” triggering the FIPA is the unauthorized access of data in electronic form containing personally identifiable information (PII).  The FIPA applies only to PII in electronic form, though an argument can be made that the secure disposal requirement under the FIPA applies to PII in any form given its use of the term “shredding.”

What is PII?  PII is defined as a first name or first initial and last name in combination with any of the following:

  • social security number;
  • driver’s license or ID card number, passport number, military identification number, or other similar number issued on a government document used to verify identity;
  • a financial account number or credit or debit card number, in combination with any required security code, access code, or password that is necessary to permit access to an individual’s financial account;
  • information regarding an individual’s medical history, mental or physical condition, or medical treatment or diagnosis by a health care professional; or
  • an individual’s health insurance policy number or subscriber identification number and any unique identifier used by a health insurer to identify the individual.

PII also includes a username or email address in combination with a password or security question and answer that would permit access to an online account.  The FIPA does not apply to PII that is encrypted, secured, or modified such that the PII is rendered unusable.

Do covered entities have to notify the Florida Attorney General’s Office of a breach?  Yes.  Covered entities must notify Florida’s Department of Legal Affairs (i.e., the Florida Office of the Attorney General) of any breach that affects more than 500 people.  Notice must be provided as expeditiously as practicable, but no later than 30 days after determination of the breach or reason to believe a breach occurred.  An additional 15 days is permitted if good cause for delay is provided in writing to the Attorney General within 30 days after determination of the breach or reason to believe a breach occurred.

The notice to the Attorney General must include:

  • a synopsis of the events surrounding the breach;
  • the number of affected Floridians;
  • any services related to the breach being offered without charge to the affected individuals (e.g., credit monitoring) and instructions as to how to use such services;
  • a copy of the notice sent to affected individuals or an explanation as to why such notice was not provided (e.g., there was no risk of financial harm); and
  • the name, address, telephone number, and email address of the employee or agent of the covered entity from whom additional information may be obtained about the breach.

Additionally, if the Attorney General asks for any of the following, the covered entity must provide it:

  • a police report
  • an incident report
  • a computer forensics report
  • a copy of the policies in place regarding breaches
  • steps that have been taken to rectify the breach

When must affected individuals be notified?  Notice to affected individuals must be made as expeditiously as practicable and without unreasonable delay.  The law allows covered entities to take into account the time necessary to allow the covered entity to determine the scope of the breach of security, to identify individuals affected by the breach, and to restore the reasonable integrity of the data system that was breached.  But even with those considerations, notice to affected individuals cannot take longer than 30 days after determining or having a reason to believe that a breach has occurred.

Two exceptions can permissibly delay or eliminate the obligation to notify affected individuals.  One exception is an authorized delay, which occurs when law enforcement determines that notice to individuals would interfere with a criminal investigation.  The determination must be in writing and must provide a specified period for the delay, based on what law enforcement determines to be reasonably necessary.  The delay may be shortened or extended at the discretion of law enforcement.

The second exception is a waiver, which occurs where, after an investigation and consultation with law enforcement, the covered entity reasonably determines that the breach has not and will not likely result in identity theft or any other financial harm to the affected individuals.  If a waiver applies, the covered entity must document it, maintain the documentation for five years, and provide the documentation to the Attorney General within 30 days after the determination.

How must notice to affected individuals take place and what must it include?  Direct notice to affected individuals can take one of two forms:  it can be in writing (sent to the mailing address of the individual in the records of the covered entity) or it can be by email to the email address of the individual in the records of the covered entity.  In either form, the notice must include:  (a) the date, estimated date, or estimated date range of the breach; (b) a description of the PII that was accessed; and, (c) information that the individual can use to contact the covered entity to inquire about the breach and the PII that the covered entity maintained about the individual.

Can a covered entity provide substitute notice to affected individuals?  If the cost of direct notice would exceed $250,000, more than 500,000 individuals are affected, or the covered entity does not have a mailing or email address for the affected individuals, then substitute notice can be provided.  The substitute notice must include a conspicuous notice on the covered entity’s website and notice in print and to broadcast media where the affected individuals reside.

What if the covered entity is governed by HIPAA or some other federal regulations?  Notice provided pursuant to rules, regulations, procedures, or guidelines established by the covered entity’s primary or functional federal regulator is deemed to be in compliance with the notice requirement to individuals under the FIPA. However, a copy of that notice must be timely provided to the Attorney General.  For example, if a company is governed by HIPAA, then their notice pursuant to the Breach Notification Rule will be sufficient to meet the requirements under the FIPA, but a copy of that notice still must be sent to the Attorney General.

Do covered entities have to notify credit reporting agencies?  If more than 1,000 individuals are affected, then notice to all consumer reporting agencies must be provided without unreasonably delay.

What if the breach occurs with a third-party agent (e.g., a vendor)?  A third-party agent is an entity that has been contracted to maintain, store, or process PII on behalf of a covered entity or governmental entity.  If a third-party agent suffers a breach, it must notify the covered entity within 10 days following the determination of the breach or reason to believe the breach occurred.  Upon receiving notice of the breach, the covered entity must then comply with the requirements to notify affected individuals and the Attorney General.  In that case, the third-party agent must provide all information necessary for the covered entity to comply with its notice requirements.  The third-party agent may notify affected individuals and the Attorney General on behalf of the covered entity, but the agent’s failure to provide proper notice is deemed a violation against the covered entity.

Are there obligations other than notification after a breach?  In addition to the reactive component of the FIPA (actions covered entities must take after a data breach), the FIPA also has a proactive component that imposes obligations on covered entities regardless of whether they ever suffer a breach.  Specifically, covered entities must take reasonable measures to protect and secure PII.  Covered entities must also take reasonable measures to dispose, or arrange for the disposal, of customer records containing PII within their custody or control when the records are no longer to be retained.  Such disposal must involve shredding, erasing, or otherwise modifying the PII in the records to make it unreadable or undecipherable through any means.

Who enforces the FIPA and how?  A violation of the FIPA is an unfair or deceptive trade practice subject to an action by the Attorney General under Florida’s Deceptive and Unfair Trade Practices Act against the covered entity or third-party agent.  A covered entity that does not properly notify affected individuals or the Attorney General may be fined up to $500,000 per breach, depending on the number of days in which the covered entity is in violation of the FIPA.  The law creates no private cause of action, nor does the presumed FDUTPA violation for the Attorney General appear to apply to a private action under FDUTPA.

The law will become effective on July 1, 2014 if it is signed by the Governor.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.

 

Plaintiffs’ lawyers were falling over themselves last week in a race to the courthouse to sue Target as a result of its recent data breach.  By at least one report, over 40 lawsuits have already been filed against Target, the first of which was filed the day after the breach became public.  This post will provide an overview of the lawsuits, analyze their merits, identify potential concerns for Target, and address some of the larger public policy implications raised by the lawsuits.  My next post will provide more specific details about a sample of the lawsuits.

A (Coordinated) Race to the Courthouse

The lawsuits were filed in Federal courts all over the country, including Alabama, California, Florida, Illinois, Minnesota, Oregon, and Rhode Island.  At least four of them were the result of coordinated efforts between plaintiffs’ firms that filed the lawsuits in California, Illinois, and Oregon, given the similarity of language and structure used in  those complaints.  (That’s not particularly unusual, but let’s not pretend that there isn’t a coordinated effort involved here).  The lawsuits will likely be consolidated or become part of a multidistrict litigation panel, and there will be an internal battle between the plaintiffs’ lawyers as to whom will serve as class counsel.

Also interesting is when the lawsuits were filed.  All of these lawsuits were filed within a few days of the data breach becoming public.  They were filed before knowing what caused the breach, before knowing when Target learned of the breach, and before knowing what Target did to prevent the breach from occurring in the first place.  The developing data breach legal landscape has shown us that liability from a data breach arises not from the breach itself (almost every company suffers a breach), but from what the company did before or after the breach to prevent it and notify affected individuals.  So the fact that these lawsuits were filed before we know much about what led to the breach and how Target responded should raise initial skepticism about the merits of the lawsuits.

On to the Merits . . .

Generally speaking, the lawsuits are not only premature, but weak for at least two reasons: their legal theories are not sufficiently specific, and almost none of them allege cognizable harm.

The lawsuits contain numerous causes of action (negligence, statutory violations, breach of implied and express contracts, invasion of privacy, bailment, etc.), but the causes of action are based primarily on two legal theories:  (1) Target failed to act reasonably in adopting safeguards that would have prevented the breach from happening; and/or, (2) Target didn’t notify affected consumers quickly enough.  Let’s evaluate these theories and other weaknesses in the lawsuits separately.

“Failure to Adopt Reasonable Safeguards”

Plaintiffs allege that Target failed to act reasonably to adopt safeguards to prevent the breach from occurring, but there are no allegations as to what specifically Target did wrong.  In the LinkedIn lawsuit, for example, there were allegations that LinkedIn failed to salt or hash sensitive information, and that LinkedIn’s conduct contradicted a specific provision of its consumer-facing privacy policy.  The LinkedIn complaint was dismissed because the court held that the plaintiffs lacked standing, but you knew upon reading it what the plaintiffs were claiming LinkedIn did (or failed to do) wrong.

There are no similarly specific allegations in the lawsuits against Target, probably because the plaintiffs don’t know enough about the facts to plead anything with the requisite specificity.  They don’t know yet what Target did wrong, or even if it did anything wrong.  The highly ambiguous pleading now puts Target in the position of trying to defend itself against a “moving target” (no pun intended) that plaintiffs will interpret differently to best suit their needs as the lawsuit progresses.

“Failure to Timely Notify Affected Consumers”

The plaintiffs also claim that Target failed to timely notify affected consumers of the breach, but there are currently  no facts that support this theory.  According to all accounts, the breach occurred between November 27th and December 15th, and Target notified potentially affected customers a few days thereafter by email and by creating a special web page (linked to Target.com) with regularly updated information about the breach and Target’s response.

As anyone with breach response experience will tell you, there are a number of time-consuming steps in the breach response process before notification can take place.  First, you need to identify and understand the nature of the compromise, and you have to be reasonably sure that the compromise has been contained and remediated so it is no longer a threat.  This step alone can take days or weeks to complete depending on the level of sophistication of the attack.  Further complicating this step is the coordination with  law enforcement, who may be concerned that acting too quickly will inhibit their ability to identify the perpetrators.  After the integrity of your system has been restored, you need to identify what information was affected by the breach.  If you learn that personal information was potentially compromised as a result of the breach, you need to know whose information was affected so you can quickly inform them and regulatory authorities in compliance with applicable legal requirements.  Undertaking this entire process can often take weeks.  Target appears to have done it within a few days.

There is another factor that must be considered in determining whether Target complied with any legal obligation to notify consumers – the various data breach notification laws. 46 states have their own data breach notification laws and they are triggered by the location of the individual whose information is compromised, not by the location of the company that suffered the breach (meaning that they’re all in play with a breach this size).  Most require notification within a “reasonable” period of time, and for some that means the breached entity may have as long as 30 to 45 days to undertake notification.  These laws usually do not “start the clock running” on notification until the company reasonably believes that it has identified the full scope of the breach and has contained it.  This makes sense because you wouldn’t want to tip off the hackers that you are on to them by issuing a public notification when your systems are still compromised.  Additionally, it is very difficult to undertake notification until you know who you need to notify (i.e., whose information was compromised, where do they live, how can I contact them, etc.), which can take some time to determine.  Finally, almost all of these laws allow for a delay in notification where law enforcement believes that such notification would impede their ability to identify and investigate the hackers. We do not know whether such a “law enforcement hold” was in place in this breach.  (Some of the plaintiffs allege in their complaints that no law enforcement hold was in place, but they couldn’t possibly know that yet).

It is possible that facts could emerge at a later date showing that Target knew of the compromise much earlier but chose not to notify affected consumers, but for the time being, the fact that Target notified affected consumers within a few days of the compromise becoming known easily disposes of the allegation that Target delayed notifying consumers.

Cognizable Harm

The plaintiffs will also have a very difficult time proving that they suffered cognizable harm, as evident by the difficulty they have in pleading it.  Almost half of the lawsuits allege that they suffered “compensatory damages” or “harm” generally, but fail to describe their damages with any specificity.  They likely cannot identify any cognizable harm at this point, further demonstrating the premature nature of these lawsuits.  Some of the lawsuits seek damages for a “risk” of harm at some unforeseeable point in the future, or for fraudulent charges that were almost certainly reimbursed or will be reimbursed by the consumers’ financial institutions, or for potential damage to their credit scores.  None of these types of damages have been recognized as cognizable in a data breach lawsuit.

This is not to say that all damages are not cognizable.  In a few jurisdictions, courts have held that plaintiffs can proceed in pursuing certain damages.  In the First Circuit, for example, consumers are allowed to pursue “mitigation expenses” (e.g., the unreimbursed cost of replacing their cards, obtaining credit reports and credit insurance, etc.).  In the Eleventh Circuit, consumers have been allowed to pursue the portion of their service fees/premiums to a company that was used for securing the consumers’ personal information.  To the extent the plaintiffs have filed lawsuits in these jurisdictions and are seeking these types of damages, their allegations of damages may be stronger.

Precedent

Finally, Plaintiffs will have to deal with the majority of case law in data breach lawsuits that, with some limited exceptions, has not allowed the lawsuits to proceed.  Two of the most important decisions will be the U.S. Supreme Court’s decision in Clapper v. Amnesty International and the Northern District of Illinois’s decision in In re Barnes & Noble Pin Pad Litigation.  Clapper raised the bar for demonstrating cognizable harm and standing in privacy violation cases such as this one.  The Clapper decision was relied on by the Northern District of Illinois in dismissing a data breach lawsuit against Barnes & Noble that arose from an almost identical set of facts — the compromise of consumers’ personal information stolen from PIN pads at a major retailer.  The court held that the plaintiffs lacked standing because they could not allege that a threatened injury was “certainly impending” as a result of the breach.

I expect the plaintiffs to rely on the recent decisions by the Eleventh Circuit, the First Circuit, and the Southern District of Florida that allowed data breach lawsuits to proceed.  Therefore, I would closely monitor what happens in the two Florida lawsuits and the Rhode Island lawsuit, or any others that are subsequently filed in the Eleventh or First U.S. Circuits.

Should Target Still Be Worried?

Despite the premature nature and overall weaknesses of the lawsuits as filed, Target still has cause for concern. First, even though legal precedent is heavily in its favor (this blog post cites only a few of the many opinions dismissing data breach lawsuits), the development of the law is still in its early phases, and as evident from the previous paragraph, some courts where lawsuits against Target are pending have allowed data breach lawsuits to proceed.

Another concern is how the facts emerge.  For example, if it turns out that Target knew about the breach long before it was disclosed publicly, knew that personal information had been compromised, knew whose information had been compromised, knew that the information was not encrypted, and was under a legal obligation to notify affected individuals, then the plaintiffs’ “failure to timely notify” will strengthen.

Target also has to be concerned about trying to keep the focus where the law requires it.  The plaintiffs’ lawyers are going to try to shift the focus from what Target did (the sophisticated and complex information security program Target likely had in place) to what Target could have done (the one “error” Target made that could have prevented the breach).  According to one study, 97% of breaches are avoidable (in hindsight) through simple or intermediate controls.  Why is that important?  Because I have little doubt that the plaintiffs’ lawyers will be able to find a cybersecurity “expert” somewhere willing to testify that Target could have done something that would have prevented the breach from occurring, thereby trying to create an issue of fact as to the reasonableness of Target’s conduct.  Target will need to try hard to keep the focus on the correct legal standard.  The legal standard isn’t whether Target could have done something to prevent the breach, but whether it acted reasonably to prevent the breach.  In other words, the plaintiffs’ lawyers will try to persuade the courts that liability should be determined by whether the breach was preventable, and Target will try to keep the focus on the fact that it adopted a highly sophisticated, expensive, and (for the most part) very effective information security program and made the security of its consumers’ information the highest priority.  If plaintiffs succeed in shifting the focus away from the legal standard, every company should be very concerned, because so many data breaches are, in hindsight, preventable, which means that almost every company could face potential liability if they suffer a breach.

So why should EVERY Company Care About These Lawsuits . . .

The lawsuits are premature, not well supported by precedent, and based heavily on rank speculation as to the safeguards Target had in place and how quickly it responded.  Despite these weaknesses, however, every company should care about what happens to these lawsuits.  Target is a very large company that undoubtedly had in place complex and sophisticated safeguards to protect against this type of a data breach, and from what we know so far, they notified affected individuals very quickly.  If there is anything less than a dismissal or summary judgment entered in all of these cases, then the proverbial blood will be in the water and we can expect the floodgates of data breach litigation to open.  Almost every company that suffers a data breach could be held liable because few are going to have the level of security and response efforts that an organization like Target has in place.

The public policy consequences of Target being held liable are significant.  Companies will be less inclined to reveal breaches due to potential liability exposure, so consumers will be less likely to know when their information has been accessed, precluding them from responding adequately to protect themselves.  Instead of investing resources into physical, technical, and administrative safeguards that could improve the security of consumers’ information, companies will be forced to spend their resources on litigation costs, settlements, and awards to plaintiffs.  The individuals who will benefit most won’t be the consumers (who could each receive nominal awards for mitigation expenses), but the attorneys who will reap significant attorney’s fees awards in class action lawsuits.  So what happens to these lawsuits will be important to any company that collects, stores, uses, and disposes of sensitive consumer information, which is almost every company doing business in this modern economy.

 

DISCLAIMER:  The opinions expressed here represent those of Al Saikali and not those of Shook, Hardy & Bacon, LLP or its clients.  Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Al Saikali, Shook, Hardy & Bacon, or its clients.  All of the data and information provided on this site is for informational purposes only.  It is not legal advice nor should it be relied on as legal advice.