Attachment J.22. - Peace Corps IT Contingency Planning.pdf

Information Technology Security Program

Contingency Planning (CP) CIO-SEC-PLN-03, v1.0

This document is approved for distribution. Policies, procedures and standards, herein, are effective at the date of signature until explicitly superseded or rescinded.

Chief Information Security Officer

CIO-SEC-PLN-03 Contingency Planning (CP)

Peace Corps

VERSION HISTORY/CHANGE RECORD

Date Author Change Reason for Change

6/2/2021 M Terry Initial draft Identifying Peace Corps’ current media protection policy and processes to ensure alignment with Federal, NIST, and Peace Corps guidance.

Peace Corps 1

Table of Contents

1 Introduction

1.1 Purpose

1.2 Scope

1.3 Policy

1.1 References

2 Contingency Planning Roles and Responsibilities

2.1 Authorizing Official (AO)

2.2 Information Systems Security Manager (ISSM)

2.3 Information Systems Security Officer (ISSO)

2.4 System Owners (e.g., System Program Managers/Project Managers)

2.5 Data Owners

2.6 Custodians

2.7 System/Network Administrators

3 IT Contingency Planning Process

3.1 Step 1 – Develop the Contingency Planning Policy Statement

3.2 Step 2 – Conduct the Business Impact Analysis

3.3 Step 3 – Identify Preventive Controls

3.4 Step 4 – Create Contingency Strategies

3.5 Step 5 – Develop an Information System Contingency Plan

3.6 Step 6 – Ensure Plan Testing and Exercises

3.7 Step 7 – Ensure Plan Maintenance

4 Implementation Guidance for CP Controls

4.1 CP-1 Contingency Planning Policy and Procedures

4.2 CP-2 Contingency Plan

4.3 CP-3 Contingency Training

4.4 CP-4 Contingency Plan Testing

4.5 CP-6 Alternate Storage Site

4.6 CP-7 Alternate Processing Site

4.7 CP-8 Telecommunications Services

4.8 CP-9 Information System Backup

4.9 CP-10 Information System Recovery and Reconstitution

5 Contingency Planning and Supply Chain Risk Management

5.1 CP-1 Contingency Planning Policy and Procedures (ICT SCRM)

5.2 CP-2 Contingency Plan (ICT SCRM)

5.3 CP-6 Alternate Storage Site (ICT SCRM)

5.4 CP-7 Alternate Processing Site (ICT SCRM)

5.5 CP-8 Telecommunications Services (ICT SCRM)

6 Summary Appendix A: Contingency Planning Templates Appendix B: Contingency Plan Sample Test Scenarios

Peace Corps 2

1 Introduction

Contingency planning focuses on the recovery and restoration of an Information Technology (IT) system following a disruption. Peace Corps (PC) MS 402 “Domestic Continuity of Operations and Occupant Emergency Plan Programs” supports the agency Continuity of Operations Plan (COOP) required by Presidential Policy Directive (PPD) 40, “National Continuity Policy” ensuring that primary mission-essential functions continue to be performed during a wide range of emergencies. Contingency and continuity of support plans must be developed and tested for all IT systems in accordance with Office of Management and Budget (OMB) Circular No. A-130, “Managing Information as a Strategic Resource,” National Institute of Standards and Technology (NIST) Special Publication (SP) 800-34, Revision 1, “Contingency Planning Guide for Federal Information Systems,” and PC policies, directives, and procedures.

Every PC IT system must follow the Contingency Planning (CP) practices identified in this guide.

Any deviations from the security requirements established in CIO-SEC-REQ-01, “Information Security Program Requirements,” must be coordinated by the Information Systems Security Officer (ISSO) through the appropriate Information Systems Security Manager (ISSM) and approved by the Authorizing Official (AO). Any deviations, exceptions, or other conditions not following PC policies and standards must be submitted using a security deviation request form.

The CP principles and practices described in this guide are based on guidance from NIST including NIST SP 800-53, Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations.” This guide provides an overview of CP roles and responsibilities, NIST SP 800-53 CP requirements per Federal Information Processing Standards (FIPS) Publication 199, “Standards for Security Categorization of Federal Information and Information Systems,” security categorization level, and procedures for implementing these requirements.

