Speaker 1: Welcome to the Cyber Risk Management Podcast. Our mission is to help executives thrive as cyber risk managers. Your hosts are Kip Boyle, Virtual Chief Information Security Officer at Cyber Risk Opportunities, and Jake Bernstein, partner at the law firm of K&L Gates. Visit them cr-map.com, and klgates.com.

Jake Bernstein: So Kip, what are we going to talk about today in Episode 141 of the Cyber Risk Management Podcast?

Kip Boyle: Hey, Jake, I saw this really cool thing. So we're recording this in early August. And just a few days ago, on August 8th, NIST dropped what they're calling the initial public draft of Version 2.0 Of the NIST Cybersecurity Framework. So I thought we should talk about that.

Jake Bernstein: That sounds like a very good thing to talk about. And you were real quick on writing an article about the new CSF. And you said you were going to use it for the podcast, so clearly you did. Let's see what this is about. And for me, this is very exciting, but for you, this is a really big deal, isn't it?

Kip Boyle: Yeah, it really is. This is going to affect a lot of my work.

Jake Bernstein: And the reason for that is that you've been teaching the NIST Cybersecurity Framework. You've been using it. Well, we've been using it in the CR-MAPs. You've taught it in your Udemy courses. You're doing it in your Secure World PLUS courses, your Cyber Resilience certifications. So I guess we're going to talk about how big of a difference is it, some of the details of that. But just to begin with, what are you going to do, particularly as you get closer and closer to 2024 and the ultimately release, which they have said... And I'll just say this. They have said this is likely to be the only full public draft. And their goal is to release in early 2024.

Kip Boyle: Right. Yeah. And so anytime you pin anything important to yourself on somebody else's platform, this is going to come up, right? Loosely speaking, since I've based so much of what I do on this framework, it reminds me sometimes of people who used to depend on Google Ads or SEO, and then Google changes the algorithm and they have to scramble. And I kind of see this as being a little bit similar, but it's easier, it's much, much easier, because Google doesn't really tell you when they're going to change their algorithm, or when Apple completely redid ads on their mobile devices and how that affected Facebook.

In this case, I have lots of warning. And I haven't had to deal with an upgrade to the framework since 2018, so it doesn't happen very often. And I've got lots of warning, so I'm feeling good. But having said that, I'm not going to update anything until NIST puts the final bow on Version 2.0, because one of the things that I'm going to share with people today in the episode is that, while they can say, like, "Hey, we're not going to do another major draft," and that's okay, the draft that's out there really isn't completely finished. There's a little bit that's just not done. But it's crucial for all of my work. So until they get that absolutely wound up, I'm not going to change anything. But I'm going to start doing a little bit of prep work. And then when it does get finalized, I'll be able to systematically go through all of my publications and courses and certifications, and we'll get up to speed.

Jake Bernstein: I think that makes a lot of sense. That's probably the only really logical way of handling it, particularly since it's not final until it's final.

Kip Boyle: Yes.

Jake Bernstein: And speaking of that, it is worth pointing out, you hinted at it when you said you had a lot of warning, but you really did have a lot of warning, because NIST has been working on this openly now for a year or more, and they've had many, many thousands of comments and events and just feedback.

Kip Boyle: Absolutely. And it's something that they don't do quickly. If you look at the evolution of Version 1.0 to Version 1.1, that was a long time coming as well. And they really repeated the pattern here. By the time it goes final, it'll have been at least two full years since they started the community feedback efforts that you were referring to. And there's quite a bit that they've done, and you can go on their website and you can see all the events that they've held. You can see all of the feedback they've collected, because those are public records. So yeah. It hasn't exactly been a secret that this was coming, but the fact that it's community-driven is something that I love about it. I'll talk about that a little bit more.

