The U.S. National Institute of Standards and Technology (NIST) recently released version 1.0 of the “Framework for Improving Critical Infrastructure Cybersecurity” (Framework). The Framework was developed in partnership with the private sector and provides a set of voluntary, risk-based measures that can be used by organizations to address cybersecurity risk. Already hailed as a useful resource by leaders in the private and public sectors, the Framework is likely to become an influential benchmark in all industries for assessing the reasonableness of an organization’s cybersecurity program. As such, it is also likely that the Framework will be referenced in regulatory proceedings, commercial and government contracts, and litigation filed following data security breaches. In this alert we summarize the Framework’s key elements and suggest practical strategies organizations can use to assess whether and how to use the Framework. 

Development of the Framework: On 12 February 2013, President Obama signed the Executive Order on Improving Critical Infrastructure Cybersecurity (EO) which, among other things, directed NIST to develop a cybersecurity Framework that would “help owners and operators of critical infrastructure identify, assess, and manage cyber risk,” while incorporating voluntary consensus standards and industry best practices. “Critical infrastructure” is defined extremely broadly in the EO 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.” 

In developing the Framework, NIST held multiple workshops, met with representatives from the private and public sectors, and received hundreds of public comments on the preliminary Framework it released in October 2013. The final Framework was announced by the president on 12 February 2014, and presented at a White House event headlined by the Secretaries of Homeland Security and Commerce and three CEOs. 

The Framework is meant to be a living document. NIST has labeled the Framework as “version 1.0” and will facilitate updates and improvements to it based on feedback from organizations. The agency plans to hold at least one workshop in the next six months that will provide stakeholders with the opportunity to comment on how the Framework works in practice. And NIST recently announced that it will hold a privacy workshop on 9-10 April focused on the advancement of “privacy engineering” as a way to develop standards and practices that can be used to address privacy issues, including the potential privacy impact of cybersecurity activities such as monitoring and information sharing.

Summary of the Framework: The Framework consists of three parts:

  • Framework Core: The heart of the Framework is the aptly named Core which lays out in tabular format a menu, organized by Functions, Categories, and Subcategories, of activities that can be expected to be found in a cybersecurity program. 

At its highest level the Core divides all cybersecurity activities into five defined “Functions”: Identify, Protect, Detect, Respond, and Recover. The Functions are meant to be “plain-language” ways to describe in broad strokes to everyone involved with an organization — from the board of directors to the workforce to investors — how the organization organizes its cybersecurity efforts.

For example, the “Identify” Function includes the Categories of activities an organization can undertake to assess its business environment and cybersecurity risk, and to prioritize and govern its risk management efforts. Included in the Identify Function are Categories of activities such as “Asset Management” (the work an organization does to identify all of the assets such as computer servers for which it is responsible) and “Risk Assessment” (the work an organization does to identify and prioritize overall cybersecurity risk). Categories are then divided into Subcategories that describe the outcomes of whatever technical, operational, or management activities the organization chooses to undertake. As an example, “Threats, both internal and external, are identified and documented” is the outcome detailed under one Subcategory of the Risk Assessment Category. Each Subcategory is mapped to “Informative References,” which consist of more detailed consensus-based standards, guidelines, and practices developed by groups such as NIST, International Organization for Standardization, and American National Standards Institute.

An important point to emphasize is that, similar to a menu, not all of the elements of the Core need be used by an organization that decides to use the Framework.

  • Framework implementation Tiers: The Tiers provide organizations with a tool to evaluate how they assess and manage cyber risks. Organizations can use the Tiers to describe the extent to which their cybersecurity programs reflect the standards set forth in the Framework. For example, Tier 1 reflects the use of “informal, reactive responses,” whereas Tier 4 reflects an “agile and risk-informed” program that is fully embedded throughout an organization. 

  • Framework Profile: Organizations can use the Framework to create a view of their current and goal states. An organization’s “Current Profile” is developed by identifying which elements of the Framework it is currently achieving, and its “Target Profile” includes the elements that the organization determines it desires to achieve (or, as described below, may be required to achieve by its customers or regulators). NIST intends that the Profiles be used to conduct self-assessments and facilitate intra- and inter-organizational communications.

