Issuu

1 Copyright acknowledgement

Where relevant, information about the NIST Cybersecurity Framework 2.0 is reproduced from the following sources:

National Institute of Standards and Technology (2023) The NIST Cybersecurity Framework (CSF) 2.0 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

And from the NIST website at https://www.nist.gov/cyberframework

Please see https://www.nist.gov/nist-research-library/nist-publications for more information about NIST copyright in Technical Series Publications.

2 Introduction

This concise guide takes you through the process of implementing the NIST Cybersecurity Framework 2.0 using the CertiKit NIST CSF2 Toolkit. This version of the toolkit uses as its reference the final version of CSF 2.0 published by NIST on February 26th 2024 It provides a recommended route to framework implementation starting from a position where very little is in place. Of course, every organization is different and there are many valid ways to embed the disciplines of information security. The best way for you may well depend upon factors including:

• The size of your organization

• The country or countries in which you operate

• The culture your organization has adopted

• The industry you operate within

• The resources you have at your disposal

• Your legal, regulatory and contractual environment

View this guide simply as a pointer to where you could start and a broad indication of the order you could do things in. There is no single “right way” to improve information security; the important thing is that you end up with an information security framework that is relevant and appropriate for your specific organization’s needs.

2.1 Introducing the NIST Cybersecurity Framework

The National Institute of Standards and Technology (NIST) is a US government agency founded in 1901 by Congress (originally as the National Bureau of Standards), and forms part of the United States Department of Commerce. Initially focused on standardizing physical weights and measures, NIST’s role has expanded over time to cover many aspects of technology and its use and included the investigation into the collapse of the World Trade Center as a result of the September 11th attacks. Some aspects of NIST’s role are explicitly laid out in US legislation and in 2013 an Executive Order from President Obama (EO 13636“Improving Critical Infrastructure Cybersecurity”) mandated the creation of a Cybersecurity Framework (CSF), with the Cybersecurity Enhancement Act of 2014 placing further emphasis on NIST’s role in cybersecurity. The first version of the Framework was published in 2014 and it was updated in April 2018 with CSF 1.1.

The use of the Cybersecurity Framework was made compulsory for federal agencies by President Trump in an Executive Order (EO 13800 – “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure”) in 2017. A strong aspect of the legislation dealing with the CSF is the need for it to stay up to date, to drive improvement and to encourage close cooperation between the private and public sectors. To this end, NIST embarked on the journey to CSF 2.0 with a comprehensive program of consultation, including a series of well-attended workshops and invitations for comment.

Other significant changes include:

• Informative references will now be provided online, to provide for easier and more frequent updating

• Implementation examples will be provided to help with interpretation of the subcategories

• The use of tiers has been clarified

• Revised guidance on how to create and use framework profiles

• Clearer emphasis on improvement, with the creation of an Improvement category within the Identify function

2.3 The Main Principles of the NIST Cybersecurity Framework

The NIST CSF 2.0 consists of a number of building blocks which, when used together, allow an organization to put in place a risk-based framework tailored to their specific environment. This section explains briefly what those building blocks are.

2.3.1

Functions

Functions provide an overall structure for the framework and group together related categories as shown in Table 1. In many respects, it may help to view the first three functions as “proactive”, as they deal with the process of assessing and treating risk ahead of time, and the latter three functions as “reactive”, as they cover the more real-time process of detecting and dealing with cybersecurity incidents.

However, NIST is clear that this is not intended to be a process model, so activities may be taking place within all of the functions at the same time.

The functions are usually color-coded to provide a degree of familiarity when working with the framework.

2.3.2

• Cybersecurity risk governance

• Cybersecurity risk management

The four levels used are:

• Tier 1 – Partial

• Tier 2 – Risk informed

• Tier 3 – Repeatable

• Tier 4 – Adaptive

In effect, the tiers are similar to levels of maturity used in other frameworks, but NIST is keen to point out that not every organization needs to be at Tier 4 for both of the areas. The additional effort required to reach a higher tier needs to be cost-justified.

