NIST 800 University of Missouri Kansas City Business Continuity Plan Report Paper

User Generated

znqfobbxre123

Computer Science

NIST 800

University of Missouri Kansas City

NIST

Description

Develop a Continuity plan for your business or organizations, Ref NIST 800-34(Attached). This assignment should be 1,200 word minimum

Unformatted Attachment Preview

NIST Special Publication 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems Marianne Swanson Pauline Bowen Amy Wohl Phillips Dean Gallup David Lynes NIST Special Publication 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems Marianne Swanson Pauline Bowen Amy Wohl Phillips Dean Gallup David Lynes May 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Director Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There are references in this publication to documents currently under development by NIST in accordance with responsibilities assigned to NIST under the Federal Information Security Management Act of 2002. The methodologies in this document may be used even before the completion of such companion documents. Thus, until such time as each document is completed, current requirements, guidelines, and procedures (where they exist) remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new documents by NIST. Individuals are also encouraged to review the public draft documents and offer their comments to NIST. All NIST documents mentioned in this publication, other than the ones noted above, are available at http://csrc.nist.gov/publications. National Institute of Standards and Technology Special Publication 800-34 Natl. Inst. Stand. Technol. Spec. Publ. 800-34, 150 pages (May 2010) CODEN: NSPUE2 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. ii CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Authority This document has been developed by the National Institute of Standards and Technology (NIST) in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III. This guideline has been prepared for use by federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright. Attribution would be appreciated by NIST. Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. NIST Special Publication 800-34, Revision 1, 150 pages (May 2010) National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 iii CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Compliance with NIST Standards and Guidelines NIST develops and issues standards, guidelines, and other publications to assist federal agencies in implementing the Federal Information Security Management Act (FISMA) of 2002 and in managing costeffective programs to protect their information and information systems. 1 • Federal Information Processing Standards (FIPS) are developed by NIST in accordance with FISMA. FIPS are approved by the Secretary of Commerce and are compulsory and binding for federal agencies. Since FISMA requires that federal agencies comply with these standards, agencies may not waive their use. • Guidance documents and recommendations are issued in the NIST Special Publication (SP) 800series. Office of Management and Budget (OMB) policies (including OMB FISMA Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management) state that, for other than national security programs and systems, agencies must follow NIST guidance. 1 • Other security-related publications, including NIST interagency and internal reports (NISTIRs) and ITL Bulletins, provide technical and other information about NIST’s activities. These publications are mandatory only when so specified by OMB. While agencies are required to follow NIST guidance in accordance with OMB policy, there is flexibility within NIST’s guidance in how agencies apply the guidance. Unless otherwise specified by OMB, the 800-series guidance documents published by NIST generally allow agencies some latitude in the application. Consequently, the application of NIST guidance by agencies can result in different security solutions that are equally acceptable, compliant with the guidance, and meet the OMB definition of adequate security for federal information systems. When assessing federal agency compliance with NIST guidance, auditors, evaluators, and assessors should consider the intent of the security concepts and principles articulated within the particular guidance document and how the agency applied the guidance in the context of its specific mission responsibilities, operational environments, and unique organizational conditions. iv CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Acknowledgements The authors, Marianne Swanson and Pauline Bowen of the National Institute of Standards and Technology (NIST), Amy Wohl Phillips, Dean Gallup, and David Lynes of Booz Allen Hamilton, wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content. The authors would like to acknowledge Kelley Dempsey, Esther Katzman, Peter Mell, Murugiah Souppaya, Lee Badger, and Elizabeth Lennon of NIST, and David Linthicum of Booz Allen Hamilton for their keen and insightful assistance with technical issues throughout the development of the document. v CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Table of Contents Executive Summary....................................................................................................................1 Chapter 1. 1.1 1.2 1.3 1.4 Chapter 2. 2.1 2.2 Chapter 3. 3.1 3.2 3.3 3.4 3.5 3.6 Chapter 4. 4.1 4.2 4.3 Introduction ....................................................................................................1 Purpose....................................................................................................................... 1 Scope.......................................................................................................................... 2 Audience ..................................................................................................................... 3 Document Structure .................................................................................................... 4 Background ....................................................................................................5 Contingency Planning and Resilience ........................................................................ 5 Types of Plans ............................................................................................................ 7 2.2.1 Business Continuity Plan (BCP) ......................................................................8 2.2.2 Continuity of Operations (COOP) Plan............................................................8 2.2.3 Crisis Communications Plan............................................................................9 2.2.4 Critical Infrastructure Protection (CIP) Plan.....................................................9 2.2.5 Cyber Incident Response Plan ......................................................................10 2.2.6 Disaster Recovery Plan (DRP) ......................................................................10 2.2.7 Information System Contingency Plan (ISCP)...............................................10 2.2.8 Occupant Emergency Plan (OEP).................................................................10 Information System Contingency Planning Process................................13 Develop the Contingency Planning Policy Statement ............................................... 14 Conduct the Business Impact Analysis (BIA)............................................................ 15 3.2.1 Determine Business Processes and Recovery Criticality..............................16 3.2.2 Identify Resource Requirements ...................................................................19 3.2.3 Identify System Resource Recovery Priorities ..............................................19 Identify Preventive Controls ...................................................................................... 19 Create Contingency Strategies ................................................................................. 20 3.4.1 Backup and Recovery ...................................................................................20 3.4.2 Backup Methods and Offsite Storage............................................................21 3.4.3 Alternate Sites ...............................................................................................21 3.4.4 Equipment Replacement ...............................................................................24 3.4.5 Cost Considerations ......................................................................................25 3.4.6 Roles and Responsibilities ............................................................................26 Plan Testing, Training, and Exercises (TT&E) .......................................................... 27 3.5.1 Testing...........................................................................................................27 3.5.2 Training..........................................................................................................28 3.5.3 Exercises .......................................................................................................29 3.5.4 TT&E Program Summary ..............................................................................29 Plan Maintenance ..................................................................................................... 31 Information System Contingency Plan Development...............................34 Supporting Information.............................................................................................. 35 Activation and Notification Phase ............................................................................. 36 4.2.1 Activation Criteria and Procedure..................................................................36 4.2.2 Notification Procedures .................................................................................36 4.2.3 Outage Assessment ......................................................................................38 Recovery Phase........................................................................................................ 39 4.3.1 Sequence of Recovery Activities ...................................................................39 vi CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS 4.4 4.5 Chapter 5. 5.1 5.2 5.3 5.4 5.5 4.3.2 Recovery Procedures ....................................................................................39 4.3.3 Recovery Escalation and Notification ............................................................40 Reconstitution Phase ................................................................................................ 41 Plan Appendices ....................................................................................................... 42 Technical Contingency Planning Considerations.....................................43 Common Considerations .......................................................................................... 43 5.1.1 Use of the BIA ...............................................................................................44 5.1.2 Maintenance of Data Security, Integrity, and Backup....................................44 5.1.3 Protection of Resources ................................................................................46 5.1.4 Adherence to Security Controls.....................................................................46 5.1.5 Identification of Alternate Storage and Processing Facilities.........................46 5.1.6 Use of High Availability (HA) Processes........................................................48 Client/Server Systems .............................................................................................. 48 5.2.1 Client/Server Systems Contingency Considerations .....................................49 5.2.2 Client/Server Systems Contingency Solutions ..............................................51 Telecommunications Systems .................................................................................. 52 5.3.1 Telecommunications Contingency Considerations........................................53 5.3.2 Telecommunications Contingency Solutions.................................................54 Mainframe Systems .................................................................................................. 56 5.4.1 Mainframe Contingency Considerations........................................................56 5.4.2 Mainframe Contingency Solutions.................................................................56 System Contingency Planning Considerations Summary......................................... 57 Appendix A— Sample Information System Contingency Plan Templates ..................... A.1-1 A.1 A.2 A.3 Sample Template for Low-Impact Systems....................................................... A.1-1 Sample Template for Moderate-Impact Systems .............................................. A.2-1 Sample Template for High-Impact Systems ...................................................... A.3-1 Appendix B— Sample Business Impact Analysis (BIA) and BIA Template ...................... B-1 Appendix C— Frequently Asked Questions......................................................................... C-1 Appendix D— Personnel Considerations in Continuity and Contingency Planning........ D-1 Appendix E— Contingency Planning Controls .................................................................... E-1 Appendix F— Contingency Planning and the System Development Life Cycle (SDLC).. F-1 Appendix G— Glossary..........................................................................................................G-1 Appendix H— Acronyms........................................................................................................ H-1 Appendix I— Resources...........................................................................................................I-1 List of Figures Figure 2-1: Contingency-Related Plan Relationships ................................................................12 Figure 3-1: Contingency Planning Process................................................................................13 Figure 3-2: Business Impact Analysis Process for the Information System...............................16 Figure 3-3: Cost Balancing ........................................................................................................18 Figure 4-1: Contingency Plan Structure.....................................................................................34 vii CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Figure 4-2: Sample Call Tree.....................................................................................................37 Figure 4-3: Sample Recovery Process ......................................................................................40 Figure F-1: System Development Life Cycle ........................................................................... F-1 List of Tables Table 2-1: Summary of NIST SP 800-53 Contingency Planning Controls for Low-, Moderate-, and High-Impact Systems of Contingency-Related Plans.....................................................7 Table 2-2: Type of Plans.............................................................................................................11 Table 3-1: Information System Resource/Component Table .....................................................19 Table 3-2: FIPS 199 Category Backup & Strategy Examples....................................................20 Table 3-3: Sample Alternate Site Criteria ..................................................................................23 Table 3-4: Contingency Strategy Budget Planning Template ....................................................25 Table 3-5: ISCP TT&E Activities ................................................................................................30 Table 3-6: Sample Record of Changes......................................................................................32 Table 5-1: Summary ..................................................................................................................58 Table E-1: Summary of NIST SP 800-53 Contingency Planning Controls for Low-, Moderateand High- Impact Systems of Contingency-Related Plans................................................ E-1 Table F-1: CP Control Implementation in the SDLC ................................................................ F-4 viii CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Errata The following changes have been incorporated into Special Publication 800-34, Revision 1, as of the date indicated in the table. DATE 5/21/2010 5/21/2010 TYPE Editorial Editorial CHANGE Remove hyphenation from “Wohl Phillips” Change “mission/business functions” to “mission/business processes” 5/21/2010 Editorial Remove hyphenation from “mission essential” 5/21/2010 Editorial 5/21/2010 Editorial 5/21/2010 5/21/2010 5/21/2010 Editorial Editorial Substantive 5/21/2010 Editorial 5/21/2010 5/21/2010 Editorial Substantive 5/21/2010 Editorial 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 5/21/2010 Editorial Substantive 5/21/2010 Substantive 5/21/2010 Editorial 5/21/2010 Editorial 5/21/2010 Editorial Correct number of Contingency Planning security controls to 9 Change “information system contingency plan” to “ISCP” Change caption from “Plan Types” to “Types of Plans” Change “mission essential functions” to “MEFs” Clarify the relationship between Mean Tolerable Downtime and Recovery Point Objective Change “continuity planners” to “contingency planners” Change “missions” to “mission” Add “and scope” to the description of system backup policies specifications Change “Information Systems Planning” to “ISCP” in footnote Change “applications” to “systems” Change “information technology systems” to “information systems” Change “Special Publication” to “SP” Clarify the Contingency Plan Test/Exercise requirement for Contingency Plan Control-4 (CP-4). Change “All” to “Low Impact = Yes Mod. Impact = Yes High Impact = Yes” Add Contingency Plan Control-4 (CP-4) to the Alternate Processing Site Recovery event; Change Moderate Impact requirement from “Yes” to “N/A” Add commas around “as part of the organization’s change management process” in the plan maintenance description of reviewing and updating the ISCP Figure 4-2, Sample Call Tree, align and remove shadow Remove “and applications” from the Sequence of Recovery Activities ix PAGE NUMBER v ES-1, 1, 2, 3, 7, 8, 10, 11, 13, 15, 16, 18, 19, 20, 21, 40, 44, 47, 48, 56 A.14, A.2-4, A.3-4, B1, B-2, B-3, B-4, C1, C-2, C-3, C-4, E2, F-2, G-1, G-2 2, 5, 8, C-1, G-1, H-2 6 10 11 11, C-1, C-2 17 17 20 21 21 23, B-4 24, C-1 30 30 30 31 37 39 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS DATE 5/21/2010 TYPE Editorial 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 Editorial 5/21/2010 Substantive 5/21/2010 Editorial 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 Substantive 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 Substantial 5/21/2010 Editorial 5/21/2010 5/21/2010 Editorial Substantive 5/21/2010 Substantive 5/21/2010 Substantive 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 5/21/2010 Editorial Editorial 5/21/2010 5/21/2010 5/21/2010 11/11/2010 Editorial Editorial Editorial Substantive CHANGE Change “backup application” to “backup solution” in the description of Backup Software Change “discloser” to “disclosure” Remove “major applications and general support” from system description Change “Mission, National, or Primary Essential Functions” to “Mission, Primary, or National Essential Functions” Spell out “ISDN” as “Integrated Services Digital Network (ISDN)”; add “with a bandwith of 128Kbps” for clarification Change “Information System Contingency Plan (ISCP)” to “ISCP” Change “Contingency Plan” to “ISCP” Change “contingency plan coordinator” to “ISCP Coordinator” Change “be needed” to “need” Change “Section 4.1 of the plan” to “Section 4.2.1 of this plan”, in reference to location of system functions Add to directions for Recovery Procedures “If an alternate location is part of the recovery strategy, include procedures for recovery to that site.” Correct section numbering starting at 5.6 Change “System Validation Test Plan” to “system validation test plan” in Appendix E Clarify “at least yearly” to “at the organization defined frequency (e.g., yearly)” Change “and exercise and questions” to “and an exercise and questions” Correct reference number to Offsite Data Storage Remove “For moderate impact systems, a yearly functional test is required.” This is not a requirement. Remove “For high impact systems, a yearly functional test is required.” This is not a requirement. Change “Incident Response Plan (IRP)” to “Cyber Incident Response Plan” Add “Information System Contingency Plan” Change “operation/maintenance” to “Operation/Maintenance” Change “Business Impact Analysis (BIA)” to “BIA” Change “Primary Mission Essential Functions” to “primary mission essential functions” Add “(MTD)” after “mean tolerable downtime” Add “and Contingency” to the Appendix title Add “(BCP) after “business continuity plan” Replaced Section 5.2 with Data Functionality Testing template text and direction. Previous text was a repeat of Section 5.3. x PAGE NUMBER 45 46 54 54 55 A.1-4, A.2-4, A.34, B-1, D-1 A.1-5, A.3-5 A.1-7, A.2-7, A.3-7 A.1-7, A.2-7, A.3-7 A.1-7, A.2-7, A.3-7 A.1-8 A.1-9 A.1-12, A.2-12, A.3-12 A.1-13, A.2-14, A.3-15 A.1-13, A.2-14, A.3-15 A.2-9, A.3-10 A.2-14 A.3-15 B-1 B-1 C-2 C-2 C-3 C-3 D-1 D-1 A.3-8 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Executive Summary NIST Special Publication 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems, provides instructions, recommendations, and considerations for federal information system contingency planning. Contingency planning refers to interim measures to recover information system services after a disruption. Interim measures may include relocation of information systems and operations to an alternate site, recovery of information system functions using alternate equipment, or performance of information system functions using manual methods. This guide addresses specific contingency planning recommendations for three platform types and provides strategies and techniques common to all systems. ƒ Client/server systems; ƒ Telecommunications systems; and ƒ Mainframe systems. This guide defines the following seven-step contingency planning process that an organization may apply to develop and maintain a viable contingency planning program for their information systems. These seven progressive steps are designed to be integrated into each stage of the system development life cycle. 1. Develop the contingency planning policy statement. A formal policy provides the authority and guidance necessary to develop an effective contingency plan. 2. Conduct the business impact analysis (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 an information system contingency plan. The contingency plan should contain detailed guidance and procedures for restoring a damaged system unique to the system’s security 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. This guide presents three sample formats for developing an information system contingency plan based on low-, moderate-, or high-impact level, as defined by Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems. Each format defines three phases that govern actions to be taken following a system disruption. The Activation/Notification Phase describes the process of activating the plan based on outage impacts and notifying recovery personnel. The Recovery Phase details a suggested course of action for recovery teams to restore system operations at an alternate site or using contingency capabilities. The final phase, ES-1 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Reconstitution, includes activities to test and validate system capability and functionality and outlines actions that can be taken to return the system to normal operating condition and prepare the system against future outages. ES-2 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Chapter 1. Introduction Information systems are vital elements in most mission/business processes. Because information system resources are so essential to an organization’s success, it is critical that identified services provided by these systems are able to operate effectively without excessive interruption. Contingency planning supports this requirement by establishing thorough plans, procedures, and technical measures that can enable a system to be recovered as quickly and effectively as possible following a service disruption. Contingency planning is unique to each system, providing preventive measures, recovery strategies, and technical considerations appropriate to the system’s information confidentiality, integrity, and availability requirements and the system impact level. Information system contingency planning refers to a coordinated strategy involving plans, procedures, and technical measures that enable the recovery of information systems, operations, and data after a disruption. Contingency planning generally includes one or more of the following approaches to restore disrupted services: ƒ Restoring information systems using alternate equipment; ƒ Performing some or all of the affected business processes using alternate processing (manual) means (typically acceptable for only short-term disruptions); ƒ Recovering information systems operations at an alternate location (typically acceptable for only long–term disruptions or those physically impacting the facility); and ƒ Implementing of appropriate contingency planning controls based on the information system’s security impact level. This document provides guidelines to individuals responsible for preparing and maintaining information system contingency plans (ISCPs). The document discusses essential contingency plan elements and processes, highlights specific considerations and concerns associated with contingency planning for various types of information system platforms, and provides examples to assist readers in developing their own ISCPs. 1.1 Purpose This publication assists organizations in understanding the purpose, process, and format of ISCP development through practical, real-world guidelines. While the principles establish a baseline to meet most organizational needs, it is recognized that each organization may have additional requirements specific to its own operating environment. This guidance document provides background information on interrelationships between information system contingency planning and other types of security and emergency management-related contingency plans, organizational resiliency, and the system development life cycle (SDLC). The document provides guidance to help personnel evaluate information systems and operations to determine contingency planning requirements and priorities. Requirements from FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, security impact levels, and NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations contingency planning controls are integrated throughout the guideline. Considerations for impact levels and associated security controls for contingency planning are presented to assist planners in developing the appropriate contingency planning strategy. Although the information presented in this document is largely independent of particular hardware platforms, operating systems, and applications, technical considerations specific to common information system platforms are addressed. CHAPTER 1 1 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS 1.2 Scope This document is published by NIST as recommended guidelines for federal organizations. To assist personnel responsible for developing contingency plans, this document discusses common technologies that may be used to support contingency capabilities. Given the broad range of information system designs and configurations, as well as the rapid development and obsolescence of products and capabilities, the scope of the discussion is not intended to be comprehensive. Rather, the document describes technology practices to enhance an organization’s information system contingency planning capabilities. These guidelines present contingency planning principles for the following common platform types: ƒ Client/server systems; ƒ Telecommunications systems; and ƒ Mainframe systems. The document outlines planning principles for a wide variety of incidents that can affect information system operations. These range from minor incidents causing short-term disruptions to disasters that affect normal operations for an extended period. Because information systems vary in design and purpose, specific incident types and associated contingency measures are not addressed in this guide. Instead, a defined process is provided for identifying planning requirements needed to develop an effective contingency plan for any information system. This document does not address facility-level information system planning (commonly referred to as a disaster recovery plan) or organizational mission continuity (commonly referred to as a continuity of operations [COOP] plan) except where it is required to restore information systems and their processing capabilities. Nor does this document address continuity of mission/business processes. Although information systems typically support mission/business processes, the processes also depend on a variety of other resources and capabilities not associated with information systems. Recovery of mission essential functions is addressed by COOP plans or business continuity plans. These plans are part of a suite of security and emergency management-related plans further described in Section 2.2. The ISCP may be prepared in coordination with disaster recovery planning, COOP planning, or business continuity planning to the degree that a particular system is necessary to provide a capability that is required during any of these events/efforts. Information in this guide is consistent with guidelines provided in other NIST documents, including NIST SP 800-53 and FIPS 199. The guidelines proposed are also consistent with federal mandates affecting contingency, continuity of operations, and disaster recovery planning, including: ƒ Federal Information Security Management Act (FISMA) of 2002; ƒ OMB Circular A-130, Management of Federal Information Resources, Appendix III, November 2000; ƒ Federal Continuity Directive (FCD)-1, Federal Executive Branch National Continuity Program and Requirements, February 2008; ƒ National Security Presidential Directive (NSPD)-51/Homeland Security Presidential Directive (HSPD)-20, National Continuity Policy, May 2007; ƒ National Continuity Policy Implementation Plan, August 2007; and ƒ National Response Framework, March 22, 2008. CHAPTER 1 2 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Federal organizations are required to comply with the above federal policies in addition to internal departmental or agency policies. Information System: An information system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.* Information system components include, but are not limited to, mainframes, servers, workstations, network components, operating systems, middleware, and applications. Network components can include, for example, such devices as firewalls, sensors (local or remote), switches, guards, routers, gateways, wireless access points, and network appliances. Servers can include, for example, database servers, authentication servers, electronic mail and Web servers, proxy servers, domain name servers, and network time servers. Information system components are either purchased commercially off-the-shelf or are custom-developed and can be deployed in landbased, sea-based, airborne, and/or space-based information systems.** * As defined by 44 U.S.C., Sec 3502. ** As defined in NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations. 1.3 Audience This document has been created for managers within federal organizations and those individuals responsible for information systems or security at system and operational levels. It is also written to assist emergency management personnel who coordinate facility-level contingencies with supporting information system contingency planning activities. The concepts presented in this document are specific to government systems, but may be used by private and commercial organizations, including contractor systems. The audience includes the following types of personnel: 2 3 4 ƒ Managers responsible for overseeing information system operations or mission/business processes that rely on information systems; 2 ƒ Chief Information Officers (CIOs) with overall responsibility for the organization’s information systems; 3 ƒ Senior Agency Information Security Officers (SAISOs) responsible for developing and maintaining the security of information systems at the organizational level; 4 ƒ Information System Security Officers (ISSOs)/Information System Security Managers (ISSMs) and other staff responsible for developing, implementing, and maintaining an information system’s security activities; ƒ System engineers and architects responsible for designing, implementing, or modifying information systems; ƒ System administrators responsible for maintaining daily information system operations; Managers include Authorizing Officials, information system owners, and information owners. For organizations without a CIO position, FISMA requires a comparable executive to have authority over the information systems. SAISOs are also called Chief Information Security Officers (CISOs). CHAPTER 1 3 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS ƒ Users who employ desktop and portable systems to perform their assigned job functions; and ƒ Other personnel responsible for designing, managing, operating, maintaining, or using information systems. 1.4 Document Structure This document is designed to logically lead the reader through the contingency plan development process. The process includes designing a contingency planning program, evaluating the organization’s needs against contingency strategy options based on the system impact levels, security controls, and technical considerations, and documenting the contingency strategy into a contingency plan, testing the plan, and maintaining it. The resulting contingency plan serves as a “user’s manual” for executing the strategy in the event of a disruption. Where possible, examples or hypothetical situations are included to provide greater understanding. The remaining chapters of this document address the following areas of contingency planning: ƒ Chapter 2, Background, provides background information about contingency planning, including the purpose of various security and emergency management-related plans, their relationships to ISCPs, and how the plans are integrated into an organization’s overall resilience strategy by implementing the six steps of the Risk Management Framework (RMF). 5 In addition, the way in which the FIPS 199 impact levels and NIST SP 800-53 contingency planning controls must be considered during the contingency planning process is also explained. ƒ Chapter 3, Information System Contingency Planning Process, details the fundamental planning principles necessary for developing an effective contingency capability. The principles outlined in this section are applicable to all information systems. The section presents contingency planning guidelines for all elements of the planning cycle, including business impact analysis, alternate site selection, and recovery strategies. The section also discusses the development of contingency plan teams and the roles and responsibilities commonly assigned to personnel during plan activation. ƒ Chapter 4, Information System Contingency Plan Development, breaks down the activities necessary to document the contingency strategy and develop the ISCP. Maintaining, testing, training, and exercising the contingency plan are also discussed in this section. ƒ Chapter 5, Technical Contingency Planning Considerations, describes contingency planning concerns specific to the three common platform types listed in Section 1.3, Scope. This section helps contingency planners identify, select, and implement the appropriate technical contingency measures for their given systems. This document includes nine appendices. Appendix A provides three sample ISCP templates, based on the FIPS 199 impact levels. Appendix B presents a sample BIA template. Appendix C contains a list of Frequently Asked Questions about information system contingency planning. Problems relevant to planning for personnel considerations are discussed in Appendix D. Appendix E provides a summary of NIST SP 800-53 contingency planning controls and control enhancements. Appendix F explains the integration of contingency planning into an organization’s SDLC. Appendices G and H contain a glossary of terms and acronyms, respectively. Appendix I provides suggested resources and references. 5 The Risk Management Framework is described in draft NIST SP 800-39, Managing Risk from Information Systems: An Organizational Perspective. CHAPTER 1 4 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Chapter 2. Background Information systems are vulnerable to a variety of disruptions, ranging from mild (e.g., short-term power outage, disk drive failure) to severe (e.g., equipment destruction, fire). Much vulnerability may be minimized or eliminated through management, operational, or technical controls as part of the organization’s resiliency effort; however, it is virtually impossible to completely eliminate all risks. 6 Contingency planning is designed to mitigate the risk of system and service unavailability by providing effective and efficient solutions to enhance system availability. This chapter discusses the ways in which federal information system contingency planning fits into an organization’s larger risk management, security, and emergency preparedness programs (each of which is a key component in developing a resiliency program). Other types of emergency preparedness-related plans and their relationships to information system contingency planning are also described. Finally, the section discusses how integrating contingency planning principles throughout the SDLC promotes system compatibility and a cost-effective means to increase an organization’s ability to respond quickly and effectively to a disruptive event. 2.1 Contingency Planning and Resilience An organization must have the ability to withstand all hazards and sustain its mission through environmental changes. These changes can be gradual, such as economic or mission changes, or sudden, as in a disaster event. Rather than just working to identify and mitigate threats, vulnerabilities, and risks, organizations can work toward building a resilient infrastructure, minimizing the impact of any disruption on mission essential functions. Resilience 7 is the ability to quickly adapt and recover from any known or unknown changes to the environment. Resiliency is not a process, but rather an end-state for organizations. The goal of a resilient organization is to continue mission essential functions at all times during any type of disruption. Resilient organizations continually work to adapt to changes and risks that can affect their ability to continue critical functions. Risk management, contingency, and continuity planning are individual security and emergency management activities that can also be implemented in a holistic manner across an organization as components of a resiliency program. Effective contingency planning begins with the development of an organization contingency planning policy and subjection of each information system to a business impact analysis (BIA). This facilitates prioritizing the systems and processes based on the FIPS 199 impact level and develops priority recovery strategies for minimizing loss. FIPS 199 provides guidelines on determining information and information system impact to organizational operations and assets, individuals, other organizations and the nation through a formula that examines three security objectives: confidentiality, integrity, and availability. 8 ƒ Confidentiality preserves authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. ƒ Integrity guards against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. 6 For example, in many cases, critical resources (such as electric power or telecommunications) may reside outside the organization’s control, and the organization may be unable to ensure their availability. 7 The Department of Homeland Security (DHS) Risk Lexicon (September 2008) defines resilience as the “ability to resist, absorb, recover from or successfully adapt to adversity or a change in conditions.” The DHS Risk Lexicon can be found at www.dhs.gov/xlibrary/assets/dhs_risk_lexicon.pdf. 8 As defined in 44 U.S. Code 35 Section 3542 (January 8, 2008). CHAPTER 2 5 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS ƒ Availability ensures timely and reliable access to and use of information. The impact for each security objective is determined to be high, moderate, or low, based on definitions provided in FIPS 199. The highest of the individual security objective impact levels are used to determine the overall information system security impact level. Contingency planning considerations and strategies address the impact level of the availability security objective of information systems. Strategies for high-impact information systems should consider highavailability and redundancy options in their design. Options may include fully redundant load balanced systems at alternate sites, data mirroring, and offsite database replication. High-availability options are normally expensive to set up, operate, and maintain and should be considered only for those high-impact information systems categorized with a high-availability security objective. Lower-impact information systems may be able to use less expensive contingency options and tolerate longer downtimes for recovery or restoration of data. Effective contingency planning includes incorporating security controls early in the development of an information system, and maintaining these controls on an ongoing basis. NIST SP 800-53, Rev. 3, identifies nine Contingency Planning (CP) security controls for information systems. Not all controls are applicable to all systems. The FIPS 199 security categorization determines which controls apply to a particular system. For example, information systems that have availability as a security objective categorized as low-impact do not require alternate processing or storage sites, and information systems that have an availability security objective categorized as moderate-impact require compliance with only the first system backup control enhancements. Using the FIPS 199 security categorization allows for tailoring of the CP security controls in NIST SP 800-53 to those applicable to the appropriate security control baselines. Table 2-1 provides a summary of the CP controls from NIST SP 800-53 and their applicability to the security control baselines. Further details and descriptions of the contingency planning controls are provided in Appendix E. Several CP controls reference environmental controls, which are part of the NIST SP 800-53 Physical and Environmental Protection (PE) control family. Environmental controls considerations are only for the location or building that houses the information system. The environment includes the hardware and technology assets that support the information system. Section 3.3 of NIST SP 800-53 provides more information on environmental controls and their relationship to information systems. There are options available to organizations to facilitate compliance with the CP controls. NIST SP 80053 allows for compensating security controls to provide comparable protection for an information system to comply with the intent of a CP control. An organization may use a compensating security control in lieu of a CP control as long as there is justification for the use of the compensating control and willingness to accept the risk of the compensating control implementation. Further explanation of compensating security controls is available in Section 3.3 of NIST SP 800-53. CHAPTER 2 6 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Table 2-1: Summary of NIST SP 800-53 Contingency Planning Controls for Low-, Moderate-, and High-Impact Systems of Contingency-Related Plans 9 Control No. Control Name Security Control Baselines Low Moderate High CP-6 Contingency Planning Policy and Procedures Contingency Plan Contingency Training Contingency Plan Testing and Exercise Contingency Plan Update (Withdrawn) Alternate Storage Site CP-7 Alternate Processing Site Not Selected CP-8 Telecommunications Services Not Selected CP-8 (1) (2) CP-9 Information System Backup Information System Recovery and Reconstitution CP-9 CP-9 (1) CP-6 (1) (2) (3) CP-7 (1) (2) (3) (4) (5) CP-8 (1) (2) (3) (4) CP-9 (1) (2) (3) CP-10 CP-10 (2) (3) CP-10 (2) (3) (4) CP-1 CP-2 CP-3 CP-4 CP-5 CP-10 2.2 CP-1 CP-1 CP-1 CP-2 CP-3 CP-2 (1) CP-3 CP-2 (1) (2) (3) CP-3 (1) CP-4 CP-4 (1) CP-4 (1) (2) (4) -----Not Selected ----CP-6 (1) (3) CP-7 (1) (2) (3) (5) ------ Types of Plans Information system contingency planning represents a broad scope of activities designed to sustain and recover critical system services following an emergency event. Information system contingency planning fits into a much broader security and emergency management effort that includes organizational and business process continuity, disaster recovery planning, and incident management. Ultimately, an organization would use a suite of plans to properly prepare response, recovery, and continuity activities for disruptions affecting the organization’s information systems, mission/business processes, personnel, and the facility. Because there is an inherent relationship between an information system and the mission/business process it supports, there must be coordination between each plan during development and updates to ensure that recovery strategies and supporting resources neither negate each other nor duplicate efforts. Continuity and contingency planning are critical components of emergency management and organizational resilience but are often confused in their use. Continuity planning normally applies to the mission/business itself; it concerns the ability to continue critical functions and processes during and after an emergency event. Contingency planning normally applies to information systems, and provides the steps needed to recover the operation of all or part of designated information systems at an existing or new location in an emergency. Cyber Incident Response Planning is a type of plan that normally focuses on detection, response, and recovery to a computer security incident or event. In general, universally accepted definitions for information system contingency planning and the related planning areas have not been available. Occasionally, this leads to confusion regarding the actual scope and purpose of various types of plans. To provide a common basis of understanding regarding information system contingency planning, this section identifies several other types of plans and describes their purpose and scope relative to information system contingency planning. Because of the lack of standard definitions for these types of plans, the scope of actual plans developed by organizations may 9 Numbers in parentheses in this table refer to control enhancements defined for that control in NIST SP 800-53. A control enhancement either adds related functionality or strengthens a basic control. CHAPTER 2 7 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS vary from the descriptions below. This guide applies the descriptions and references in sections below to security and emergency management-related plans. The plans listed are in alphabetical order, and do not imply any order of importance. 2.2.1 Business Continuity Plan (BCP) The BCP focuses on sustaining an organization’s mission/business processes during and after a disruption. An example of a mission/business process may be an organization’s payroll process or customer service process. A BCP may be written for mission/business processes within a single business unit or may address the entire organization’s processes. The BCP may also be scoped to address only the functions deemed to be priorities. A BCP may be used for long-term recovery in conjunction with the COOP plan, allowing for additional functions to come online as resources or time allow. Because mission/business processes use information systems (ISs), the business continuity planner must coordinate with information system owners to ensure that the BCP expectations and IS capabilities are matched. 2.2.2 Continuity of Operations (COOP) Plan COOP focuses on restoring an organization’s mission essential functions (MEF) at an alternate site and performing those functions for up to 30 days before returning to normal operations. Additional functions, or those at a field office level, may be addressed by a BCP. Minor threats or disruptions that do not require relocation to an alternate site are typically not addressed in a COOP plan. Standard elements of a COOP plan include: ƒ Program plans and procedures ƒ Continuity communications ƒ Risk management ƒ Vital records management ƒ Budgeting and acquisition of resources ƒ Human capital ƒ Essential functions ƒ Test, training, and exercise ƒ Order of succession ƒ Devolution ƒ Delegation of authority ƒ Reconstitution ƒ Continuity facilities COOP plans are mandated for organizations by HSPD-20/NSPD-51, National Continuity Policy and FCD 1, Federal Executive Branch National Continuity Program and Requirements. Federal directives distinguish COOP plans as a specific type of plan that should not be confused with Information System Contingency Plans, Disaster Recovery Plans or BCPs. Nongovernment organizations typically use BCPs rather than COOP plans to address mission/business processes. CHAPTER 2 8 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS COOP vs. ISCP – The Basic Facts FUNCTIONS ƒ COOP plans address national, primary, or mission essential functions; ISCPs address federal information systems. o COOP functions have specific criteria; not all government mission/business processes meet COOP criteria. o COOP functions may be supported by information systems. o Information systems support government mission/business processes, but not all government mission/business processes fall within the scope of COOP. SCOPE ƒ COOP planning applies to mission essential functions of federal government departments and agencies. ƒ ISCPs apply to all information systems in federal organizations. AUTHORITIES ƒ 2.2.3 COOP is mandated for federal organizations by HSPD-20/NSPD-51, FCDs 1 and 2, and the National Continuity Policy Implementation Plan (NCPIP); ISCPs are mandated for federal organizations by FISMA. Crisis Communications Plan Organizations should document standard procedures for internal and external communications in the event of a disruption using a crisis communications plan. A crisis communications plan is often developed by the organization responsible for public outreach. The plan provides various formats for communications appropriate to the incident. The crisis communications plan typically designates specific individuals as the only authority for answering questions from or providing information to the public regarding emergency response. It may also include procedures for disseminating reports to personnel on the status of the incident and templates for public press releases. The crisis communication plan procedures should be communicated to the organization’s COOP and BCP planners to ensure that the plans include clear direction that only approved statements are released to the public by authorized officials. Appendix D provides further discussion of topics addressed by the crisis communications plan and informational resources. 2.2.4 Critical Infrastructure Protection (CIP) Plan Critical infrastructure and key resources (CIKR) are those components of the national infrastructure that are deemed so vital that their loss would have a debilitating effect of the safety, security, economy, and/or health of the United States. 10 A CIP plan is a set of policies and procedures that serve to protect and recover these national assets and mitigate risks and vulnerabilities. CIP plans define the roles and responsibilities for protection, develop partnerships and information sharing relationships, implement the risk management framework defined in the National Infrastructure Protection Plan (NIPP) and Homeland Security Presidential Directive (HSPD) - 7 for CIKR assets, and integrate federal, state and local emergency preparedness, protection, and resiliency of critical infrastructure. 10 For more information on Critical Infrastructure and Key Resources (CIKR), refer to the Department of Homeland Security’s National Infrastructure Protection Plan 2009, available at www.dhs.gov/xlibrary/assets/NIPP_Plan.pdf. CHAPTER 2 9 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS 2.2.5 Cyber Incident Response Plan The cyber incident response plan 11 establishes procedures to address cyber attacks against an organization’s information system(s). 12 These procedures are designed to enable security personnel to identify, mitigate, and recover from malicious computer incidents, such as unauthorized access to a system or data, denial of service, or unauthorized changes to system hardware, software, or data (e.g., malicious logic, such as a virus, worm, or Trojan horse). This plan may be included as an appendix of the BCP. 2.2.6 Disaster Recovery Plan (DRP) The DRP applies to major, usually physical disruptions to service that deny access to the primary facility infrastructure for an extended period. A DRP is an information system-focused plan designed to restore operability of the target system, application, or computer facility infrastructure at an alternate site after an emergency. The DRP may be supported by multiple information system contingency plans to address recovery of impacted individual systems once the alternate facility has been established. A DRP may support a BCP or COOP plan by recovering supporting systems for mission/business processes or mission essential functions at an alternate location. The DRP only addresses information system disruptions that require relocation. 2.2.7 Information System Contingency Plan (ISCP) An ISCP provides established procedures for the assessment and recovery of a system following a system disruption. The ISCP provides key information needed for system recovery, including roles and responsibilities, inventory information, assessment procedures, detailed recovery procedures, and testing of a system. The ISCP differs from a DRP primarily in that the information system contingency plan procedures are developed for recovery of the system regardless of site or location. An ISCP can be activated at the system’s current location or at an alternate site. In contrast, a DRP is primarily a site-specific plan developed with procedures to move operations of one or more information systems from a damaged or uninhabitable location to a temporary alternate location. Once the DRP has successfully transferred an information system site to an alternate site, each affected system would then use its respective ISCP to restore, recover, and test systems, and put them into operation. 2.2.8 Occupant Emergency Plan (OEP) The OEP outlines first-response procedures for occupants of a facility in the event of a threat or incident to the health and safety of personnel, the environment, or property. Such events include a fire, bomb threat, chemical release, domestic violence in the workplace, or a medical emergency. Shelter-in-place procedures for events requiring personnel to stay inside the building rather than evacuate are also addressed in an OEP. OEPs are developed at the facility level, specific to the geographic location and structural design of the building. General Services Administration (GSA)-owned facilities maintain plans based on the GSA OEP template. The facility OEP may be appended to the COOP or BCP, but is executed separately and as a first response to the incident. Aspects of planning for personnel safety and evacuation are discussed in Appendix D. 11 A cyber incident response plan is different from the Cyber Incident Annex of the National Response Framework (NRF). The Cyber Incident Annex is for incidents “capable of causing extensive damage to critical infrastructure or key assets” and is more applicable to CIP plans. 12 NIST SP 800-61 Rev. 1, Computer Security Incident Handling Guide, provides guidance on establishing a cyber incident response capability and plan. CHAPTER 2 10 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Error! Reference source not found. summarizes the types of plans. The plan types identified are implemented individually or in coordination with one another as appropriate to respond to a disruptive event. Table 2-2: Type of Plans Plan Purpose Scope Business Continuity Plan (BCP) Provides procedures for sustaining mission/business operations while recovering from a significant disruption. Addresses mission/business processes at a lower or expanded level from COOP MEFs. Continuity of Operations (COOP) Plan Provides procedures and guidance to sustain an organization’s MEFs at an alternate site for up to 30 days; mandated by federal directives. Provides procedures for disseminating internal and external communications; means to provide critical status information and control rumors. Provides policies and procedures for protection of national critical infrastructure components, as defined in the National Infrastructure Protection Plan. Provides procedures for mitigating and correcting a cyber attack, such as a virus, worm, or Trojan horse. Addresses MEFs at a facility; information systems are addressed based only on their support of the mission essential functions. Disaster Recovery Plan (DRP) Provides procedures for relocating information systems operations to an alternate location. Activated after major system disruptions with long-term effects. Information System Contingency Plan (ISCP) Provides procedures and capabilities for recovering an information system. Addresses single information system recovery at the current or, if appropriate alternate location. Occupant Emergency Plan (OEP) Provides coordinated procedures for minimizing loss of life or injury and protecting property damage in response to a physical threat. Focuses on personnel and property particular to the specific facility; not mission/business process or information system-based. Crisis Communications Plan Critical Infrastructure Protection (CIP) Plan Cyber Incident Response Plan CHAPTER 2 Plan Relationship Mission/business process focused plan that may be activated in coordination with a COOP plan to sustain non-MEFs. MEF focused plan that may also activate several business unit-level BCPs, ISCPs, or DRPs, as appropriate. Addresses communications with personnel and the public; not information systemfocused. Incident-based plan often activated with a COOP or BCP, but may be used alone during a public exposure event. Addresses critical infrastructure components that are supported or operated by an agency or organization. Risk management plan that supports COOP plans for organizations with critical infrastructure and key resource assets. Addresses mitigation and isolation of affected systems, cleanup, and minimizing loss of information. Information systemfocused plan that may activate an ISCP or DRP, depending on the extent of the attack. Information systemfocused plan that activates one or more ISCPs for recovery of individual systems. Information systemfocused plan that may be activated independent from other plans or as part of a larger recovery effort coordinated with a DRP, COOP, and/or BCP. Incident-based plan that is initiated immediately after an event, preceding a COOP or DRP activation. 11 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Figure 2-1 shows the interrelationship of each plan as they are implemented to respond to the event as applicable to their respective scopes. Figure 2-1: Contingency-Related Plan Relationships CHAPTER 2 12 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Chapter 3. Information System Contingency Planning Process This section describes the process to develop and maintain an effective information system contingency plan. The process presented is common to all information systems. The seven steps in the process are: 1. Develop the contingency planning policy; 2. Conduct the business impact analysis (BIA); 3. Identify preventive controls; 4. Create contingency strategies; 5. Develop an information system contingency plan; 6. Ensure plan testing, training, and exercises; and 7. Ensure plan maintenance. These steps represent key elements in a comprehensive information system contingency planning capability. Developing contingency planning policy and performing system BIA(s) are accomplished early in the SDLC (see Appendix F) and before the systems are categorized in accordance with the RMF. Six of the seven planning process steps are discussed in this section. Because plan development represents the core of information system contingency planning, including the individual sections that compose the plan, plan development is addressed in Chapter 4. Responsibility for the planning process generally falls under the auspice of the Information System Contingency Plan Coordinator, or ISCP Coordinator, who is typically a functional or resource manager within the organization. The ISCP Coordinator develops the strategy in cooperation with other functional and resource managers associated with the system or the mission/business processes supported by the system. The ISCP Coordinator also typically manages development and execution of the contingency plan. All federal information systems must have a contingency plan. Figure 3-1 illustrates the contingency planning process. Develop Contingency Planning Policy Conduct Business Impact Analysis • Identify statutory or regulatory requirements • Develop IT contingency planning policy statement • Reflect FIPS 199 • Publish policy • Determine business processes and recovery criticality • Identify outage impacts and estimated downtime • Identify resource requirements • Identify recovery priorities for system Identify Preventive Controls • Identify controls • Implement controls • Maintain controls Create Contingency Strategies • Backup & recovery • Consider FIPS 199 • Identify roles & responsibilities • Address alternate site • Identify equipment and cost considerations • Integrate into system architecture Develop Contingency Plan* • Document recovery strategy Plan Testing, Training, and Exercises • Plan testing • Train personnel • Plan exercises • TT&E activities Plan Maintenance • Review and update plan • Coordinate with internal/ external organizations • Control distribution • Document changes *Discussed in Section 4 Figure 3-1: Contingency Planning Process CHAPTER 3 13 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS 3.1 Develop the Contingency Planning Policy Statement To be effective and to ensure that personnel fully understand the organization’s contingency planning requirements, the contingency plan must be based on a clearly defined policy. The contingency planning policy statement should define the organization’s overall contingency objectives and establish the organizational framework and responsibilities for system contingency planning. To be successful, senior management, most likely the CIO, must support a contingency program and be included in the process to develop the program policy. The policy must reflect the FIPS 199 impact levels and the contingency controls that each impact level establishes. Key policy elements are as follows: ƒ Roles and responsibilities; ƒ Scope as applies to common platform types and organization functions (i.e., telecommunications, legal, media relations) subject to contingency planning; ƒ Resource requirements; ƒ Training requirements; ƒ Exercise and testing schedules; ƒ Plan maintenance schedule; and ƒ Minimum frequency of backups and storage of backup media. Sample information system contingency policy statement All organizations must develop contingency plans for each information system to meet the needs of critical system operations in the event of a disruption. The procedures for execution of such a capability shall be documented in a formal contingency plan by the Information Systems Contingency Plan (ISCP) Coordinator and must be reviewed annually and updated as necessary by the ISCP Coordinator. The plan must account for the FIPS 199 security categorization (low, moderate, high) and comply with the appropriate security controls. The plan must assign specific responsibilities to designated staff or positions to facilitate the recovery and/or continuity of essential system functions. Resources necessary to ensure viability of the procedures must be acquired and maintained. Personnel responsible for target systems must be trained to execute contingency procedures. The plan recovery capabilities and personnel shall be tested annually to identify weaknesses of the capability. As information system contingency plans are developed during the Initiation phase of the SDLC, 13 they should be coordinated with related organization-wide policies and programs, including information system security, physical security, human resources, system operations, and emergency preparedness functions. Information system contingency activities should be compatible with program requirements for these areas, and recovery personnel should coordinate with representatives from each area to remain aware of new or evolving policies, programs, or capabilities. The ISCPs must be written in coordination with other plans associated with each target system as part of organization-wide resilience strategy. Such plans include the following: 13 The SDLC refers to the scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation, and maintenance, and ultimately its disposal that instigates another system initiation. The SDLC approach is discussed in depth in NIST SP 800-64, Security Considerations in the Information System Development Life Cycle. An overview of contingency planning and the SDLC is provided in Appendix F. CHAPTER 3 14 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS ƒ Information system security plans; ƒ Facility-level plans, such as the OEP and DRP; ƒ MEF support such as the COOP plan; and ƒ Organization-level plans, such as CIP plans. Similarly, the six-step RMF 14 brings together the supporting security standards and guidelines necessary for managing risk related to information systems. Implementing the RMF on an information system encompasses a broad range of activities to identify, control, and mitigate risks. From the information system contingency planning perspective, the six steps in the RMF actively support the development, implementation, testing, and maintenance of an information system’s contingency plan as it supports the mission of the organization. 3.2 Conduct the Business Impact Analysis (BIA) The BIA is a key step in implementing the CP controls in NIST SP 800-53 and in the contingency planning process overall. The BIA enables the ISCP Coordinator to characterize the system components, supported mission/business processes, and interdependencies. The BIA purpose is to correlate the system with the critical mission/business processes and services provided, and based on that information, characterize the consequences of a disruption. The ISCP Coordinator can use the BIA results to determine contingency planning requirements and priorities. Results from the BIA should be appropriately incorporated into the analysis and strategy development efforts for the organization’s COOP, BCPs, and DRP. The BIA should be performed during the Initiation phase of the SDLC. As the system design evolves and components change, the BIA may need to be conducted again during the Development/Acquisition phase of the SDLC. Incorporating the RMF Step 1 (FIPS 199 categorization) and Step 2 (select security controls) helps to ensure that the BIA accounts appropriately for the level of risk to the organization. COOP vs. ISCP – The Basic Facts BUSINESS IMPACT ANALYSIS (BIA) ƒ COOP functions are subject to a process-focused BIA; federal information systems are subject to a system-focused BIA. o Information systems that support COOP functions will be identified in the process-based BIA. o FCD-2 provides a required template for a process-based BIA; NIST 800-34 provides a recommended template for a system-based BIA. Three steps are typically involved in accomplishing the BIA: 1. Determine mission/business processes and recovery criticality. Mission/Business processes supported by the system are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum time that an organization can tolerate while still maintaining the mission. 2. Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as 14 NIST SP 800-37 further describes the RMF and provides guidance on organization-wide risk management including the development of risk management strategies, risk-related governance issues, defining protection requirements and associated risks for organizational mission/business processes, integration of security and privacy requirements into enterprise architectures, and managing risk within the system development life cycle. CHAPTER 3 15 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records. 3. Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can be linked more clearly to critical mission/business processes and functions. Priority levels can be established for sequencing recovery activities and resources. The sample BIA process and data collection activities, outlined in this section and illustrated in Figure 3-2, consisting of a representative information system with multiple components (servers), are designed to help the ISCP Coordinator streamline and focus contingency plan development activities to achieve a more effective plan. 15 An example of the BIA process and a BIA template are provided in Appendix B. Stakeholder input Potential Impacts Max Tolerable Downtime* Recovery Time System Components Objective* FIPS 199 Confidentiality Integrity Availability Process Invoice Operations – more than 1,000 staff affected 72 hours Application Server 36 hours L L L Prepare Report Reputation – media outlets announce concerns 30 hours Web Server 24 hours M M M Create Budget Reputation – congressional insight 36 hours Database Sever 12 hours L M M Customer Service – over 500 customer complaints 36 hours Desktop Computers 30 hours L L L Respond to Inquiries Interdependencies Moderate Business Process *Notional Times Figure 3-2: Business Impact Analysis Process for the Information System 3.2.1 Determine Business Processes and Recovery Criticality An information system can be very complex and often supports multiple mission/business processes, resulting in different perspectives on the importance of system services or capabilities. To accomplish the BIA and better understand the impacts a system outage or disruption can have on the organization, the ISCP Coordinator should work with management and internal and external points of contact (POC) 16 to identify and validate mission/business processes and processes that depend on or support the information system. The identified processes’ impacts are then further analyzed in terms of availability, integrity, confidentiality, and the established FIPS 199 impact level for the information system. FIPS 199 requires organizations to categorize their information systems as low impact, moderate impact, or high impact for the security objectives of confidentiality, integrity, and availability (RMF Step 1). The FIPS 199 category for the availability security objective serves as a basis of the BIA. Further identification of additional mission/business processes and impacts captures the unique purpose of the 15 For completeness and to assist ISCP Coordinators who may be new to or unfamiliar with the information system, the sample BIA process presented includes basic steps. In many cases, the ISCP Coordinator will be very familiar with specific system components and the ways in which they support business processes and may modify the approach to fit the respective system and contingency needs. 16 When identifying POCs, it is important to include organizations that provide or receive data from the system as well as POCs of any interconnected systems. Coordination should enable the system manager to characterize the full range of support provided by the system, including security, managerial, technical, and operational requirements. CHAPTER 3 16 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS system. Organizational and system uniqueness are important considerations for contingency planning and business impact. Adding information types to address this uniqueness will enhance the prioritization of system component impacts. Unique processes and impacts can be expressed in values or units of measurement that are meaningful to the organization. Values can be identified using a scale and should be characterized as an indication of impact severity to the organization if the process could not be performed. 17 For example, an impact category such as “Costs” can be created with impact values expressed in terms of staffing, overtime, or fee-related costs. The ISCP Coordinator should next analyze the supported mission/business processes and with the process owners, leadership and business managers determine the acceptable downtime if a given process or specific system data were disrupted or otherwise unavailable. Downtime can be identified in several ways. 18 ƒ Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave contingency planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content. 19 ƒ Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD. Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD. 20 When it is not feasible to immediately meet the RTO and the MTD is inflexible, a Plan of Action and Milestone should be initiated to document the situation and plan for its mitigation. ƒ Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage. Unlike RTO, 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. Because the RTO must ensure that the MTD is not exceeded, the RTO must normally be shorter than the MTD. For example, a system outage may prevent a particular process from being completed, and because it takes time to reprocess the data, that additional processing time must be added to the RTO to stay within the time limit established by the MTD. 17 NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, provides additional guidance on security categories and information types that could influence criticality. 18 The first version of NIST SP 800-34 used the term Maximum Allowable Outage (MAO) to describe the downtime threshold. To further delineate business process and information system downtime, Maximum Tolerable Downtime (MTD) and Recovery Time Objective (RTO) terms are used. 19 Any information system that supports continuity of operations Mission Essential Functions (MEF), Primary Mission Essential Functions (PMEF), or National Essential Functions (NEF) must be able to meet the function’s MTD of 12 hours or less per FCD-1. 20 RTOs for telecommunications systems that support continuity of operation MEFs, PMEFs, or NEFs must support the function’s COOP requirements including those put forth by National Communications Systems (NCS) Directive 3-10. CHAPTER 3 17 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS COOP vs. ISCP – The Basic Facts RECOVERY TIMES ƒ COOP functions must be sustained within 12 hours and for up to 30 days from an alternate site; ISCP recovery time objectives are determined by the system-based BIA. o Information systems that support COOP functions must have an RTO that meets COOP requirements. o Information systems that do not support COOP functions do not require alternate sites as part of the ISCP recovery strategy, but may have an alternate site security control requirement. The ISCP Coordinator, working with management, should determine the optimum point to recover the information system by addressing the factors mentioned above while balancing the cost of system inoperability against the cost of resources required for restoring the system and its overall support for critical mission/business processes. This can be depicted using a simple chart, such as the example in Figure 3-3. Cost of Disruption (Business Downtime) Cost to Recover (System Mirror) Cost Cost Balance Point Cost to Recover (Tape Backup) Length of Disruption Time Figure 3-3: Cost Balancing The longer a disruption is allowed to continue, the more costly it can become to the organization and its operations. Conversely, the shorter the RTO, the more expensive the recovery solutions cost to implement. For example, if the system must be recovered immediately, zero downtime solutions and alternate processing site costs will be much higher, whereas a low-impact system with a longer RTO would be able to implement a less costly simple tape backup system. Plotting the cost balance points will show an optimal point between disruption and recovery costs. The intersecting point (Cost Balance Point in Figure 3-3: Cost Balancing) will be different for every organization and system based on the financial constraints and operating requirements. CHAPTER 3 18 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS 3.2.2 Identify Resource Requirements Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes as quickly as possible. Working with management and internal and external POCs associated with the system, the ISCP Coordinator should ensure that the complete information system resources are identified. 21 A simple table such as the one shown in Table 3-1 can be used to capture relevant information system resources. Table 3-1: Information System Resource/Component Table System Resource/Component Application Server 3.2.3 Platform/OS/Version (as applicable) Sun V245/ Solaris / v10.0 Description Serves as the main application server Identify System Resource Recovery Priorities Developing recovery priorities is the last step of the BIA process. Recovery priorities can be effectively established taking into consideration mission/business process criticality, outage impacts, tolerable downtime, and system resources. The result is an information system recovery priority hierarchy. The ISCP Coordinator should consider system recovery measures and technologies to meet the recovery priorities. 3.3 Identify Preventive Controls In some cases, the outage impacts identified in the BIA may be mitigated or eliminated through preventive measures that deter, detect, and/or reduce impacts to the system. Where feasible and costeffective, preventive methods are preferable to actions that may be necessary to recover the system after a disruption. Step 2 of the RMF includes the identification of effective contingency planning preventive controls and maintaining these controls on an ongoing basis. A variety of preventive controls are identified in NIST SP 800-53, depending on system type and configuration; some common measures are listed below: 21 ƒ Appropriately sized uninterruptible power supplies (UPS) to provide short-term backup power to all system components (including environmental and safety controls); ƒ Gasoline- or diesel-powered generators to provide long-term backup power; ƒ Air-conditioning systems with adequate excess capacity to prevent failure of certain components, such as a compressor; ƒ Fire suppression systems; ƒ Fire and smoke detectors; ƒ Water sensors in the computer room ceiling and floor; To avoid duplication of effort, this information may be obtained from the system component inventory and the system software inventory. CHAPTER 3 19 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS ƒ Heat-resistant and waterproof containers for backup media and vital non electronic records; ƒ Emergency master system shutdown switch; ƒ Offsite storage of backup media, non electronic records, and system documentation; ƒ Technical security controls, such as cryptographic key management; and ƒ Frequent scheduled backups including where the backups are stored (onsite or offsite) and how often they are recirculated and moved to storage. 3.4 Create Contingency Strategies Organizations are required to adequately mitigate the risk arising from use of information and information systems in the execution of mission/business processes. The challenge for organizations is in implementing the right set of security controls. Guided by the RMF and in accordance with FIPS 199 and NIST SP 800-53, security controls are selected and implemented. Contingency strategies are created to mitigate the risks for the contingency planning family of controls and cover the full range of backup, recovery, contingency planning, testing, and ongoing maintenance. 3.4.1 Backup and Recovery Backup and recovery methods and strategies are a means to restore system operations quickly and effectively following a service disruption. The methods and strategies should address disruption impacts and allowable downtimes identified in the BIA and should be integrated into the system architecture during the Development/Acquisition phase of the SDLC. A wide variety of recovery approaches may be considered, with the appropriate choice being highly dependent upon the incident, type of system, BIA/FIPS 199 impact level, and the system’s operational requirements. 22 Specific recovery methods further described in Section 3.4.2 should be considered and may include commercial contracts with alternate site vendors, reciprocal agreements with internal or external organizations, and service-level agreements (SLAs) with equipment vendors. In addition, technologies such as redundant arrays of independent disks (RAID), automatic failover, UPS, server clustering, and mirrored systems should be considered when developing a system recovery strategy. Several alternative approaches should be considered when developing and comparing strategies, including cost, maximum downtimes, security, recovery priorities, and integration with larger, organization-level contingency plans. Table is an example that can assist in identifying the linkage of FIPS 199 impact level for the availability security objective, recovery priority, backup, and recovery strategy. Table 3-2: FIPS 199 Category Backup & Strategy Examples FIPS 199 Availability Impact Level Information System Target Priority and Recovery Backup / Recovery Strategy 23 Low Low priority - any outage with little impact, damage, or disruption to the organization. Backup: Tape backup Strategy: Relocate or Cold site Moderate Important or moderate priority - any system that, if disrupted, would cause a moderate problem to the organization and possibly other networks or systems. Backup: Optical backup, WAN/VLAN replication Strategy: Cold or Warm site 22 Chapter 5, Technical Contingency Planning Considerations, provides detailed discussion of recovery methods applicable to specific types of information systems. 23 Additional recovery strategy technical details and descriptions can be found in Sections 3.4.2 through 3.4.6. CHAPTER 3 20 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS FIPS 199 Availability Impact Level Mission-critical or high priority - the damage or disruption to these systems would cause the most impact on the organization, mission, and other networks and systems. High 3.4.2 Information System Target Priority and Recovery Backup / Recovery Strategy 23 Backup: Mirrored systems and disc replication Strategy: Hot site Backup Methods and Offsite Storage System data should be backed up regularly. Policies should specify the minimum frequency and scope of backups (e.g., daily or weekly, incremental or full) based on data criticality and the frequency that new information is introduced. Data backup policies should designate the location of stored data, file-naming conventions, media rotation frequency, and method for transporting data offsite. Data may be backed up on magnetic disk, tape, or optical disks, such as compact disks (CDs). The specific method chosen for conducting backups should be based on system and data availability and integrity requirements. These methods may include electronic vaulting, network storage, and tape library systems. 24 It is good business practice to store backed-up data offsite. Commercial data storage facilities are specially designed to archive media and protect data from threatening elements. If using offsite storage, data is backed up at the organization’s facility and then labeled, packed, and transported to the storage facility. If the data is required for recovery or testing purposes, the organization contacts the storage 25 facility requesting specific data to be transported to the organization or to an alternate facility. Commercial storage facilities often offer media transportation and response and recovery services. When selecting an offsite storage facility and vendor, the following criteria should be considered: ƒ Geographic area: distance from the organization and the probability of the storage site being affected by the same disaster as the organization’s primary site; ƒ Accessibility: length of time necessary to retrieve the data from storage and the storage facility’s operating hours; ƒ Security: security capabilities of the shipping method, storage facility, and personnel; all must meet the data’s security requirements; ƒ Environment: structural and environmental conditions of the storage facility (i.e., temperature, humidity, fire prevention, and power management controls); and ƒ Cost: cost of shipping, operational fees, and disaster response/recovery services. 3.4.3 Alternate Sites As stated in Section 2.1, NIST SP 800-53 identifies the CP controls for information systems. The FIPS 199 security categorization for the availability security objective determines which controls apply to a particular system. For example, an information system categorized with a low-availability security objective does not require alternate storage or a processing site (CP-6 and CP-7, respectively), and an information system with a moderate-availability security objective requires the system backup and testing 24 25 Additional technical considerations are discussed in Chapter 5. Backup tapes should be tested regularly to ensure that data are being stored correctly and that the files may be retrieved without errors or lost data. Also, the ISCP Coordinator should test the backup tapes at the alternate site, if applicable, to ensure that the site supports the same backup configuration that the organization has implemented. CHAPTER 3 21 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS the backup (CP-9 [1]). Further details and descriptions of the contingency planning controls are provided in Appendix E. Although major disruptions with long-term effects may be rare, they should be accounted for in the contingency plan. Thus, for all FIPS 199 moderate- or high-impact systems, the plan should include a strategy to recover and perform system operations at an alternate facility for an extended period. Organizations may consider FIPS 199 low-impact systems for alternate site processing, but that is an organizational decision and not required. In general, three types of alternate sites are available: ƒ Dedicated site owned or operated by the organization; ƒ Reciprocal agreement or memorandum of agreement with an internal or external entity; and ƒ Commercially leased facility. Regardless of the type of alternate site chosen, the facility must be able to support system operations as defined in the contingency plan. The three alternate site types commonly categorized in terms of their operational readiness are cold sites, warm sites, or hot sites. 26 Other variations or combinations of these can be found, but generally all variations retain similar core features found in one of these three site types. Progressing from basic to advanced, the sites are described below. ƒ Cold Sites are typically facilities with adequate space and infrastructure (electric power, telecommunications connections, and environmental controls) to support information system recovery activities. ƒ Warm Sites are partially equipped office spaces that contain some or all of the system hardware, software, telecommunications, and power sources. ƒ Hot Sites are facilities appropriately sized to support system requirements and configured with the necessary system hardware, supporting infrastructure, and support personnel. As discussed above, these three alternate site types are the most common. There are also variations, and hybrid mixtures of features from any one of the three. Each organization should evaluate its core requirements in order to establish the most effective solution. Two examples of variations to the site types are: ƒ Mobile Sites are self-contained, transportable shells custom-fitted with specific telecommunications and system equipment necessary to meet system requirements. ƒ Mirrored Sites are fully redundant facilities with automated real-time information mirroring. Mirrored sites are identical to the primary site in all technical respects. There are obvious cost and ready-time differences among the options. In these examples, the mirrored site is the most expensive choice, but it ensures virtually 100 percent availability. Cold sites are the least expensive to maintain, although they may require substantial time to acquire and install necessary equipment. Partially equipped sites, such as warm sites, fall in the middle of the spectrum. In many cases, mobile sites may be delivered to the desired location within 24 hours, but the time necessary for equipment installation and setup can increase this response time. The selection of fixed-site locations should account for the time and mode of transportation necessary to move personnel and/or equipment there. In addition, the fixed site should be in a geographic area that is unlikely to be negatively affected by the same hazard as the organization’s primary site. 26 For more complete technical details and descriptions, refer to Chapter 5. CHAPTER 3 22 CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS Table summarizes the criteria that can be employed to determine which type of alternate site meets the organization’s requirements. Sites should be analyzed further by the organization, including considerations given to business impacts and downtime defined in the BIA. As sites are evaluated, the ISCP Coordinator should ensure that the system’s security, management, operational, and technical controls are compatible with the prospective site. Such controls may include firewalls, physical access controls, and personnel security requirements of the staff supporting the site. Table 3-34: Sample Alternate Site Criteria Site Cost Cold Site Warm Site Hot Site Low Medium Medium/High Hardware Equipment None Partial Full Telecommunications Setup Time None Partial/Full Full Long Medium Short Location Fixed Fixed Fixed Alternate sites may be owned and operated by the organization (internal recovery), or commercial sites may be available under contract. If contracting for the site with a commercial vendor, adequate testing time, work space, security requirements, hardware requirements, telecommunications requirements, support services, and recovery days (how long the organization can occupy the space during the recovery period) must be negotiated and clearly stated in the contract. Customers should be aware that multiple organizations may contract with a vendor for the same alternate site; as a result, the site may be unable to accommodate all of the customers if a disaster affects enough of those customers simultaneously. The vendor’s policy on how this situation should be addressed and how priority status is determined should be negotiated. Two or more organizations with similar or identical system configurations and backup technologies may enter into a formal agreement to serve as alternate sites for each other or enter into a joint contract for an alternate site. This type of site is set up via a reciprocal agreement or memorandum of understanding ...
Purchase answer to see full attachment
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer

