NIST Cybersecurity Framework, Beyond Version 1.0 – Part 3

In this series I take a close look at the Framework for Improving Critical Infrastructure Cybersecurity which NIST first published in February of 2014. Read Part One ‘All Infrastructure and the NIST Framework’ and Part Two ‘Hackers Are Not Afraid of Frameworks.’

There I was preparing part 3 of my close reading of the 2014 Framework for Improving Critical Infrastructure Cybersecurity from NIST and then I realized it was almost three years old. Soon, it will be under a new administration and version 1.1 is due for release anytime. So, if I intend to be ruled by the “current” in Security Current, I needed to wrap up my treatment of 1.0 quickly and make what follows more broadly relevant.  I must go beyond version 1.0.

What follows are some impressions of 1.0 that hopefully do just that.  The series will resume when 1.1 is released.

1. The Gaps

While analysts and engineers might agree that gaps are a measurement of the distance between what is and what should be, here I am defining a gap as both an expression of dissatisfaction and a recognition that assumptions are being made.  These are instructive.

As I’ve already discussed, 2014 Framework for Improving Critical Infrastructure Cybersecurity  is a bit murky.  It does not actually define what a framework is, for example and it relegates the description of what it terms its “Core” to an Appendix that is as long as the rest of the document .  It defines its “why” in the introduction and its “how” in the Framework Core (a well ordered and presented list of more or less familiar controls).

Then there is something in between the descriptions of the why (pages 1-7) and the how (18-35).

Placed squarely between the purpose of the NIST Cybersecurity Framework and the Framework Core are the components of the Framework that were designed to connect the why and the how.  These are the Framework Implementation Tiers and the Framework Profile, the schematics for achieving the Framework Core’s more specific objectives.  For lack of a more accurate description, the Tiers and the Profile are the “what.”

This is the murkiest part of the document.  Descending from the HIPAA Security Rule’s Flexibility of approach[1], this section at once tries to define how to approach evaluating and improving cybersecurity while allowing that even within a single organization, there is probably no single right answer.

It recommends at least two profiles (current and target) but allows that two is a minimum: “Given the complexity of many organizations, they may choose to have multiple profiles, aligned with particular components and recognizing their individual needs” (page 11).

That’s not to say that those 11 pages between 7 and 18 are not useful.  They are.  They are also striking in a number of ways.

2. The Tiers

The Tiers are most likely more familiar to most readers than the Profile as they resemble maturity levels from other frameworks such as COBIT.  And although the document is explicit that the Tiers are not maturity levels, it does not make clear why not and, for that matter, why bother making the distinction (there’s that murkiness).  The argument seems to be that using the Tiers as maturity levels would somehow weaken the concept of the organization’s Profile:

Tiers do not represent maturity levels. Progression to higher Tiers is encouraged when such a change would reduce cybersecurity risk and be cost effective. Successful implementation of the Framework is based upon achievement of the outcomes described in the organization’s Target Profile(s) and not upon Tier determination. (page 9)

In other words, basing a program on the Tiers might distract the organization from using the profile building methodology.  The profile building methodology emphasizes implementation.

Regardless of what we call them, the description of the tiers is striking because of what they are missing.  They do not allow for a zero.  Tier zero is literally missing.  That is, the Tiers do not allow that there are absolutely no information security controls protecting the Enterprise.  This is startling, but also highly accurate.

This lack of a tier zero is ground breaking.  It is a recognition that by 2014 security was sufficiently built into infrastructure, operating system and application product designs that having an environment with no controls is virtually impossible.   It challenges organizations to identify and control the procedures and technologies that must, even to some limited extent, be in place.

The four tiers that are defined follow a familiar path from tier one where controls are mostly out of control to tier four, a fully governed program that can adapt to a changing threat landscape and technology environment.

Another striking thing about the tiers is that they describe activities but only vaguely define who would perform them.  The “organization” is mentioned eight times as being the one to perform cybersecurity activities.  Management, personnel, staff and partners are all mentioned once as entities that perform some action.

This lack of definition of a staffing model or named roles within the organization ties back to NIST’s avoidance of a one size fits all approach.  It is only important to note that while the document gives us guidance on why, what and how, there is barely a hint of who will improve the cybersecurity of the nation’s infrastructure.

3. Profiles

The Framework allows organization’s the opportunity to reach a rather dramatic conclusion “An organization may find that it is already achieving the desired outcomes, thus managing cybersecurity commensurate with the known risk.” (page 13).  I discuss how dangerous this attitude is in The Winter of our Discontent.

To summarize it here: when you reduce cybersecurity to a checklist of controls and let what’s left be defined as “known risk”, you create a risk within the organization that the organization will become complacent, content with its own efforts.  NIST addresses this by proposing the concept of the current and target profiles.   Again, however, what’s missing is the “who.”

Who drives the organization to the target profile?  Who is charged with not allowing the target profile to get stale?  This is the role of the security professional and it is unfortunate that is not more clearly spelled out in the document.  To be fair to NIST, while the document is murky on this, NIST itself in the National Initiative for Cybersecurity Education (NICE) is certainly doing its part to address the “who.”

The consummate security professionals are not qualified because they may understand in detail why there is a DES encryption algorithm and a triple DES encryption algorithm but no double DES encryption algorithm, but because of a different quality altogether.   Call it their penchant for “dissatisfaction.” Security professionals are the most important actor in assuring the security program is up to the challenge of defending the organization.

4. People

The most overlooked component of a security framework is the professionals that implement and maintain it.

The Security professional protects the infrastructure and the data.  That’s the job.  And it doesn’t matter if we are looking at a Network Security Analyst whose tasks are narrowly focused or a CISO who is accountable for the entire Enterprise (“the Bitcoin stops here”).  Protect the data.  Protect the infrastructure.  Keep the secrets secret.  That’s the job.

And if there were certainty in delivering that service to the Enterprise, then the Security Professional could put their head down and get on with it.  But we can’t.  Our heads cannot be down.  They have to be “on a swivel” because in this world, we can modify the old adage and say that the only thing certain is death, taxes and cyber-attacks.

In other words, the job includes never being completely comfortable defining the limits of the job.    When they found this diversity of focus, the National Research Council’s Committee on Professionalizing the Nation’s Cybersecurity Workforce reached a few odd conclusions in their 2013 report, Professionalizing the Nation’s Cybersecurity Workforce? Criteria for Decision Making:

Conclusion 3. The cybersecurity workforce encompasses a variety of contexts, roles, and occupations and is too broad and diverse to be treated as a single occupation or profession. Whether and how to professionalize will vary according to role and context.

Conclusion 4. Because cybersecurity is not solely a technical endeavor, a wide range of backgrounds and skills will be needed in an effective national cybersecurity workforce.

In fact, the workforce should never be fully professionalized in the classic sense.  “Broad and diverse” is exactly what is needed in a security professional.