Tiers are an optional part of the framework and they are intended to be used at a number of different levels as appropriate, from a high level aspiration of “becoming a Tier 3 organization” to a more specific goal of “improving the Cybersecurity Supply Chain Risk Management category from Tier 2 to Tier 3”.

2.3.7 Profiles

Within the context of the CSF, a profile is a description of parts of the framework that are either in place already (a current profile) or that the organization aspires to meet (a target profile). In common terms this comparison between current state and desired state is often called a gap assessment, although this is not a term used by NIST. There is no standard way to create a profile, and it may be done at a number of different levels; for example at the highest level by function and at the lowest by subcategory. A further level of granularity can be introduced by the use of tiers (as described above).

The key output of the use of profiles is an action plan to move the organization’s cybersecurity from where it is now to where it is desired to be.

2.4 Guidance available from NIST

In line with its mandate from the US Government, NIST provides a variety of information to help organizations implement the CSF, most of which is available via its website at https://www.nist.gov/cyberframework. This includes:

• The core framework document

• NIST Cybersecurity Framework (CSF) 2.0 Reference Tool

• Quick Start Guides

• Online Learning

• Examples of Framework Profiles

• Informative Reference Catalog

• Videos, blogs, news and FAQs

We recommend you make use of these resources in addition to the CertiKit toolkit to smooth your journey to implementing the Cybersecurity Framework 2.0.

3 The CertiKit NIST CSF2 Toolkit

Relevant Toolkit documents:

• CERTIKIT – NIST CSF2 Implementation Guide

• CERTIKIT – Standard Licence Terms

• CERTIKIT NIST CSF2 Toolkit Completion Instructions

• CERTIKIT NIST CSF2 Toolkit Index

The CertiKit NIST CSF2 Toolkit (referred to within this document simply as “the Toolkit”) provides an array of useful documents which provide a starting point for the different functions, categories and subcategories of the framework. The documents are in Microsoft Office 2010® format and consist of Word documents, Excel workbooks, PowerPoint presentations and Project plans.

To open and edit the documents you will need to use the relevant Microsoft application at version 2010 or later.

3.1 How the documents work

The documents themselves have a common layout and look and feel and adopt the same conventions for attributes such as page widths, fonts, headings, version information, headers and footers. These can all be changed very easily using the various tools in Microsoft Word, including themes, styles and color palettes. Custom fields are used for the common items of information that need to be tailored such as [Organization Name] and these are easily changed in the document properties (see CERTIKIT NIST CSF2 Toolkit Completion Instructions for details of how to do this, and how to change the look of the documents using themes etc.).

Each document starts with an “Implementation Guidance” section which describes its purpose, the specific subcategories of the CSF it is relevant to, general guidance about completing and reviewing it and some legal wording about licensing etc. Once read, this section, together with the CertiKit cover page, may be removed from the final version of the document.

The layout and headings of each document have been designed to guide you carefully towards implementing the principles of the framework and example content has been provided to illustrate the type of information that should be given in the relevant place. This content is based upon an understanding of what a “typical” organization might want to say but it is very likely that your organization will vary from this profile in some ways, so you will need to think carefully about what content to keep and what to change. The key to using the Toolkit successfully is to review and update each document in the context of your specific organization. Do not accept the contents without reading them and thinking about whether they meet your needs – does the document say what you want it to say, or do you need to change various aspects to make it match the way you do things? This is particularly

relevant for policies and procedures where there is no “right” answer. The function of the document content is help you to assess what’s right for you so use due care when considering it. Where the content is very likely to need to be amended, we have highlighted these sections but please be aware that other non-highlighted sections may also make sense for you to update for your organization.

3.2 Last words before you begin

The remainder of this guide will take you through what you may need to do in each area and show how the various items in the CertiKit NIST CSF2 Toolkit will help you to implement the principles of the framework quickly and effectively.

As we have said earlier, regard this guide as helpful advice rather than as a detailed set of instructions to be followed without thought; every organization is different, and the idea of the Toolkit is that it molds itself over time to fit your specific needs and priorities.

