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.^[1] 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.

Key Takeaways

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

2. While the FTC’s blog post focuses on security, its privacy mandate is equally important.

The FTC’s Section 5 authority reaches not only “unfair,” but also “deceptive” acts and practices. In the cybersecurity context, the FTC has brought numerous actions based on allegations that privacy policies, terms of use, and marketing statements misled consumers with respect to material claims about a company’s security measures. Indeed, the agency’s recent Start with Security  publication actually starts with privacy-related recommendations that form the foundation for sound security practices: “Don’t collect personal information that you don’t need”; “Hold on to information only as long as you have a legitimate business need”; “Don’t use personal information when it’s not necessary.” And, in an earlier blog post by the FTC concerning the agency’s investigative process for major data breaches, Assistant Director Mark Eichorn noted that the FTC will look at “privacy policies and any other promises the company has made to consumers about its security.” Thus, while security professionals may gain some comfort from the FTC’s support for the NIST Cybersecurity Framework as a useful tool for identifying and managing risk, in-house privacy and legal teams should ensure that data privacy compliance is not lost in the shuffle.

3. 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.^[2] 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. ^[3] 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).

Conclusion

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.

^[1] 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.

^[2] 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.”

^[3] 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 per­sonal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.”