But in reading the public draft, and I read it very carefully, I just want to start off by saying there's a lot to like about what version 2.0 is shaping up to be. One of the things... There's many things, but let me just... Right off the bat, they have stopped talking about CSF as something that is designed for critical infrastructure. So what is critical infrastructure? For anybody who doesn't know already, in the United States, we have designated sectors, which I think the rest of us would call them industries, that are considered critical for the so-called American way of life. And this would include transportation, power generation, hospitals. It goes on and on and on. It wouldn't include theme parks, unfortunately, for some people who think that the world's not interesting enough to live in without them. But had to draw the line somewhere.

And so the new version, Version 2.0, has been revised so that everybody can use it. I think that's fantastic, because it turns out that my company, Cyber Risk Opportunities, well, we've been using the framework mostly with organizations outside of critical infrastructure for the past eight years, and it's worked really well for them. And I think this fundamental philosophical change is going to open the doors for more people to benefit. And I think the updates, that I'm going to touch on today in the episode, are also backing up the assertion that, "Hey, this is a framework for everybody, not just for critical infrastructure."

Jake Bernstein: And it makes sense. It's not like everyone hasn't been calling it the CSF/Cybersecurity Framework for much of its life anyway. Since I've been dealing with it, it's been called the CSF. No one's ever said, "The framework for improving critical infrastructure cybersecurity." What is that? The FICIC?

Kip Boyle: Most people haven't.

Jake Bernstein: Yeah. No one's ever called it the FICIC, as far as I know.

Kip Boyle: FIFIC. Oh, my lord.

Jake Bernstein: Well, yeah.

Kip Boyle: Yeah. I mean, they could. I've never heard that acronym before. Thank you very much.

Jake Bernstein: Well, that's because nobody uses it.

Kip Boyle: Exactly. Point taken. And there's another really cool change with this version of the framework, which I know you are going to appreciate, which is there's a new connection with the privacy domain. And I really like the way it's done, because I've seen a lot of people allege, outside of the NIST Cybersecurity Framework context, that, "Oh, cybersecurity and privacy should just converge. It's really just the same thing at the end of the day."

Jake Bernstein: It is not the same thing, Kip.

Kip Boyle: It's not. You're absolutely correct. And I have felt that way since, I don't know, 2005, when privacy in the United States really started to become a thing that businesses needed to really take care of. But I like the way that... Again, it's very thoughtful. There's a diagram in Version 2.0 of the Framework, and it shows... It's a Venn diagram, and it shows overlap between the two disciplines, and I think they got it right. I think that the overlap is correct. So at a high level, that's what I'm seeing. I don't know if you've had a chance to look at that aspect yet.

Jake Bernstein: I have. I did see it. I haven't read everything there is to read about it, of course. It's been, what, three days? But I definitely looked at it right away. I even have a printout of it. And I agree. I think that the... Spoiler alert... Let's come back to this, because I do want to say, I think that the changes to the CSF probably could inform Privacy Framework 1.5, but I think that the fundamental point here is they're not the same. They shouldn't be treated the same, and NIST did not choose to collapse them. So I think that's all correct.

Kip Boyle: Right, right. And there's so much more to say about it, but I just want to touch on that right now. We could do an entire podcast episode just on this one change. Really, any of these single changes could be entire episodes.

Jake Bernstein: Oh, absolutely.

Kip Boyle: And we probably will. But something also that I want to say about the Framework is, I noticed that in reading it, it comes off as... The language is more certain, it's more focused, it's more useful. And overall, it just feels like the authors are more sure of what this Framework is doing, what its intent, what the benefits are, what the opportunities are. For example, there's stronger emphasis on the need to prioritize the opportunities that the Framework exposes in order to improve your cybersecurity risk management. And that language has been in there before, but it's been muddled. Now, it's just plain, it's clear. I love it. There's better language about how to determine where an organization may have cybersecurity gaps. Again, muddled before, much more clear now. Plus more tooling and more guidance on that, which I think is great.

Jake Bernstein: And we'll talk more about some of that. It's truly a v2.0 as opposed to... And you mentioned that you haven't had to deal with a cybersecurity framework update since, what, 2018? Or whatever.

