With the thicket of 47 often conflicting state data breach notification laws and the the Federal Trade Commission’s independent efforts to regulate cyber security (which is a hot topic, but one that is outside the scope of this post), businesses of all sizes and in all industries are looking for a cyber security standard that can be adopted as a best practice.
While there is no one legal standard to apply in the United States (yet), the NIST Cybersecurity Framework comes close. “NIST” stands for the National Institute of Standards and Technology, and on February 12, 2014 (in response to the President’s Executive Order 13636, signed a year earlier on February 12, 2013) NIST released its Cybersecurity Framework, which can be found here:
The Framework was the result of a long and interactive collaboration with the private sector, giving it the cache of significant private-sector input (rather than being a cyber security edict handed down from on high). Partially because of this, the NIST Framework has steadily gained traction in the private sector, becoming a de facto national cyber security standard in some areas, and finding wide acceptance in others.
In this multi-part blog series, we will explore the NIST Framework, breaking down some of the barriers to implementation of the Framework, and demystifying the entire Framework implementation process. Although initially intended for “critical infrastructure,” as defined in E.O. 13636, entities of all sizes and complexity should consider implementing the NIST Framework in some fashion (or make an educated decision that the NIST Framework is not a good fit).
In this post, we will deal with E.O. 13636 and the origins of the NIST Framework.
E.O. 13636 directed NIST “to lead the development of a framework to reduce cyber risks to critical infrastructure.” In turn, the E.O. defined “critical infrastructure” as: “systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.”
After a year’s worth of consultation with the private sector, the NIST Framework was born and it immediately garnered attention, undoubtedly because of the dearth of substantive cyber security guidance that was available to businesses up until that point. Just months after the NIST Framework was released, in June of 2014, then current SEC Commissioner Louis Aguilar presented at a cyber security conference, referring to the Framework as a “conceptual roadmap” that publicly traded boards should consider and hinted that the Framework may soon become the “baseline for best practices by companies, including in assessing legal or regulatory exposure to these issues or for insurance purposes.”
Commissioner Aguilar’s statements in this regard can be found here:
What NIST is:
“The Framework is a risk-based approach to managing cybersecurity risk,” and a voluntary one at that.
What NIST is not:
As mentioned just above, the NIST Framework is, at its core, a tool for management of cyber risk. It is not a set of positive controls or security standards that a company can use to show compliance with any specific cyber security requirement. It is also not a safe harbor. Just because a company is implementing the NIST Framework, that does not protect the company from regulatory action or potential liability arising from a data breach. As of the posting of this entry, no reported case in the United States addresses the impact of the NIST Framework on a company’s potential liability arising from, for example, a data breach, but - - given its widespread and growing adoption - it is likely inevitable that the NIST Framework will be used at some point to show that a company engaged (or failed to engage) in due care in relation to cyber security.
Because the NIST Framework is a process (sometimes referred to as a “feedback loop”), there is no such thing as being NIST Framework “compliant.” The NIST Framework, rather, consists of a series of implementation “Tiers” that a company passes through as it seeks to raise its level of cyber security maturity. In the coming posts, we will address these implementation “Tiers,” after first addressing the core implementation steps in the Framework, called the “Framework Core.”