NIST CSF 2.0 – Fans of Governance Unite!

By now, you are probably aware of the recent announcement that the National Institute of Science and Technology (NIST) updated the Cybersecurity Framework (CSF) If not, consider yourself informed! Along with the framework itself, NIST published implementation examples, quick start guides, and provided a cross reference guide to other frameworks like the Center for Internet Security Top 20 controls and several others.

In order to sort out what is new and different with the NIST CSF 2.0, we’re going to start with the previous version. Version 1.1 organized a cybersecurity program’s controls into five Functions: Identify, Protect, Detect, Respond, and Recover. Contained within those Functions were Categories and Subcategories which organized cyber security controls into areas that aligned with each Function. In most cases, controls are grouped to one Function, but for a few others they are distributed throughout the framework. An example of a control spread out throughout the framework is Vulnerability Management which contains individual controls in Identify, Protect, Detect, and Respond Functions. This distribution makes some feel like the Framework is blind to the control family. Even with it’s warts, I like this framework because it is easy to communicate broadly with business leaders at a high level (i.e. a Protective control) as opposed to getting into the weeds and confusing my audience.

While comprehensive at it’s creation, the NIST CSF quickly became outdated as the cyber security industry changed in response to adversaries’ capabilities and new regulatory requirements. New concepts of threat intelligence, information sharing, threat hunting (and others) have emerged as effective methods for combating cyber adversaries. Additionally, CISOs expanded their responsibilities to manage a broader range of risks, including those brought by third parties, and enhanced the integration of cybersecurity controls within business applications.

There are some unintended drawbacks of the previous version of the CSF. Many organizations looked at Implementation Tier definitions and believed that lower-scored controls were the appropriate level of investment because their businesses were not “critical infrastructure” and continuous improvement (Tier 4) was overkill. This belief structure conflicts with evidence from the field (and common sense) that shows how organizations that learn from security incidents and near-misses tend to fare better than those who ignore lessons learned. I also believe that this belief structure stems from the disconnect between business risks and cyber security risks.

So how does the new framework differ from its ancestor? What is really new? While controls are still organized by Functions, there is a new Function, and it is the GOVERN function! Fans of Cyber Governance unite! We’ll dive into the Govern function a little bit later in this article so we can focus more broadly on the substantive changes to the framework. The framework hasn’t grown because it reduced the number of Categories (control families) from 23 to 22 and lowered the count of Subcategories (individual controls) from 108 to 106. While at the surface, it would appear that there weren’t significant changes to the guidance, NIST removed or combined a large number of Subcategories to provide room for 17 new Subcategories.

Subcategory	Subcategory Description	Notes
ID.AM-07	Inventories of data and corresponding metadata for designated data types are maintained	This is formally the first time that the NIST CSF identified data as an “asset”. Traditionally speaking, assets were servers or applications. This is a necessary but complex change.
ID.IM-01	Improvements are identified from evaluations	Prior versions of the NIST CSF (and many organizations) focused on documentation and consistency in processes as opposed to automation and continuous improvement.
PR.AA-04	Identity assertions are protected, conveyed, and verified	As many attacks focus on security assertions between systems, this is a welcome addition to highlight a well-used link in many attack chains.
PR.PS-05	Installation and execution of unauthorized software are prevented	Many security outcomes benefit from this control. While commonly viewed as a security consideration, I believe that this control manages a core IT supportability issue.
RS.MA-05	The criteria for initiating incident recovery are applied	While frameworks are generally not prescriptive, I would have preferred to see actual criteria identified in this case. Note: Criteria not provided in examples either.
RS.AN-07	Incident data and metadata are collected, and their integrity and provenance are preserved	This is a key component of not only being able to manage an incident properly, but is also of utmost importance during an after-action review or outside / independent investigation of an incident.
RS.AN-08	An incident’s magnitude is estimated and validated	I believe that the spirit of this particular Subcategory is that the organization has a process and technology available to look for similar indicators of compromise outside of systems identified as compromised in an incident. I would have rather seen “scope confirmed” in the control language.
RC.RP-03	The integrity of backups and other restoration assets is verified before using them for restoration	This is a key step that mature incident responders perform, and is a great call-out for organizations new to the NIST CSF to consider in their recovery procedures.
RC.RP-04	Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms	There appears to be some conflation between RC.RP-04 and RC.RP-02 in the examples. From my perspective the spirit of this control is to ensure that if compromised, organizational leadership considers and prioritizes restoration of cyber security risk management controls to ensure the clean recovery of the organization.
RC.RP-05	The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed	Many organizations look at the availability or restoration of services as the official closure of an incident, but the organization must ensure that the environment is actually clean and secure.
RC.RP-06	The end of incident recovery is declared based on criteria, and incident-related documentation is completed	This is a huge oversight during the majority of incidents, large and small. Incidents that are closed after a cursory review are prone to relapse, as those that do not document the contributing factors never holistically solve the root cause issues that led to the compromise in the first place.

