Last week, our good friend Raj Umadas, Director of Security at ActBlue, teamed up with our very own Tim Erlin, Head of Product, to talk about the newly proposed NIST Cybersecurity Framework (CSF). It was a fantastic discussion covering the intent behind this update, the major changes from v1.1 to v2.0, and how it applies to API security. Raj and Tim really dug deep into a lot of issues, and answered a lot of questions from the audience.

If you missed the webinar, you can watch it on-demand here:

In this post, we do not intend to cover the same ground beyond some of the basics. Rather, we’d like to address some of the questions we were unable to get to during the event.

The Basics

NIST released the first version back in 2014 and updated to version 1.1 in 2018. The draft of CSF version 2.0 is currently open for comment until Nov-2023, and is expected to be released in early 2024.

Some of the more important changes include:

• Applicability. The new CSF has expanded beyond Critical Infrastructure to be more broadly applicable.
• Interconnected. It now includes updated and more current references, mappings, and links.
• Implementation. It also includes “implementation examples” to help users successfully apply the new guidance.
• Supply Chain Security. NIST has added focus on software supply chain security throughout the new CSF as well.
• Revamped Functions. In addition to changes & updates to the previous five (5) functions (Identify, Protect, Detect, Respond, Recover), NIST has added a new one to the list: Govern.

Who’s Using It?

Before the event started, we were wondering how many security practitioners out there were really using the current version, or indeed if they were even aware of it. Several of us thought that adoption was probably pretty low, while Raj bet it would be greater than 50% – so we polled the audience to find out.

As you can see, Raj won the bet. But it also suggested that the audience was going to be very interested in the implications of the changes in CSF 2.0 and how to leverage it moving forward. This was borne out by all the questions being posed.

The Discussion

A lot of the questions that Raj and Tim addressed during the event revolved around how to implement the new CSF 2.0, the overlap with other frameworks, and the implications of specific changes. In addition, a lot of folks were interested in whether and how AI might be leveraged.

One main point they covered was how to use it to facilitate communication north (to your bosses), south (to your team) and east-west (to other stakeholders). Another was the tendency for practitioners to try to boil the ocean. Here, Raj and Tim suggested instead you “scope down brutally, almost to the point where it feels like it’s a waste of time,” and then use the tier mechanisms articulated in CSF 2.0 to help make progress in each of the function categories and subcategories. As Kevin in the audience observed: “I would keep it simple. Everything is about scope.”

There was also some confusion about the differences and uses of a framework such as CSF 2.0 and standards (e.g., COBIT or ITIL) and controls (e.g., NIST SP 800-218, which covers secure software development). As Xiaoying asked: “How do you assess the security risk? You can use the CSF framework from a control perspective, or you can use tools from an attack surface or assets perspective? What is the best approach you would recommend?”

To augment the live discussion, we should note that assessment can occur at multiple levels. The CSF is itself a tool for assessment of your cybersecurity program, but it’s not designed to assess any specific control. An audit or penetration test might be used to assess a specific control’s effectiveness. The best approach is a layered one that looks at the program as a whole and the effectiveness of the controls themselves. 

Some other interesting questions from the audience that we did not get to during the event include:

• Paula asked us to “talk more about why I should prefer using CSF over ISO for API security? I think ISO helps so much to start building a GRC program.” We agree – you shouldn’t! If you prefer ISO and your organization has adopted it, there’s no real reason to change. One benefit of ISO is that you can be certified, so that might be an important factor in your decision.
• Someone else asked if one “can have different profiles to represent segments of an organization.” A profile is meant to represent some state of your cybersecurity program, so yes – just like you can have a community profile, you could have a profile for a business unit or subsidiary.

Another sage comment came from Brett, another audience member, who noted that “We need to be clear that CSF is not a maturity model, it’s a risk-based model. It specifies in the doc that the tiers are not meant to imply a maturity model.”

API Security

Finally, Ravi asked if there is a “quick list of NIST recommendations for API Security and Governance.” As Tim and Raj emphasized during the discussion, the NIST CSF 2.0 is not about specific technologies or controls, but rather to help you: 1) understand your current cybersecurity posture; 2) assess it against some required or desired future state; 3) prioritize the gaps that you’ve identified; and then 4) communicate with stakeholders about cybersecurity.

That said, we have created a quick reference guide to help you map all the Functions in the new NIST CSF 2.0 to your API security needs. This high-level mapping provides some guidance on API security capabilities which you will probably want or need in order to properly implement CSF 2.0 to your API portfolio.

As always, if you’d like to learn more about how to secure your web apps and APIs, give us a shout.