Hoover Dam, a piece of critical infrastructure (though not in private hands ;-))

A Look at NIST’s Preliminary Cybersecurity Framework

Yet Another Security Standard?

The National Institute of Standards and Technology (NIST) recently released an official draft of its Cybersecurity Framework for America’s critical infrastructure, i.e. the infrastructure that contributes to keeping the US and its economy running. Think power generation and distribution, transportation, communication networks, …

The framework is a direct result of President Obama’s Executive Order 13636, which stipulates:

The Cybersecurity Framework shall include a set of standards, methodologies, procedures, and processes that align policy, business, and technological approaches to address cyber risks.

On a high level, the Cybersecurity Framework (CSF) defines five functions for an organization’s security management: Identify, Protect, Detect, Respond, and Recover. It then specifies a number of controls for organizations to consider, organized into categories and subcategories, with cross-references to existing best practice standards. And it lines out different maturity “tiers” for information security management systems.

Other standards exist that have similar aims, and have been readily available to the private industry. Notably, ISO/IEC 27001 specifies a fairly comprehensive set of security requirements and guidelines and has been around for almost a decade. COBIT also comes in an information security (pardon me, cybersecurity) flavor. And there are more. They share in common that — to date — they are used mostly (and if at all) by organizations who have the dedication, resources, and maturity to run a sophisticated security operation.

Like ISO/IEC 27001 and COBIT, and unlike a compliance standard like the PCI Data Security Standard, NIST’s Cybersecurity Framework provides a set of guidance references that is designed to give an organization freedom to implement specific controls in a way that meets that organization’s risk exposure and business environment. So what is the difference between the framework and existing standards?

Focus on Critical Infrastructure

While born out of a specific initiative to better protect the critical infrastructure in the US, the CSF is largely (and thankfully) industry-agnostic. There are obviously references to industrial control systems in the framework, and a few of the recommended control “subcategories” address particular needs of the critical infrastructure sectors. But overall, the framework presented can serve organizations in sectors other than the critical infrastructure ones as a useful guide as well.

Privacy Emphasis

Thanks to the executive order spelling this need out explicitly, the Cybersecurity Framework contains an appendix with privacy considerations related to the individual categories that the framework defines for security management. Given that a lot of utilities process large numbers of private information in order to bill their customers for their services and vet their creditworthiness, and also just in general, this is a good idea. I wonder why it wasn’t possible to simply integrate these with the overall set of controls, though.

Executive Focus and Maturity Levels

The CSF makes an effort to provide practical guidance to organizations on governance for their cybersecurity efforts, and on how to communicate risks to executive management. Given that a fair number of the targeted organizations are probably lacking in that area or are likely not to have very mature security organizations and pretty much starting from scratch, that’s useful.

Figure 3 from NIST’s Preliminary Cybersecurity Framework

The framework also defines maturity levels, referred to as “Framework Implementation Tiers”, in an effort to give organizations a (very) basic understanding of where they are and where they might want to be with their security management efforts. Something to compare each other to, if you will.

Emphasis on External Cooperation

Both the implementation tiers and some of the functional categories underscore the need to not only understand an organization’s dependencies on external third parties, but to actively communicate with “partners” and share information about risks and concrete events that might be threatening the industry.

The need for this kind of (threat) information sharing is also stressed in the executive order. It’s good to put emphasis on it, but I am curious to see how successful this will be. While it certainly increases the resilience the individual organizations participating in the sharing of security intelligence and as a result of the whole industry, it’s not necessarily a given between industry peers (though not unheard of) to share this or any other kind of information. Not just for competitive, but also for liability reasons.

Conclusions

It certainly seems that NIST has had a decent amount of participation and input from various stakeholders in defining the CSF. In my opinion, the document needs some work on making its language consistent, is a bit rough on maintaining a uniform level of detail when it comes to defining its “cybersecurity activities”, etc. — things that are acceptable in a draft.

I am, however, not at all convinced that re-inventing definitions of security controls instead of simply integrating perfectly adequate existing ones by reference (like those from ISO/IEC 27001 and 27002) is the most efficient use of resources. I don’t see an improvement in the newly defined controls or framework language that would make it easier for the targeted consumers to understand what they are supposed to do, compared to existing standards.

In fact, when I was searching the web for additional cross-references between the preliminary framework’s controls and existing standards, I ran into an alternate proposal by Phil Agcaoili that does exactly this: integrate existing standards by reference. Which seems to make more sense to me.

Regardless: Like any other standard attempting to provide a comprehensive list of best practice controls, the CSF relies on an organization’s risk management processes to prioritize the pre-defined controls and identify additional ones that might be organization-specific. (Agcaoili’s framework proposal goes further here than NIST’s, too, providing some prioritization guidance based on breach surveys, and concrete examples on how to visualize risk.)

But having (yet another) framework available that identifies best practice controls or not, managing risk and an information security organization still requires effort and expertise. The framework might make it easier for smaller organizations to get started on this, but it can’t deliver a ready-to-operate system. For larger organizations and the industry in general, it might serve as a common-language-tool to communicate requirements on suppliers or industry sectors, and report on the own state of information security management.

The Cybersecurity Framework is part of a larger initiative to motivate the private industry that operates critical infrastructure in the US to enhance their security posture, both individually and in cooperation with peers, government agencies, and industry-specific interest groups. I predict that in the end, and regardless of its final form, whether the framework will be a success or not will depend largely on the incentives that the government (or natural selection) can come up with to motivate organizations to implement it.


David Ochel is an information security management consultant based out of Austin, Texas (Secuilibrium, LLC).