Kip Boyle: Five years.

Jake Bernstein: And that was just 1.0 To 1.1. And really they just added a few things here and there, mostly around cyber supply chain risk management. This though is much more significant. And I think what we should do, because this podcast is going to end before we know it, there's just not much time to talk about everything here. Let's go ahead and just dive into what they have done with 2.0. And I do think it's worth pointing out, as you do here in your article, it's been very community driven from the start. I already mentioned that there's been a year's worth of community feedback on top of all the industry voices that originally drove all of the 1.0 to 1.1. And it is not at all an exaggeration to say that thousands of people have participated in the feedback process. What do you think the odds are that something would have gone wrong at some point?

Kip Boyle: Well, honestly, that's always my concern. As much as I love the community voice and especially the engagement level, not with just random people, but these are practitioners, these are people who do this work-

Jake Bernstein: These are our people.

Kip Boyle: ... all the time. These are our people, our peeps. Probably many people listening to this podcast contributed in one form or another in providing feedback. So that's always wonderful. But of course, too many cooks in the kitchen, too many chiefs, not enough Indians. Pick your metaphor. There's always the opportunity that there's going to be clash and conflict and strife, and then the authors are going to have to try to maybe compromise and water things down or just go in a completely bizarre direction.

Other community efforts have suffered like that. This one hasn't. And maybe it's because we've got really great facilitators out of NIST who are clearheaded and are able to make sense of all the feedback. That sounds like the most likely explanation that I can come up with. I wasn't deeply involved in it. I provided a little bit of feedback, not much. I was just too busy using it. I'm really glad that my faith in the community has completely paid off, and this thing has gone in the right direction.

Jake Bernstein: Yeah. No, I think so. Okay, so give us just the high level overview. What do you see? Was it a good evolution? Was it a bad evolution? Obviously it's not a bad evolution, but what do you think?

Kip Boyle: Well, they could have tore it completely apart and done some revolutionary new thing. They did not do that. I feel like version 2.0 is a very smart evolution. One of the things that I often look at when I'm working with customers is as I ask myself, "Okay, well they're paying great attention to what's going on inside their four walls, but are they paying attention to what's going on in the world, in the broader landscape?" And often the answer is no, they're not. But this new version of the framework feels like yes, they have. They're not just looking at what the framework itself could do to be better, but they actually also looked in the broader world and said, "What does this framework need to be in order to help people keep up with everything that's going on?" Ransomware, for example, and all kinds of different changes with the kinds of attacks that we're seeing with supply chain. And so I think it's done a wonderful job of keeping up with the evolution of all of these developments.

Jake Bernstein: I agree. I think it really does. Let's go ahead and dive into what has happened. What are some good stats here, Kip?

Kip Boyle: So what, what's nice but strange, usually when you revise something, it gets bigger, more pages, more diagrams, more this, more that. But that's not exactly what happened with the CSF. So if you look at the public draft that they just released, it actually has three fewer pages than the 1.1 version. And I think it's probably going to be a little bit shorter once the final edits are made, because there's a lot of parenthetical text in this draft. So how did they do it? Well, actually they moved a lot of material out of the core publication, and they've moved it into other locations, which we'll cover that in a minute as to why they did that. But I just want to say right now, that was a good move. It was a very good move and I think people are going to be happy with those changes. Now in the core of the framework, so for those of you who may not remember your CSF terminology, the core of the framework is the five functions. Now there's six functions.

Jake Bernstein: Spoiler alert.