An essential point to note when looking at the Framework is that it is not intended to replace existing practices or to establish prescriptive standards. Instead, the Framework provides a set of tools for organizations to evaluate their cybersecurity programs, determine whether those programs acceptably address cyber risk to critical assets and resources, identify areas for improvement, and develop roadmaps to meet desired goals. While NIST encourages organizations identified as Tier 1 to move toward higher Tiers, the Tiers should not be viewed as a metric for evaluating the maturity of cybersecurity programs. According to NIST, organizations should consider moving to higher Tiers “when such a change would reduce cybersecurity risk and be cost effective.”  Unlike the preliminary version, the final Framework does not include a separate appendix presenting a privacy methodology mapped to every cybersecurity function and category identified in the Framework Core. Instead, after recognizing that “not all activities in a cybersecurity program may give rise” to privacy considerations, NIST largely adopted an industry consensus alternative (originally put forward by Hogan Lovells) to the proposed privacy methodology. This alternative moves the cybersecurity-focused privacy guidance to the “How to Use” section of the Framework. The privacy methodology discusses the privacy concerns that could arise from cybersecurity activities and identifies certain policy and process measures and controls — all outcomes based — that organizations can incorporate into their cybersecurity programs to address those concerns. For example, if an organization employs monitoring of its networks and systems for cybersecurity purposes, the privacy methodology would suggest that it have a process in place to address the privacy implications of such activity. 

Likely impact of the Framework: The Framework has been designed to be flexible, technology-neutral, and operable outside the United States and across industry sectors. So, even though the Framework is designed initially for U.S. critical infrastructure, it can readily be applied to a wide range of organizations within the United States and around the globe. Although the Framework is voluntary, the administration is considering various proposals to incent its adoption by owners and operators of critical infrastructure. In August, the White House released a statement regarding the incentives proposals under consideration, including liability limitations, streamlining regulations, and fostering a competitive cyber insurance market. 

Once critical infrastructure organizations begin to use the Framework, they likely will expect their service providers to do the same. Those providers in turn likely will expect that the companies with which they do business will also use the Framework. As more and more organizations become familiar with and use the Framework, it would not be surprising to see the Framework’s language and approach used as a high-level benchmark for assessing organizations’ cybersecurity programs and practices, no matter the industry. Should that practice become common, the Framework may well become more than just a tool for assessing and developing cybersecurity programs for critical infrastructure; whether and how it is used may become an indicator of whether any organization’s cybersecurity program is reasonable for particular purposes.

Practical strategies: For organizations considering whether and how to use the Framework, the decision should not be viewed as solely the province of IT and security. Adopting the Framework involves significant governance, policy, and risk decisions that can affect an entire organization. Organizations would be wise to undertake a deliberate assessment of their goals and the Framework itself prior to making a decision to use it. Strategies such as the ones outlined below can help organizations thoughtfully consider whether, when, and how to use the Framework.

Involve the senior team. An ideal place for an organization to start is to form a multidisciplinary team that is familiar with the organization’s current approach to risk management, IT/IT security, data privacy, physical security, legal issues, supply chains, and vendor oversight. This team may already exist under the name of Enterprise Security Risk Committee, Information Security Risk Steering Committee, or something similar. If such a team does not exist, consideration of the Framework may provide the needed impetus for its formation. The existence of such a team is rapidly becoming an expected practice given the complexity and pervasiveness of cybersecurity risk, and organizations should consider assembling such teams regardless of whether they choose to adopt the Framework. The team should be composed of senior leaders who collaborate to prepare and guide the organization’s response to significant incidents and who help prioritize the investments and initiatives that manage security and data risk. The key question to ask when forming the senior team is, “Can this team reach to the most senior management of the organization to tee up issues, and can its leaders be called upon to brief the board of directors if necessary?”

Understand Framework requirements. An organization considering Framework adoption should ensure that it understands the Framework itself and what adopting it would entail. A first step would be to commission an initial assessment of how the organization’s approach to cybersecurity compares with the approach described in the Framework Core. Because the Framework contains nuanced language arrived at after much discussion among industry and government stakeholders and is packed with references to informative references and specific standards, an initial assessment may require specialized assistance. 

The senior team described above would ideally be briefed on the elements of the Framework, the outlook for its adoption and use in relevant markets, and an initial assessment of how the organization’s program compares to the Framework. Depending on the organization’s situation, the senior team may wish to commission a deeper dive to determine in more detail how much work the organization would need to do to align its current cybersecurity governance, policies, procedures, and programs with the Framework and other applicable benchmarks.

Prepare options for decision. The team supporting the organization’s decision making regarding Framework adoption should prepare a strategic analysis that outlines with supporting facts and insights the pros and cons for Framework adoption in the near or medium term. That assessment would include the outlook for regulatory actions, likelihood of market uptake, and legal compliance considerations. Those factors could be quite influential in the organization’s decision making. For example, if an organization’s major customers signal their intent to assess and select vendors based on their adoption of the Framework — perhaps even requiring its use — that may hasten an organization’s decision to align its security program with the Framework.

The assessments, plans, and analyses described above can be used in communications with and presentations to senior management and/or a board of directors to propose and secure agreement to proceed with appropriate actions and investments.