We also appreciate that you may be limited for time and so we have kept the guidance short and to the point, covering only what we think you might need to know to achieve the intended end result. There are many great books available about information security and we recommend that, if you have time, you invest in a few and supplement your knowledge as much as possible.

But perhaps our single most important piece of advice would be to study the main components of the CSF itself. There is really no replacement for going straight to the source documents if you want to understand what it’s all about. So, by all means, listen to what other people tell you about it, but try to take some time out to go to a coffee shop or somewhere equally comfortable, and read the published materials from beginning to end We believe you will not regret it. Enough said.

4 Implementing the NIST Cybersecurity Framework 2.0

Adopting the NIST Cybersecurity Framework 2.0 is a valid choice for any organization that wishes to improve its cybersecurity. But given the breadth of the framework there are many different ways in which adoption can be approached. For the purposes of this implementation guide, we have followed the guidance of the Cybersecurity and Infrastructure Security Agency (CISA) of the US Department of Homeland Security in their publication “Commercial Facilities Sector – Cybersecurity Framework Implementation Guidance” dated May 2020. This sets out a seven-step process towards CSF adoption.

However, this is not the only valid approach; you could decide to split the project into two parts covering the proactive functions (GV, ID and PR) and the reactive functions (DE, RS and RC) and then address them one after the other or, if resources allow, in parallel. Equally, you could start at GV and address each function in turn, as each one to some extent builds on the outcomes of previous functions. Where the seven-step approach helps is in focusing your efforts on those areas of greatest need by prioritizing the risk assessment and creating a before (current profile) and after (target profile) definition.

4.1 Step 1: Prioritize and Scope

The first step is to establish what you’re trying to achieve by using the Cybersecurity Framework. This is likely to relate the improvement of cybersecurity defenses to overall business objectives and may provide the justification for the resources that will be spent on implementation. You may decide to use the CSF across the business, or to approach a subset of the organization first, for example a specific business unit or service. This step will inevitably make use of some of the categories within the Govern function of the framework, such as Organizational Context.

4.2 Step 2: Orient

Having defined your goals, the next step is to gather information about the systems, information, working practices and other relevant factors involved with the areas you have decided are in scope. This is a focused fact-finding exercise which will use many of the categories defined within the Identify function of the framework. It will also be a key input into creating the current profile and conducting the risk assessment. You should build up a clear picture not only of how your cyber infrastructure works, but also who within your organization knows most about it.

4.3 Step 3: Create a Current Profile

Before embarking on improvement efforts, it’s good to know where you’re starting from, and the creation of a current profile is intended to fulfil this purpose. The current profile lists the functions, categories and subcategories of the Cybersecurity Framework and states the extent to which the given objectives (as described in the subcategories) is met by your organization at the current time. The people you identified in the previous step who have relevant knowledge will be helpful in understanding where things currently stand. In some cases it may also state that a specific subcategory is not applicable to your organization, as not all of them may be relevant.

Part of the current profile may also cover an assessment of which of the four levels of implementation tier the organization’s risk governance, risk management and third-party cybersecurity risk management practices currently fall into.

4.4 Step 4: Conduct a Risk Assessment

Once your scope, priorities, supporting information and understanding of current controls are in place, a risk assessment can be conducted to identify areas where additional actions are desirable. These actions will reduce the organization’s overall risk level and tighten things up in specific areas. Again, the involvement of key people with accurate knowledge of how your organization works will be vital.

The risk assessment will consider the likelihood of a wide variety of potential threats coming to pass, and the impact on the organization if they were to happen. Those that score highly will be prime candidates for further action.

4.5 Step 5: Create a Target Profile

Your risk assessment will help you to create a target profile that describes where you need to be with respect to the subcategories of the CSF. This could include additional administrative, technical or procedural controls within a subcategory to reduce the likelihood of a threat occurring.

Thought should also be put into which of the four implementation tiers your organization will aspire to meeting longer term (your target tiers).

