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.
Posts by: Emily Tabatabai
States were busy updating their data breach notification statutes in 2016. With 2016 in the rear view, let’s take a look back at the legislative changes that will impact corporate incident response processes and what those trends portend going forward.
Expanded Definition of “Personal Information”
Login Credentials. In 2016, Rhode Island, Nebraska and Illinois (effective January 2017), joined the ranks of states that include usernames (or email addresses) and passwords in the definition of “personal information” that triggers notification obligations. As of this writing, the following eight states may require notification when login credentials are compromised: California, Florida, Illinois, Nebraska, North Dakota, Nevada, Rhode Island and Wyoming.
Data breach notification requirements are going global. By spring 2018, companies operating in the European Union must comply with the new General Data Protection Regulation’s (GDPR) data breach notification requirements and the Network and Information Security (NIS) Directive’s security incident notification requirements. Stricter and more far-reaching notification obligations underscore the importance of establishing a proactive Security Incident Response Policy to analyze potential legal obligations and prepare to respond to incidents long before they occur.
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.”
There is no doubt that companies face unprecedented volume and variation in both disruptive and intrusive cyberattacks on their networks. Among the different attack methodologies today, ransomware is quickly becoming a major concern for CISOs and security professionals. According to Interagency Guidance from the U.S. Government, there are currently over 4,000 daily ransomware attacks – up over 300% from the 1,000 daily ransomware attacks experienced in 2015.
Ransomware can potentially hold hostage critical corporate, customer and employee data, but in-house legal and communications teams are also concerned about whether these attacks trigger notification rules. The Department of Health and Human Services Office of Civil Rights (“HHS OCR”), which enforces the HIPAA Security and Breach Notification Rules, stated in recently issued guidance that ransomware incidents may be considered a breach that require notification. The guidance is a poignant reminder to all companies, whether regulated by HIPAA or not, to carefully consider how evolving attack methodologies can directly implicate incident response strategies and compliance obligations.
The Düsseldorfer Kreis, a committee made up of representatives of German data protection authorities, recently published guidance on the requirements for obtaining valid consent to the collection, processing and use of personal data under the relevant German data protection provisions, the Federal Data Protection Act (Bundesdatenschutzgesetz) (“BDSG”) and the Telemedia Act (Telemediengesetz).
The Düsseldorfer Kreis frequently publishes guidelines on topics of relevance for data privacy law which are broadly recognized as good practices (and from the supervisory authorities’ viewpoint, mandatory interpretations of the applicable law). The German data protection authorities found the topic of consent to be particularly relevant, noting that while it is common for companies to rely on obtaining consent from their customers to justify the processing of personal data, in many cases these companies fail to implement compliant data privacy consent language into their business processes. To ensure that such data processing can be performed in compliance with data privacy law, the procedure of obtaining valid consent should be the focus of any company active in processing personal data.
Last week, the Seventh Circuit revived a data breach class action against P.F. Chang’s restaurant in an important opinion that continues a plaintiff-friendly trend that began with the court’s opinion in the Neiman Marcus case that we previously reported on here. The court used statements that P.F. Chang’s made in response to the breach and protective remediation measures it implemented to draw inferences that customers were at a risk of identity theft and harm, and then used those inferences to find that plaintiffs had standing to proceed with their litigation. The case raises new issues that organizations should consider in crafting post-breach communications, and important takeaway lessons that may help increase the likelihood of obtaining dismissal of data breach class actions at the pleadings stage.
Tennessee recently amended its data breach notification law, and in doing so, it has joined the ranks of states like Florida, Ohio, and Wisconsin that require notification to residents of a data breach within a defined time period. When the law becomes effective on July 1, 2016, the statute will require notice to Tennessee residents within forty-five (45) days after discovery that personal information has been acquired by an “unauthorized person.” The original amendment required notice within fourteen (14) days, but the bill was subsequently amended to expand the deadline to 45 days.
Last week, fashion retailer Lord & Taylor reached a settlement with the FTC over its allegedly deceptive advertising campaign, the first such action since the FTC released its Enforcement Policy Statement on Deceptively Formatted Advertisements and its companion guidance, Native Advertising: A Guide for Businesses, in December 2015. Native Advertising is clearly on the FTC’s 2016 enforcement agenda.
This month, the Federal Communications Commission (FCC) will consider issuing a Notice of Proposed Rulemaking (NPRM) for privacy regulations that will apply to broadband providers. The goals and objectives of the proposed regulations, which will be offered by FCC Chairman Wheeler, are outlined in a short document that the FCC released. The proposed regulations will likely contain strict privacy requirements that broadband providers have never before been subject to under federal law.