Being an InfoSec Professional / Cybersecurity

The other shoe drops: NIST issues version 1.0 of the Framework for Improving Critical Infrastructure Cybersecurity

It’s ironic that the new publication from NIST does not have an 800 series numeric designation.   Not that it needs to, but here we all are using those numbers as shorthand (e.g., “I took an 800-30 July 2002 approach because revision 1 from 2012 just seemed too complex for the environment”, “We are looking to use the 800-63-1 levels for authentication” etc.).    Then this comes along.

And what is this really?  Is it merely the companion to the earlier Executive Order on Cybersecurity or is it something more?  If the former, then it is a political document.  Perhaps it is just the other shoe dropping, pairing with the Executive Order to represent some government issued loafers with nothing much to them.  Maybe it asks nothing more than that we change our nomenclature.  NIST claims “The resulting Framework…uses a common language to address and manage cybersecurity risk.” (p. 1) But it might be more than that.  To figure that out takes analyzing the document itself.

What we are seeing in this document is NIST attempting to be the focal point of a good deal of thinking and standards that have preceded this effort.    ISO, ISA, COBIT, NIST (those 800 series special publications), all get mentions in the detailed sub-categories that form a large part of the document.  Those mentions are the external demonstration of the effort to define “best practice”.  They appear to be both a good cross-section of control standards and a good cross-walk.  But there’s something else going on here that is worth noting.

First of all, NIST wants us to look beyond a static data-centric view.  Security has always been process oriented to some extent but as the metaphors of keeping data locked away have become weaker (I go into that in my post about change management– click here), the language of security has not always kept up.  For example, HIPAA continues to be refined, but the language for protecting EPHI (Electronic Protected Health Information) remains the nine box grid: Physical, Administrative and Technical safeguards  to protect the Confidentiality, Integrity and Availability of the data (three attributes, three types of safeguards=nine combinations).

NIST wants us to get functional in our thinking.  We are asked to go from intransitive to transitive verbs.  From “Encryption is a technical safeguard” to the functional “the Enterprise protects the data”.  It is only when you get down to the sub-category (PR.DS-1) that you find the static “Data-at-rest is protected” (p. 25).  The functions are not revolutionary: Identify, Protect, Detect, Respond, Recover.  But they avoid settling for lists and that is a good thing.

It has always been easy and tempting to confuse risk analysis with a true Cybersecurity framework.  After all, if I identify my risks and controls then aren’t I protecting my environment?  If I dump the controls into categories, that’s a framework, right?  The document provides us with a way to clearly distinguish between a risk analysis/control cataloguing and a framework for cybersecurity.  Compare the 7 steps outlined on page 14 for “Establishing or Improving a Cybersecurity Program” with the 9 steps in the July 2002 special publication on risk management (yes, 800-30), or even the Risk Management Framework steps in the 800-30 2012 revision.

Step 800-30 7/2002 800-30 rev 1 2012 Cybersecurity Framework


System Characterization Categorize Prioritize and Scope


Threat Identification Select Orient


Vulnerability Identification Implement Create a Current Profile


Control Analysis Assess Conduct a Risk Assessment


Likelihood Determination Authorize Create a Target Profile


Impact Analysis Monitor Determine, Analyze and Prioritize Gaps


Risk Determination Implement Action Plan


Control Recommendation


Results Documentation

Notice how the older 800-30 requires creating a lot of lists (systems, threats, vulnerabilities, controls) and the 2012 revision moves away from lists, and tries to focus on management tasks.  The 2012 revision is a more action orientated approach but is still primarily reactive.

The Framework allows for business decisions regarding the actual design of the control environment.  This distinction is more than just the difference between what 800-30 is trying to do (define the Risk Management/Analysis process) and what the Framework is trying to do.  This reflects the maturing of the world of Cybersecurity.

Look at the Tier definitions on page 10.  The Tiers are clearly influenced by documents like the COBIT 4 Maturity Model for Internal Controls (compare how they both use the phrase “ad hoc” for example).   There are two things that stand out, however, when you compare the COBIT table with the Framework’s Tiers.   COBIT’s top level is number 5, “Optimised”.  The description of that level makes it clear that it does include on-going self-assessment, but it also assures you that when you reach that level your program provides “continuous and effective control and risk issues resolution”.   In other words, it lets you take a deep breath and take credit for a job well done.  The Framework’s top Tier puts the emphasis not on how well you have controlled things, but on the reality that the job is never finished.  The Framework’s top Tier is appropriately named “Adaptive”.  You haven’t arrived, you’ve just structured your work better than before.

How much has the world of IT Control and Cybersecurity matured?  The COBIT maturity model I am referencing above (copyright 2007) has 5 levels.  NIST’s Cybersecurity Framework has 4.   The two do not match up exactly anyway, but all you need to know about how the world has evolved/matured can be summed up in the level that COBIT has and NIST has left out.  For NIST this level is essentially unimaginable: “Maturity Level 0: Non-existent.  There is no recognition of the need for internal control.”  The NIST Framework for Improving Critical Infrastructure Cybersecurity cannot and will not allow such a Tier.

We had the Executive Order of 2013 and now we have the Framework of 2014.  I like the pair.  Together they are supposed to move relevant industries to a sufficiently security aware state that these industries can serve as components of the Infrastructure.  The other shoe has indeed dropped.  And to take a phrase from the restaurant industry and use it as a statement of risk: no shoes, no service.

One thought on “The other shoe drops: NIST issues version 1.0 of the Framework for Improving Critical Infrastructure Cybersecurity

  1. Pingback: Bookish Security | {Cyber Security}

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.