4.6 Step 6: Determine, Analyze, and Prioritize Gaps

Comparison of the current and target profiles allows a list of gaps between the two to be made, and this will form the basis of your action plan. Some actions may be more important than others, and the risk assessment should be used to help to prioritize each action.

Discussions of costs and timescales are appropriate at this stage to produce an agreed plan that is achievable.

4.7 Step 7: Implement Action Plan

The prioritized list of actions may be managed as a project, with a project manager, project plan and regular progress reports to management. The cybersecurity landscape can change quickly, so a regular eye must be kept on the identified risks and whether further actions may be warranted. A scheduled repetition of all seven steps may be sensible at a frequency that makes sense for the rate of change of the organization and the external threat environment.

Once the desired functions, categories and subcategories of the CSF are in place, the organization will benefit from an increased level of proactivity and move into a continuous improvement mode of operation that will adjust the controls in place in line with risks and needs.

5 The Functions and Categories of the Cybersecurity Framework

5.1 Govern (GV)

The addition of the Govern function is one of the main events with Version 2.0 of the framework. The idea is to establish a set of processes that provide context for the other functions within the core, and so this function is shown in diagrams of the CSF as an internal ring which touches all of the other functions.

5.1.1 Organizational Context (GV.OC)

Relevant Toolkit documents:

• InfoSec Context, Reqts and Scope

• Legal, Regulatory and Contractual Requirements Procedure

• Legal, Regulatory and Contractual Requirements

• Schedule of Confidentiality Agreements

• Non-Disclosure Agreement

• Business Impact Analysis Process

• Business Impact Analysis Report

• Business Impact Analysis Tool

Before we can manage our cybersecurity, we have to have a clear understanding of what it is we’re trying to achieve. At the highest level, this comes down to the core mission of the organization; its very reason for existence in its present form. We then need to establish who has a stake in the organization’s success (interested parties, or stakeholders) and what they need our cybersecurity program to deliver. This will help us later to identify risks that relate to any inabilities to meet those important requirements.

No organization operates in a vacuum, and there will be requirements and constraints put upon it in the form of legal obligations, possibly the needs of a regulatory body, and from contractual arrangements with third parties. All of these dictate what it is we need to achieve from our cybersecurity framework. To inform this thought process, we also need to understand the processes of the organization and their relative importance in ensuring its success. This is achieved by conducting a business impact assessment which models what would happen if each of the business processes were partially or completely disabled.

5.1.2 Risk Management Strategy (GV.RM)

Relevant Toolkit documents:

• InfoSec Objectives and Plan

• Cybersecurity Risk Management Policy

• Risk Assessment and Treatment Process

• Opportunity Assessment Tool

There are various decisions that need to be made before we can start conducting risk assessments, including how will we know if risk management is working appropriately, how much risk is acceptable to us, how cybersecurity risk management fits in with risk management in other areas, and which of the many available methods we’re going to use to assess risk.

Not all risk is bad, and we need to ensure we consider how we would capitalize on events going our way, that is, on opportunities.

5.1.3 Roles, Responsibilities, and Authorities (GV.RR)

Relevant Toolkit documents:

• InfoSec Roles Responsibilities and Authorities

• Executive Support Letter

• HR Security Policy

• Employee Screening Procedure

• Guidelines for Inclusion in Employment Contracts

• Employee Disciplinary Process

• Employee Screening Checklist

• Employee Termination and Change of Employment Checklist

• Leavers Letter

As well as the leadership of the organization showing that they are serious about cybersecurity (partly by allocating resources to it), there needs to be clear definition of relevant roles and their associated responsibilities and authorities, so that no-one is in any doubt about the part they play in protecting the organization.

Human resources practices need to embrace information security at each stage of employment and reduce the insider threat from deliberate or accidental actions.

5.1.4

Policy (GV.PO)

Relevant Toolkit documents:

• Information Security Policy

• Social Media Policy

• Information Security Whistleblowing Policy

• Internet Access Policy

• Electronic Messaging Policy

• Online Collaboration Policy

