On 17 August 2022, NIST conducted the first Workshop to organize the effort to update the NIST Cybersecurity Framework (CSF) to version 2.0. Praetorian originally submitted comments to the CSF 2.0 RFI in February 2022. This Workshop provided a forum for NIST to frame the discussion around the major topics that emerged from the RFI. This post will provide Praetorian’s perspective on each key topic: Governance, Measurement, Supply-Chain, Profiles, and International.
For a full review of the update process and to access the recording of the workshop (posting date TBD), reference NIST’s Updating the NIST Cybersecurity Framework – Journey To CSF 2.0 page. The associated Slack organization also contains a wealth of information and discussion on the topics that may be useful to the curious reader.
Consideration of Governance, Measurement, and Assessment
Currently, because the CSF is not a regulatory framework, many of the objectives in the CSF can be seen as aspirational or optional. In fact, we want to emphasize that the CSF is not a maturity model, nor is it a standardized control framework. Rather, the CSF is descriptive and control frameworks are prescriptive. Put differently, the CSF provides a list of objectives for which organizations must determine their own controls.
The NIST 800-53 and other related documents provide limited control guidance that some businesses choose to implement, but the key word here is “choose.” In most cases, businesses choose to set their own measurement criteria, making adherence to the NIST CSF quite subjective in practice. In contrast, other frameworks now provide more clear methods of measuring control implementations or maturity levels, such as the CIS Implementation Tiers, or the CMMI maturity model. This distinction is important because measurement plays a crucial role in governance, enabling organizations to make data driven decisions.
Ultimately, the CSF would best serve the industry by better aligning itself to pair with risk management frameworks. It does overlap with existing, dedicated risk management frameworks such as FAIR, but not to any extent that materially aids in cybersecurity program regulation. It also needs to link more directly with the actual risk management measures that organizations undertake and, potentially, have more teeth to enforce implementation.
In the shorter term, NIST plans to update the NIST 800-55 “Performance Measurement Guide for Information Security” to align it with the NIST 2.0, providing more useful control guidance for those organizations that choose to use it. However, the consensus of the conference was that the framework must maintain its flexibility regardless of the measurement attributes that accompany version 2.0. If the measurement discussion results in hard “requirements,” fewer industries and organizations will be able to customize the CSF to suit their needs, resulting in decreased adoption.
Implications for Governance and Measurement Standardization
Two secondary discussions touched on the implications of standardizing controls and enforcing requirements. The first highlighted the definition of Overall Control Effectiveness, acknowledging that measurement of the effectiveness of the CSF versus effectiveness of individual controls are two different perspectives. However, the two levels of measurement are directly related to one another. The way in which Subcategories interrelate impacts overall control effectiveness, as when a good asset management program (ID.AM-1/2) facilitates an effective vulnerability management program (PR.IP-12). Similarly, an effective IR Plan is impossible to implement if the practitioners misunderstand their organization’s Mission Statement.
The second correlated topic centered around how cyber insurance providers could use NIST CSF scoring and measurement of objectives to determine premiums in an inverse proportion. This would help immensely in justifying the expenditure needed to develop and maintain a cybersecurity program, and could help align companies to the NIST CSF. It also reinforces the need for a specific maturity model or control measurement program to facilitate this secondary application of the CSF.
Lessons Learned from Development and Use of Profiles
Profiles in the NIST CSF context are supposed to be representative implementations of the CSF on a per-industry basis. The profiles are meant to *potentially* define which CSF sub-categories should be applied, what target states should be set, and any specific considerations for the industry in question. The conference discussion largely centered on the need for more profiles and a better method for organizing them.
Industry-specific profiles are available from disparate sources, including but not limited to NIST. However, we noted a consistent pain point wherein finding vetted profiles remains difficult. Many (if not most) CSF practitioners did not have a great handle on where to access profile resources.
Therefore, to us, the most important recommendation out of this panel was for NIST to develop a process to create, submit, vet, approve, and post/host profiles in a standardized fashion. This would ease the current pain point of finding reliable profiles, and also allow practitioners to contribute back to the community in a very useful way.
International Use and Alignment
This panel provided interesting insights into how national governments and entities are utilizing the CSF, and in particular how the CSF control mapping remains US-centric. The consensus of the panel was that the CSF could benefit from an expanded set of frameworks for international partners to better align with international standards. This could further extend into the various international privacy regulations, as well. However, the greater challenge will be how the CSF can better account for all of this while maintaining flexibility.
On a more academic note, we found the panel’s corollary discussion of how other languages translate the CSF to be particularly interesting. While Praetorian does utilize the NIST CSF for assessment with international partners, we are not heavily involved in the international application of the CSF. The variety of interpretations for various words is not something we encounter in our day to day application of the CSF, but it can have a significant impact on how international organizations implement objectives and controls .
Considerations of Supply Chain Cybersecurity
Practitioners involved in this discussion agreed almost unanimously that supply-chain considerations should remain in version 2.0 of the CSF.
However, the various definitions of “supply-chain” that arose reinforced the necessity of maintaining flexibility in the new version. The CSF currently lumps together vendor supply chain, software supply chain, hardware supply chain, supply chain provider, and others. With the explosive growth of hardware devices in consumer hands (IOT), software driven processes (SaaS, open-source libraries, etc.), and the number of organizations providing software to consumers (apps, websites, etc.) the need to differentiate seems prudent. Since the approach to securing each may be vastly different, the generic “supply chain” may limit rather than enhance the flexibility of the framework.
While most practitioners are looking at supply chain risk from the perspective of a consumer, Praetorian and others believe the perspective of the producer must also factor in. The onus should be on those organizations to secure their supply chain using principles such as provenance.
Next Steps for Developing NIST CSF 2.0
This workshop was just an initial step in the process to develop version 2.0 of the NIST CSF. If history is any indicator, this process is likely to take almost a full year, so we don’t expect to see the new version published (even just for comments) until mid 2023. That being said, the NIST’s commitment to the evolution of the framework and willingness to consider such a broad range of public input definitely bolsters our confidence in the end result. Keep an eye out for more information at the NIST CSF 2.0 page linked at the top of this article if you want to be part of this process.
