News

ISF Resources to Support the NIST Cybersecurity Framework 2.0

Alex Jordan, Head of Security Tools & Methodologies
Published 20 - March - 2024
governance

Understanding Change: Indicative mapping now available

To help organisations and individuals understand the extent of change within the NIST CSF, and migrate to 2.0 with ease, the ISF has produced an indicative mapping document, comparing the content of versions 2.0 and 1.1.

  • This document is designed to be easy to read, for humans and machines alike, with each 2.0 Subcategory mapped (where possible) to one (or more) Subcategories in 1.1.
  • Each mapping has been provided with an alignment rating, designed to help practitioners easily understand the extent to which two Subcategories align.
  • New Subcategories in 2.0, and discarded Subcategories in 1.1, are highlighted.

This document will be updated in line with any incremental updates made by NIST, and will also be used to help align the latest version of the Standard of Good Practice for Information Security (SOGP) to the CSF 2.0 later this month.

 

Download the mapping document here

 

Expanding scope

The most impactful change to the CSF is not any specific change to Tiers, Profiles, or the Framework Core; it is, instead, the title of the CSF itself. The original version of the CSF was titled “Framework for Improving Critical Infrastructure Cybersecurity”. The updated version of the CSF, however, is simply titled “The NIST Cybersecurity Framework (CSF) 2.0”. So, what’s in a name?

The original CSF was produced with the intent to secure the United States’ critical infrastructure. In the executive summary, the CSF describes a situation whereby: “Cybersecurity threats exploit the increased complexity and connectivity of critical infrastructure systems, placing the Nation’s security, economy, and public safety and health at risk.” However, the simplicity and flexibility of the CSF meant that it was not long before organisations across the United States were looking to the CSF as a mechanism for improving their cybersecurity capabilities.

The five functions “Identify, Protect, Detect, Respond, Recover” roll off the tongue of security professionals, and help streamline messaging with senior stakeholders. The subcategories are concise and refined, yet broad enough to encompass much of a security team’s day-to-day activities. Combined with backing from the US government, the NIST CSF was perfectly positioned as a mechanism to help stem organisations’ cybersecurity woes – regardless of whether they were part of US critical infrastructure. Further, given the desire of many organisations to do business in the United States, it was only a matter of time before this national framework became an international benchmark.

Thus, the updates to the CSF acknowledge this new reality, where the CSF 2.0 has outgrown its original purpose. The preface acknowledges this change by suggesting that 2.0 is “designed to be used by organizations of all sizes and sectors” and that 1.1 was “leveraged successfully by many governments and other organizations both inside and outside of the United States”.

Whilst many changes to the CSF can be viewed independently in terms of their impact, NIST’s overall approach to the update must always be framed against the broader goal of increasing the suitability of the framework for organisations regardless of their maturity or location.

 

Good governance takes centre stage

The NIST framework core is the starting point for any organisation looking to align its cybersecurity strategy with the CSF. In the latest version of the CSF, the five original functions “Identify, Protect, Detect, Respond, Recover” have been joined by a sixth additional function: Govern. This function sits at the centre of the framework core on updated NIST documentation (see below) and is designed to inform the organisation in its efforts to achieve and prioritise the content of the other five functions.

Effective security governance should align security with business strategy but may take many years to reach effective maturity. The CSF 2.0, whilst not including timeframes, equally suggests that effective security governance will take time and energy, requiring engagement with numerous stakeholders from across the business.

The new govern function is mostly comprises subcategories drawn from other functions in the CSF 1.1 (such as ID.RM, Risk Management) with content either duplicated from, or heavily influenced by, the previous CSF. There are, however, some notable exceptions, such as the requirement to implement strategic oversight of cyber risk management, and the utilisation of a standardised method for managing risk.

ISF Members can learn more about standardised risk approaches from our risk assessment methodologies: IRAM2 and QIRA.

