Previewing the Upcoming Changes in NIST CSF v2.0

For those who haven’t heard, NIST is in the process of updating the Cybersecurity Framework (CSF) to version 2.0, targeting a quarter 1 of 2024 release.  Since its original issue in 2014, the CSF has been a very effective foundational framework for critical infrastructure cybersecurity.  For most verticals and most maturity levels, the CSF works well.     Compared with other security-controls focused standards, the CSF supports faster (if more high level) baselining, allowing the focus to remain on driving cybersecurity improvement instead of prematurely fussing over controls interpretations and over-exerting on assessments.  After all, if your cybersecurity program is yet to be established, there is no garden for your security controls to live and thrive in the first place.

The 5 Functions of NIST CSF v1.1 will expand to 6 in v2.0 when the Governance function is added.

The relatively “light weight” aspect of the CSF lets its categories and functions serve as good framing tools for evaluating changes, considering system capabilities, and designing procedures, not just assessments .  For the consumer, it gives the “warm fuzzy” around being able to say “yes I use a framework” but it is a truly practical checklist to answer the questions of “do I have coverage of all the angles”.  An experienced assessor will easily self-select the appropriate level of details when evaluating a sub-category.  Skipping the CSF or similar leads to reinventing the wheel to create an independent framework, or risks being incomplete.  ACE has been using NIST CSF for years as a default framework if a customer asks us to engage in cybersecurity activities but does not have their own program, standards-basis, regulatory requirement, or other framework substitute/derivative.

While the draft of version 2.0 hasn’t been completed, NIST released a concept paper earlier this year describing potential changes to the CSF that may be present in version 2.0.  While NIST has done a good job summarizing their updates, consider this the greatest hits from NIST’s 17 track long double album.

KEEPING IT CURRENT

The biggest in-band change to the framework is the addition of an entire new function: Governance.  In the current CSF version, the “front matter” of the framework builds the case for governance and describes its characteristics.  When it comes to the actual functions as depicted in the graphic above, the role of governance is distributed and implicit in many of the sub-categories.  For many utilizers, it hasn’t been a challenge to drive governance improvements as part of achieving the outcomes of the other cybersecurity functions.  However, given the way in which the functions often translate into scoring and in turn quantitative discussions around resources for cybersecurity, the pragmatism of making sure governance receives necessary resources makes it a worthwhile change.
NIST is also working to keep the mechanics of using the CSF current.  This is most evident in change efforts around machine readability of the framework, continuing to create cross-references and mappings, and moving to online and updateable references using NIST’s CPRT website.  NIST is explicitly aiming to make it easier for users to reference other NIST cybersecurity frameworks and mappings to other standards.  The standard mappings are especially useful when detailing controls and designing implementations.  With the CPRT, it should soon be easier than ever to stay on top of the relevant references, no subscription to a third party risk-analysis tool required.  You can already demo the CPRT with CSF 1.1.

WHAT’S IN A NAME 

After years of going by  its nickname, the CSF is being officially renamed the “Cybersecurity Framework” instead of the “Framework for Improving Critical Infrastructure Cybersecurity”.  This name change reflects more than just a briefer title.  CSF 2.0 seeks to better signal its utility beyond critical infrastructure.  Factors driving this include an explicit congressional mandate to NIST in the Small Business Cybersecurity Act, and an existing practice of using the CSF in contexts outside of critical infrastructure.

While the suitability of the CSF beyond critical infrastructure is clear, lets hope that the re-scoping does not cause the CSF to drift from its firm basis in critical infrastructure. A variety of other digital security standards like PCSS, HIPAA, GDPR, and ISO 27001 exist to cater to the security needs of organizations outside of critical infrastructure.  At a very fundamental level, infrastructure requires keeping the focus on functionality, while data protection is often the golden jewel in non-infrastructure systems.  In a computing system this is sometimes a false dichotomy, but it is still an essential mindset along with the “proportional to real world risk” aspect when approaching security for critical digital assets.
While the de-focusing from critical infrastructure raises some concerns, it is also a reality that the median security maturity in the critical infrastructure space is still behind the median in mainline “information security”.  While major automation system manufacturers  still have not created full computing environments based on authorizable communication protocols, security providers have had to pick up all the slack in the network layer.  The fingers-crossed of broadening the audience is that mapping beyond OT will help maintain the maturity of the CSF framework in relation to the overall state of security practice.

ANNOUNCING THE NON-CHANGES

Beyond the existential nomenclature question, NIST took the opportunity in their concept paper to reinforce some things that aren’t changing.  The most comforting non-change in the NIST review is that the current level of detail is considered to be appropriate and will be maintained.  The level of detail of the CSF has always been its strong-suite.  Some notional examples will likely be added, but with no illusion of creating a baseline or being comprehensive.  It’s likely that these examples will mirror the connections to implementation that security practitioners already automatically make as “mental math”.  Making the standard more inclusive in this fashion is helps everyone by keeping stakeholders on the same page as SMEs.  Don’t worry, if the CSF feels too concise, feel free to add a row in your spreadsheet for all the 800-53 controls listed in the informative references column.  (Bonus points if you line-item all three baseline levels from your overlay controls, because triples is best).  

NIST also  clearly reinforced the necessity   of remaining technology and vendor neutral in their framework.  To do otherwise would obscure the performance-based and function-focused character of the framework that is necessary to address an actual threat instead of selling a product.  The CSF is not a controls list, it is the outcomes your controls lists achieves.  Maintaining a limited level of detail and vendor neutrality does not absolve us security practitioners of doing the necessary work to build and interpret the specifics of controls.  But the choices around controls have always been an essential part of robust program development, and controls-list based standards still require adopters to go through the process of deciding what a control means on their system and for their goals and ultimately owning their security.

For anyone looking for implementation examples right now, I’d encourage you to dig up the example CSF manufacturing profiles NIST has developed.  These gems buried on NIST’s website are helpful for those who learn best from a concrete example.  Or, feel free to reach out to ACE and schedule a cybersecurity workshop.  We can help walk you through what the typical solutions are for building your cybersecurity functions, and we can draw the picture of how that turns into computing infrastructure, systems engineering, workflows, and documentation.

Good luck fellow CSF’ers!