Attached. Please let me know if you have any questions or need revisions.

1

Business continuity plan
Name of Student
Institutional Affiliation
Course Number/Name
Instructor’s Name
Due Date

2
Introduction
With the dynamic advancements in technology, a corresponding challenge in managing the
risks associated with information technology breaches is rising. The Federal government is
particularly offering pioneering assistance and coordination necessary to develop and maintain a
working template that other organizations can adopt and implement (Swanson et al., 2010). The
federal government aims to continue research using the most competitive applications and tools
and develop the most appropriate mode of protecting information systems. A breach in information
in any organization, small or big, may have a long-term impact that may derail the organization's
overall reputation.
According to (Swanson et al., 2010), information systems are particularly vulnerable to the
ever-rising cases of cybersecurity. The attacks could be on an information system of critical
infrastructures like the health sector, commerce, national security, and emergency system. The
business's continuity plan aims to prepare for uncertainties that may interfere with normal activities
in the business. The contingencies would be prepared and tested before any eventuality to ensure
a swift and sure return to normalcy as soon as a risk is recorded in the system. There is a risk of
having an improperly framed contingency plan, which may keep the business organization out of
operation for a longer time, or even permanently, depending on the level of sophistication of the
challenge presented. This is why the United States of America's federal government, through the
National Institute of Standards and Technology (NIST), has developed a contingency plan
framework that can guide other organizations in safeguarding their information systems.
RGK telecommunication continuation plan
RGK is a developing telecommunications company in the United States of America. It
deals with the provision and support of client communication services through mobile phones and