The strategic oversight of risk management does not simply stop at managing cyber risk. Strategic opportunities (i.e. positive risks) are explicitly called out in GV.RM-07 and must be discussed as part of cybersecurity risk discussions. This positive spin on risk reflects the maturing nature of cyber as a business function, with the recent ISF Leadership Insights paper (available on request), which showed that 97% of C-Suite members believe the security function could improve on delivering value for the amount of budget they receive.

 

Recovery is more than just good communication

In the previous version of the Cybersecurity Framework, the recover function relied significantly on the security function being a good communicator – 50% of all subcategories relate to communication activities during an incident. In 2014, with security still maturing as a business function, and with businesses not fully understanding cybersecurity as a major risk, the focus on improving communication with the rest of the business was paramount.

Fast forward a decade, and cyber security, whilst still immature in some regards, has significantly matured, and its importance to most businesses is accepted (if not always fully understood). Whilst there are still requirements in the recover function to manage both internal and external communication, the function now includes several additional requirements, such as checking the integrity of backups and ensuring the integrity of restored assets.

This shift in focus accurately reflects need for additional recovery mechanisms within increasingly complex businesses; attacks with significant impact on US infrastructure (such as the Colonial Pipeline and SolarWinds attacks) will have undoubtedly played a part in the development of additional, robust requirements in the recover space.

 

Implementation examples dig a layer deeper

One of the most interesting additions to the latest version of the CSF is the introduction of implementation examples. NIST defines these as “a concise, action-oriented, notional illustration of a way to help achieve a CSF Core outcome”, but are, in many regards, controls (or control requirements) associated with each individual subcategory.

These examples can be used by organisations to determine whether they are notionally meeting the requirement set out in any particular subcategory but shouldn’t be relied upon as a thorough breakdown of controls needed to fully meet the subcategory’s outcome.

Instead, broader control frameworks aligned to the NIST CSF, should be used to demonstrate complete effective coverage. NIST has provided mappings to additional frameworks through the means of ‘Information References’, and other organisations, such as the ISF, are working towards similarly aligning their controls, as outlined in the ISF SOGP.

Importantly, the number of implementation examples associated with each subcategory varies significantly across the CSF. For example, some subcategories in Govern have only one example associated with them (e.g. GV.OC-01), whereas others have up to 10 different associated examples (e.g. GV.SC-05). Generally, it appears that subcategories with more complex outcomes tend to be provided with more implementation examples.

As per the examples used above, GV.OC-01 requires the business to communicate its overall mission and consolidate this into cyber security risk management – a simple implementation example is provided, which suggests distributing organisational messaging through vision statements and internal marketing functions – whilst not a small feat, the requirement can still be distilled in a simple manner.

GV.SC-05, however, requires the business to address cyber security risk in supply chains and integrate it into contracts. As any security professional will know, this is a highly complex, problematic space, and worthy of additional implementation examples that can be used to arm security professionals in their conversations with suppliers and senior stakeholders.

ISF Members can benefit from using the Supplier Security suite to streamline security with suppliers.

 

Next steps

Whilst the CSF 2.0 has only just been released, there are several steps that businesses can take today to ensure alignment. NIST has released updated guidance documentation relating to NIST tiers and profiles, as well as mappings to a few major NIST publications. These materials can be used to get a good general sense of CSF 2.0 requirements, and also how these requirements align with other NIST materials.

For guidance on specific new requirements, ISF Members benefit from using existing ISF materials that can already help stay a step ahead of the curve including our Information Risk Assessment Methodology 2 (IRAM2) to standardise risk reporting and implement approaches for positive risk management or our Supplier Security WebApp to refine your management of suppliers, and the latest version of the Standard of Good Practice for Information Security (SOGP)  to implement specific controls launching end of March.

Prepare your recovery plans with Extinction Level Attacks: A survival guide, or see how you and senior management respond to a crisis by engaging with our Cyber Simulation Exercise activities.

No matter the NIST CSF requirement, the ISF is here to support your journey.