Initial impressions of the NIST Cybersecurity Framework version 2.0 draft

Posted on 2023-04-27 by Matt Strahan in Compliance

The latest draft of NIST Cybersecurity Framework (NIST CSF) has just been released! This is the first preview of the new 2.0 version of the framework that updates the hugely successful framework. The draft follows from a Concept Paper released at the beginning of the year. The final version is due to be released in 2024.

This post will go over the main changes that I can see and gives my initial impressions on the good and the bad.

What’s wrong with NIST CSF 1.1?

NIST CSF 1.1 is used by hundreds of thousands of organisations across the world to guide their security controls. It’s split into five categories:

  • Identify
  • Protect
  • Detect
  • Respond
  • Recover

When the CSF was first released it caused a huge splash. A lot of the success came down to the collection of controls simply being quite sensible, appropriate for all organisations from SMEs to the biggest enterprises. The vendor and technology-agnostic approach meant it was flexible, describing goals rather than specific implementations. The framework, while being prescriptive, was also not overly burdensome. You could approach the implementation not worrying about having to throw what you have away and start from scratch.

Finally, the overall pitch of the framework was great. What’s NIST CSF about? Well it allows you to Identify, Protect, Detect, Respond, and Recover!

However, its been over five years now and the NIST CSF 1.1 has been showing its age. Since 2018 there’s been some big changes to how we approach cyber security:

  • NIST CSF 1.1 still mostly treats cyber security as an IT issue with a sprinkling of “make sure your leaders are OK with it all” thrown in. That’s not reality now, with cyber security being a central topic for boards.
  • While AWS was a thing back then, we now have organisations that have their entire networks based in the cloud with a heavy usage of Software-as-a-Service (SaaS) in core business processes. The new ways of working have enabled zero-trust architectures, for instance, and raised the importance of the endpoint for security.
  • On a related note, teleworking has a much bigger emphasis now than before. Work-from-home pretty quickly went from being unusual to being standard and it means that endpoints have moved outside of the perimeter and become guardians of data and business processes. Cyber security controls must enable and secure remote access to data and core business services.
  • The supply chain has a section in NIST CSF 1.1 but the topic felt like it was relegated to the side. Meanwhile the “digital supply chain” has become core parts of business processes with SaaS. Supply chain attacks (most recently 3CX) have become rampant.

There were a whole bunch of smaller issues as well, particularly with clarity of controls. Take RS.AN-3: “Forensics are performed”. That doesn’t give any definition of what “forensics” mean here and not much clarity about the intent of the control.

The first impressions of version 2.0

Overall, the changes made to the standard are extremely positive and brings the standard forward to meet the new risks facing organisations today. It’s not perfect (more on that later!) but is definitely a great improvement which provides greater clarity and I believe will give better outcomes to organisations.

I’ve split up my comments into five sections:

  • The new Govern category
  • Supply chain is now integrated into the standard
  • Continual improvement
  • Clearer definitions of controls
  • What’s missing?

In each section I’ll be taking some of the new controls from the draft to discuss how things are different and where the major changes lie.

The new Govern category

Version 1.1 had “Governance” as a subcategory of Identify. The subcategory really only had a few high level requirements, saying that policy is established and you have “governance”. Other areas that might be considered “cyber security governance” like risk management were predominantly spattered around Identify, which is a bit of a strange place to put it. This made me often say that “NIST CSF is a more technical standard compared to ISO 27001 which is more a governance standard”.

The new draft now has Govern as one of what is now six categories. This makes for a much more sensible categorisation. In particular, the governance controls place more of an emphasis on how cyber security is an organisational effort rather than just an IT effort. If you look at these new and changed controls, they all talk about strategy, leadership, and the organisation as a whole:

  • GV.RM-05: Strategic direction describing appropriate risk response options, including cybersecurity risk transfer mechanisms (e.g., insurance, outsourcing), investment in mitigations, and risk acceptance is established and communicated
  • GV.RM-07: Risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks
  • GV.RM-08: Effectiveness and adequacy of cybersecurity risk management strategy and results are assessed and reviewed by organizational leaders
  • GV.RR-01: Organizational leadership takes responsibility for decisions associated with cybersecurity risks and establishes a culture that is risk-aware, behaves in an ethical manner, and promotes continuous improvement
  • GV.PO-03: Policies and procedures are reviewed, updated, and communicated to reflect changes in requirements, threats, technology, and organizational mission

I definitely welcome this new category. Simply elevating the “Govern” category to the top level emphasises the importance of cyber security through to the leadership, executive, and board.

The one thing I see that is missing in the Govern section is around communication back to the leadership. The upwards communication is something that is often assumed (for instance “we require audits to be done and of course the results should reach the board, right?”). For instance, two controls that talk about communication are:

  • GV.OC-04: Critical objectives, capabilities, and services that stakeholders expect are determined and communicated
  • GV.OC-05: Critical outcomes, capabilities, and services that the organization relies on are determined and communicated