Kip Boyle: Yep. And then it's organized into three tiers. There's top level functions. At the second level of the core are categories or activities, as I like to call them. The standard uses both words. And then there's a third level of detail, which is called a subcategory or an outcome, which is, again, another synonym that I prefer. I think it's more business friendly to call them functions, activities, and outcomes. So that's what we do. Now, in version two, they've said, all right, we need a govern function. So now we've got six. And graphically, the way it's depicted, you can look at it as like a wheel where govern is the hub. Or you can think of it as a pyramid where govern is like the foundational layer, however you want to think about it. But that's really what's going on here. And my heart sang when I read this because what they say in there is that cybersecurity is a major source of enterprise risk, and it ranks alongside other well-known enterprise risks, legal risks, financial risks. I would add sales. I would add order fulfillment. I would add accounts receivable.

Jake Bernstein: All the risks that you can really come up with are inaudible

Kip Boyle: Yeah. All the big things-

Jake Bernstein: They really are.

Kip Boyle: ... that traditionally kill companies when they go really, really bad. I'm thinking about, I don't know, Nokia. When the iPhone came out, all this market risk that killed them, small companies that struggle to get product market fit. If they don't get that right, it kills them. Inability to collect money that people owe you. Inability to deliver products people have purchased from you, all that stuff. So we've got this governing function now in version 2.0. And interestingly, the way they made the govern function is they didn't create it out of whole cloth, they actually went mostly into the identify function. So it was an existing one, and they gutted it of all of the obviously governance oriented things and moved them.

Jake Bernstein: And to be fair, there were quite a few.

Kip Boyle: There was a lot. You could argue that the governance function was already existent in version 1.1, it just wasn't called out. And I think this is a smart improvement for a number of different reasons, and I'm really happy about this. And of course, the fact that something I've been saying, cyber is now a material business risk, we now have NIST saying, and of course the SEC is now and has been saying this for months and months and months. And I think this is a wonderful turn of affairs.

Jake Bernstein: So I think talking about this new function govern, it's obviously the single biggest change. The CSF was almost defined by identify, detect, protect, respond, recover. And now you add govern. And what I like about it too is they didn't just take from identify. They really did scrape around in all of the other functions and pull out those aspects that honestly never really fit. And as part of that, and you mentioned this in your review, Kip, is it's actually clarified some of the other, particularly at the activity level, a number of the other functions and the activities within them, in a way that I think is actually going to make... It's going to make the whole CSF even more useful to business.

Kip Boyle: I agree. I also saw somebody post on LinkedIn this morning, because the initial reactions are starting to show up on social media. And somebody said, and I thought this was interesting, I haven't totally made up my mind about this yet, but they said, "The govern function itself would be worth adopting even if you didn't want to adopt any other aspect of the framework." And then somebody else said that they thought that the govern function out of the framework plus ISO 27,001, would be a killer combination. And I don't know about that, but I just thought it was interesting that people, as you just said, Jake, are really focused on the fact that we have a new function, it's called govern. People are looking at it and they like what they see. I think that's fantastic.

Jake Bernstein: And what's the corporate acronym that I am blanking on that everyone uses? Govern, GRC.

Kip Boyle: Oh, yeah.

Jake Bernstein: Governance, risk and compliance, right?

Kip Boyle: Yep.

Jake Bernstein: It's a long time concept in corporate management. And it was always a little odd that there wasn't an explicit govern function in the CSF. So I'm glad to see it's there. It makes a lot of sense. But what else is there? This is meant to be an overview episode of version 2.0. So what else do we have?

Kip Boyle: Okay, so remember how I said that the document itself is fewer pages because a lot of the content has been moved. Well, so one of the things that they did is in the core of the framework, all the way to the right-hand side, there used to be a column that was called informative references. And they've taken that out and in its place they've released an annex to the framework, and they have a new column called implementation examples. And by the way, they have another... They've done something else that I want to mention too, which is, and then we'll dive back into implementation examples.

But one of the things about the informative reference column is it used to say, "Well, this outcome or subcategory maps to this control in 800-53, this control in 27,001, this control in COVID," so forth. Well, that was really... That column got stale fast. So they've taken that out and now they're going to have a tool, an online tool, that is going to take the place of that informative reference column, and then they're going to expand that tool to have a lot more functionality, and they're going to be able to keep it updated more. There's a whole lot we could talk about there.

