|
|
ITS 3050 - Security Policies and Auditing
Managing Risk in Information Systems
Chapter 12, Mitigating Risk with a Business Impact Analysis
Chapter 13, Mitigating Risk with a Business Continuity Plan
Objectives:
This lesson presents two related chapters about risk mitigation planning.
Objectives important to this lesson:
- Business impact analysis
- Scope of a BIA
- Objectives of a BIA
- Steps of a BIA
- Mission critical functions and processes
- Mapping functions and processes to IT systems
- Best practices
- Business continuity plan
- Elements of a BCP
- BCP as a mitigation of organizational risk
- Best practices for BCPs
Concepts:
Chapter 12
Having mentioned a Business Impact Analysis
several times, the text presents a chapter dedicated to it. A BIA should
build a list of the assets that are critical to an organization, but it
should also let you rate how important all the other assets are as well.
The text tells us to learn three concepts that relate to a BIA:
- Maximum acceptable outage
(MAO) - if an outage falls below
this level, the business should be able to continue; if downtime
exceeds MAO, the organization cannot meet its mission
- Critical business functions
(CBFs) - a list of functions
that our organization must be able to perform to meet its mission; actions
we must be able to take
- Critical success factors (CSFs)
- a list of things that our organization depends on to perform its functions,
such as access to a running Internet, and other factors that are either
inside or outside our circle of control; things
and conditions we must have to do our business
As the text explains it, the BIA process is meant to tag the things that
are most important to our organization, whether they are IT systems, processes
and procedures, or components of a system. We are not charged with identifying
everything on this mission, that
should have already been done. We are just identifying the important
things.
That being said, we need to set the scope for our inquiry. Are we determining
the important things for all users, or a subset of all users? We should
determine who the stakeholders are for the system, the division, the location,
or the function we are documenting. It would always be better to include
stakeholders for all aspects of our organization, but there may not be
time, funding, or interest in doing a BIA for the entire organization.
In the illustration on page 319, the author shows us assets that concern
a customer making an Internet purchase. The author points out that even
short downtime for the firewalls, web server, and database server all
affect the immediate experience of the buyer. However, the buyer is not
immediately affected by longer downtime for the warehouse or the shipper.
The customer does not expect immediate shipment or delivery, unless we
have made a silly promise that such a thing will happen.
On
page 320, we see a graph that
shows time increasing along the
x-axis, and cost increasing up
the y-axis. Its point is that as outage
time increases, cost of a disruption
increases as well. In fact, the graph indicates that the longer
an outage lasts the faster the
costs go up. A second curve is also shown on that graph. It shows that
the costs to recover from an outage
diminish as time goes on. The
graph is similar to the ones you will see on this technet
web page. The argument to make from this data is that there is a point
where the two curves intersect, and that this point defines the time at
which the combination of outage cost and recovery cost is typically the
lowest.
The next section of the chapter walks through the example of the customer
making a web purchase from our organization. In pages that follow, the
text outlines a procedure to identify what is important.
- What is our organization's environment?
- Who are the stakeholders who must be satisfied?
- What are the critical business functions?
- What IT resources are involved in each function?
- What is the MAO for each resource? When considering outage time, consider
the list of costs that might accrue during an outage, presented on pages
324 through 327. Unless you have been through an outage, some of these
costs may be news to you.
- What must be true for our organization to reach "recovered" status?
- Put all this information in a report for management's consideration.
When considering the maximum acceptable outage, you should also define
what the text calls the recovery objective. You will have to specify what
conditions define "recovery" to you and your organization, else there
will be internal and external disagreements about the state of recovery
having been reached.
Just to make sure we understand the material this chapter presents, the
author presents it again, and then one more time. Oh, my.
Chapter 13
To make this chapter, like most of the others, a stand-alone chapter,
the author begins with another statement about the nature of a Business
Continuity Plan. Remember that this is the plan for continuing critical
business activities while we are experiencing some kind of crisis. To
continue conducting business we must:
- identify critical business functions (CBFs) - what are the
things our organization must do to stay in operation?
- identify critical processes that support CBFs - what are the
things we do that make the CBFs run?
- identify critical IT services that support CBFs, and identify
dependencies, other services that enable your identified services
to run
- determine acceptable downtimes for the the three lists generated
above: identified CBFs, processes, and IT services
It should be obvious that we are considering the IT needs of the business
for our part of the BCP, but we should be aware that assembling the full
BCP requires a great deal of knowledge about what the organization does,
who does what, what the management structure is, what our various locations
need to stay operational, what alternatives we have for continuing operations
when locations must halt operations, and more.
The text spends several pages trying to make general recommendations
for the information that you need to gather about the items above, and
about the things to look for that will enable you to keep them running.
It may be helpful to consider a business continuity plan as having three
operational phases that will be used while it is needed.
- notification/activation phase - Starting on page 355, the text
offers a contrast between the BCP for a hurricane, and the BCP for an
earthquake. One point is that some crises come with forewarning, like
most hurricanes, but some give no warning, like earthquakes. When we
can see a crisis coming, we can afford to take different actions based
on its magnitude, as shown in the table on page 356. Note the four
levels of hurricane intensity listed, and the differing lists
of actions and staff to notify for each one. Note that a
stage 4 hurricane requires all steps for a stage 3 hurricane, as well
as its own. This inclusion of all lower level steps continues down the
rows of the table. This BCP requires layers of notifications to various
staff that there is no time to consider in the case of an event with
more sudden onset. In those cases, we may have to take action quickly
and notify stakeholders when possible.
In addition to notification of interesedt parties, we must have a clear
statement of what conditions authorize the activation of a BCP.
The text lists four examples of activation criteria on page 357: an
imminent concern for safety, damage to a location affecting
CBFs, loss of operations affecting CBFs, and specific criteria
like an announcement of a crisis that this BCP covers. The instance
of any one of these examples would be sufficient cause to activate this
BCP.
- recovery phase - The text begins a discussion of this phase
on page 359. This is not a disaster recovery plan (DRP), which
will be confusing to most of us. This phase of the BCP only concerns
us with the repair and recovery of the items required to support
CBFs. We may do the same things that are done is a DRP, but our
scope is limited to the CBFs that mean keeping the business running.
- reconstitution phase - Again, this is a phase of the BCP, which
is limited in scope to the CBFs that were identified for the plan. As
such, it addresses the recovery from emergency operations to standard
operations, the transfer of duties from temporary locations to "permanent"
locations (as if anything is really permanent), and the return of control
to normal operations staff for CBFs.
The text cautions us to hold periodic reviews of BCPs, in conjunction
with practice sessions when and where possible.
The chapter ends with some recommendations for best practices:
- Complete the BIA early in the BCP creation process.
- Return functions from alternate locations cautiously, starting with
least critical functions.
- Review and update the BCP regularly, and when affecting changes occur.
- Test all aspects of the plan.
- Conduct exercises of the plan, to test linkages between parts.
|