Incident Response Plan

sepola
bd_ch_10_sect_01_01.html
Home>Computer Science homework help>Incident Response Plan

Fundamentals of Contingency Planning

The overall process of preparing for unexpected adverse events is called contingency planning (CP) The actions taken by senior management to specify the organization’s efforts and actions if an adverse event becomes an incident or disaster. This planning includes incident response, disaster recovery, and business continuity efforts, as well as preparatory business impact analysis. . During CP, the IT and InfoSec communities of interest position their respective organizational units to prepare for, detect, react to, and recover from events that threaten the security of information resources and assets, including human, information, and capital. The main goal of CP is to restore normal modes of operation with minimal cost and disruption to normal business activities after an unexpected adverse event—in other words, to make sure things get back to the way they were within a reasonable period of time. Ideally, CP should ensure the continuous availability of information systems to the organization even in the face of the unexpected.

CP consists of four major components:

  • Business impact analysis (BIA)

  • Incident response plan (IR plan)

  • Disaster recovery plan (DR plan)

  • Business continuity plan (BC plan)

The BIA is a preparatory activity common to both CP and risk management, which was covered in Chapters 6 and 7. It helps the organization determine which business functions and information systems are the most critical to the success of the organization. The IR plan focuses on the immediate response to an incident. Any unexpected adverse event is treated as an incident, unless and until a response team deems it to be a disaster. Then the DR plan, which focuses on restoring operations at the primary site, is invoked. If operations at the primary site cannot be quickly restored—for example, when the damage is major or will affect the organization’s functioning over the long term—the BC plan occurs concurrently with the DR plan, enabling the business to continue at an alternate site, until the organization is able to resume operations at its primary site or select a new primary location.

Depending on the organization’s size and business philosophy, IT and InfoSec managers can either

  • (1)

    create and develop these four CP components as one unified plan or

  • (2)

    create the four separately in conjunction with a set of interlocking procedures that enable continuity.

Typically, larger, more complex organizations create and develop the CP components separately, as the functions of each component differ in scope, applicability, and design. Smaller organizations tend to adopt a one-plan method, consisting of a straightforward set of recovery strategies.

Ideally, the chief information officer (CIO), systems administrators, the chief information security officer (CISO), and key IT and business managers should be actively involved during the creation and development of all CP components, as well as during the distribution of responsibilities among the three communities of interest. The elements required to begin the CP process are: a planning methodology; a policy environment to enable the planning process; an understanding of the causes and effects of core precursor activities, known as the BIA; and access to financial and other resources, as articulated and outlined by the planning budget. Each of these is explained in the sections that follow. Once formed, the contingency planning management team (CPMT) The group of senior managers and project members organized to conduct and lead all CP efforts. begins developing a CP document, for which NIST recommends using the following steps:

  1. Develop the CP policy statement. A formal policy provides the authority and guidance necessary to develop an effective contingency plan.

  2. Conduct the BIA. The BIA helps identify and prioritize information systems and components critical to supporting the organization’s mission/business processes. A template for developing the BIA is provided to assist the user.

  3. Identify preventive controls. Measures taken to reduce the effects of system disruptions can increase system availability and reduce contingency life cycle costs.

  4. Create contingency strategies. Thorough recovery strategies ensure that the system may be recovered quickly and effectively following a disruption.

  5. Develop a contingency plan. The contingency plan should contain detailed guidance and procedures for restoring damaged organizational facilities unique to each business unit’s impact level and recovery requirements.

  6. Ensure plan testing, training, and exercises. Testing validates recovery capabilities, whereas training prepares recovery personnel for plan activation and exercising the plan identifies planning gaps; combined, the activities improve plan effectiveness and overall organization preparedness.

  7. Ensure plan maintenance. The plan should be a living document that is updated regularly to remain current with system enhancements and organizational changes.*

    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/12/15 from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

Source: NIST

Even though the NIST methodologies are used extensively in this chapter, NIST actually treats incident response separately from contingency planning; the latter is focused on disaster recovery and business continuity. This chapter attempts to integrate the approach to contingency planning in NIST SP 800-34, Rev. 1 with the guide to incident handling in NIST SP 800-61, Rev. 2.