3
other devices. Both individuals and organizations rely on the company for communication services
and sending and reception of money. Being a network provider, the company is vulnerable to ITrelated compromise, which may have an escalating effect on its operation and clients' safety.
Therefore, the outline provided, adapted from the NIST framework, outlines how to recover the
company's operations when there is an outage (Swanson et al., 2010). The outage anticipated in
this case is an information technology system breach from either an internal or external attack.
The contingency plan is aimed to address aspects like the customer's safety by ensuring
their data is safe and safely restored (Padilla & Freire, 2019). The organization's
telecommunication system is second since it must be protected and restored safely for the systems
to work conventionally. A third aspect is the mainframe systems, which are the physical computers
and gadgets found in the company.
Through a business impact analysis, the information system is at risk of breach by cyberbased criminals. Therefore, it prompts the organization to adopt the template provided by NIST in
readiness to respond to an eventuality without having to escalate further. The restoration process
would work so that the organization's business and mission statement is still achievable.
Identification and implementation of preventive measures are necessary. One such
initiative for my RKG telecommunication services is the reliance on back up of data. In the event
of interference in the organization's information system, data that are backed up will be restored
for normal business operations. The recovery timeframe for such critical information to the
company should be recovered in less than one hour. Systems restorations require pa...


Anonymous
Awesome! Made my life easier.

Studypool
4.7
Trustpilot
4.5
Sitejabber
4.4

Similar Content

Related Tags