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:

1. Business impact analysis
   
2. Scope of a BIA
   
3. Objectives of a BIA
   
4. Steps of a BIA
   
5. Mission critical functions and processes
   
6. Mapping functions and processes to IT systems
   
7. Best practices
   
   
8. Business continuity plan
   
9. Elements of a BCP
   
10. BCP as a mitigation of organizational risk
    
11. 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.

1. What is our organization's environment?
2. Who are the stakeholders who must be satisfied?
   
3. What are the critical business functions?
4. What IT resources are involved in each function?
5. 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.
6. What must be true for our organization to reach "recovered" status?
7. 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.