Executive Order (EO) 13800, “Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure” requires all agencies to use “The Framework for Improving Critical Infrastructure Cybersecurity (the Framework) developed by the National Institute of Standards and Technology (NIST) or any successor document to manage the agency’s cybersecurity risk.” This NIST document is commonly referred to as the Cybersecurity Framework (CSF).

The CSF focuses on using business drivers to guide cybersecurity activities and considering cybersecurity risks as part of the organization’s risk management processes. The core of the CSF consists of five concurrent and continuous Functions—Identify (ID), Protect (PR), Detect (DE), Respond (RS), Recover (RC). The CSF complements, and does not replace, an organization’s risk management process and cybersecurity program. PC uses NIST’s Risk Management Framework (RMF) from NIST SP 800-37, Revision 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. Table 1-1, CSF Categories/Subcategories lists the Categories and Subcategories from the CSF that are identified as related to the implementation of policies, Peace Corps 3 procedures, and processes implementing the NIST SP 800-53 CP control family. CIO-SEC-REQ- 01 and this procedural guide provide PC’s policies and procedural guidance regarding contingency planning for PC IT systems and CP controls.

Table 1-1: CSF Categories/Subcategories CSF Category/ Subcategory

Identifier Definition/Description

Asset Management

(ID.AM)

The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to organizational objectives and the organization’s risk strategy.

ID.AM-5 Resources (e.g., hardware, devices, data, time, personnel, and software) are prioritized based on their classification, criticality, and business value

ID.AM-6 Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established

Business Environment

(ID.BE)

The organization’s mission, objectives, stakeholders, and activities are understood and prioritized; this information is used to inform cybersecurity roles, responsibilities, and risk management decisions.

ID.BE-1 The organization’s role in the supply chain is identified and communicated ID.BE-4 Dependencies and critical functions for delivery of critical services are established ID.BE-5 Resilience requirements to support delivery of critical services are established for all operating states (e.g. under duress/attack, during recovery, normal operations) Governance (ID.GV) The policies, procedures, and processes to manage and monitor the organization’s regulatory, legal, risk, environmental, and operational requirements are understood and inform the management of cybersecurity risk.

ID.GV-1 Organizational cybersecurity policy is established and communicated ID.GV-3 Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed Supply Chain Risk Management (ID.SC)

The organization’s priorities, constraints, risk tolerances, and assumptions are established and used to support risk decisions associated with managing supply chain risk. The organization has established and implemented the processes to identify, assess and manage supply chain risks.

ID.SC-5 Response and recovery planning and testing are conducted with suppliers and third-party providers

Data Security (PR.DS) Information and records (data) are managed consistent with the organization’s risk strategy to protect the confidentiality, integrity, and availability of information.

PR.DS-4 Adequate capacity to ensure availability is maintained Information Protection Processes and Procedures (PR.IP)

Security policies (that address purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities), processes, and procedures are maintained and used to manage protection of information systems and assets.

PR.IP-4 Backups of information are conducted, maintained, and tested PR.IP-7 Protection processes are improved PR.IP-9 Response plans (Incident Response and Business Continuity) and recovery plans

(Incident Recovery and Disaster Recovery) are in place and managed

Peace Corps 4

CSF Category/ Subcategory

Identifier Definition/Description

PR.IP-10 Response and recovery plans are tested Protective Technology

(PR.PT)

Technical security solutions are managed to ensure the security and resilience of systems and assets, consistent with related policies, procedures, and agreements.

PR.PT-4 Communications and control networks are protected PR.PT-5 Mechanisms (e.g., failsafe, load balancing, hot swap) are implemented to achieve resilience requirements in normal and adverse situations Anomalies and Events

(DE.AE)

Anomalous activity is detected and the potential impact of events is understood.

DE.AE-4 Impact of events is determined Response Planning

(RS.RP)

Response processes and procedures are executed and maintained, to ensure response to detected cybersecurity events.

RS.RP-1 Response plan is executed during or after an incident Communications

(RS.CO)

Response activities are coordinated with internal and external stakeholders (e.g.

external support from law enforcement agencies).

RS.CO-1 Personnel know their roles and order of operations when a response is needed RS.CO-3 Information is shared consistent with response plans RS.CO-4 Coordination with stakeholders occurs consistent with response plans Analysis (RS.AN) Analysis is conducted to ensure effective response and support recovery activities.