Effective CP begins with effective policy. Before the CPMT can fully develop the planning document, the team must receive guidance from executive management, as described earlier, through formal CP policy. This policy defines the scope of the CP operations and establishes managerial intent in regard to timetables for response to incidents, recovery from disasters, and reestablishment of operations for continuity. It also stipulates responsibility for the development and operations of the CPMT in general and may also provide specifics on the constituencies of all CP-related teams. It is recommended that the CP policy contain, at a minimum, the following sections:

  • An introductory statement of philosophical perspective by senior management as to the importance of CP to the strategic, long-term operations of the organizations.

  • A statement of the scope and purpose of the CP operations, stipulating the requirement to cover all critical business functions and activities.

  • A call for periodic (e.g., yearly) risk assessment and BIA by the CPMT, to include identification and prioritization of critical business functions (while the need for such studies is well understood by the CPMT, the formal inclusion in policy reinforces that need to the rest of the organization).

  • A description of the major components of the CP to be designed by the CPMT, as described earlier.

  • A call for, and guidance in, the selection of recovery options and BC strategies.

  • A requirement to test the various plans on a regular basis (e.g., semiannually, annually, or more often as needed).

  • Identification of key regulations and standards that impact CP planning and a brief overview of their relevance.

  • Identification of key individuals responsible for CP operations, such as establishment of the chief operations officer (COO) as CPMT lead, the CISO as IR team lead, the manager of business operations as DR team lead, the manager of information systems and services as BC team lead, and legal counsel as crisis management team lead.

  • An appeal to the individual members of the organizations, asking for their support and reinforcing their importance as part of the overall CP process.

  • Additional administrative information, including the original date of the document, revision dates, and a schedule for periodic review and maintenance.

A number of individuals and teams are involved in CP and contingency operations:

  • CPMT—This team collects information about the organization and about the threats it faces, conducts the BIA, and then coordinates the development of contingency plans for incident response, disaster recovery, and business continuity. The CPMT often consists of a coordinating executive and representatives from major business units and the managers responsible for each of the other three teams. It should include the following personnel:

    • Champion—As with any strategic function, the CP project must have a high-level manager to support, promote, and endorse the findings of the project. This champion could be the COO or (ideally) the CEO/president.

    • Project Manager—A champion provides the strategic vision and the linkage to the power structure of the organization but does not manage the project. A project manager—possibly a mid-level operations manager or even the CISO—leads the project, putting in place a sound project planning process, guiding the development of a complete and useful project, and prudently managing resources.

    • Team Members—The team members should be the managers or their representatives from the various communities of interest: business, IT, and InfoSec. Business managers supply details of their activities and insight into those functions critical to running the business. IT managers supply information about the at-risk systems used in the development of the BIA and the IR, DR, and BC plans. InfoSec managers oversee the security planning and provide information on threats, vulnerabilities, attacks, and recovery requirements. A representative from the legal affairs or corporate counsel’s office helps keep all planning steps within legal and contractual boundaries. A member of the corporate communications department makes sure the crisis management and communications plan elements are consistent with the needs of that group. Supplemental team members also include the planning teams: the incident response planning team The team responsible for designing and managing the IR plan by specifying the organization’s preparation, reaction, and recovery from incidents. , disaster recovery planning team The team responsible for designing and managing the DR plan by specifying the organization’s preparation, response, and recovery from disasters, including reestablishment of business operations at the primary site after the disaster. , and business continuity planning team The team responsible for designing and managing the BC plan of relocating the organization and establishing primary operations at an alternate site until the disaster recovery planning team can recover the primary site or establish a new location. . For organizations that decide to separate crisis management from disaster recovery, there may also be representatives from the crisis management planning team The individuals from various functional areas of the organization assigned to develop and implement the CM plan. .

As indicated earlier, in larger organizations these teams are distinct entities, with non-overlapping memberships, although the latter three teams have representatives on the CPMT. In smaller organizations, the four teams may include overlapping groups of people, although this is discouraged because the three planning teams (IR, DR, BC) will most likely include members of their respective response teams—the individuals who will actually respond to an incident or disaster. The planning teams and response teams are distinctly separate groups, but representatives of the response team will most likely be included on the planning team for continuity purposes and to facilitate plan development and the communication of planning activities to the response units. If the same individuals are on the DR and BC teams, for example, they may find themselves with different responsibilities in different locations at the same time. It is virtually impossible to establish operations at the alternate site if team members are busy managing the recovery at the primary site, some distance away. Thus, if the organization has sufficient personnel, it is advisable to staff the two groups with separate members.

As illustrated in the opening scenario of this chapter, many organizations’ contingency plans are woefully inadequate. CP often fails to receive the high priority necessary for the efficient and timely recovery of business operations during and after an unexpected event. The fact that many organizations do not place an adequate premium on CP does not mean that it is unimportant, however. Here is how NIST’s Computer Security Resource Center (CSRC) describes the need for this type of planning:

These procedures (contingency plans, business interruption plans, and continuity of operations plans) should be coordinated with the backup, contingency, and recovery plans of any general support systems, including networks used by the application. The contingency plans should ensure that interfacing systems are identified and contingency/disaster planning coordinated. *

Swanson, M., J. Hash, and P. Bowen. “Special Publication 800-18, Rev 1: Guide for Developing Security Plans for Information Systems.” National Institute of Standards and Technology (February 2006, p. 31). Accessed 7/12/15 from csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf.

As you learn more about CP, you may notice that it shares certain characteristics with risk management and the SecSDLC methodology. Many IT and InfoSec managers are already familiar with these processes; they can readily adapt their existing knowledge to the CP process.

Listen webReader by ReadSpeaker Open/close toolbar