The First Step, The First Time (part 2)

(This blog post is the second of two; the first one is here.)

Respond and Recover are different from the other pillars in that they are not something you do on a regular basis: rather, you do them on an as-needed basis. Ideally, you never need them but no one can count on that.

Respond and Recover are two parts of what you do when there is an incident. Note that an incident can be the result of a threat, such as an attack act by a malicious human being. An incident can also be the result of a vulnerability, such as a power outage not covered by battery backup.

Respond is what you do in the short-term and Recover is what you do in the long-term. This difference in time frame is why Respond and Recover are separate: Respond is about moving as quickly as possible to restore access to whatever systems or data were affected. Recover is about moving as deliberately as possible to undo as much damage as possible. Recover also has a review component aimed at figuring out what to do to prevent future occurrences of this same problem.

However, Respond and Recover are often both covered by the Incident Response Plan (IRP). In theory, the IRP is as detailed and specific as possible. In practice, just about any IRP is better than no IRP; it is extra true in this part of C/S that the perfect must not be the enemy of the good.

Until you have gone through an Incident, it is hard to imagine how stressful one can be, and how frustrating it is to want to move as quickly as possible, but to be figuring out what to next on-the-fly. The Respond part of your IRP should be very much like a pilot's Standard Operating Procedure: a series of fairly specific check lists so that you can focus on execution rather than research. Specifically, your check list should include the names and contact information of those who need to be notified and which risk has come to pass and what steps are expected to be followed when the control for this risk has failed.

If this risk was not among those covered by your CSP, then you have no choice but to wing it. Be warned that "wing it" means "move ahead without specific preparation" and does not mean "thrash around like a headless chicken." Your immediate goal is responding to the crisis, but your next goal is presenting what you did in the Incident Report and that requires that you take good notes and move deliberately. Do not give into the temptation to worry about the details later. Worry about the details as you go. Your future self will thank you later.

The Recover phase should be less rushed and more collaborative. Alas, you will often find that it is hard to balance the twin demands of "get the system back ASAP" and "lose as little work or data as you can." Do not try to make these trade-off decisions on your own. The IRP should direct the appropriate people to make themselves available to you when you need their input. Document everything you can. Move with all deliberate speed--but no faster.

When the dust settles, avoid the temptation to sigh with relief as you put this all behind you. Take a pause, but commit to the final phase, the review. Your IRP is only as good as you make it. Every time you use it, it should get better. Do not wait too long to do the review or to share the report. The sweet oblivion of relief will steal more details from you than you might expect.

It is not easy to imagine what will happen in a situation you have never experienced, so if there a chance for you to tap someone's experience or to start with a real-world IRP for a similar organization, seize that chance with both hands. Don't be too proud to learn from someone else's experience.

If you have to do it yourself we recommend iteration: visual what would happen if your database server died, or if you were attacked by ransomware, write out a Respond check list and a Recover check list. Take a beat, perhaps do some research on the Internet about how other people have handled these situations, and revise what you have done. Get input from all appropriate colleagues for yet another draft. Every time something occurs to you or is suggested to you, revise the IRP. It is far more common that people regret how little they worked on their IRP before they needed than that people feel over-prepared when their time comes.