• Cloud Services Policy

• IP and Copyright Compliance Policy

• Privacy and Personal Data Protection Policy

• Remote Working Policy

• Mobile Device Policy

• BYOD Policy

• Information Deletion Policy

• Data Masking Policy

• Data Leakage Prevention Policy

It’s important that management’s intentions with regard to cybersecurity are clearly stated and communicated, and this often means creating an appropriate set of policies, processes and procedures for people to work from. Once in place, these need to be managed so that they stay up to date and that changes to them are properly reflected and recommunicated to all those that need to know about them.

5.1.5 Oversight (GV.OV)

Relevant Toolkit documents:

• Process for Monitoring, Measurement, Analysis and Evaluation

• Procedure for Management Reviews

• Management Review Meeting Agenda

There needs to be a clear method for checking that your cybersecurity framework is working as intended and this will likely involve a combination of key performance indicators and regular reviews by management to identify and tweak any areas that are not delivering. This is done with varying frequencies at each of the strategic, operational and tactical levels.

5.1.6 Cybersecurity Supply Chain Risk Management (GV.SC)

Relevant Toolkit documents:

• Cybersecurity Supply Chain Policy

• Supplier Information Security Agreement

• Supplier Due Diligence Assessment Procedure

• Supplier Information Security Evaluation Process

• Supplier Evaluation Covering Letter

• Supplier Due Diligence Assessment

• Supplier Evaluation Questionnaire

Cybersecurity supply chain risk management is a whole subject in itself, driven partly by recent breaches at major suppliers that have had dire consequences for their customers. A comprehensive program is called for, that dovetails with related risk management efforts within the organization. As well as ensuring that due diligence is carried out when suppliers are selected, there needs to be an ongoing approach that manages the risks from suppliers and encourages their adoption of effective controls.

5.2 Identify (ID)

The Identify function is about gathering together all the relevant information about hardware, software, services and data to act as a base for assessing risk within your organization. Risks are then formally assessed in the context of the threats to them, and the vulnerabilities they possess, to produce an actionable plan to take steps to reduce the overall level of risk to within acceptable bounds.

5.2.1 Asset Management (ID.AM)

Relevant Toolkit documents:

• Asset Management Policy

• Asset Inventory

• Acceptable Use Policy

• Asset Handling Procedure

• Procedure for Managing Lost or Stolen Devices

• Procedure for Taking Assets Offsite

• Procedure for the Management of Removable Media

• Physical Media Transfer Procedure

• Acceptable Use Confirmation Form

This category is about understanding the assets your organization has that need to be protected, including hardware, software, internal services, external services and data. It is likely that much of this information will be held within configuration management-related systems that automatically collect inventories of the hardware you have, the software that is installed on it, and their configuration, so making a manual list of these things is unlikely to be the best approach. It will more likely be a case of finding out where this information already exists. Services and information can be more difficult to define, so you may need to put some effort into identifying the services (internal and external) you operate and how data flows within and outside of your organization’s boundaries. Some will be more important than others, so having an idea of criticality will be useful, informed by the business impact assessment you did in the Organizational Context (GV.OC) category.

5.2.2 Risk Assessment (ID.RA)

Relevant Toolkit documents:

• Risk Assessment Report

• Risk Treatment Plan

• Threat Intelligence Policy

• Threat Intelligence Process

• Threat Intelligence Report

• Technical Vulnerability Management Policy

• Technical Vulnerability Assessment Procedure

• Change Management Process

• Asset-Based Risk Tool

• Scenario-Based Risk Tool

Based on the asset information you collected in the previous category, we now need to understand the vulnerabilities associated with those assets (particularly software) and the threats that are out there before starting our risk assessment. This will result in a risk treatment plan which will be one of your main tools in driving risk reduction and general improvement within your organization. Addressing issues such as the effective management of change is also covered within this category.

5.2.3 Improvement (ID.IM)

Relevant Toolkit documents:

• Procedure for Continual Service Improvement

• Service Improvement Plan

• Procedure for the Mgt of Nonconformity

