Did you see that on August 8, 2023, the U.S. National Institute of Standards and Technology (NIST) released the Initial Public Draft of its Cybersecurity Framework (CSF) version 2.0?
Shortly after it was originally published in 2014, I started using the CSF with our customers to help them find and mitigate their top five cyber risks.
As a heavy user of CSF, I read the Public Draft carefully, and there's a lot to like. There are also a few missed opportunities, but I'll cover those as we go. Here's the NIST press release.
First of all, this new version was designed to help all sectors of our economy. Prior versions were just targeted at critical infrastructure, such as transportation, power generation, and hospitals. And, at my company, Cyber Risk Opportunities, we have used CSF v1 and v1.1 mostly with organizations outside of critical infrastructure over the past eight years. So, I'm sure v2 will work even better for them.
This specific difference is reflected in the CSF's official title, which has changed to "The Cybersecurity Framework" (it's what we were all calling it anyway) from the more stiff and limited "Framework for Improving Critical Infrastructure Cybersecurity."
CSF users also wanted NIST to make sure it could address emerging cybersecurity issues, such as supply chain risks and the widespread threat of ransomware. Version 2 addresses all of that.
It also has a new connection with privacy. I like the way it's done by stating there are a few "cyber-related privacy events" that justify the connection, but CSF v2 doesn't try to fully converge the cybersecurity and privacy disciplines.
I also noticed this new CSF version is more sure of itself. The language is more certain, focused, and useful. There's a stronger emphasis on prioritizing opportunities to improve cybersecurity risk management, and clearer language about determining where an organization may have cybersecurity gaps. It also places more emphasis on informing decisions about cybersecurity-related workforce needs and capabilities. And there's greater focus on "action plans" than before.
One thing I've always liked about CSF is that it's been community driven from the start. And version 2.0 has benefitted from well over a year's worth of community feedback, on top of the industry voices that drove versions 1 and 1.1. Thousands of people participated in the feedback process, which featured live workshops as well as written requests for input. With that many people participating, v2 could have gone wrong at any point; but I'm excited that it didn't.
[RELATED: Security Experts Assess 2.0 Draft of NIST Cybersecurity Framework]
Overall, I see v2 as a smart evolution from 1.1, rather than a major remodel that makes it look and feel quite different. And I think this evolution is just what we needed to keep up with the changing cyber risk landscape.
And, as a strange bonus, there's less CSF than ever! The version 1.1 publication has 55 pages, while the version 2 draft has only 52 pages. And it will likely be shorter once final edits are made. Part of the reason for this is that some material from v1.1 has been moved to other locations. More about that later.
Now, there are some specific and important changes in the Core of the Framework that I want you to know about:
- Prior versions of the Framework were organized along five top-level functions: identify, protect, detect, respond, and recover. These describe the lifecycle of a cybersecurity incident.
- Version 2 has added a sixth Function: Govern, which emphasizes that cybersecurity is a major source of enterprise risk, ranking alongside legal, financial, and other risks as considerations for senior leadership. In other words, cyber has become a material business risk and it deserves top-down attention.
- The Govern function isn't all new material, however. It's been largely built out of other functions, mostly by moving many revised v1.1 outcomes into the new Govern function.
- Helpfully, the definitions of the other five Functions have been refined and simplified. This helps make the Framework easier to operationalize and to be understood better by non-cybersecurity people. For example, Recover (RC) in v1.1 read like this: "Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity incident." Whereas in v2.0, it's been simplified to: "Restore assets and operations that were impacted by a cybersecurity incident."
- The overall breadth of CSF v2 is similar to v1.1. There are now 23 Activities (categories) versus 22. And the number of Outcomes (subcategories) is similar: 106 now versus 108 previously.
Over the years, NIST said that CSF users had been requesting more guidance on implementing the Framework. Our customers definitely wanted that, so we created our own implementation methods that we still use today. (I described most of them in Part 2 of my book, "Fire Doesn't Innovate.") This is one of the missed opportunities: v2 has more implementation guidance but not as much as our customers have been asking for.
Still, the changes are very good. Let's look at a new feature called "Implementation Examples." NIST has released about 360 of them at the Outcome (subcategory) level. To be clear, these are not controls. You still need to choose your own controls. But the examples are very helpful at getting you pointed in the right direction.
Let's take a look at one for this Outcome: "GV.SC-04: Suppliers are known and prioritized by criticality."
The implementation example provided is: "Develop criteria for supplier criticality based on, for example, the sensitivity of data processed or possessed by suppliers, the degree of access to the organization's systems, and the importance of the products or services to the organization's mission."
In this example, the criteria for supplier criticality itself is not a control. Before you select controls, you'll need to design a basic supplier risk management process flow that will evaluate suppliers against the criteria. Then you can select and implement several controls that are designed to get you the outcome GV.SC-04.
Here's a possible policy control chosen to prevent suppliers from skipping the criticality evaluation: "No supplier contract may be signed without the supplier being categorized as low, medium, or high risk based on established criteria."
And, here's another policy control for managing the results of the criticality evaluation: "No supplier contract may be signed without all criticality criteria gaps going through the organization's risk treatment process." You might also require contract signers to affirm that they have categorized the supplier and treated the found risks.
You also might need a detective control to discover if preventative controls have been circumvented. A periodic review of the supplier risk management process by the internal audit team might work well.
Despite all these improvements, some things did not change:
- CSF v2 is still not a checklist. You're going to need to put in time and effort to tailor it to your organization, which is a good thing.
- It still encourages you to Profile the Framework to your organization. By defining a current and target profile, you can identify and then close the gaps you find. This is exactly how our Cyber Risk Management Action Plan (CR-MAP) works.
- It still has Tiers, with new criteria, but doesn't change their essence from v1.1. Tiers are still not a maturity model where everyone is expected to reach the highest level as quickly as possible.
- It retains its "top-down" orientation, as compared to something like PCI-DSS, which is more "bottom-up."
I did see two missed opportunities:
- The subcategories should be written as testable statements.
- The subcategories should be written in plain English (although, v2 is much improved as compared to v1).
Let's see what I mean by looking at PR.AA-05: "Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties."
Here's the Outcome as testable statements in plain English:
- PR.AA-05-a: Access permissions are defined in a policy.
- PR.AA-05-b: Access permissions are managed.
- PR.AA-05-c: Access permissions are enforced.
- PR.AA-05-d: Access permissions are reviewed.
- PR.AA-05-e: Access permissions incorporate the principles of least privilege.
- PR.AA-05-f: Access permissions incorporate separation of duties.
So, what's next? NIST is accepting public comment on the draft framework until November 4, 2023. There's no plan to release another draft. A workshop planned for the fall will be announced shortly and will serve as another opportunity for the public to provide feedback and comments on the draft. NIST plans to publish the final version of CSF 2.0 in early 2024.
~~~
Note about the author:
Kip Boyle is teaching SecureWorld PLUS Courses on "Implementing the NIST Cybersecurity Framework" at all six of our in-person conferences this fall. These are opportunities to get a deeper dive on the NIST CSF and earn 6 CPE credits (in addition to the conference CPEs). Most courses are held the day before or day after (or in the morning and afternoons at 2-day events), and the course fee includes a Conference Pass to each event. Here is the schedule of PLUS Course offerings:
- SecureWorld Denver – PLUS Course, Sep. 20 at Hyatt Place Denver/Cherry Creek; conference is Sep. 19 at The Cable Center
- SecureWorld Detroit – PLUS Course, Sep. 27; conference is Sep. 28 at Suburban Collection Showplace
- SecureWorld St. Louis – PLUS Course, Oct. 18; conference is Oct. 19 at The Ritz-Carlton St. Louis
- SecureWorld Dallas – PLUS Course, Oct. 25; conference is Oct. 26 at Plano Event Center
- SecureWorld Seattle – PLUS Course (and conference), Nov. 8-9 at Meydenbauer Center in Bellevue
- SecureWorld New York – PLUS Course, Nov. 14; conference is Nov. 15 at Marriott Marquis Times Square
To attend the PLUS Courses, visit each conference's event page and choose the PLUS Course option during registration and make payment accordingly.