RS.AN-2 The impact of the incident is understood RS.AN-4 Incidents are categorized consistent with response plans Improvements (RS.IM) Organizational response activities are improved by incorporating lessons learned from current and previous detection/response activities.

RS.IM-1 Response plans incorporate lessons learned RS.IM-2 Response strategies are updated Recovery Planning

(RC.RP)

Recovery processes and procedures are executed and maintained to ensure restoration of systems or assets affected by cybersecurity incidents.

RC.RP-1 Recovery plan is executed during or after a cybersecurity incident Improvements (RC.IM) Recovery planning and processes are improved by incorporating lessons learned into future activities.

RC.IM-1 Recovery plans incorporate lessons learned RC.IM-2 Recovery strategies are updated Communications

(RC.CO)

Restoration activities are coordinated with internal and external parties (e.g.

coordinating centers, Internet Service Providers, owners of attacking systems, victims, other CSIRTs, and vendors).

RC.CO-3 Recovery activities are communicated to internal and external stakeholders as well as executive and management teams

Peace Corps 5

1.1 Purpose

The purpose of this guide is to provide guidance for the CP security controls identified in NIST SP 800-53 and contingency planning requirements specified in CIO-SEC-REQ-01. This procedural guide provides PC Federal employees and contractors with significant security responsibilities, as identified in CIO-SEC-REQ-01, and other IT personnel involved in the contingency planning of IT assets the specific procedures and processes they are to follow for PC information systems under their purview.

1.2 Scope

The requirements outlined within this guide apply to and must be followed by all PC Federal employees and contractors who are involved in the contingency planning of PC information systems and data. All PC systems must adhere to the requirements and guidance provided with regard to contingency planning as described in this guide.

1.3 Policy

CIO-SEC-REQ-01 contains the following policy statements regarding contingency planning.

Chapter 3, Section 1 Asset Management

(h) As part of a system’s contingency planning process, resources must be prioritized based on their classification, criticality, and business value. A BIA is required as part of the system’s contingency plan.

Chapter 3, Section 2 Business Environment

(c) PC system contingency plan’s BIA should prioritize business missions in relation to the systems supporting the mission objectives and activities.

(d) PC system contingency plan’s BIA should identify critical services and any dependencies regarding those services.

(g) PC system contingency plans must address the ability to continue missions under all operating states (e.g., disasters/attacks, recovery, and restoration to normal operations).

Chapter 4, Section 4 Information Protection Processes and Procedures

(r) Contingency plans must be developed and revised annually, as necessary, for all IT systems IAW PC CIO-IT Security-06-29. The plans must include recovery procedures, a separate disaster recovery plan may be developed if necessary.

(t) Contingency plans must be annually tested in accordance with CIO-SEC-PLN-03 “Contingency Planning (CP)”.

Chapter 6, Section 1 Response Planning

(a) All information systems must have their contingency plans and Incident Response Plans tested annually.

(b) Lessons learned during contingency plan and incident response plan tests must be incorporated into revised plans.

Peace Corps 6

Chapter 6, Section 2 - Communications

(b) Personnel with contingency planning responsibilities must be trained in their contingency roles and responsibilities with respect to the information system annually.

Chapter 6, Section 5 - Improvements

(b) Contingency plans must be updated based on lessons learned during responses to disasters, other events invoking the contingency plan or plan testing.

Chapter 7, Section 1 – Recovery Planning

As part of a system’s contingency planning process, recovery plans are exercised as part of a cybersecurity incident response or after the response, as appropriate.

Chapter 7, Section 2 - Improvements

(a) As part of a system’s contingency planning processes, lessons learned from contingency plan tests regarding recovery must be incorporated into a revised contingency plan.

(b) Personnel with contingency planning responsibilities must be trained in their contingency roles and responsibilities with respect to the information system annually.

1.1 References

Federal Standards, Regulations, and Publications:

• EO 13800, “Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure”

• FIPS PUB 199, “Standards for Security Categorization of Federal Information and Information Systems”

• NIST Cybersecurity Framework, “Framework for Improving Critical Infrastructure Cybersecurity”

• NIST SP 800-34, Revision 1, “Contingency Planning Guide for Federal Information Systems”

• NIST SP 800-37, Revision 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy”

