ITS 4350 - Disaster Recovery

Chapter 9, Disaster Recovery: Preparation and Implementation

Objectives:

This lesson is about chapter 9. Objectives important to this lesson:

1. Disaster classification
2. Forming the team
   
3. Planning functions
   
4. IT considerations
   

Concepts:

Chapter 9

This chapter begins with another disaster story, this time about a nearby building having a bad fire. This leads to a general discussion about disasters and disaster planning, along with some alarming statistics:

• 90% of companies having a data center disruption lasting 10 days or more went into bankruptcy
• 40% of companies that have disasters never reopen
• 30% of companies that have disasters fail within two years

The other two statistics relate to large companies, and we are not told what that means, so we will ignore them. The three statistics above should tell you to have a plan in place that will not let the disaster close your company.

Before the chapter discusses making a team and making a plan, it considers classifications for disasters. Two points of view are offered:

• natural disaster or man-made disaster - Is the disaster caused by nature, or by an act of a human being? Consider the list in table 9-1. Most of the disasters listed are clearly natural (e.g. earthquake, tornado, tsunami) while others require more detail to determine their class. Can a fire be caused by a person? How about a flood? How about other kinds of mayhem? (Cue video...)
  
  
  
  Mayhem comes in both classifications: natural and man-made. The question is what can we do to avoid or minimize the mayhem?
• The other point of view is time based. Does the disaster have a rapid onset or a slow onset? Is it more like a storm or more like global warming?
  

What should be crossing your mind now is why the category you place a disaster in should matter? Are the plans in the red books or the blue books depending on the classification? If that is how your organization works, go for it. The rest of us are going to the next topic.

As we saw in the chapter about the CSIRT, the author thinks we should form a team for Disaster Recovery. I wonder if he has considered the possibility that it is the same team? In a small company, you should expect that this is so. The author names 12 subteams on pages 374 and 375, and he suspects there may be even more teams to handle specific concerns for a large, widespread organization. His point on page 375 is good: you should form a group to handle the concerns of each item in the BIA, since those are the elements that you decided were important at the beginning of the planning process. If you need a separate group for each BIA element, you probably have a very complex organization. If one team can do the whole thing, good for them. You are better served if all the teams (however many there are) cooperate and communicate their intentions to each other. They are all building (or rebuilding) the same company. Management oversight should be quite thorough because the end result of this process is our new, improved organization.

Pages 377 and 378 discuss a plan development process drawn from NIST SP 800-34, Revision 1. This may be the first time we have been referred to this document, but it seems very much like the one that was used as a plan for the CSIRT team and its duties. The author covers each point of this outline through page 387. Get support to make the plan, consult the BIA, propose and add controls to reduce the need for the plan, plan to service the disaster, write out the plan (Duh?), test the plan, then review and maintain the plan. Familiar enough?

The text goes on with a section about specific IT concerns in a disaster recovery plan:

• client/server systems
• data communications systems
• mainframe systems