By Kimberly Peretti and Lou Dennig, Alston & Bird LLP
On October 22, 2013, the US National Institute of Standards and Technology (NIST) released its Preliminary Cybersecurity Framework ("Framework"), marking one of the final steps in creating the "voluntary" Framework envisioned in an Obama Administration Executive Order (EO) issued earlier this year. The final Framework is expected to be released in February of 2014. This Top Ten will provide an overview of the purpose, development, structure and implications of the Framework.
1. The Framework's Purpose and Goal
The EO was designed to strengthen the cybersecurity of the United States' critical infrastructure, which includes vital assets such as communications, critical manufacturing, emergency services, energy and financial services. As part of that effort, NIST was tasked with developing a voluntary Framework that would identify beneficial cybersecurity practices and create a common language for discussing those practices. The goal of the Framework is to make current cybersecurity best practices the common and expected practices of critical infrastructure entities.
2. The Development Process Involved Significant Private Sector Input
In developing the Framework, NIST engaged with over 3,000 individuals and organizations to identify and discuss current cybersecurity standards, best practices and guidelines. Shortly after the EO was announced, NIST issued a Request for Information (RFI) that resulted in over 200 responses, many of which were comprehensive reports. NIST also hosted a series of five workshops throughout the country to engage with stakeholders on creating the Framework. Each workshop took place after NIST completed an important step in creating the Framework, such as releasing its analysis of RFI responses, which allowed for a continuous dialogue with industry practitioners. Initial private sector reaction to the Framework has lauded the process for engaging relevant stakeholders.
3. At Its Core, the Framework Organizes Cybersecurity Activities to Create a Common Language
The Framework is made up of three primary parts, the most important of which is the Framework Core. The Framework Core is a roadmap that allows entities across a wide-range of industries to organize cybersecurity activities (e.g., implementing a data breach response plan or protecting network integrity) into distinctly defined Subcategories. Cybersecurity activities are first split into five high-level "Functions": Identify, Protect, Detect, Respond and Recover. Within each Function, cybersecurity activities are split into Categories, such as "Awareness and Training," and are further differentiated into Subcategories, such as "Third-party stakeholders understand roles & responsibilities." Each cybersecurity activity equates to a single Subcategory. In doing so, the Framework Core allows for easy reference to any given cybersecurity activity, thus creating a common language that allows for better communication on cybersecurity practices both among industry participants and with the government.
4. The Framework Identifies Existing Standards as Cybersecurity Benchmarks
Potentially the most important aspect of the Framework Core is that each Subcategory is tied to an Informative Reference, which provides a current industry best practice for a given cybersecurity activity. The Informative References do not create any new standards; instead, they refer to one of the following five existing standards: Council on CyberSecurity Critical Security Controls (CCS CSC), Control Objectives for Information and Related Technology (COBIT), International Society of Automation (ISA) 99.02.01, International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27001 and various NIST Special Publications (SP). By identifying a current best practice for each cybersecurity activity, the Framework allows organizations to determine whether their own cybersecurity practices are meeting, exceeding or falling below those standards.
5. The Framework Provides Tools for Organizations to Improve Internal Practices
The other two primary parts of the Framework are the Framework Profile and Implementation Tiers. Organizations are first tasked with creating a "Current Profile" that identifies how that organization's current practices measure up to industry best practices in each Subcategory. Entities are then to conduct a risk assessment that analyzes the likelihood they will be the target of a cyber attack, and the impact such an attack would have on the organization. Based on that risk assessment, the entities are to create a "Target Profile" outlining an aspirational cybersecurity posture. The Framework's Implementation Tiers describe four levels of increasingly sophisticated cybersecurity risk management practices. Organizations are expected to identify their current Tier, as well as a desired Tier based on what is feasible and cost-effective. Using the Framework Profile and Implementation Tiers, organizations can better determine what resources should be devoted to enacting industry best practices to achieve the "Target Profile."
6. In Practice, Framework Adoption May Be Mandatory
Part of the EO orders the Secretary of Homeland Security and sector-specific agencies to establish a voluntary "Program" to support Framework adoption. As part of the Program, sector-specific agencies must provide an annual report to the President stating the extent to which critical infrastructure organizations are participating in the Program. To do so, those agencies will need to make inquiries to private sector organizations regarding the degree to which they have adopted the Framework. Entities receiving such inquiries may find it difficult to view Framework adoption as a truly voluntary decision because responses indicating little or no Framework adoption may prompt additional, unwanted interest from the regulator.
The Program also includes incentives for organizations to adopt the Framework, some of which may be so compelling that entities have no real option but to adopt the Framework. One proposed incentive is to make Framework adoption either a prerequisite or weighted criteria to receive critical infrastructure grants, which may compel compliance with certain requirements. Other incentives, including access to a cybersecurity insurance market and reduced tort liability, could similarly make the costs of not adopting the Framework too high. The matter of incentives continues to be discussed by the Administration.
7. Insufficient Framework Adoption May Lead to Additional Regulation
Another factor influencing critical infrastructure organizations to adopt the Framework is the specter of added regulation. In addition to the adoption Program, the EO tasks sector-specific agencies with analyzing the Framework to determine whether the existing regulatory requirements provide sufficient protection from cybersecurity risks. Those agencies must determine whether they have the authority to establish any necessary additional regulatory requirements, or if legislative action is needed to empower those agencies to enact such regulations. The EO thus indicates that if Framework adoption is not widespread enough to adequately protect critical infrastructure from cybersecurity risks, additional regulation may be necessary. Compared to added regulation, entities may view Framework adoption as the more palatable option.
8. The Framework May Create Mandatory Privacy Standards for PII Collection and Maintenance Practices
As directed by the EO, the Framework includes a methodology to protect individual privacy and civil liberties. That methodology is included in an appendix to the Framework ("Privacy Appendix") and based on well-recognized principles known as the Fair Information Practice Principles (FIPPs). The FIPPs are at the core of the Privacy Law of 1974, which governs federal agencies' information collection and maintenance practices related to personally identifiable information (PII). A variation of the FIPPs also forms the basis of the practices the Federal Trade Commission recommends private sector entities use in developing their own PII data collection practices, particularly with respect to certain online activities. The Privacy Appendix organizes privacy and civil liberty practices in the same way the Framework Core organizes cybersecurity activities, thereby providing a methodology for how entities should deal with issues related to collecting and maintaining PII. This Privacy Appendix could potentially build an added privacy layer into the Framework, transforming what are otherwise recommended privacy practices for the private sector into requirements.
9. Framework Adoption Will Likely Extend to Critical Infrastructure Partners and Non-Critical Infrastructure Businesses
Framework adoption may end up being as compulsory for critical infrastructure contractors, partners and service providers as it is for the critical infrastructure industry itself. As an initial matter, if sector-specific agencies ask critical infrastructure entities to provide information on their level of Framework adoption, those entities will make similar inquiries to their service providers and contractors. Only if critical infrastructure partners' cybersecurity practices are Framework "compliant" can the entity itself feel so compliant. Businesses hoping to maintain relationships with critical infrastructure organizations may view Framework adoption as an added requirement of those relationships.
The natural extension of critical infrastructure industries and their contractors, partners and service providers adopting the Framework is that those entities' non-critical infrastructure business partners will also feel compelled to adopt the Framework. Those non-critical infrastructure entities hoping to strategically position themselves to win contracts may feel that Framework adoption is a virtual prerequisite to working with critical infrastructure companies. Though Framework adoption is meant to be voluntary, even for critical infrastructure, it is easy to see the ripple effect the Framework may have of expanding outward to many organizations.
10. The Framework Could Create a De Facto Cybersecurity Standard (and Standard of Care for Liability)
The Framework could become the standard by which an organization's cybersecurity practices are measured in one of two ways; first, the Framework could become such a standard if an entity adopts the Framework. Second, the Framework could be looked to as the de facto cybersecurity standard because it was developed by the government while working closely with the private sector, which gives the industry best practices identified in the Framework the weight of legitimacy. If the Framework is widely adopted, it is more likely to be viewed as the de facto standard of what constitutes "reasonable security." While having a cybersecurity standard in place for purposes of legal liability is beneficial by creating certainty for organizations hoping to protect themselves from such liability, it also holds organizations to a standard they may not be able, or wish, to meet based on the costs of adopting the Framework.
Critical infrastructure organizations and entities that have business relationships with those organizations should closely monitor the creation of the final Framework, as it is likely to be a key component of cybersecurity discussions and practices for the foreseeable future.