• NIST SP 800-53, Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”

• NIST SP 800-84, “Guide to Test, Training and Exercise Programs for Information Technology Plans and Capabilities”

• NIST SP 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations”

• OMB Circular No. A-130, “Managing Information as a Strategic Resource”

PC Policies, Procedures, Guidance:

• MS 542, “Information Security Program”

• MS 402, “Domestic Continuity of Operations and Occupant Emergency Plan Programs” https://www.whitehouse.gov/presidential-actions/presidential-executive-order-strengthening-cybersecurity-federal-networks-critical-infrastructure/ https://www.whitehouse.gov/presidential-actions/presidential-executive-order-strengthening-cybersecurity-federal-networks-critical-infrastructure/ https://www.whitehouse.gov/presidential-actions/presidential-executive-order-strengthening-cybersecurity-federal-networks-critical-infrastructure/ https://www.whitehouse.gov/presidential-actions/presidential-executive-order-strengthening-cybersecurity-federal-networks-critical-infrastructure/ https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-84.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf

Peace Corps 7

• CIO-SEC-REQ-01 “Information Security Program Requirements”

• CIO-SEC-PLN-05, “Incident Response (IR)”

• CIO-SEC-PLN-04, “Information Security Program Plan”

• PC Solution Delivery Framework

2 Contingency Planning Roles and Responsibilities

There are many roles associated with implementing effective contingency planning for IT systems. The roles and responsibilities provided in this section have been extracted or paraphrased from CIO-SEC-REQ-01 or summarized from PC and Federal guidance. Throughout this guide, specific processes and procedures for implementing NIST’s CP controls are described.

2.1 Authorizing Official (AO)

Responsibilities include the following:

• Ensuring Information Assurance is included in management planning, programming budgets, and the IT Capital Planning process.

• Ensuring contingency plans are developed and tested annually in accordance with OMB Circular A-130, NIST SP 800-34, Revision 1, and CIO-SEC-PLN-03, “Contingency Planning”

2.2 Information Systems Security Manager (ISSM)

Responsibilities include the following:

• Ensuring assessment and authorization support documentation, including contingency plans and test reports, are developed and maintained.

• Reviewing and coordinating reporting of Security Advisory Alerts, compliance reviews, security and privacy awareness training, incident reports, contingency plan testing, and other IT security program elements.

2.3 Information Systems Security Officer (ISSO)

Responsibilities include the following:

• Assisting in the development and maintenance of contingency plan and contingency plan test report documentation.

• Assisting in the identification, implementation, and assessment of a system’s security controls, including common controls.

• Working with the system owners to develop, implement, and manage Plans of Action and Milestones (POA&Ms).

Peace Corps 8

2.4 System Owners (e.g., System Program Managers/Project Managers)

Responsibilities include the following:

• Participating in activities related to the assessment and authorization of the system to include security planning, risk assessments, security and incident response testing, and contingency planning and testing.

• Developing, implementing and maintaining an approved IT Contingency Plan which includes an acceptable Business Impact Analysis (BIA).

• Coordinating with IT security personnel including the ISSO and Data Owners to ensure implementation of system and data security requirements

• Working with the ISSO and ISSM to develop, implement, and manage POA&Ms.

2.5 Data Owners

Responsibilities include the following:

• Coordinating with system owners, ISSMs, ISSOs, and Custodians to ensure the data is properly stored, maintained, and protected in accordance with PC policies, regulations and guidelines.

• Coordinating with IT security personnel including the ISSM and ISSO and system owners to ensure implementation of system and data security requirements.

2.6 Custodians

Responsibilities include the following:

• Coordinating with Data Owners and System Owners to ensure the data is properly stored, maintained, and protected.

• Providing and administering general controls such as back-up and recovery systems consistent with the policies and standards issued by the Data Owner.

• Establishing, monitoring, and operating information systems in a manner consistent with

PC policies and standards as relayed by the AO.

2.7 System/Network Administrators

Responsibilities include the following:

• Ensuring the appropriate security requirements are implemented consistent with PC IT security policies and hardening guidelines.

• Implementing system backups and remediation of security vulnerabilities, including patching, updates, configuration changes, etc.

• Working with the Custodian/ISSO to ensure appropriate technical security requirements are implemented.

Peace Corps 9

