Introduction

The National Institute of Standards and Technology (NIST) recently released Cybersecurity Framework (CSF) 2.0, updating one of the most popular risk management frameworks used by both government and private organizations. The newest iteration marks a significant improvement from the previous 1.1 version, aiming to enhance clarity, organization, and overall applicability for the broad range of organizations that have adopted the CSF.

But what’s practically different between the previous 1.1 version and the new 2.0? A whole lot changes, yet the core principles remain the same.

Read on for details.

TL;DR:

• NIST CSF 2.0 is a solid evolution of 1.1, with enhanced clarity, organization, and focus on core principles.
• While core content remains similar, changes are substantial enough that a line-by-line comparison doesn’t make sense.
• Adopting CSF 2.0 shouldn’t require you to change anything material in your day-to-day operations, it primarily involves updating assessments and attributions.
• Notably, CSF 2.0 adds a “Govern” function focused on enterprise strategy, policies, risk tolerance and management. It blends new material with re-classified Identify categories.
• “Protect” and “Detect” see similar content to 1.1, but much improved organization and abstraction of subcategories.
• Respond & Recover see a significant overhaul, being less “hand-wavy” than 1.1 and focusing on practical response and recovery activities over documentation.
• References to other frameworks and implementation details are missing from the core document, but a companion with practical Implementation Examples, is available.

Below, I won’t cover things like Framework Profiles and Implementation Tiers, for though they receive a graphical face-lift in version 2.0 of the CSF, they are not materially changed from a content perspective.

Changes in more detail:

It’s all about Governance!

The most obvious change in the latest CSF is the creation of a 6th top-level Function: Govern. Previously scattered across other Functions, “Govern” emphasizes the critical role of business leadership and strategic risk management in cybersecurity. This function highlights the importance of defining security strategy, risk appetite, establishing policies, and creating a risk management program – all elements that tie security efforts to overall business objectives.

The new circular lifecycle diagram from the framework doc sums it up best – Govern sits at the core of the framework and is the glue that holds the five other functions together. While subtle, the wording of the framework and use of visuals like the one above highlight a new focus on thinking of security risk management as an ongoing process, and less of a one-time exercise.

Adding Abstraction – good for clarity and broadening applicability, bad for “security noobs”

A common change across functions is the use of more abstract terms to consolidate subcategory specifics. For example, in framework 1.1, the Awareness and Training Category of the Protect function (PR.AT) was very specific, with subcategory requirements for each of a number of specific roles – users, privileged users, executives, security personnel etc. In framework 2.0, this is all condensed to 2 simple categories – one covering “personnel” generally, and another covering “individuals in specialized roles” (which would conceptually include things like privileged access users, executives, etc.).

This is a common pattern in CSF 2.0 – consolidating specific lists of inventory or services (applications, hardware, etc.) into “catch-all” terms like “assets”. This makes the framework more timeless and universal, but also requires a little more thought on implementation or assessment to translate the abstract terms into something more concretely implementable. It is less approachable to someone not already versed in core information security principles and best practices.

GRC assessment wonks rejoice, you’ve just gained a little extra job security.

Other key changes: Category Revisions

A number of key categories from framework 1.1 are revised in 2.0.

Identity – Streamlined and focused (mostly)

With the creation of “Govern“, much of the content previously in “Identify” (and oddly out of place there…) finds a new home, leading to a more compact and targeted “Identify” in CSF 2.0.

• Identify’s Asset Management and Risk Assessment are expanded upon, with additional content focused on vulnerability management, asset life cycles, etc.
• Outside that, Identify is much streamlined, with Governance, Business Environment, and Supply Chain moving into the new Govern Function.
• A new “Improvement” category is added to Identify, collecting up various subcategories around process improvements, lessons learned, etc. that were previously included in various other categories / functions.
• I’m not a big fan of this last change – I don’t know that it improves clarity or usability to pull all of the “lessons learned” / improvement out of specific categories in places like Respond and Recover, and even if one were to do that, putting it under “Identify” seems somewhat arbitrary.

Protect and Detect – Similar Content, Much Better Structure

These areas see light changes in subcategory specifics, but significant overhauls in how those directives are grouped, structured, and explained.