• Nonconformity and Corrective Action Log

• Incident Lessons Learned Report

Improvement is a cross-cutting category that applies to most of the other functions and categories within the CSF. Encouraging the identification and communication of improvements from all areas is key, so you’ll need to be clear who should be notified and how they will be logged and actioned, so that improvement becomes a relentless machine for the benefit of the organization.

Having an internal audit program is a useful way to keep everyone on their toes and check that everything is being done as it should.

5.3 Protect (PR)

Having put our overall framework in place, identified our assets and then conducted a risk assessment against them, the Protect function is where we implement the relevant treatment actions to actually start reducing the risk to our organization.

5.3.1 Identity Management, Authentication, and Access Control (PR.AA)

Relevant Toolkit documents:

• Access Control Policy

• User Access Management Process

• Dynamic Access Control Policy

• Segregation of Duties Guidelines

• Physical Security Policy

• Physical Security Design Standards

• Data Centre Access Procedure

• Procedure for Working in Secure Areas

This category is about ensuring that only authorized users get access to our assets, both electronic and physical. This involves having clear policies, procedures and controls for identifying users correctly and controlling what they have access to, with additional attention given to issues such as password strength and multifactor authentication.

5.3.2

Awareness and Training (PR.AT)

Relevant Toolkit documents:

• Awareness Training Presentation

• InfoSec Competence Development Procedure

• InfoSec Competence Development Report

• Information Security Summary Card

It’s important that users are aware of their information security responsibilities, and that they are educated in the methods that might be used to try to trick them into allowing someone else access (such as phishing and social engineering). As well as the wider user population, there will be a need for more specialized training for people with larger roles to play in the cybersecurity framework of the organization, such as system administrators, auditors and managers.

5.3.3 Data Security (PR.DS)

Relevant Toolkit documents:

• Cryptographic Policy

• Records Retention and Protection Policy

• Information Classification Procedure

• Information Labelling Procedure

• Clear Desk and Clear Screen Policy

• Procedure for the Disposal of Media

• Backup Policy

• Privileged Utility Program Register

The Data Security category concerns itself with the lifecycle of the organization’s data, ensuring that it is encrypted where possible, backed up appropriately and destroyed effectively when no longer needed. It is useful to adopt a classification scheme so that resources may be focused on the most sensitive data, and to only retain them for as long as necessary. Obviously applicable data protection legislation will be relevant in this area, and the measures used must ensure compliance with these laws.

5.3.4 Platform Security (PR.PS)

Relevant Toolkit documents:

• Configuration Management Policy

• Configuration Management Process

• Configuration Standard Template

• Logging and Monitoring Policy

• Software Policy

• Secure Development Policy

• Secure Coding Policy

• Secure Development Environment Guidelines

Having dealt with the security of the data in the previous category, Platform Security covers the hardware and software that hosts that data, ensuring that it is configured and maintained correctly, that it’s monitored for suspicious events, and that bespoke code is written and implemented in a secure way. The specifics of this category will depend a lot on the platforms used (for example Microsoft, Google, AWS) and, if applicable, the development approach taken for bespoke code. Software tools will play a significant part in this area, including log management and monitoring, anti-malware and integrated development environments.

5.3.5

Technology Infrastructure Resilience (PR.IR)

Relevant Toolkit documents:

• Network Security Policy

• ICT Continuity Incident Response Procedure

• ICT Continuity Plan

• ICT Continuity Exercising and Testing Schedule

• ICT Continuity Test Plan

• ICT Continuity Test Report

• Capacity Plan

• Availability Management Policy

Further to the data and the platforms, the technology infrastructure supporting them also needs to be managed, particularly in terms of its availability. As well as designing the various components for resilience, there needs to be a documented approach to reacting to unforeseen events such as fire, flood and other environmental threats. Consideration of the current and future capacity of the infrastructure also needs to be made so that problems are not encountered due to lack of resources.

5.4 Detect (DE)