3 IT Contingency Planning Process

Contingency planning is a coordinated strategy involving plans, procedures, and technical measures that enable a system to be recovered as quickly and effectively as possible following a service disruption. The process 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 its FIPS 199 security categorization level.

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 appropriate NIST SP 800-53 contingency planning controls based on the information system’s FIPS 199 security impact level.

NIST SP 800-34 details a seven-step methodology depicted in Figure 3-1 which identifies the key elements in the contingency planning process. The seven steps incorporate the need to establish CP policy, determine the business criticality of systems/components, identify appropriate CP (and other controls supporting CP), develop and implement CP strategies and plans, train and test them, and maintain them for the system’s lifecycle.

Figure 3-1: Contingency Planning Process (Figure 3-1 from NIST SP 800-34)

All information systems must have well developed and tested contingency plans in place to facilitate the recovery of systems, data and operations after a disruption. The following sections detail the steps in the contingency planning process.

Peace Corps 10

3.1 Step 1 – Develop the Contingency Planning Policy Statement

The first step in the process is to develop the contingency planning policy statement. This is critical to ensure personnel fully understand PC’s contingency planning requirements as stated in CIO-SEC-REQ-01 and this guide.

As documented in NIST SP 800-34, the following key elements are reflected in the PC contingency planning policy statement:

• 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.

3.2 Step 2 – Conduct the Business Impact Analysis

Completion of the BIA is one of the key steps in implementing the CP controls in NIST SP 800- 53, and in the contingency planning process overall. It enables PC associates and contractors with contingency planning responsibilities to characterize the system components, supported mission/business functions, and interdependencies. The BIA correlates the system with the critical mission/business processes and services provided, and based on that information, characterizes the consequences of a disruption.

Per NIST SP 800-34, the BIA should be performed during the initiation phase of a system’s lifecycle. As the system design evolves and components change, the BIA may need to be updated during the development and acquisition phases of the lifecycle. All information systems are required to conduct a BIA as part of the overall contingency planning process. The BIA development process as detailed by NIST SP 800-34, typically consists of the following steps:

• Determine mission/business functions and recovery criticality.

• Identify resource requirements.

• Identify recovery priorities for system resources.

Results of the BIA are used to determine any system specific contingency planning requirements and priorities and can be incorporated into the analysis and strategy development efforts for the COOP, Business Continuity Plan (BCP), and Disaster Recovery Plan (DRP). The BIA process is fully detailed in NIST SP 800-34. A BIA template can be found on the ISSO template network path.

Peace Corps 11

3.3 Step 3 – Identify Preventive Controls

Outage impacts to the information system that have been identified in the BIA can be mitigated through the implementation of preventive controls. Preventive controls are technical measures or operational procedures taken to deter, reduce, and/or detect impacts to the information system and to prevent system disruption. Where feasible and cost-effective, preventive methods are recommended over any actions necessary to recover the system. Preventive controls are identified in NIST SP 800-53. Depending on the system type and its configuration, common measures may include such things as:

• 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;

• 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 Step 4 – Create Contingency Strategies

Contingency strategies are used to mitigate risks associated with the contingency planning family of controls in NIST SP 800-53 and may vary depending on the FIPS 199 security impact level for the information system. As documented in NIST SP 800-34, these strategies generally cover the full range of backup, recovery, contingency planning, testing, and ongoing maintenance of the information system. Detailed backup and recovery guidance for implementing appropriate backup and recovery strategies to restore system operations following a disruption can be found in Section 3.4 of NIST SP 800-34.

3.5 Step 5 – Develop an Information System Contingency Plan

Development of the contingency plan is a critical step in the process of implementing a comprehensive contingency planning program. The plan contains detailed roles, responsibilities, teams, and procedures associated with restoring an information system following a disruption. The contingency plan documents the technical capabilities designed to support contingency operations. The contingency plan format must follow NIST SP 800-34.

Contingency Plan Templates for FIPS 199 Low, Moderate, and High impact systems are available

Peace Corps 12 in the ISSO template directory. The templates may be modified to accommodate system specific, operational, and/or organization requirements.

Figure 3-2 identifies the five main components of the Contingency Plan. The supporting information and plan appendices provide essential information to ensure a comprehensive contingency plan. The Activation and Notification, Recovery, and Reconstitution Phases address specific actions that must be taken following a system disruption or emergency. Detailed contingency plan development guidance can be found in Section 4 of NIST SP 800-34.

