Chapter 9, Disaster Recovery: Preparation and Implementation
Objectives:
This lesson is about chapter 9. Objectives important to this lesson:
Disaster classification
Forming the team
Planning functions
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
The text does not spend as much as a page on each topic, so we can assume
that it has covered the needs of each of these systems in earlier chapters.
That being the case, we don't seem to need to spend more than one week on
this chapter.
Assignments
The assignment for this week has not yet been determined.