How to Use NIST CSF 2.0 to Identify Security Gaps (Part 5)

This is the fifth blog in a five-part series on utilizing a cybersecurity framework (NIST CSF 2.0) to establish a comprehensive cybersecurity program. If you missed the previous parts, you can find them here:

Now, in Part 5, we are moving to the end of the attack chain, focusing on recovery after a breach.

Breach (post-threat)

We have reached the final function of NIST CSF 2.0 (Recover). This post-threat phase is all about how organizations are prepared to handle a breach and get their business back up and running. Much of this phase involves pre-planning, testing, and running simulations and is closely connected with many of the activities that organizations implement in Phase 1.

Organizations must have a proper plan in place to handle the impact of the breach, deal with regulatory and legal ramifications, maintain business continuity, and re-establish trust with their customers. NIST CSF 2.0 lays out the categories and subcategories that help organizations focus on building up a proper recovery plan.

Recover

While this function is last in order and deals with the aftereffects of an incident, much of the work should be done while working on the Preparation phase. To properly handle recovery after a breach, organizations must have plans and processes in place that have been thoroughly tested to ensure they can “recover” properly and quickly. Here’s a key list of things that can guide organizations to prepare to recover properly from a breach:

1. Create a Disaster Recovery and Business Continuity (DR/BC) plan

a. Establish metrics to measure recovery

b. Develop and deliver stakeholder communication

c. Integrate the recovery plan across key business stakeholders

2. Test and validate the plans and processes

3. Conduct post-incident analysis

4. Create and implement improved security procedures

Developing the DR/BC Plan

Developing this plan from scratch will take up the bulk of the work and will likely need to involve stakeholders across different business operations within the organization. But once complete, maintaining the plan is simpler and should require less work.

The overall recover plan should be reviewed at least annually and updated or adjusted to account for changes to the business or organizational environment as well as to changes in the cybersecurity landscape and the presence of new threats and attack types. Again, this plan should be focused on all the things the organization needs to do to recover from an incident and maintain business continuity, minimizing damage and the impact of the breach as much as possible.

1. Begin by defining the scope of recovery activities

a. For example: recovering data, restoring critical systems, and getting business operations back online

b. Sequence recovery based on business impact and interdependencies.

c. Develop the processes for recovery and document configuration management

2. Specify Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO):

a. RTO: Maximum allowable downtime for critical systems

b. RPO: Maximum allowable data loss measured in time (e.g., 4 hours of data loss)

3. Establish the roles and responsibilities, and define escalation paths and decision-making authority

a. Incident Response Team

b. IT Recovery Specialists

c. Data Owners

d. Communications Team (for internal and external updates)

e. Senior Leadership for decision-making

4. Implement a proper data backup, restoration, and recovery process

a. Specify the location of backups (on-premises, cloud, offsite)

b. Define the frequency and retention of backups

c. Ensure backups are encrypted and secure

d. Develop step-by-step instructions to recover data from backups

e. Validation checks to ensure data integrity after restoration

5. Define how to handle communication (both internally and externally)

a. Notify relevant stakeholders about recovery progress and timelines

b. Inform customers, partners, and regulators as required

c. Pre-approved templates for press releases, FAQs, and notifications

6. Coordinate with Third Parties and other security vendors that have a part in the plan/process

a. Collaborate with managed service providers (MSPs), incident response vendors, and other stakeholders

7. Define compliance and legal documentation

a. Ensure all recovery activities align with regulatory requirements (e.g., GDPR, HIPAA)

Testing the Plan

The DR/BC plan is only as good as it is successful in accomplishing its goals. The only way to determine if the plan is sound is to conduct frequent testing throughout the year to validate that the processes and plans in place will be successful.

1. Test backups and data recovery

2. Test system recoveries to ensure business continuity

3. Perform tabletop exercises and simulate real-world scenarios to test the processes for breach recovery

Post-Recovery Validation and Continuous Improvement

Part of the plan should be steps required to validate the recovery, investigate, and implement ways to improve the overall security of the organization.

1. After a breach, perform incident mitigation and root cause analysis

a. Ensure vulnerabilities or threats that caused the incident are remediated

b. Perform root cause analysis and address issues before full recovery

c. Monitor for reinfection or ongoing malicious activity

2. Verify that the restored systems meet operational and security baselines

a. Confirm data accuracy and integrity

b. Ensure all affected processes are functional and effective

3. Update the recovery plan based on lessons learned from the incident

a. Schedule regular reviews and tests of the recovery plan

b. Incorporate feedback from stakeholders and simulations

Final Steps and Summary

When I first set out to write this blog series, my intention was simply to document on paper (digitally) a set of ideas and concepts for building a successful cybersecurity program. Throughout my career in the cybersecurity industry, spanning across different companies and industries, the one thing that I learned that has stuck with me is the general desire for organizations and the people who make up these organizations to help others in the fight against cyberthreats in any and all ways. With that, my goal became to provide guidance to anyone on their own journey to combat cyberthreats.

While there are many cybersecurity frameworks, I chose NIST CSF 2.0 as it is the one that I have the most experience with and have engaged with for many years. I also think the way the functions are organized is similar to how I visualize the processes of developing and implementing a cybersecurity program. Many of the ideas and suggestions I covered throughout this series are things that I have learned and picked up along my way in my 10+ year career in cybersecurity.

For organizations reading through this series, the primary takeaway should be to find a framework and process that works best for you. Select a cybersecurity framework, review it, and use it as a guide to conduct an honest self-assessment of the organization and its current security practices. Use that to identify security gaps and as a starting point for developing a plan of action.

With a semblance of a plan in place, assess the internal capabilities of your organization and the resources available. Utilize the other resources we’ve created to help determine whether building something in-house is necessary and viable, or if partnering with a third-party security provider (such as Bitdefender, offering a range of security services) is more beneficial. Then execute that plan.

I hope that this blog series has been educational, informative, and beneficial.

Also, if you’ve read through the series and are looking for assistance in implementing these best practices, contact us today to learn more.