Deciphering the Cybersecurity Framework

Reading the National Institute of Standards and Technology’s “Framework for Improving Critical Infrastructure Cybersecurity” is like being trapped in a nonstop risk management meeting. Within the Framework, organizations “dynamically select” improvements, functions “align with existing methodologies for incident management,” and “interdependent stakeholders” are “engaged.”

Published in response to President Obama’s Executive Order 13636, which called for the development of industry standards and best practices to help companies manage cyber risk, the Framework provides recommendations for improving network security and responding to cyber threats.

To read the framework, see: http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf

Yet the Framework couches its suggestions in dense risk management speak that makes concepts appear more complicated than they actually are. The Framework’s reliance on buzzwords undermines its primary purpose – to develop a common language that allows all corporate personnel to get more involved in addressing data security.

Despite the document’s flaws, businesses will use it as a resource. And if commentary is to be believed, companies can’t ignore the Framework’s suggestions. Though designed for critical infrastructure sectors, many data security experts believe that the Framework will be the key factor in establishing best practices in almost all industries.

This includes insurers. Like all businesses, insurance companies should have safeguards in place to minimize the risk of data loss. Underwriters could use the Framework’s concepts when evaluating a company for cyber insurance policies. For claims professionals, the Framework provides tools for determining whether an insured took reasonable steps to maintain data security or to mitigate losses after a data breach.

Because we are going to have to live with the Framework, it pays to get to know the document a little better. For those not well versed in “cyber” or “risk management” speak, this process is not easy.

The Framework has three parts: the Core, the Implementation Tiers, and the Profile. The Framework’s drafters repeatedly emphasize that these components are interrelated, with each part reinforcing the other. Yet precisely how the different parts are supposed to interact is not always clear.

The Framework is supposed to be “living document” that evolves over time. Nothing is static – a company’s infrastructure must be flexible enough to adapt to changed circumstances and threats. A company never reaches a cyber plateau where it can rest on its laurels, but must “concurrently” and “continuously” apply a variety of mechanisms to mitigate risk.

The Core is a process to identify weaknesses in computer systems and networks and respond to data breaches. Consistent with the theme that the Framework is a living document, the Core is not a one-size-fits-all process. Methodologies may vary depending upon the particular industry, a company’s sophistication, and evolving cyber threats.

The Core consists of five “Functions”: Identify, Protect, Detect, Respond and Recover. Broadly speaking, the Identify function refers to the process by which a company develops an understanding of its systems; Protect, the implementation of safeguards; Detect, mechanisms for recognizing data breaches; Respond, action plans for responding to data breaches; and Recover, procedures for restoring systems to normal operations.

The Functions are broken down into different “Categories.” The Categories vary for each Function – thus, Identify includes such Categories as “Asset Management” and “Risk Assessment,” while Protect includes “Access Control” and “Data Security.” Within each Category, there are “Subcategories” comprising specific tasks, such as “Asset vulnerabilities are identified and documented” and “Threats, both internal and external, are identified and documented.”

The Framework provides “Informative References” corresponding to each subcategory. These references cite specific sections of various industry guidelines that might help businesses achieve the goals associated with the subcategory.

The Framework assigns “Category Unique Identifiers” to individual categories and subcategories. Thus, an astute practitioner of the Framework would understand that “PR.AT-2” refers to Protect (Function), Awareness and Training (Category), Subcategory 2: “Privileged users understand roles & responsibilities.” Expect terms like the “Function Core” and “PR.AT-2” to find their way into IT and risk management reports.

The Core steps provide a roadmap for identifying weaknesses. But, as always, the Framework’s recommendations come with caveats about the need for flexibility. Companies should not apply the Core mechanistically from Step A to Step Z with the goal of reaching a “static desired end state.” Certain steps, such as testing a system for vulnerabilities, should always be taking place. And companies should never get complacent but continuously review procedures to improve safeguards and address new threats.

The “Implementation Tiers” represent different sophistication levels with respect to cyber risks. The Framework identifies four levels: Partial, Risk Informed, Repeatable, and Adaptive.

Companies in the Partial tier have “limited awareness” of cyber risks and lack formalized procedures for addressing this risk. Risk Informed organizations have an awareness of risks but have not established formalized, organization-wide approaches to address cyber issues. Companies at the Repeatable level apply organization-wide approaches, regularly update their practices, and have “consistent methods” for responding to changes in risk.

As the name suggests, Adaptive companies “actively adapt” through a “process of continuous improvement incorporating advanced cybersecurity technologies and practices.” Cybersecurity is part of the organizational culture. These companies “actively share information” and have “continuous awareness of activities on their systems.

Those who have taken multiple choice tests immediately recognize the right answer: be Adaptive. But the Framework’s drafters suggest that there are no correct answers. Achieving any tier is fine. A company may select the “desired” tier based on that entity’s objectives and constraints.

The Framework should drop the pretence that it would be acceptable for companies to aspire for Tier 1 or Tier 2. After all, the Framework is designed for the nation’s “critical infrastructure” sectors. While Tier 3 may be passable, all companies within these important sectors should desire to be Adaptive.

More importantly, the Framework never explains how the tier selection process fits into overall strategies for managing cyber risks. There is no discussion about how this ranking system helps companies implement “Core” programs or develop cybersecurity “Profiles.”

The Implementation Tier ranking reflects a general assessment of organizational culture with respect to security. By contrast, constructing a Framework Profile requires detailed study of a company’s systems and procedures to identify specific weaknesses.

This process involves not one but two profiles: a Current Profile and a Target Profile. An organization reviews the categories and subcategories in the “Framework Core” to identify important procedures and safeguards applicable to that company. The company then studies its systems to assess its compliance with each category’s and subcategory’s requirements.

After generating a Current Profile, the company creates a “Target Profile” that addresses gaps and weaknesses in the company’s systems. The company then develops a plan to close those gaps.

The “Profile” concept is flexible. Companies might devise unique categories and subcategories. An entity also might use multiple profiles since different systems could require different protection levels.

The National Institute of Standards and Technology apparently intends the Framework to provide a common language for understanding and managing cyber risks. The document falls short of this goal. Although risk managers and technology professionals might appreciate the Framework’s terminology, those outside these narrow spheres probably won’t.

Business surveys show that senior executives don’t understand cyber risks and rarely make decisions involving data security. As a result, many companies do not make security a priority. This attitude will continue as long as proponents talk about data security in terms of “implementation scenarios.”

Travis Wall is an attorney at the California office of Barger & Wolen.