While I am excited that we have a whole function dedicated to Governance and the NIST CSF diagram shows Govern as a layer across which all of the other Functions rely…the details of this Function tell a slightly different story. There is progress in this area, however I do believe that we could have jumped ahead and skipped the traditional “oversight” role, or at the very least introduced continuous improvement into the risk management Subcategories. Let me explain my mild disappointment with the new Function.

My disappointment mostly stems from how I have seen organizations respond to security requirements like the NIST CSF. Organizations can of course implement a higher standard and I’m hoping that many do, however experience tells me otherwise. Let’s take a topical look at the Govern function and see what’s new, what’s old, and what is exciting!

While the NIST CSF didn’t get married, this proverb / saying seemed to make the most sense when I thought about how the Govern Function came to be. Most of the Categories within the Govern Function were simply lifted out of other Functions with only 6 out of 31 Subcategories being “conceptually new”.

Let’s take a closer look at the “something new” 6 Subcategories:

Subcategory	Subcategory Description:	Notes
GV.RM-07	Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions	A recent emphasis in the industry has been to weigh security investments against the risks (measured in dollars) that are being managed. Another way to make the sale per se, is to leverage SWOT analysis to make the case for investments in cyber security.
GV.SC-03	Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes	This control is key because for many organizations, supplier/third party risk management programs operate in isolation of the broader vendor management program.
GV.RR-01*	Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving	The key to this particular Subcategory is that organizational leadership is accountable for cyber security risk. While the CISO should be the leader accountable for identifying key cyber risks to manage, the entire organization’s leadership plays a part in this process. This was how the most successful and smoothest running cyber security programs were operated and governed in my experience.
GV.OV-01*	Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction	The spirit of this Subcategory is to review the organization’s cybersecurity strategy development / communication / outcome processes to determine if it is enabling decision making and/or impacting business operations negatively.
GV.OV-02*	The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks	Strategically, present top risks during budgeting cycles and/or after emergent events and include options to manage those risks.
GV.OV-03*	Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed	Tactically, review key performance indicators and key risk indicators to determine if adjustments to deployed controls are necessary to improve the identification and management of cyber security risks in the organization.

Cyber Governance is a group of technologies, activities, and choices that achieve the following outcomes:
– Provide real-time telemetry regarding cyber security control coverage/effectiveness and the usage of organizational assets (data/applications/resources).
– Align security controls and asset usage to specific business risks and enable the organization to identify existing/evolving risk exposure and wargame what-if scenarios.
– Make informed decisions both at the tactical day-to-day operational level, during emergent scenarios, and at enterprise strategic planning events.
Source: Cybergovernance.net

Successful Cyber Governance in my mind occurs when senior leaders continuously adjust risk management programs to counter new and emerging risk patterns and look forward to the horizon and anticipate the future risk universe. With this update, the most substantial Cyber Governance improvements to the framework are easily the four Subcategories identified above by the asterisk. Make sure that in your Cyber Governance programs you are leveraging and maximizing these Subcategories to make informed choices intended to manage risk and not simply say “we got this*” to back your way into justifying that you meet the spirit of this framework.

What NIST CSF Functions, Categories and/or Subcategories do you want us to explore deeper? Is there specific guidance that would be helpful for you to begin the transition to the NIST CSF 2.0? What did you learn? What do you think? Share, Comment, Like Below!