Figure 3-2: Contingency Plan Structure (Figure 4-1 in NIST SP 800-34)

3.6 Step 6 – Ensure Plan Testing and Exercises

The contingency plan must be maintained routinely and exercised/tested at least annually to continually refine resumption and recovery procedures to reduce the potential for failure.

Contingency plan tests aid in determining the plan’s overall effectiveness by enabling plan deficiencies to be identified and addressed by validating one or more of the system components and the operability of the plan. The scope, scenario, and objective of each test should be varied to ensure that all of the elements of the contingency plan remain current and effective. NIST SP 800-84 provides guidelines on designing, developing, conducting, and

Peace Corps 13 evaluating test, training, and exercise (TT&E) events to capabilities to prepare for, respond to, manage, and recover from adverse events. Results from testing activities shall be documented in a Contingency Plan Test Report.

There are two categories of testing: announced and unannounced. In an announced test, personnel are instructed when testing will occur, what the objectives of the test are, and what the scenario will be for the test. Announced testing provides test participants the opportunity to prepare for the test in advance by becoming familiar with the procedures. Unannounced testing involves testing without prior notification. Unannounced testing focuses on the adequacy of in-place procedures and team preparedness. The combination of both test types improves the accuracy of recovery procedures and the readiness of test participants.

Regardless of the test type selected, all Contingency Plan Tests should address the following key areas (as applicable):

• Notification procedures;

• System recovery on an alternate platform from backup media;

• Internal and external connectivity;

• System performance using alternate equipment;

• Restoration of normal operations; and

• Other plan testing (where coordination is identified, i.e., COOP, BCP).

There are two basic formats for contingency plan tests, including:

• Classroom or Tabletop Exercise: Tabletop exercises are discussion-based exercises where personnel meet in a classroom setting or in breakout groups to discuss their roles during an emergency and their responses to a particular emergency situation. A facilitator presents a scenario and asks the exercise participants questions related to the scenario, which initiates a discussion among the participants of roles, responsibilities, coordination, and decision making. A tabletop exercise is discussion-based only and does not involve deploying equipment or other resources.

• Functional Exercises: Functional exercises allow personnel to validate their operational readiness for emergencies by performing their duties in a simulated operational environment. Functional exercises are designed to exercise the roles and responsibilities of specific team members, procedures, and assets involved in one or more functional aspects of a plan (e.g., communications, emergency notifications, system equipment setup). Functional exercises vary in complexity and scope, from validating specific aspects of a plan to full-scale exercises that address all plan elements. Functional exercises allow staff to execute their roles and responsibilities as they would in an actual emergency situation, but in a simulated manner.

The selection of a contingency plan test format will depend on the frequency of testing, cost, and time. PC requires annual contingency plan testing for all systems to determine the plan’s effectiveness and the organization’s readiness to execute the plan. The depth and rigor of contingency plan testing activities increases with the FIPS 199 availability security objective. All tests and exercises should include some kind of determination of the effects on the

Peace Corps 14 organization’s operations and provide for a mechanism to update and improve the plan as a result.

• For low impact systems, an annual tabletop exercise is sufficient. The tabletop should simulate a disruption, include all main contingency plan points of contact, and be conducted by the system owner or responsible authority;

• For moderate impact systems, a functional exercise must be conducted at least once every three years. A tabletop exercise is acceptable in other years. The functional exercise is a simulation of a disruption to a system recovery component. The test should include all contingency plan points of contact and be facilitated by the system owner or responsible authority. Exercise procedures should be developed to include an element of system recovery from backups; and

• For high impact systems, a functional exercise must be conducted annually. The functional exercise may vary from a simulation of a disruption to a system recovery component to a complete failure prompting a system failover to an alternate location.

This could include additional activities such as full notification and response of key personnel to the recovery location, recovery of a server or database from backups or setup, and processing from a server at an alternate location. The test may also include a full recovery and reconstitution of the information system to a known state. The extent of the functional exercise is up to the SO based on resources, previous exercises, and other system-specific factors.

3.6.1 Suggested Contingency Plan Test Actions/Key Processes