Having created our cybersecurity framework (Govern), identified the things that must be protected (Identify), assessed the risks to them and implemented a set of controls to reduce those risks (Protect), we can now sit back and wait for something to happen. The Detect function aims to raise the alarm when an event is recognized as a deliberate (or sometimes accidental) attempt to circumvent our defences and inflict some form of harm on our organization.

5.4.1

Continuous Monitoring (DE.CM)

Relevant Toolkit documents:

• Monitoring Policy

• Anti-Malware Policy

• Web Filtering Policy

• CCTV Policy

In general, the activities of this category will largely be carried out by software, ideally aided by artificial intelligence, to recognize what a normal situation looks like, and raise a flag when this normality appears to be deviated from. Services such as intrusion detection (and prevention) systems, anti-malware, log analyzers and file integrity monitors can be used to keep a close eye on the IT environment and raise a possible incident according to set rules.

That is not to say that humans don’t play a part too; monitoring of the physical environment is likely to involve a combination of technology, for example CCTV, and people, such as security guards and security-aware employees.

5.4.2 Adverse Event Analysis (DE.AE)

Relevant Toolkit documents:

• Information Security Event Reporting Procedure

• Information Security Event Assessment Procedure

One of the challenges with continuous monitoring is to avoid false positives, where the alarm is being raised too often for events that are actually normal. Each alarm needs to be evaluated to assess whether it represents a genuine incident that must be reacted to, or whether it is simply noise. Again, software helps in this, with a security information and event management (SIEM) system now being a common addition to an organization’s toolset. A SIEM system can allow various events across the infrastructure to be correlated to establish whether the set of individual clues represents an incident, or whether an event is an isolated anomaly. Cyber threat intelligence can play a part in this too, if known indicators of compromise (IoCs), which are the signature of a specific type of attack, are found at the same time.

If all the signs point to an incident, then the next function of the CSF is triggered; Respond.

5.5 Respond (RS)

In contrast to many of the proactive risk reduction activities performed in the other functions of the CSF, Respond is much more of a real-time function, where speed and coordination can pay dividends. Having a well-trained team available that has immediate access to the right tools is essential if damage to the organization is to be minimized.

5.5.1 Incident Management (RS.MA)

Relevant Toolkit documents:

• Information Security Incident Response Procedure

It’s important to have a well-defined plan available that everyone is familiar with, and systems and procedures that can cope with more than one ongoing incident at a time. Third parties, including your cyber-insurance provider and the additional resources they can give access to, should be involved where appropriate.

5.5.2

Incident Analysis (RS.AN)

Relevant Toolkit documents:

• Preservation of Evidence Guidelines

• Incident Impact Information Log

• Plan Activation Log

This category is about working out what’s happened, when and in what order. A balance needs to be struck between the urgency of reaching conclusions about points of entry and other vulnerabilities, and the need to preserve evidence for later analysis and possibly use in a prosecution.

5.5.3

Incident Response Reporting and Communication (RS.CO)

Relevant Toolkit documents:

• Personal Data Breach Notification Procedure

• InfoSec Communication Program

• Authorities Contacts

• Special Interest Group Contacts

• Personal Data Breach Notification Form

• Breach Notification Letter to Data Subjects

How you keep stakeholders informed about incidents is key to how it is perceived and limiting the resulting reputational damage. For breaches involving personally identifiable information (PII), there may be timescales for notification laid out in relevant legislation. Communication is a two-way process, where others may be able to provide you with details such as indicators of compromise to look for.

5.5.4

Incident Mitigation (RS.MI)

Relevant Toolkit documents:

• Incident Response Plan Ransomware

• Incident Response Plan Denial of Service

• Incident Response Plan Data Breach

This category is where an incident is firstly contained and then eradicated. This may be automated via software, or it may be a manual process involving isolation of affected infrastructure, followed by further investigation and restoration from backups.

5.6 Recover (RC)

Having eradicated the cause of the incident, this function deals with the process of getting things back to normal as quickly as possible, whilst ensuring that the risk of further compromise is minimized. During this process, it’s important that appropriate communications are made with those affected by the incident.