These controls imply but don’t specify that there should be upwards communication. Instead the default seems to be downwards communication.

I feel that if governance is addressed specifically in NIST CSF 2.0 it should make upwards communication more explicit, potentially having a requirement like:

  • “The performance of security controls, including key risks and the results of reviews, assessment results, and audits, is communicated to leadership”.

Supply chain is now integrated into the standard

As I said in the previous sections, the supply chain part of NIST CSF 1.1 felt relegated to a separate topic. There was the single “ID.SC” supply chain subcategory that made it feel like you go “ok do we have security in our contracts for other companies? Yep? All good!”

This doesn’t work anymore. What used to be “digital supply chain” is now “components of core digital business processes”. The new version of NIST reflects this by incorporating supply chain considerations into all the different parts of the framework. A collection of these new controls are below. While I feel the controls themselves are interesting, what’s more interesting is that these controls are in different subcategories and span four categories. This reflects the new reality of how supply chain integrates into the digital systems of modern organisations.

  • GV.PO-02: The same policies used internally are applied to suppliers
  • GV.RR-05: Lines of communication across the organization are established for cybersecurity risks, including supply chain risks
  • ID.AM-04: Inventories of external assets and suppliers are maintained
  • ID.RA-01: Vulnerabilities in first-party and third-party assets are identified, validated, and recorded
  • ID.IM-02: Security tests and exercises, including in coordination with suppliers and third-party providers, are carried out to identify improvements
  • PR.PS-08: Supply chain security practices are integrated and their performance is monitored throughout the technology product and service life cycle
  • DE.CM-06: External service providers and the services they provide are monitored to find adverse cybersecurity events

Continual improvement

In version 1.1, improvement was around the response to incidents. You would use the Recovery component of incident response to improve your processes and strategies. That’s great, but it has the obvious drawback that you’ll only improve after something goes wrong, not before.

The new draft removes this sub-category entirely and creates and new Improvement subcategory within Identify. There’s a few requirements there, but here’s the most important:

  • ID.IM-01: Continuous evaluation, including through reviews, audits, and assessments (including self-assessments), is applied to identify opportunities for improvement across all Framework Functions

I personally have a couple of quibbles putting improvements in Identify. I suppose you’re trying to identify improvements, but wouldn’t it be better placed in the new Govern category? Nevertheless, the new Improve subcategory is a welcome change.

On a similar topic, I also appreciate this new requirement:

  • ID.RA-10: Exceptions to security measures are reviewed, tracked, and compensated for

An issue many frameworks have is when the specifics of the framework might not be appropriate. This gives a way of allowing and tracking these cases.

Clearer definitions of controls

There’s a whole bunch of improvements to terminology and words to make everything clearer and reduce ambiguity. Just taking the example from the introduction, instead of “RS.AN-3: Forensics are performed”, this has been replaced with:

  • RS.AN-03: Analysis is performed to determine what has taken place during an incident and the root cause of the incident
  • RS.AN-06: Actions performed during an investigation are recorded and the record’s integrity and provenance are preserved

These two controls say what the previous control was meaning to say but say it in a way that doesn’t involve people trying to guess what is meant by “forensics”. This will both make it more likely for the control to be implemented and reduce uncertainty when assessing yourself against the standard.

What’s missing?

The new draft meets most of my critique of version 1.1 except for one key area: There doesn’t seem to be anything that specifically addresses remote working and the growing importance of the security of the endpoint. Since the pandemic and lockdowns pushed organisations into greater work-from-home arrangements, remote working has been a mainstay for all organisations. Although I’m biased - Volkis is a remote-only organisation - I personally don’t see the new work-from-home dynamic changing.

This isn’t quite tackled head-on in the new draft. Instead, bits and pieces are addressed around the standard. For instance:

  • PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions
  • PR.AA-04: Federated assertions are generated, protected, conveyed, and verified
  • PR.AA-05: Access permissions, entitlements, and authorizations are managed and enforced, incorporating the principles of least privilege and separation of duties

The new controls, particularly the one around federated assertions, are welcome, but I believe without tackling remote working head-on we might find that once the controls are implemented we realise that they’re not comprehensive. We will find gaps where implementing the controls as they’re stated doesn’t cover the edge cases that come with remote working and you’ll need a bit of an asterisk saying “OK I know NIST says this but maybe do this as well!”

There are also controls where I feel the technology-agnostic approach simply makes the standard more vague than it needs to be. For instance, this one seems to call for Application Control, but does it? Hopefully the implementation guidance will help us there.

  • PR.PS-05: Protective technologies are executed on or within platforms to stop unauthorized software execution

Summing up

I’m looking forward to the release of NIST CSF 2.0. I can see areas for further improvement, but even the draft standard has clear improvements over the previous version and I’d feel comfortable picking up and using it as is.

Good work NIST!

I’m also keen to hear your thoughts. Let me know what you think!

About the author

Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.

If you need help with your security, get in touch with Volkis.
Follow us on Twitter and LinkedIn