New NIST Cyber Recovery Guide, What’s Your Plan?

The adversaries trying to breach your cyber defenses have a plan, do you? A few weeks ago, the National Institute of Standards and Technology (NIST) released their Guide for Cybersecurity Event Recovery. The guide includes topics contained in a typical recovery plan and really boils down to documentation, communication and practice. Everyone on a recovery team – C-level officers, system administrators, application owners, general counsels, human resources and public relations personnel – need to work as a team when an incident occurs.

Proper documentation is key to a quick and prioritized recovery. Start with a playbook. Playbooks describe the formal recovery process used by the recovery team. The recovery team needs a solid understanding of the critical assets and the dependencies within the IT infrastructure that keep them available. With current knowledge of functional and security dependency maps, the recovery remains focused on critical systems first. In addition, formally define the circumstances under which the recovery plan is initiated and the recovery team is activated. Everyone has probably heard the fable of the boy who cried wolf. If you do not want to create delays in response and skepticism within the recovery teams, keep the false alarms to a minimum. 

It is very difficult to be an effective team if everyone is working independently or if the opponent knows the plan too. A coordinated and secure response is vital, therefore it is essential that communications between the recovery team members are detailed and private. For example, if the attacker has access to your organization’s email system or network traffic flow, you will have to change the way you communicate; go old school and meet in person or connect via phone until the root cause is remediated. Once the root cause is remediated, communication and documentation of actionable information and recovery insights are key to improving internal responses. 

Practice. Practice. Practice. Nobody likes it, but practice actually does make perfect. Most of us have been there at some point in our careers. Raise your hand if you have experienced high availability systems where failover capability was tested at installation but never again in fear of a network or system outage; or have gone through an exercise where all networks were down yet the recovery team participating in the exercise was still coordinating efforts using email or VoIP phones. Practicing can either expose flaws in the playbook or provide confidence that the playbook is ready for the real game. Of course the practice schedule needs to make sense for the organization, but as a general rule-of-thumb should be performed at least once a year.

The playbook will constantly be evolving due to personnel changes, technology additions, corporate acquisitions and technology retirements. Yes, technology retirements. In my experience, most waivers from security requirements are requested for hardware and applications that just keep on running (whether it be government organizations still using mainframes from the 1960’s or financial institutions that still have not upgraded their ATMs off of Windows XP). The old adage, if it’s not broke don’t fix it, may help budgets and bottom lines, but also helps your adversary.

Unfortunately we live in a time where it is not a matter of if, but when an incident will occur. Having a solid plan and playbook in place before an incident is critical to lessen the impact on your organization.