5.6.1 Incident Recovery Plan Execution (RC.RP)

Relevant Toolkit documents:

• Information Security Incident Response Procedure

Once the cause of the incident has been eradicated, the required actions must be undertaken to bring the situation back to a business as usual footing. This may involve the restoration of full or partial backups, re-initialization of hardware and software and user participation in confirming the correct operation of the systems affected. This is normally done in a prioritized order, with the most business-critical resources being addressed first. Care must also be taken that the backups used have not been compromised, as is sometimes the case with an attack such as ransomware.

5.6.2 Incident Recovery Communication (RC.CO)

Relevant Toolkit documents:

• Draft Public Update on Incident Recovery

Keeping internal and external stakeholders, such as management, customers, users and in some cases the general public, informed of what is happening is key to the post-incident perception that will exist after the situation has been resolved – that is, whether the incident was handled well, or poorly. Communication needs to be handled carefully so that it is both timely and accurate and sets expectations appropriately.

6 Conclusion

This implementation guide has taken you through the process of positioning your organization to adopt the NIST Cybersecurity Framework, supported by the CertiKit NIST CSF2 Toolkit Hopefully, you will have seen that most of what is involved is applied common sense.

Implementing the recommendations of a framework such as the CSF is always a culture change towards becoming more proactive as an organization and, with the day-to-day reactive pressures of delivering a product or service, it can sometimes seem daunting. However, we hope you will find that the Toolkit is of value in clarifying what needs to be done and speeding up the process of implementing the framework

We wish you good luck in your work and, as always, we welcome any feedback you wish to give us via feedback@certikit.com

CERTIKIT NIST CSF2 Implementation Guide V2-1

1 Copyright acknowledgement

2 Introduction

2.1 Introducing the NIST Cybersecurity Framework

2.3 The Main Principles of the NIST Cybersecurity Framework

Functions

Categories

2.3.3 Subcategories

CATEGORY

2.3.4 Implementation examples

SUBCATEGORY

IMPLEMENTATION EXAMPLES

2.3.5 Informative references

2.3.6 Tiers

2.3.7 Profiles

2.4 Guidance available from NIST

3 The CertiKit NIST CSF2 Toolkit

3.1 How the documents work

3.2 Last words before you begin

4 Implementing the NIST Cybersecurity Framework 2.0

4.1 Step 1: Prioritize and Scope

4.2 Step 2: Orient

4.3 Step 3: Create a Current Profile

4.4 Step 4: Conduct a Risk Assessment

4.5 Step 5: Create a Target Profile

4.6 Step 6: Determine, Analyze, and Prioritize Gaps

4.7 Step 7: Implement Action Plan

5 The Functions and Categories of the Cybersecurity Framework

5.1 Govern (GV)

5.1.1 Organizational Context (GV.OC)

5.1.2 Risk Management Strategy (GV.RM)

5.1.3 Roles, Responsibilities, and Authorities (GV.RR)

Policy (GV.PO)

5.1.5 Oversight (GV.OV)

5.1.6 Cybersecurity Supply Chain Risk Management (GV.SC)

5.2 Identify (ID)

5.2.1 Asset Management (ID.AM)

5.2.2 Risk Assessment (ID.RA)

5.2.3 Improvement (ID.IM)

5.3 Protect (PR)

Awareness and Training (PR.AT)

5.3.3 Data Security (PR.DS)

5.3.4 Platform Security (PR.PS)

Technology Infrastructure Resilience (PR.IR)

5.4 Detect (DE)

Continuous Monitoring (DE.CM)

5.4.2 Adverse Event Analysis (DE.AE)

5.5 Respond (RS)

5.5.1 Incident Management (RS.MA)

Incident Analysis (RS.AN)

Incident Response Reporting and Communication (RS.CO)

Incident Mitigation (RS.MI)

5.6 Recover (RC)

5.6.1 Incident Recovery Plan Execution (RC.RP)

5.6.2 Incident Recovery Communication (RC.CO)

6 Conclusion