Plan for phases. For organizations of significant size, it is vital to understand the workload implicated by a shift to the Framework’s nomenclature and approach. Adopting the Framework in one fell swoop would be imprudent. Large organizations should plan to phase in the Framework in tandem with other operational changes and priorities (and hopefully not in response to artificial deadlines imposed by customers).

Ensure appropriate documentation. Adopting the Framework is not primarily a technology exercise. In the near term, most of the work associated with using the Framework likely will involve updating and revising the organization’s description and documentation of its approach to cybersecurity risk management and governance. That endeavor may include creating documents that compare the organization’s current activities to the comprehensive list of activities contained in the Framework Core’s categories and subcategories. Needless to say, such an exercise will almost certainly identify gaps. Those gaps should be acknowledged and examined, but it is prudent to provide guidance to the organization’s personnel as to how the analysis and findings should be documented and communicated. In many situations, it may be useful to label certain documents and conduct certain discussions under the attorney-client privilege. 

Adopting the Framework is likely to prompt the review and revision of certain policies and procedures, as well as the metrics and dashboards organizations use to report their progress to their senior management and boards. If changes are to be made to program language, policies, or other documentation, those changes may have legal consequences. Organizations should take care that adjustments to policies and practices are considered in light of past representations and commitments. This is especially true for those organizations that have experienced security incidents in the past. Consumer-facing statements about an organization’s approach to cybersecurity — and, more specifically, its use of the Framework — also should be drafted with care. Significant liability may result if those statements are later found to be deceptive under consumer protection laws. 

Documentation is important even for those organizations that appropriately choose not to implement some of the many activities listed in the Framework. An organization may, for example, decide that it has innovated or otherwise identified alternative methods for managing risk in a certain area. Or an organization may determine that its risk profile does not require the implementation of each and every listed activity. Although the Framework is designed to be flexible and used in such a manner, it may still be prudent for organizations to review and document their rationale for not adopting all or part of the Framework in the event that a future security incident calls into question the sufficiency of the organization’s efforts.

Understand regulatory compliance interplay. If an organization is already subject to data security or privacy regulations, it is important, from the start, to identify whether and how the Framework can complement and ideally support existing compliance programs. 

For example, under the Gramm-Leach-Bliley Act, federal banking agencies have issued Interagency Guidelines Establishing Information Security Standards (Security Guidelines), which require financial institutions to develop written information security programs with administrative, technical, and physical safeguards designed to ensure the security, confidentiality, and integrity of customer information. The Security Guidelines were supplemented by an Interagency Guidance on Response Programs for Unauthorized Access to Customer Information and Customer Notice (Response Guidance), which requires financial institutions to develop and implement response programs designed to address incidents of unauthorized access to customer information maintained by institutions or their service providers. Under the Security Guidelines and Response Guidance, financial institutions must implement a wide range of actions, many of which are mentioned in the Framework. 

Similar laws, regulations, and guidance exist and apply in sectors outside of financial services. It is therefore essential that organizations subject to security or privacy regulations form close partnerships between their security, compliance, and legal teams to address the interplay between those regulations and the Framework.

Address vendor and customer ecosystem. Depending on the industry, some organizations may find that their customers will soon start to ask questions about security practices that are derived from Framework. Some customers may go so far as to ask for representations via contract relating to Framework use or adoption. Organizations must anticipate those questions and requests, and plan for how to address them, especially in light of the significant and growing legal risk associated with breaches of security-related representations. 

In recognition of the significant risks posed by vendors that have access to the organization’s systems and data or that otherwise pose supply chain risk, organizations may also wish to review their vendor oversight programs. For example, organizations may wish to include new language in their vendor contracts or bid processes reflecting vendors’ use or adoption of the Framework (e.g., giving preference to vendors that agree to use the Framework).

Plan for privacy. Section 3.5 of the Framework describes how certain cybersecurity activities (e.g., systems monitoring or information sharing) may impact privacy. The Framework offers a “methodology” for organizations to use when addressing privacy in those contexts. The methodology is actually a list of process-based measures, such as “process is in place to conduct a privacy review of an organization’s anomalous activity detection and cybersecurity monitoring.” It would be prudent for all organizations, even those that do not use the Framework in its entirety, to review the methodology and confirm that they have implemented appropriate measures to address privacy that are consistent with, and hopefully part of, their overall privacy programs.

Conclusion: Organizations should take the time now to become familiar with the Framework and determine how to respond to its release. Customers and competitors will no doubt soon be considering their strategies for Framework implementation. Organizations that set aside the Framework for a later time may find themselves playing catch up in the market or being forced to make critical cybersecurity decisions on another entity’s time frame.