The following are suggested contingency plan test actions. These key processes are central to effective contingency plan testing and management. Steps 1-4 form the contingency test plan, step 5 is the exercise of the test plan, and step 6 involves revisions to the contingency plan and the contingency test plan following an exercise.

Step 1: Identify contingency plan elements to test: Review the contingency plan to select key procedures that must be tested and periodically revised to ensure that all of the elements of the contingency plan remain current and are effective.

Step 2: Define test objectives: List the specific objective with success criteria for each test element and the overall test plan. Test objectives must include (as applicable):

• Notification procedures;

• System recovery on an alternate platform from backup media;

• Internal and external connectivity;

• System performance using alternate equipment;

• Restoration of normal operations; and

• Other plan testing (where coordination is identified, i.e., COOP, BCP).

Step 3: Identify test participants, pre-test information, location, schedule and environment:

List each test participant and the specific roles they are to perform within the test, the test

Peace Corps 15 location, a test schedule, and affected system components (servers, workstation, and other components that will be tested).

Step 4: Define test scenario and test procedures: List the specific scenario that will be utilized for the test. In determining the scenarios consider both the worst-case incident and those incidents that are most likely to occur. Test scenarios should mimic reality as closely as possible.

Appendix B contains a few sample test scenarios and expected outcomes. Document steps 1-4 in a contingency plan test plan.

Step 5: Execute test and document results: Test results and lessons learned should be documented in a test report. The results should be reviewed with the test participants and other personnel as appropriate.

Step 6: Revision of Contingency Plan: To be effective, the plan must be maintained in a ready state that accurately reflects system requirements, procedures, organizational structure, and policies. Periodic reviews of the plan must be conducted in addition to reviews whenever there are changes affecting:

• Operational requirements

• Security requirements

• Technical procedures

• Changes of hardware, software, and other equipment

• Changes with alternate facility requirements

• Changes with team members and team members contact information

• Changes with vendors and vendors contact information (including alternate and off-site vendor POCs)

• Vital records

3.7 Step 7 – Ensure Plan Maintenance

The contingency plan should be reviewed and updated annually to address system/organizational changes or problems encountered during plan implementation, execution, or testing. The contingency plan is a living document and must always be current.

The plan must be reviewed for accuracy and completeness at least annually or whenever significant changes occur to any element of the plan. At a minimum, plan reviews should focus on the following elements:

• Operational requirements;

• Security requirements;

• Technical procedures;

• Hardware, software, and other equipment (types, specifications, and amount);

• Names and contact information of team members;

• Names and contact information of vendors, including alternate and offsite vendor POCs;

• Alternate and offsite facility requirements; and

• Vital records (electronic and hardcopy).

Peace Corps 16

The plan reviews should also include review of supporting information to ensure that the information is current and continues to meet system requirements adequately. This information includes the following:

• Alternate site contract, including testing times;

• Offsite storage contract;

• Software licenses;

• Memorandums of Understanding (MOUs) or Service Level Agreements (SLAs);

• Hardware and software requirements;

• System interconnection agreements;

• Security requirements;

• Recovery strategy;

• Contingency policies;

• Training and awareness materials;

• Testing scope; and

• Other plans, e.g., COOP, BCP.

Although some changes may be quite visible, others will require additional analysis. When a significant change occurs, the BIA should be updated with the new information to identify new contingency requirements or priorities. As new technologies become available, preventive controls may be enhanced and recovery strategies may be modified. Finally, plan maintenance should be continued as the information system passes through the Disposal phase of its life cycle to ensure that the plan accurately reflects recovery priorities and concurrent processing changes.

Record changes to the plan on a change tracking matrix attached in the front of the document or in an appendix.

4 Implementation Guidance for CP Controls

The PC-defined parameter settings included in the control requirements are italicized and offset by brackets in the control text. As stated in Section 1.2, Scope, the requirements in this guide apply to PC Federal employees and contractors who are involved in contingency planning of PC information systems and data. The PC implementation guidance stated for each control applies to personnel and/or the systems operated on behalf of PC. Any additional instructions/requirements for contractor systems will be included in the “Additional Contractor System Considerations” portion of each control section.

Each CP control or control enhancement paragraph indicates the applicability of the control/control enhancement. CP-1, Contingency Planning Policy and Procedures, has been identified as a Common Control for all PC Federal systems and as a Hybrid Control for PC Contractor systems. The other controls/control enhancements, when included in a system’s control set, either are a Common Control by another Major Information System, a system

