Shortly after the new year, the Federal Trade Commission filed suit in the Northern District of California against D-Link Corporation, a Taiwan-based maker of wireless routers, Internet Protocol (IP) cameras, and software used in consumer electronics (such as baby monitors). The complaint alleges that D-Link failed to reasonably secure its products from hackers. Notably, the FTC has not alleged that D‑Link products were exploited by hackers or that a data breach or cyberattack resulted from any alleged security vulnerabilities. Rather, the action is based squarely on security vulnerabilities that “potentially compromis[ed] sensitive consumer information, including live video and audio feeds from D-Link IP cameras” and marketing statements made by D-Link that touted the products’ security features.
It was about time for data breach defendants to get a win. The District Court for the Northern District of Illinois delivered one to Barnes & Noble in its long-running class action that stems from a breach suffered in 2012. Plaintiffs’ case was dismissed in its entirety on a motion to dismiss under Rule 12(b)(6). This development—just days after the Sixth Circuit in Nationwide had aligned itself with the Seventh Circuit’s Neiman Marcus and P.F. Chang’s decisions that found standing to sue for breach plaintiffs—shows that the legal battle over “harm” may start with standing, but goes nowhere absent alleged damages that tightly match the substantive elements of each claim.
According to a press release of the Data Protection Supervisory Authority in the Land Mecklenburg Vorpommern of November 3, German supervisory authorities have randomly selected 500 companies in Germany and sent them requests for information on their international data transfers. The German supervisory authorities are undertaking this coordinated action in order to increase awareness among companies of the need to ensure data privacy compliance of international data transfers.
Last week, FinCEN (Financial Crimes Enforcement Network) issued a formal Advisory to Financial Institutions and published FAQs outlining specific cybersecurity events that should be reported through Suspicious Activity Reports (SARs). This Advisory follows former FinCEN Director Jennifer Shasky Calvery’s recent statements reminding “financial institutions to include cyber-derived information (such as IP addresses or bitcoin wallet addresses) in suspicious activity reports.” It also follows the launch of the Federal Financial Institutions Examination Council (FFIEC) Cybersecurity Assessment Tool (CAT). Although the Advisory does not change existing Bank Secrecy Act (BSA) requirements or other regulatory obligations, the Advisory highlights a series of cybersecurity events–such as Distributed Denial of Service (DDoS) attacks and ransomware incidents–that should be reported on SARs filed with FinCEN, even though they often (but not always) fall outside the traditional notion of a data breach or a compromise of personal information.
Even today, most companies—even technology companies—do not think they have information that the U.S. Government wants or needs, particularly as it might relate to a national security investigation. The reality is that as terrorists and others who threaten national security use a broader spectrum of technology resources to communicate and to finance and conduct operations, the U.S. Government has significantly increased its collection of data from technology companies and others.
What should companies do when ransomware hits? The FBI says: (a) report it to law enforcement and (b) do not pay the ransom. Given the recent onslaught in ransomware attacks—such as a 2016 variant that compromised an estimated 100,000 computers a day—companies should consider how their incident response plans account for decision-making in response to ransomware, and include this scenario in their next (or an interim) tabletop simulation.
FBI Public Service Announcement
In a September 15 announcement, the FBI urged companies to come forward and report ransomware attacks to law enforcement. The FBI acknowledged that companies may hesitate to contact law enforcement for a variety of reasons: uncertainly as to whether a specific attack warrants law enforcement attention, fear of adverse reputational impact or even embarrassment, or a belief that reporting is unnecessary where a ransom has been paid or data back-ups have restored services.
Notwithstanding these dynamics, the FBI is calling on companies to help in the fight: “Victim reporting provides law enforcement with a greater understanding of the threat, provides justification for ransomware investigations, and contributes relevant information to ongoing ransomware cases.”
The FBI also offered some best practices that companies should consider incorporating into their cybersecurity program and/or their disaster recovery and business continuity plans. These recommendations include: regular backups that are verified, securing backups, implementation of anti-virus and anti-malware solutions, increased employee awareness training, institution of principle of least privilege policies, and more. READ MORE
Just as it promised a year ago, New York State proposed new proscriptive, minimum cybersecurity requirements for regulated financial services institutions. The regulations go final after a 45-day notice and public comment period. At that point, entities regulated by the NYDFS will be subject to the nation’s first proscriptive set of cybersecurity requirements in contrast to the usual risk-based cybersecurity programs mandated by other financial regulators to date. Thus, unlike previous guidance and reports issued by financial regulators such as FINRA and the SEC, New York’s rules are specific requirements that all regulated financial institutions must adopt.. In this Part I, we review the proposed requirements, and offer some specific steps that regulated financial services institutions should begin to consider for compliance readiness.
Last week, the FTC published a blog post titled The NIST Cybersecurity Framework and the FTC, in which the agency issued a nuanced answer to an oft-asked question: “If I comply with the NIST Cybersecurity Framework, am I complying with what the FTC requires?”
The short answer: “No.” On a more positive note, the FTC acknowledges that the NIST Cybersecurity Framework is aligned with the agency’s long-standing approach to data security and that it may serve as a useful tool for companies developing and evaluating a data security program. The FTC blog post reiterates, yet again, that there is no magic bullet to establish adequate data security. Ultimately, what is required is careful, detail-oriented design, implementation, and enforcement of sound policies and practices to mitigate both the impact of cybersecurity incidents and of serious regulatory scrutiny.
NIST Cybersecurity Framework: Not a Standard or a Checklist
The Department of Commerce’s National Institute of Standards and Technology (NIST) issued the NIST Cybersecurity Framework in February 2014. The Framework organizes security around a“Core,” consisting of five (5) functions – Identify, Protect, Detect, Respond and Recover – that represent the high-level activities that help organizations make sound decisions around risk/threat management and forward improvement. Each function maps to key categories of desired outcomes (e.g., “Asset Management,” “Access Control”). Each category then expands to a series of more specific outcomes and technical/management activities that are, in turn, tied to dozens of “informative references,” such as ISO/IEC, ISA and COBIT, which are well established implementation standards. The Framework doesn’t include specific practices or requirements. Instead, it’s meant to facilitate an iterative process that involves “detecting risks and constantly adjusting one’s security program and defenses.”
As the FTC notes, the NIST Framework “is not, and isn’t intended to be, a standard or checklist.” To bluntly answer the million-dollar question: “there’s really no such thing as ‘complying with the Framework.’’’ The Framework provides guidance on process. It does not proscribe the specific practices that must be implemented. Most importantly, the FTC correctly observes that there is “no one-size-fits-all approach,” nor the possibility of achieving “perfect security.” Put simply, the framework is just that: a framework for understanding the current state of an organization’s cybersecurity program and preparing a risk-based approach to improving maturity.
FTC’s Enforcement Record Aligned With NIST Framework
The FTC blog post highlights that NIST’s focus on risk assessment and mitigation are “fully consistent” with concept of “reasonableness” embedded in the agency’s Section 5 enforcement record. The post lists numerous examples from the FTC’s list of 60+ cybersecurity actions to date where the deficient security practices underlying the FTC complaint align squarely with the Framework’s Core functions:
- Identify: failures to maintain processes for receiving, addressing, or monitoring reports about security vulnerabilities;
- Protect: providing broad employee administrative access to data systems; failure to secure sensitive data in-transit; and to appropriately manage removal, transfer or disposition of data;
- Detect: failures to use processes to identify unauthorized intrusions to networks and systems(i.e., monitoring), and unauthorized external disclosures of personal information;
- Respond: repeated failures to enhance incident response procedures despite multiple data breaches, and failure to notify consumers regarding known vulnerabilities associated with products
- Recover: consent orders that include requirements to proactively notify consumers about security vulnerabilities and remediation measures, and to work with security vendors as part of sustaining secure products/services.
- Companies must continue to operate without specific FTC security standards.
Nothing in the FTC’s recent post points to specific, articulated security practices that organizations can employ to avoid enforcement under the FTC’s Section 5 authority to regulate “unfair practices.” In other words, there are no hard and fast rules on what is (or is not) required. If anything, the post makes the opposite point: each company has unique risks that call for a fact-specific assessment of “reasonable” data security measures in light of sensitivity of the data the company holds, the size and complexity of the company’s operations, known threats in the industry, the availability and cost of security tools, and other factors that make up an organization’s risk profile. Accordingly, companies must continue to synthesize the myriad regulatory consent decrees, frameworks, guidelines and litigated outcomes that collectively outline the contours of reasonableness in cybersecurity to understand what the FTC expects and what they deem as (un)reasonable.
For example, prior FTC enforcement actions establish mileposts for minimally necessary security measures (e.g., firewalls, encryption, access controls, vendor management, and incident response planning) that companies should implement and test for efficacy. Companies that go without them risk heavy investigative and enforcement scrutiny by regulators and plaintiffs alike. In addition, the FTC has made clear that cybersecurity must be a dynamic (not static) process that includes measurable adaptation and improvement. What is a defensible posture today, may not be so tomorrow. Information security programs (including technical security tools) and incident response plans that are not adaptable (or adapted) to changing risk landscapes, attack vectors, third-party interplays, and other critical mesh points unique to each organization will not aid a company that comes under FTC scrutiny. Hence, the FTC’s emphasis on the NIST Framework as a process-oriented vehicle.
- While the FTC’s blog post focuses on security, its privacy mandate is equally important.
- Companies must still address significant devils-in-the-details.
Though the Framework eschews specific security procedures in favor of providing companies the flexibility design a “reasonable” data security program, it does not eliminate a company’s responsibility for compliance with other regimes. Even if a company uses the Framework to organize its approach to security, coordinating these various obligations and priorities is not made any less complicated or intense.
For example, companies that accept or process or provide technology in relation to payment card data must comply with specified Payment Card Industry (PCI) rules, including specific data security standards (PCI DSS) and implementation protocols. Covered entities and business associates under HIPAA and the Hi-Tech Act must comply with both specific and ‘flexible’ privacy, security and incident response rules issued by the Dept. of Health and Human Services. Financial institutions regulated by Gramm Leach Bliley, or under the purview of regulatory entities like the CFPB, FINRA, FDIC, OCC, and state analog agencies (e.g., NY DFS, California DBO), have specific industry tools such as the FFIEC’s cybersecurity assessment tool that is tailored for the financial space and expected to be used in audits and examinations. Companies operating in California may now be required to meet the Center for Internet Security’s Critical Security Controls as a minimum floor for security standards.  In addition, companies with B2B or sophisticated B2C relationships often have hundreds (often thousands) of contractual agreements that contain specified, and differing, security implementation requirements, as well as obligations in response to security incidents and data breaches – which are critical to operationalize. Finally, companies that operate in Europe must ensure that Framework activities are tightly harmonized with the EU data protection rules, including the oncoming General Data Protection Regulation (GDPR).
Remember that cybersecurity is about risk management, not risk avoidance. There is no such thing as 100% secure. A company that suffers a data breach may very well have been acting “reasonably,” for FTC enforcement purposes. The FTC’s cybersecurity enforcement history, guidance documents and staff reports (not to mention rules and guidance from an alphabet soup of other federal agencies), statutory requirements, and contractual obligations may all dictate data security minimums or best practices, and every regulator and security expert in the industry has a proposed set of best practices and guidelines to follow. The NIST Cybersecurity Framework presents a helpful tool by which to organize a compliance program that is adaptable and scalable, but ultimately, a company’s data security posture will be judged on the reasonableness of its implemented security practices, regardless of how the company developed its security program. A company will be best served by taking a careful, reasoned approach to cybersecurity preparedness, calibrating its security processes and controls to its own unique risk posture and industry norms, and always regarding cybersecurity as an ongoing process and priority.
 The Framework was prepared in response to an Executive Order calling for a risk-based methodology that could help critical infrastructure entities effectively identify, respond to, and recover from, cybersecurity risks. Over its short existence, it has become the guidepost for organizations across sectors well beyond critical infrastructure – regardless of their size, risk profile or regulated status, whether publicly traded or privately held.
 The FTC has publicly stated as follows regarding PCI compliance: “Certifications [of PCI compliance] alone will not suffice [to meet the obligations of providing adequate security safeguards], if we find evidence of security failures that put consumer information at risk. The injunctive relief we obtained in the Wyndham case corroborates our longstanding view that PCI DSS certification is insufficient in and of itself to establish the existence of reasonable security protections…[T]he existence of a PCI DSS certification is an important consideration in, but by no means the end of, our analysis of reasonable security.”
 Companies operating in California must contend with Attorney General Kamela Harris’ recent statement in California’s 2015 Data Breach Report that, “The 20 controls in the Center for Internet Security’s Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.”
On July 5, 2016, the Ninth Circuit Court of Appeals issued its highly anticipated decision in the most recent chapter of United States v. Nosal, holding that an individual acts “without authorization” as used in the Computer Fraud and Abuse Act (“CFAA”) when, after his/her own access has been revoked, the individual utilizes legitimate log‑in information of another to access company databases. This decision has important consequences for organizations as they consider how to implement policy and technical controls on user access to ensure they are protected against unauthorized access under the CFAA.
Last month the Federal Communications Commission (“FCC”) closed the comment period for its proposed privacy regulations, which we previously wrote about here. The million dollar question on everyone’s minds is whether the final regulations will be broader or narrower in scope than the initial proposal, which included not only a significant expansion of the definition of personal information, but also sweeping new obligations and raised serious questions in areas where the obligations could become even stricter still. Accordingly, companies subject to the new regulations are bracing for tighter FCC Enforcement Bureau scrutiny of broad data collection and handling practices.