Incident Response Plan

profilesepola
bd_ch_10_sect_01_03.html
Home>Computer Science homework help>Incident Response Plan

Business Impact Analysis

The business impact analysis (BIA) An investigation and assessment of adverse events that can affect the organization, conducted as a preliminary phase of the contingency planning process, which includes a determination of how critical a system or set of information is to the organization’s core processes and its recovery priorities. is the first phase of the CP process. A crucial component of the initial planning stages, it serves as an investigation and assessment of the impact that various adverse events can have on the organization.

One of the fundamental differences between a BIA and the risk management processes discussed in Chapters 6 and 7 is that risk management focuses on identifying the threats, vulnerabilities, and attacks to determine which controls can protect the information. The BIA assumes that these controls have been bypassed, have failed, or have otherwise proved ineffective, that the attack succeeded, and that the adversity that was being defended against has come to fruition. By assuming the worst has happened, then assessing how that adversity will impact the organization, insight is gained regarding how the organization must respond to the adverse event, minimize the damage, recover from the effects, and return to normal operations.

The BIA begins with the prioritized list of threats and vulnerabilities identified in the risk management process discussed in Chapter 6 and enhances the list by adding the information needed to respond to the adversity. Obviously, the organization’s security team does everything in its power to stop these attacks, but as you have seen, some attacks, such as natural disasters, deviations from service providers, acts of human failure or error, and deliberate acts of sabotage and vandalism, may be unstoppable.

When undertaking the BIA, the organization should consider the following:

  1. Scope—Carefully consider which parts of the organization to include in the BIA; determine which business units to cover, which systems to include, and the nature of the risk being evaluated.

  2. Plan—The needed data will likely be voluminous and complex, so work from a careful plan to assure the proper data is collected to enable a comprehensive analysis. Getting the correct information to address the needs of decision makers is important.

  3. Balance—Weigh the information available; some information may be objective in nature, while other information may be only available as subjective or anecdotal references. Facts should be weighted properly against opinions; however, sometimes the knowledge and experience of key personnel can be invaluable.

  4. Objective—Identify what the key decision makers require for making choices in advance. Structure the BIA to bring them the information they need, organized to facilitate consideration of those choices.

  5. Follow-Up—Communicate periodically to insure process owners and decision makers will support the process and the end result of the BIA.*

    Zawada, B., and L. Evans. “Creating a More Rigorous BIA.” CPM Group, November/December 2002. Accessed 5/12/05 from www.contingencyplanning.com/archives/2002/novdec/4.aspx.

According to NIST’s SP 800-34, Rev. 1, the CPMT conducts the BIA in three stages described in the sections that follow:*

Swanson, M., P. Bowen, A. Phillips, D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1: Contingency Planning Guide for Federal Information Systems.” National Institute of Standards and Technology. Accessed 7/11/15 from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

  1. Determine mission/business processes and recovery criticality.

  2. Identify resource requirements.

  3. Identify recovery priorities for system resources.

Determine Mission/Business Processes and Recovery Criticality

The first major BIA task is the analysis and prioritization of business processes within the organization, based on their relationship to the organization’s mission. Each business department, unit, or division must be independently evaluated to determine how important its functions are to the organization as a whole. For example, recovery operations would probably focus on the IT Department and network operation before turning to the Personnel Department’s hiring activities. Likewise, recovering a manufacturing company’s assembly line is more urgent than recovering its maintenance tracking system. This is not to say that personnel functions and assembly line maintenance are not important to the business, but unless the organization’s main revenue-producing operations can be restored quickly, other functions are irrelevant.

Note that throughout this section, the term mission/business process is used, as some agencies that adopt this methodology aren’t businesses and thus don’t have business processes per se. Don’t let the term confuse you. Whenever you see the term, it’s essentially describing a business process A task performed by an organization or one of its units in support of the organization’s overall mission. . NIST prefers this term, although the term business process is just as accurate.

It is important to collect critical information about each business unit before beginning the process of prioritizing the business units. The important thing to remember is to avoid “turf wars” and instead focus on the selection of those business functions that must be sustained in order to continue business operations. While one manager or executive might feel that his or her function is the most critical to the organization, that particular function might prove to be less critical in the event of a major incident or disaster. It is the role of senior management to arbitrate these inevitable conflicts about priority; after all, senior management has the perspective to make these types of trade-off decisions.