Jake Bernstein: That's exciting. We can't talk about it yet for what the most important reason being that it hasn't been released at the time of recording. It almost certainly will be out by the time this podcast episode airs.

Kip Boyle: Yeah, or version one of it. They do have a roadmap. There's a three iteration process that they're going through. And ultimately their vision is that when you use the framework and you want to access supplemental materials, let's say you want to browse 800-53, that catalog for relevant controls. Well, today, when you do that, and I know I do it all the time, I have to manually search in the 800-53 and I have to browse around.

Jake Bernstein: Like a brutish savage from the distant Stone Age, Kip.

Kip Boyle: Yeah, I practically have to turn paper.

Jake Bernstein: I know. Do you have to go and dig through books, like in the old law libraries?

Kip Boyle: Yeah. Dusty Tomes, I'm Gandalf searching for, does Bilbo have the one ring?

Jake Bernstein: Okay. But joking aside, it really does slow you down. And I think it's going to be really, really nice to have this.

Kip Boyle: It's going to be database driven, so it's going to not only show you the relevant 800-53 stuff, but hopefully at the click of a mouse, it's going to show you all kinds of other stuff that could be useful to you. Also, the privacy stuff too. Anyway.

Jake Bernstein: And you know what? I bet it's also going to... They have another risk management framework, Kip, and you and I haven't spent a lot of time talking about it, but the AI risk management framework I'm sure will also be incorporated.

Kip Boyle: Yep. And RMF, there's all kinds of good stuff. Now, let's go back to implementation examples, since I went down that rabbit hole. Okay, this is a new feature. I love it. There are 360, roughly, implementation examples at the third level of detail in version 2.0 Of the framework, so the subcategory level. Now, these aren't controls, you still need to get controls. But I think of these implementation examples as a bridge between an outcome and the controls that you need. And I'm looking at the clock, and I think we have time. I wonder if I should provide an example.

Jake Bernstein: I think you should.

Kip Boyle: All right, let's do it.

Jake Bernstein: Do it.

Kip Boyle: Okay, let's choose an outcome. I'm going to choose one out of the new governance function, Why not, GV.SC-4, and this comes out of the supply chain activity in the governance function. And it's a real simple one. It says, suppliers are known and prioritized by criticality. That's all it says. So you have to know who your suppliers are, and you have to have some sense of... It says criticality here. But I also think about risk. So if you have, "Well, without this supplier, we can't operate." So that's a highly critical supplier. But that also implies there's a lot of risk there, or that you should at least get in there and find out is there a lot of risk there? So yeah. So the implementation example that's provided, here's what it says. "Develop criteria for supplier criticality based on, for example, the sensitivity of data processed or possessed by the supplier, the degree of access to the organization's systems, and the importance of the products or services to the organization's mission." That's what it said.

Jake Bernstein: That's honestly really helpful.

Kip Boyle: Yeah, it is.

Jake Bernstein: It is really helpful, because before you just had to come up with that.

Kip Boyle: Yeah. On the fly.

Jake Bernstein: On the fly. So I think this is great. I'm tremendously excited about the potential of the new tool to really just further increase adoption of the CSF. And we've mentioned this before, at least briefly, but they've even started to translate it into other languages.

Kip Boyle: Oh yeah.

Jake Bernstein: So I think they're aware of the potential here and I think it's great.

Kip Boyle: Yeah, I do too. I haven't read all these implementation examples, but just having them there, I mean-

Jake Bernstein: Well, it's 360 of them.

Kip Boyle: Yeah, it's going to even help my team, because right now we have a knowledge base that we've built up, so when supply chain becomes a top cyber risk for a customer of ours, we have this knowledge base that we can go into and say, "Okay, what kinds of mitigations have we provided to other customers for this?" And that's just all comes from just work that we've done. Nobody else has access to that. And everything in there has been painfully created from zero. Well now we've got this. So my team can now look at these implementation examples and much, much more quickly get to the heart of the matter and deliver real value to our customers.