• “Protect” has had significant restructuring and clarification of its content. “Information Protection Processes and Procedures“, “Maintenance” and “Protective Technology” have all been replaced, with Data Security, Platform Security, and Infrastructure Resilience taking their place. Most of the content from the previous categories, in updated format, finds a home in these newer, and better-organized, categories (though some ends up in places like Asset Management and Risk Management).
• “Detect” sees “Anomalies and Events” and “Detection Processes” folded into a combination of “Continuous Monitoring” and the new “Adverse Event Analysis“. The new grouping is cleaner, with all monitoring directives under “Continuous Monitoring” (they were previously split between “Anomalies and Events“, “Detection Process” and “Continuous Monitoring“), and all response-related activities (impact analysis, etc.) under “Adverse Event Analysis“.
• Curiously, while we lose some meaningless categories (“Detection activities comply with all applicable requirements”), we also lose some seemingly valid ones (“Detection processes are tested”) – unclear as to the rationale here.
• This is another place where we see instances of the “generalization / abstraction” mentioned above – categories specifying searching for malicious code, unauthorized mobile code, unauthorized connections or devices, etc… have been removed in favor of the more general “Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events”, for example.

Respond and Recover – Finally First Class Citizens

These areas receive a significant overhaul in CSF 2.0, while 1.1 content remains part of the 2.0 framework, the structure is much improved, and the level of detail is made more consistent (previously, it was a mix of high level hand-waves and oddly-specific proscriptions). Whereas 1.1’s version of Respond and Recover focused on documentation and communication (and not actual incident handling), version 2.0 stresses actual incident operations, and condenses the meaningful portions of communication down to a few key requirements.

Respond sees a significant overhaul –

• The 1.1 version was hand-wavy, with multiple subcategory definitions focused on communication (e.g. RS.CI had 5 subcategories in 1.1 outlining specific information sharing needs – this is down to 2 in version 2.0).
• Version 2 includes notions of prioritization, escalation, analysis details, and defined transition to recovery phase.
• Communication is streamlined into 2 simple objectives around engaging and updating relevant internal and external stakeholders.
• Overall, the new version is cleaner and more elegant, focusing more on incident response than detailed communications mandates.

Similarly, the 1.1 Recover had a simplistic “have a recovery plan, execute it, run a post mortem, and manage PR” approach – which is now both expanded on and made more sensible.

• The revised 2.0 version includes requirements around preparation – validation of the recovery plan and relevant assets prior to execution
• The revisions also make clear that re-establishment of business operations is a key part of recovery – with specific requirements for re-establishing critical processes and risk management functions.
• Communications is clarified / made more sensible, moving from a focus on “managing PR” to establishing communications with relevant internal and external stakeholders.

Don’t forget the implementation examples and related frameworks…

One flaw in the current 2.0 CSF release is the fact that some of the most useful companion content from version 1.1 is missing or captured in separate artifacts.

More specifically, version 1.1 included references to other relevant frameworks, from the CIS CSC, COBIT, ISA, ISO 27000 series, to NIST’s OWN 800-53.. which often provided useful additional thoughts on implementation and a starting point for an organization looking to migrate over to or assess itself against NIST-CSF when already on an existing framework.

This is all lacking in the core NIST CSF 2.0 document. Hopefully a future addition will address this, if not, I’m certain the broader community will fill in the gaps to cover this.

There is an available companion document with implementational examples, which is a godsend for those wishing to translate the framework’s generalities into specific solutions. The concrete examples provided can take a “the organization will …[do X]” down to something more practical and measurable for most practitioners and their management team(s).

Wrapping it up: “So what?”

NIST’s CSF 2.0 is a significant evolution of the 1.1 version. Breaking out “Govern” as a core function, and acknowledging the role of business objectives, strategy, risk tolerance, and policies, is a huge step in better reflecting how actual, functioning security programs live “in the wild”.

Revisions to the other functions improve overall organization and usability, while also condensing needlessly detailed subcategory requirements down to more universally applicable forms. While still not perfect (e.g. the “Improvement” category of Identify seems ill-thought-out, and we could stand to have references to other frameworks restored), the second full version of the CSF is solid improvement on the existing thinking, and an excellent response to the broad popularity the CSF has gained in organizations outside its initial “Critical infrastructure” scope.

While you don’t need to make any immediate practical changes to adopt the NIST CSF 2.0 in your organization, as most of the requirements / advice are similar to previous versions of the CSF and NIST 800-53, consider updating to score based on it in your next formal assessment. The NIST organization has several templates that can help with this, which should render this a welcome and reasonably smooth swap-over for most.