A weighted table analysis (WTA), sometimes called a weighted factor analysis, can be useful in resolving the issue of what business function is the most critical. The CPMT can use this tool by first identifying the characteristics of each business function that matter most to the organization—the criteria. The team should then allocate relative weights to each of these criteria. Each of the criteria is assessed on its influence toward overall importance in the decision-making process. Once the characteristics to be used as criteria have been identified and weighted (usually as columns in a worksheet), the various business functions are listed (usually as rows on the same worksheet). Each business function (row) is assessed a score for each of the criteria (column). Once this activity has been accomplished, the weights can be multiplied against the scores in each of the criteria, and then the rows are summed to obtain the overall scored value of the function to the organization. In the process just described, the higher the value computed for a given business function, the more important that function is to the organization.

A BIA questionnaire is an instrument used to collect relevant business impact information for the required analysis. It is useful as a tool for identifying and collecting information about business functions for the analysis just described. It can also be used to allow functional managers to directly enter information about the business processes within their area of control, their impacts on the business, and dependencies that exist for the functions from specific resources and outside service providers.

NIST Business Process and Recovery Criticality

NIST’s SP 800-34, Rev. 1 recommends that organizations use categories like low impact, moderate impact, or high impact for the security objectives of confidentiality, integrity, and availability (NIST’s Risk Management Framework [RMF] Step 1). Note that large quantities of information are assembled and a data collection process is essential if all meaningful and useful information collected in the BIA process is to be made available for use in the overall CP development process.

When organizations consider recovery criticality, key recovery measures are usually described in terms of how much of the asset they must recover within a specified time frame. The terms most commonly used to describe this value are:

  • Recovery time objective (RTO) The maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported business processes, and the MTD.

  • Recovery point objective (RPO) The point in time before a disruption or system outage to which business process data can be recovered after an outage, given the most recent backup copy of the data.

  • Maximum tolerable downtime (MTD) The total amount of time the system owner or authorizing official is willing to accept for a business process outage or disruption. The MTD includes all impact considerations.

  • Work recovery time (WRT) The amount of effort (expressed as elapsed time) needed to make business functions work again after the technology element is recovered. This recovery time is identified by the RTO.

The difference between RTO and RPO is illustrated in Figure 10-3. WRT typically involves the addition of nontechnical tasks required for the organization to make the information asset usable again for its intended business function. The WRT can be added to the RTO to determine the realistic amount of elapsed time required before a business function is back in useful service, as illustrated in Figure 10-4.

Figure 10-3. RTO vs. RPO NIST Business Process and Recovery Criticality Source: http://networksandservers.blogspot.com/2011/02/high-availability-terminology-ii.html. Figure 10-4. RTO, RPO, MTD, and WRT NIST Business Process and Recovery Criticality Source: http://networksandservers.blogspot.com/2011/02/high-availability-terminology-ii.html.

Failing to determine MTD, NIST goes on to say, “could leave contingency planners with imprecise direction on

  • (1)

    selection of an appropriate recovery method, and

  • (2)

    the depth of detail that will be required when developing recovery procedures, including their scope and content.”*

    Swanson, M., P. Bowen, A. Phillips, D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1: Contingency Planning Guide for Federal Information Systems.” National Institute of Standards and Technology. Accessed 7/11/15 from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

Determining the information system resource’s RTO, NIST adds, “is important for selecting appropriate technologies that are best suited for meeting the MTD.”* As for reducing RTO, that requires mechanisms to shorten the start-up time or provisions to make data available online at a failover site.

Swanson, M., P. Bowen, A. Phillips, D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1: Contingency Planning Guide for Federal Information Systems.” National Institute of Standards and Technology. Accessed 7/11/15 from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

Unlike RTO, NIST adds, “RPO is not considered as part of MTD. Rather, it is a factor of how much data loss the mission/business process can tolerate during the recovery process.”* Reducing RPO requires mechanisms to increase the synchronicity of data replication between production systems and the backup implementations for those systems.

Swanson, M., P. Bowen, A. Phillips, D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1: Contingency Planning Guide for Federal Information Systems.” National Institute of Standards and Technology. Accessed 7/11/15 from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

Because of the critical need to recover business functionality, the total time needed to place the business function back in service must be shorter than the MTD. Planners should determine the optimal point to recover the information system to in order to meet BIA-mandated recovery needs while balancing the cost of system inoperability against the cost of the resources required for restoring systems. This must be done in the context of the BIA-identified critical business processes and can be shown with a simple chart, such as the one in Figure 10-5.