Peace Corps 17 specific control implemented by the system, or as a Hybrid Control with shared responsibilities for control implementation. CIO-SEC-PLN-04, “Information Security Program Plan,” describes the PC enterprise-wide common and hybrid controls and outlines the responsible party for implementing them.

4.1 CP-1 Contingency Planning Policy and Procedures

Parameter assignments and implementation guidance for the CP-1 control are provided in

CIO-SEC-PLN-04.

4.2 CP-2 Contingency Plan

Control: The organization:

a. Develops a contingency plan for the information system that:

1. Identifies essential missions and business functions and associated contingency requirements;

2. Provides recovery objectives, restoration priorities, and metrics;

3. Addresses contingency roles, responsibilities, assigned individuals with contact information;

4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;

5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and

6. Is reviewed and approved by [the Information System Security Officer (ISSO) and

System Owner(SO)];

b. Distributes copies of the contingency plan to [the Authorizing Official (AO), Information System Security Officer (ISSO), System Owner, and the Chief Information Security Officer (CISO)];

c. Coordinates contingency planning activities with incident handling activities;

d. Reviews the contingency plan for the information system [annually];

e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;

f. Communicates contingency plan changes to [the Authorizing Official (AO),

g. Information System Security Officer (ISSO), System Owner, and the Chief Information

Security Officer (CISO)]; and

h. Protects the contingency plan from unauthorized disclosure and modification.

Control Enhancements:

(1) Contingency Plan | Coordinate With Related Plans. The organization coordinates contingency plan development with organizational elements responsible for related plans.

Peace Corps 18

(2) Contingency Plan | Capacity Planning. The organization conducts capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations.

(3) Contingency Plan | Resume Essential Missions/Business Functions. The organization plans for the resumption of essential missions and business functions within [a time period recommended by the SO or Contractor in accordance with the Business Impact Analysis (BIA) and approved by the AO] of contingency plan activation.

(4) Contingency Plan | Resume All Missions/Business Functions. The organization plans for the resumption of all missions and business functions within [a time period recommended by the SO or Contractor in accordance with the Business Impact Analysis (BIA) and approved by the AO] of contingency plan activation.

(5) Contingency Plan | Continue Essential Missions/Business Functions. The organization plans for the continuance of essential missions and business functions with little or no loss of operational continuity and sustains that continuity until full information system restoration at primary processing and/or storage sites.

(8) Contingency Plan | Identify Critical Assets. The organization identifies critical information system assets supporting essential missions and business functions.

PC Implementation Guidance: Control CP-2 is applicable at all FIPS 199 levels. Enhancements CP-2(1), (3), and (8) are applicable at the FIPS 199 Moderate and High levels. Enhancements CP- 2(2), (4), and (5) are applicable at the FIPS 199 High level.

CIO-SEC-REQ-01 requires all information systems to have a contingency plan in accordance with NIST SP 800-34 and this guide.

The contingency plan must be reviewed and tested annually and updated as-needed. This can be done either individually or in coordination with annual incident response plan testing or exercises as described in CIO-SEC-PLN-05, “Incident Response (IR).” Copies of the contingency plan must be distributed to personnel who have assigned incident response roles for the information system including the AO, ISSO, PM, and CISO.

Information System Contingency Plan templates for each of the FIPS 199 impact levels are available on the Info Security ISSO template folder.

For enhancements CP-2(1), (3) and (8), FIPS 199 Moderate and High impact systems must coordinate their contingency plan testing/exercises with organizational elements responsible for related plans such as Disaster Recovery, Continuity of Operations (COOP) and/or Incident Response plans.

For enhancements CP-2(2), (4), and (5), FIPS 199 High impact systems must plan for the recovery of the systems essential business functions and mission within the recovery timeframes established by the BIA. In addition, capacity planning must be performed in order to ensure that information processing, telecommunications and environmental support are matched to the needs of the information system, during contingency operations.

Peace Corps 19

Additional Contractor System Considerations: Vendor/contractor systems are required to comply with the control statements.

4.3 CP-3 Contingency Training

Control: The organization provides contingency training to information system users consistent with assigned roles and…