Jake Bernstein: And I think we've talked a lot about how they're not... The CSF is not law, right? We've mentioned this many, many times. But the funny thing about these types of standards and these types of frameworks is that they have a tendency to worm their way into becoming the law.

Kip Boyle: If they're good.

Jake Bernstein: If they're good. And you've see this with... The most extreme example of course is the New York Department of Financial Services cybersecurity rule, which is... It is directly based off of the CSF 1.1. It'll be interesting to see if the New York Agency updates their rule. I bet they will. And then also, of course, just in the course of cases coming down over time, experts will cite to it, judges may talk about it in cases, and it will worm its way into... So this is very important. And the beauty of those examples is that if you follow them, I don't want to say you're, per se, reasonable. I don't want to ever say such a thing, but you're real close.

Kip Boyle: Well, you're certainly increasing the chance that you'll be seen as reasonable should you ever have to prove it.

Jake Bernstein: Correct.

Kip Boyle: Yeah, I love that. Can we talk about some things that didn't change?

Jake Bernstein: Yeah, let's do that.

Kip Boyle: All right. And I love that these things didn't change because I don't see any better way to do this stuff. So first of all... We've always said this, this rings in my head, the NIST cybersecurity framework is not a checklist. It's not.

Jake Bernstein: Never has been.

Kip Boyle: And version 2.0 Doesn't change that. It's still not a checklist. I understand why people love checklists. Checklists are the closest thing that we're ever going to get to an easy button in our work. But that's not what we need, although I understand we desire it, but what we need is a framework. And that's what this continues to be. We are going to have to continue to put in time and effort to tailor the framework for our organization, and then to figure out what are the gaps, where are the opportunities to be better and go find the right controls. This is a good thing, even though it's work.

Jake Bernstein: It is. No, it is a good thing. And you have to do that work.

Kip Boyle: I think so. Another thing that hasn't changed is that the document continues to encourage you to profile the framework to your organization. And I think this is guidance that's gone all the way back to version 1.0. It's good guidance, because not everything in the framework applies to everybody. And this is really good because in version 1.1 and version 1.0, we almost always had to remove some things out of the framework right away because there were some subcategories or outcomes that were critical infrastructure only. And so when we worked with, for example, a professional sports team, we could take those out immediately. Now, that's an obvious example, but you should always look at the framework and say, "What doesn't apply to us?"

Some organizations actually go crazy here in a good way. And they'll say, "You know what? Since detect is our big weak area, we're just going to profile to detect. We're not going to even look at identify and all the other ones because we just already know that we need to be better at detection." And so their current profile will just be based on that one function. I don't have a problem with that. I think that's actually very good. Why should you diffuse your efforts if you already know, or strongly suspect, that that's not the best use? So you go on a current profile, you want to target profile, and then you identify your gaps and you close your gaps. Guess what? That's exactly how the cyber risk management action plan works.

Jake Bernstein: It is. It's very familiar. It just works. It's a good idea.

Kip Boyle: Yeah. It is a good idea. Now, one thing that also was not changed, which I don't know, I'm not excited by this, I'm not disappointed by this. It is what it is. But there's this thing that's been there since version 1.0 called a tier, tier one, tier two, tier three, tier four. Prior versions have said, "Hey, this is not a maturity model. We're not expecting everybody to go from whatever tier you're currently at to tier four. That's not what's expected." Well, everybody's always found that confusing. I still find it confusing. They've tweaked it a little bit, but they really haven't changed the fact that tiers are weird and confusing and I don't like them.

Jake Bernstein: And you have every right to not like them. I think that we'll continue to monitor the tiers. Maybe they'll be incorporated, maybe they won't into what we do. I think that there is... There's probably some value there.

Kip Boyle: I haven't come across a use case yet, but who knows?

Jake Bernstein: Who knows? Yep.