Figure 10-5. Cost Balancing NIST Business Process and Recovery Criticality

The longer an interruption to system availability remains, the more impact and cost it will have for the organization and its operations. When plans require a short RTO, the solutions that will be required are usually more expensive to design and use. For example, if a system must be recovered immediately it will have an RTO of 0. These types of solutions will require fully redundant alternative processing sites and will therefore have much higher costs. On the other hand, a longer RTO would allow a less expensive recovery system. Plotting the cost balance points will show an optimal point between disruption and recovery costs. The intersecting point, labeled the cost balance point in Figure 10-5, will be different for every organization and system, based on the financial constraints and operating requirements.*

Swanson, M., P. Bowen, A. Phillips, D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1: Contingency Planning Guide for Federal Information Systems.” National Institute of Standards and Technology. Accessed 7/11/15 from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

Information Asset Prioritization

As the CPMT conducts the BIA, it will be assessing priorities and relative values on mission/business processes. To do so, it needs to understand the information assets used by those processes. The presence of high-value information assets may influence the valuation of a particular business process. Normally, this task would be performed as part of the risk-assessment function within the risk management process. The organization should identify, classify, and prioritize its information assets, placing classification labels on each collection or repository of information in order to better understand its value and to prioritize its protection. If the organization has not performed this task, the BIA process is the appropriate time to do so.

Identify Resource Requirements

Once the organization has created a prioritized list of its mission/business processes, it needs to determine what resources would be required in order to recover those processes and the assets associated with them. Some processes are resource intensive—like IT functions. Supporting customer data, production data, and other organizational information requires extensive quantities of information processing, storage, and transmission (through networking). Other business-production–oriented processes require complex or expensive components to operate. For each process (and information asset) identified in the previous BIA stage, the organization should identify and describe the relevant resources needed to provide or support that process. A simplified method for organizing this information is to put it into a resource/component table, like the example shown in Table 10-1. Note in the table how one business process will typically have multiple components, each of which must be enumerated separately.

Table 10-1. Example Resource/Components Table

Mission/Business Process Required Resource Components Additional Resource Details Description and Estimated Costs
Provide customer support (help desk) Trouble ticket and resolution application Application server w/LINUX OS, Apache server, and SQL database Each help desk technician requires access to the organization’s trouble ticket and resolution software application, hosted on a dedicated server. See current cost recovery statement for valuation.
Provide customer support (help desk) Help desk network segment 25 Cat5e network drops, gigabit network hub The help desk applications are networked and require a network segment to access. See current cost recovery statement for valuation.
Provide customer support (help desk) Help desk access terminals 1 laptop/PC per technician, with Web-browsing software The help desk applications require a Web interface on a laptop/PC to access. See current cost recovery statement for valuation.
Provide customer billing Customized accounts receivable application Application server with Linux OS, Apache server, and SQL database Accounts Receivable requires access to its customized AR software and customer database to process customer billing. See current cost recovery statement for valuation.

Identify System Resource Recovery Priorities

The last stage of the BIA is prioritizing the resources associated with the mission/business processes, which provides a better understanding of what must be recovered first, even within the most critical processes. With the information from previous steps in hand, the organization can create additional weighted tables of the resources needed to support the individual processes. By assigning values to each resource, the organization will have a custom-designed “to-do” list available once the recovery phase commences. Whether it is an IR- or DR-scaled recovery or the implementation of critical processes in an alternate site during business continuity, these lists will prove invaluable to those who are tasked to establish (or reestablish) critical processes quickly.

In addition to the weighted tables described earlier, a simple valuation and classification scale, such as Primary/Secondary/Tertiary, or Critical/Very Important/Important/Routine, can be used to provide a quicker method of valuating the supporting resources. What is most important is not to get so bogged down in the process that you lose sight of the objective (the old “can’t see the forest for the trees” problem). Teams that spend too much time developing and completing weighted tables may find a simple classification scheme more suited for their task. However, in a complex process with a large number of resources, a more sophisticated valuation method like the weighted tables may be more appropriate. One of the jobs of the CPMT, while preparing to conduct the BIA, is to determine what method of valuating processes and their supporting resources should be used.

Listen webReader by ReadSpeaker Open/close toolbar