NIST Cybersecurity Framework 2.0: Recover
Authors: Mark keppler, steve foretCybersecurity Frameworks Series, part 9
Today, we will take a deep dive into the RECOVER function. The inevitable (they say) has happened and you have had a significant event. You know what happened, you’ve contained the attack. Now what?
The goal of the RECOVER function is to get back to normal to restore activities that were lost because of the incident and keep the impact of the incident as minimal as possible. The key to RECOVER is preparation so you can recover when you need to. Recovery difficult otherwise - impossible in some cases.
Sub-functions of the RECOVER function include:
Incident Recovery Plan Execution (RC.RP):
Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents.
RC.RP-01: The recovery portion of the incident response plan is executed once initiated from the incident response process,
RC.RP-02: Recovery actions are selected, scoped, prioritized, and performed,
RC.RP-03: The integrity of backups and other restoration assets is verified before using them for restoration,
RC.RP-04: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norm,
RC.RP-05: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed,
RC.RP-06: The end of incident recovery is declared based on criteria, and incident related documentation is completed.
There can be a great deal of overlap between the recovery portion of an incident response plan and a disaster recovery plan. At some organizations, they are the same plan. This category calls for testing of backups. This is a common sense control - I’m not sure how anyone could be comfortable without a successful recovery test.
While I would always recommend a documented and tested DR / BCP, cloud backup and organizations who are already largely in the cloud can make recovery easier and more straightforward. I have known some SMBs to successfully recovery without a documented plan. Complex organizations with lots of systems and applications to recovery need to understand all business processes and define a recovery priority to the most critical functions.
Incident Recovery Communication (RC.CO):
Restoration activities are coordinated with internal and external parties.
The Incident Recovery Communications category requires you to coordinate with key stakeholders (internal and external). The stakeholders should be defined as part of your recovery plan.
RC.CO-03: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders,
RC.CO-04: Public updates on incident recovery are shared using approved methods and messaging.
The Incident Response Communication category requires a communications plan. Organizations should have a policy on who is authorized to communicate externally. External communication may include the new SEC rules requiring timely disclosure of material breaches.
That concludes our deep dive into the RECOVER function. RECOVER is the last function of the CSF, however we won’t stop there. In future articles, we will help you interpret the results of a CSF Assessment, prioritize your remediation plans, and cover some other common security frameworks.
In the meantime, if you are not sure or would like to discuss, please feel free to reach out to SEVN-X. Our goal is to help you Achieve Better Cybersecurity and we’re happy to help!
Previous Blog:
Cybersecurity Frameworks Series part 8, NIST Cybersecurity Framework 2.0: Respond
Next Blog:
Cybersecurity Frameworks Series part 10, Security Framework Assessment: Interpreting Your Results