Kip Boyle: Yep. And then one other thing I want to mention about what's not changed is, and this really messes with some people, is it's always had a top down orientation, which is to say that you should not treat the framework like, for example, PCI DSS, which is a very bottom up type of a checklist. And then it's not just about the difference between a framework and a checklist. It's really the difference between PCI is super prescriptive. It actually wants you to have a certain key length on your TLS algorithm keys, right? It actually gets way down into the weeds.

And I know people like that because they don't have to sit there and go, "Mm, should I do 128 bits or should I go to 256?" They just want somebody to tell them. So that's really more of a bottom up approach. The framework continues to be top down, which is to say, you survey everything that you do and then you go deep in the areas where it seems like you have the most risk. And so you never really know where you're going to end up when you do this top-down approach, but it will reveal the biggest gaps. And I like that.

Jake Bernstein: I also like it because it mirrors how cyber risks should be managed overall. If managing your cyber risk from the bottom up where you have your SOC analysts down there making policy for the company through what they do and don't do, that's just not going to cut it. You need cybersecurity... Imagine a company deciding what products to make based on the bottom up decision making process. That's not how it works. And cyber risk management is the same.

Kip Boyle: Well, and I'll say one more thing about that as we move into the wrap up phase of our episode. If all we do is focus on bottom up, we're never going to uncover other things that are really important to managing cyber as a material business risk. For example, where's the checklist out there that says, "Hey, make sure that you have the right indemnification clauses in your contracts, that if you-"

Jake Bernstein: That's nowhere.

Kip Boyle: Right. It's nowhere and it would never be looked at. Where's the checklist that says, make sure that you have a public relations function that is ready to manage the organization's reputation in the case of a massive ransomware attack. Also not there.

Jake Bernstein: Not there.

Kip Boyle: But it is in this framework. And you can put your finger on that as a critical success function, and you can look at yours and ask, "Do we have what we need?" And if anybody thinks that that's too peripheral to good cyber risk management, well go read the case study on the Norse Hydro Aluminum producer, which got massively ransomware attack back to paper and pencil based operations. They did such a masterful job at recovering themselves that Microsoft actually created entire case study and made them the poster child for this is the way you do recovery. Their stock price went up based on the way they recovered from that ransomware attack. So there's so much business value there and we should be unlocking it.

Jake Bernstein: Absolutely.

Kip Boyle: I love top down framework. Anyway, those things didn't change. There's a little list.

Jake Bernstein: So what is next?

Kip Boyle: All right, so what NIST said is that they're going to have another workshop this fall, and it's going to be the final public feedback and comment opportunity. And then they're going to close the feedback process on November 4th, 2023. They say there's no plan to release another draft. That doesn't mean there won't be, because maybe they're going to hear some things in this final feedback period that will cause them to rethink that. Who knows? But if they don't release another draft, then all they would say is early 2024 is when we can expect to see the final version of CSF 2.0. And I'm taking that to mean sometime before March 31st.

Jake Bernstein: Yeah, I think that's probably fair. Yeah. Well, I think that we will definitely be spending more time talking about the CSF 2.0 and it's accompanying documentation, and definitely that online tool as it gets released. So exciting. It really is. That's just the bottom line. I think it's good for the profession, and I look forward to seeing what the final looks like.

Kip Boyle: I do too. And anybody out there who hasn't looked at this initial public draft, I suggest you go get it and just flip to the stuff that sounds the most interesting to you from all of the things that we've covered today on this episode, which is now wrapped up. So what did we talk about today? What is probably going to be in version 2.0 Of the NIST Cybersecurity Framework? Thanks for being here, Jake. Thanks to everybody else who was here, and we'll see you next time.

Jake Bernstein: See you next time.

Speaker 1: Thanks for joining us today on the Cyber Risk Management Podcast. If you need to overcome a cybersecurity hurdle that's keeping you from growing your business profitably, then please visit us at cr-map.com. Thanks for tuning in. See you next time.