contingency planning guide for federal information systems€¦ · web viewvalidation data...

Contingency planning guide for federal information systems

National Archives Catalog (NAC)

Security Categorization: Moderate

Information System Contingency Plan (ISCP)

Date: April 15, 2020

Version #: 7.0

Prepared by

National Archives and Records Administration

8601 Adelphi Road

College Park, MD 20740

Table of ContentsPlan Approval11.0Introduction21.1Background21.2Scope21.3Assumptions22.0Concept of Operations32.1System Description32.2Overview of Three Phases32.3Roles and Responsibilities43.0Activation and Notification53.1Activation Criteria and Procedure53.2Notification53.3Outage Assessment64.0Recovery64.1Sequence of Recovery Activities64.2Recovery Procedures64.3Recovery Escalation Notices/Awareness75.0Reconstitution75.1Validation Data Testing75.2Validation Functionality Testing75.3Recovery Declaration75.4Notifications (users)75.5Cleanup75.6Offsite Data Storage – Moderate Availability Rating75.7Data Backup85.8Event Documentation85.9Deactivation8APPENDIX A: PERSONNEL CONTACT LIST9APPENDIX B: VENDOR CONTACT LIST10APPENDIX C: DETAILED RECOVERY PROCEDURES11APPENDIX D: ALTERNATE PROCESSING PROCEDURES12APPENDIX E: SYSTEM VALIDATION TEST PLAN13APPENDIX F: ALTERNATE STORAGE, SITE AND TELECOMMUNICATIONS14APPENDIX G: DIAGRAMS (SYSTEM AND INPUT/OUTPUT)15APPENDIX H: HARDWARE AND SOFTWARE INVENTORY16APPENDIX I: INTERCONNECTIONS17APPENDIX J: TEST AND MAINTENANCE SCHEDULE18APPENDIX K: ASSOCIATED PLANS AND PROCEDURES19APPENDIX L: BUSINESS IMPACT ANALYSIS20APPENDIX M: DOCUMENT CHANGE PAGE21

Plan Approval

In accordance with National Archives Records Administration’s (NARA) contingency planning policy, I hereby affirm that the contingency plan is complete and has been tested sufficiently. The designated authority is responsible for continued maintenance and testing of the ISCP.

As the designated authority for the National Archives Catalog (NAC) system, I hereby certify that the information system contingency plan (ISCP) is complete, and that the information contained in this ISCP provides an accurate representation of the application, its hardware, software, and telecommunication components. I further certify that this document identifies the criticality of the system as it relates to the mission of NARA, and that the recovery strategies identified will provide the ability to recover the system functionality in the most expedient and cost-beneficial method in keeping with its level of criticality.

I further attest that this ISCP for NAC will be tested at least annually. This plan was last tested on March 25, 2020; the test, training, and exercise (TT&E) material associated with this test can be found in Xacta. This document will be modified as changes occur and will remain under version control, in accordance with NARA’s contingency planning policy.

_________________________________________________

Jason ClingermanDate

System Owner

18

1.0Introduction

Information systems are vital to NARA mission/business processes; therefore, it is critical that services provided by the NAC system are able to operate effectively without excessive interruption. This Information System Contingency Plan (ISCP) establishes comprehensive procedures to recover NAC quickly and effectively following a service disruption.

1.1Background

This NAC ISCP establishes procedures to recover NAC following a disruption. The following recovery plan objectives have been established:

· Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:

· Activation and Notification phase to activate the plan and determine the extent of damage.

· Recovery phase to restore NAC operations; and

· Reconstitution phase to ensure that NAC is validated through testing and that normal operations are resumed.

· Identify the activities, resources, and procedures to carry out NAC processing requirements during prolonged interruptions to normal operations.

· Assign responsibilities to designated NARA personnel and provide guidance for recovering NAC during prolonged periods of interruption to normal operations.

· Ensure coordination with other personnel responsible for NARA contingency planning strategies. Ensure coordination with external points of contact and vendors associated with NAC and execution of this plan.

1.2Scope

This ISCP has been developed for NAC, which is classified as a moderate impact system, in accordance with Federal Information Processing Standards (FIPS) 199 – Standards for Security Categorization of Federal Information and Information Systems. Procedures in this ISCP are for moderate impact systems and designed to recover NAC within 48 hours (2 business days). This plan does not address replacement or purchase of new equipment; short-term disruptions lasting less than 48 hours; or loss of data at the onsite facility or at the user-desktop levels.

1.3Assumptions

The following assumptions were used when developing this ISCP:

· NAC has been established as a moderate-impact system, in accordance with FIPS 199.

· NAC includes services provided by the Amazon Web Services (AWS) cloud service provider.

· If the Availability of NAC is Moderate, then an alternate processing site and offsite storage is required and has been established for NAC as discussed below:

· Current backups of the system software and data are intact and available at the offsite storage facility in provided by Amazon Web Services (AWS).

· Alternate facilities have been established at AWS and are available if needed for relocation of NAC.

· The NAC is inoperable at AWS and cannot be recovered within 48 hours (2 business days).

· The Recovery Time Objective (RTO) for NAC is 48 hours.

· Key NAC personnel have been identified and trained in their emergency response and recovery roles; they are available to activate the NAC ISCP.

· Additional assumptions as appropriate.

The NAC ISCP does not apply to the following situations:

· Overall recovery and continuity of mission/business operations. The Business Continuity Plan (BCP) and Continuity of Operations Plan (COOP) address continuity of mission/business operations.

· Emergency evacuation of personnel. The Occupant Emergency Plan (OEP) addresses employee evacuation.

· Any additional constraints and associated plans should be added to this list.

2.0Concept of Operations

The Concept of Operations section provides details about NAC, an overview of the three phases of the ISCP (Activation and Notification, Recovery, and Reconstitution), and a description of roles and responsibilities of NARA personnel during a contingency activation.

2.1System Description

The NAC system was created by NARA to serve as the primary method for search, access, and distribution of publicly available, digital NARA content.

At a high level, NAC will:

· Hold a copy of publicly available NARA digital content

· Provide methods for downloading this content by the public

· Maintain and make available renditions (for example, images at different resolutions) of the content designed to make the content more useful for the public.

· Provide methods to search this content and associated metadata so that users can easily find the content they wish to access. This will include:

· Maintaining a search engine index over the content;

· Providing a search user interface to the content;

· Providing APIs and other methods for end-users to access the content programmatically.

NAC is installed and running in the AWS US East/West region. AWS East/West is FedRAMP approved cloud service provider. AWS leverages the Infrastructure-as-a-Service (IaaS) cloud computing model, which enabled on-demand Internet access to a shared pool of configurable computing resources such as servers, storage, network infrastructure, and various other web services. Customers can provision or release computing resources on demand.

2.2Overview of Three Phases

This ISCP has been developed to recover and reconstitute the NAC using a three-phased approach. This approach ensures that system recovery and reconstitution efforts are performed in a methodical sequence to maximize the effectiveness of the recovery and reconstitution efforts and minimize system outage time due to errors and omissions.

The three system recovery phases are:

Activation and Notification Phase – Activation of the ISCP occurs after a disruption or outage that may reasonably extend beyond the RTO established for a system. The outage event may result in severe damage to the facility that houses the system, severe damage or loss of equipment, or other damage that typically results in long-term loss.

Once the ISCP is activated, system owners and users are notified of a possible long-term outage, and a thorough outage assessment is performed for the system. Information from the outage assessment is presented to system owners and may be used to modify recovery procedures specific to the cause of the outage.

Recovery Phase – The Recovery phase details the activities and procedures for recovery of the affected system. Activities and procedures are written at a level that an appropriately skilled technician can recover the system without intimate system knowledge. This phase includes notification and awareness escalation procedures for communication of recovery status to system owners and users.

Reconstitution –The Reconstitution phase defines the actions taken to test and validate system capability and functionality at the original or new permanent location. This phase consists of two major activities: validating successful reconstitution and deactivation of the plan.

During validation, the system is tested and validated as operational prior to returning operation to its normal state. Validation procedures may include functionality or regression testing, concurrent processing, and/or data validation. The system is declared recovered and operational by system owners upon successful completion of validation testing.

Deactivation includes activities to notify users of system operational status. This phase also addresses recovery effort documentation, activity log finalization, incorporation of lessons learned into plan updates, and readying resources for any future events.

2.3Roles and Responsibilities

The ISCP establishes several roles for NAC recovery and reconstitution support. Persons or teams assigned ISCP roles have been trained to respond to a contingency event affecting NAC.

Contingency Plan Role

NAC Role

Responsibilities

ISCP Director / ISCP Director (Alternate)

NAC System Owner

· Overall management of the ISCP

· Confirming severity of a system disruption with the ISCP Coordinator

· Formal activation of the ISCP

· Notifying the ISCP Coordinator to begin formal assessment of the system disruption and develop recovery strategies

· Notifying the ISCP Coordinator to assemble the ISCP Recovery Teams and begin system recovery

· Overseeing annual testing, maintenance, and distribution of the plan

· Contacting vendors, contractors or other external organizations to assist in the system recovery as necessary

· Making initial assessment of system disruption (i.e., is it a minor system failure or a catastrophic event/major system failure)

· For a minor system failure:

· Assure that the incident is reported to NARA IT Operations, and is logged in the trouble ticket system.

· Assess the system disruption

· Estimate system recovery time and communicate this information to the ISCP Director

· Contact and instruct all necessary ISCP Recovery Team members to recover the failing system component(s)

· For a catastrophic event/major system failure:

· Initiate full activation of the ISCP

· Assess the system disruption and develop recovery recommendations, providing thorough assessment of catastrophic events/major system failures

· Develop the damage assessment report and recommend recovery and resumption strategies to the ISCP Director for review and consideration

· Contact all necessary ISCP Recovery Team Members and instruct them to assemble their teams to recover the failing system component(s)

· Coordinate communications between the ISCP Recovery Teams and ISCP Director in recovering the system

· Complete an after-action report upon resumption of normal operations

· Ensure the annual testing, maintenance, and distribution of the plan

ISCP Coordinator / ISCP Team Member

All necessary technicians, administrators, and programmers from the major divisions

· Assisting in all recovery and resumption activities for minor system failures, as necessary

· Assisting in all recovery and resumption activities for catastrophic events/major system failures, as necessary

3.0Activation and Notification

The Activation and Notification Phase defines initial actions taken once a NAC disruption has been detected or appears to be imminent. This phase includes activities to notify recovery personnel, conduct an outage assessment, and activate the ISCP. At the completion of the Activation and Notification Phase, NAC ISCP staff will be prepared to perform recovery measures.

3.1Activation Criteria and Procedure

The NAC ISCP may be activated if one or more of the following criteria are met:

· The cloud service provider indicates an outage that will exceed the RTO of 48 hours

· The type of outage indicates NAC will be down for more than 48 hours;

· The facility housing NAC is damaged and may not be available within 48 hours; and,

· Other criteria, as appropriate.

The following persons or roles may activate the ISCP if one or more of these criteria are met:

· ISCP Director

· ISCP Director – Alternate

3.2Notification

The first step upon activation of the NAC ISCP is notification of NARA Helpdesk, appropriate mission/business and system support personnel. Contact information for appropriate POCs is included in Appendix A, Personnel Contact List and Appendix B, Vendor Contact List.

Notification of outage incidents for NAC that require activation of the ISCP will be performed through phone or email. The following information should be relayed to individuals during the notification phase:

· Nature of the emergency that has occurred or is impending;

· Loss of life or injuries;

· Any known damage estimates;

· Response and recovery details;

· Where and when to convene for briefing or further response instructions;

· Instructions to prepare for relocation for estimated time period (if applicable);

· Instructions to complete notifications (if applicable).

Notification will also be provided to the system stakeholders when the issue is resolved.

3.3Outage Assessment

The cloud service provider is responsible for the outage assessment if it is within the scope of their services. That assessment will include the extent of the disruption and expected recovery time.

If the outage is outside the scope of the cloud service provider, a thorough outage assessment is necessary to determine the extent of the disruption, any damage, and expected recovery time. This outage assessment is conducted by the technical team. Assessment results are provided to the ISCP Coordinator to assist in the coordination of the recovery of NAC.

Outage Assessment includes activities to determine:

· The cause of the disruption;

· Potential for additional disruption or damage.

4.0Recovery

The Recovery Phase provides formal recovery operations that begin after the ISCP has been activated, outage assessments have been completed (if possible), personnel have been notified, and appropriate teams have been mobilized. Recovery Phase activities focus on implementing recovery strategies to restore system capabilities, repair damage, and resume operational capabilities at the original or an alternate location. At the completion of the Recovery Phase, NAC will be functional and capable of performing the functions identified in Section 2.1 of this plan.

4.1Sequence of Recovery Activities

The cloud service provider is responsible for the sequence of recovery activities and will report status as appropriate to the ISCP Director.

4.2Recovery Procedures

Since NAC is a cloud-hosted architecture, the recovery of business operations depends on the nature of the contingency. In the event that the cloud provider incurs a partial loss, the cloud provider will default to their back up systems with no impact to the NARA user.

In the event that the NARA workspace becomes unavailable, the NARA user is able to access the cloud-hosted system from any other physical environment so long as there is Internet access.

NARA does not maintain any alternate processing capabilities or procedures in the event that the cloud service provider is unable to provide service. In the event of an outage, NARA will work with the provider to restore service. In the event that the cloud service provider is no longer able to provide service, the NAC business functions are suspended until a new vendor is identified and funded.

4.3Recovery Escalation Notices/Awareness

While the recovery effort is underway, hourly status notification will be provided to the ISCP Director, ISCP Coordinator, and all appropriate stakeholders.

5.0Reconstitution

Reconstitution is the process by which recovery activities are completed and normal system operations are resumed. If the original facility is unrecoverable, the activities in this phase can also be applied to preparing a new permanent location to support system processing requirements. A determination must be made on whether the system has undergone significant change and will require reassessment and reauthorization. The phase consists of two major activities: validating successful reconstitution and deactivation of the plan.

5.1Validation Data Testing

Validation data testing is the process of testing and validating data to ensure that data files or databases have been recovered completely at the permanent location. Detailed validation test procedures are provided in Appendix E, System Validation Test Plan.

5.2Validation Functionality Testing

Validation functionality testing is the process of verifying that NAC functionality has been tested, and the system is ready to return to normal operations. Detailed functionality test procedures are provided in Appendix E, System Validation Test Plan.

5.3Recovery Declaration

Upon successfully completing testing and validation, the system owner will formally declare recovery efforts complete, and that NAC is in normal operations. NAC business and technical POCs will be notified of the declaration by the ISCP Coordinator.

5.4Notifications (users)

Upon return to normal system operations, NAC users will be notified by the ISCP Director or ISCP Director - Alternate using predetermined, and the most appropriate notification procedures (e.g., email, broadcast message, phone calls, etc.).

5.5Cleanup

Cleanup is the process of cleaning up or dismantling any temporary recovery locations, restocking supplies used, returning manuals or other documentation to their original locations, and readying the system for a possible future contingency event.

Materials, plans, and equipment used during the recovery and testing must be returned to storage or their proper location. All sensitive materials must be destroyed or properly returned to safe storage, as appropriate. Any personnel temporarily assisting other office locations during the disruption should be instructed by their respective team leaders to conclude their assistance and report to their primary sites and duties.

5.6Offsite Data Storage – Moderate Availability Rating

It is important that all backup and installation media used during recovery be returned to the offsite data storage location.

5.7Data Backup

As soon as reasonable following recovery, the cloud service provider will complete a new data backup.

5.8Event Documentation

It is important that all recovery events be well-documented, including actions taken and problems encountered during the recovery and reconstitution effort, and lessons learned for inclusion and update to this ISCP. It is the responsibility of each ISCP team or person to document their actions during the recovery and reconstitution effort, and to provide that documentation to the ISCP Coordinator.

Types of documentation that should be generated and collected after a contingency activation include:

· Activity logs (including recovery steps performed and by whom, the time the steps were initiated and completed, and any problems or concerns encountered while executing activities);

· Functionality and data testing results;

· Lessons learned documentation; and,

· After Action Report (including identification of any new components including all information applicable to the Configuration Management (CM) documentation.

5.9Deactivation

Once all activities have been completed and documentation has been updated, the ISCP Director/ISCP Coordinator will formally deactivate the ISCP recovery and reconstitution effort. Notification of this declaration will be provided to NARA Helpdesk, all business and technical POCs.

The following procedures will be followed to deactivate the ISCP for NAC:

· Verify that the application is functioning correctly.

· Inform vested parties that the application has been restored and is functioning properly.

· Log details of the event and problems encountered with the ISCP.

· Incorporate problem solutions into later versions of the ISCP.

Any personnel temporarily assisting other office locations during the disruption should be instructed by their respective team leaders to conclude their assistance and report to their primary sites and duties.

APPENDIX A: PERSONNEL CONTACT LIST

NAC ISCP Key Personnel

Key Personnel

Contact Information

Key ersonnel

Contact Information

ISCP Director

Work

301-837-3022

Jason Clingerman System Owner

Home

8601 Adelphi Rd.

Cellular

College Park, MD 20740

Email

[email protected]

ISCP Director – Alternate

Work

301-837-3024

Richard Steinbacher Contracting Officer Representative

Home

Cellular

Email

[email protected]

ISCP Coordinator

Work

301-837-3022

Jason Clingerman System Owner

Home

Cellular

Email

[email protected]

ISCP Coordinator – Alternate

Work

301-837-3024

Richard Steinbacher

Home

Cellular

Email

[email protected]

ICSP Team – Team Members

Adil Latiwala – Technical Point of Contact

Work

301-837-3161

Home

Cellular

240-593-5831

Email

[email protected]

Gang Chen

Work

Home

Cellular

Email

[email protected]

Information System Security Officer

Work

301-837-0430

Anton Davis

Home

Cellular

301-755-7026

Email

[email protected]

NARA Helpdesk

Work

703-872-7755

Email

[email protected]

APPENDIX B: VENDOR CONTACT LIST

Vendor Contact List

Key Personnel

Vendor

Component/Service

Contact Information

Amazon Web Services

Cloud

866 216-1072

Aspire

Content Processing

703 953-2791

Splunk

Search, monitor and analyze data

855 775-8657

InfoReliance

Cloud

844 458-5433

DSA

Service

703 748-7601

APPENDIX C: DETAILED RECOVERY PROCEDURES

The cloud service provider is responsible for recovery procedures.

APPENDIX D: ALTERNATE PROCESSING PROCEDURES

NARA does not maintain any alternate processing capabilities or procedures in the event that the Cloud Service Provider (CSP) is unable to provide service. In the event of an outage, NARA will work with the CSP to restore service. In the event that the CSP is no longer able to provide service, the NAC business functions are suspended until a new vendor is identified and funded.

APPENDIX E: SYSTEM VALIDATION TEST PLAN

Once the system has been recovered, the following steps will be performed to validate system data and functionality:

The NAC system administrator tests for basic NAC functionality during regular operation.

Restoration

The NAC system administrator restored operations to the production server

Test Functionality

Test functionality of NARA NAC application: login, search and retrieval capabilities.

Assessment procedures

Have the NAC system administrator use a NARA workstation to access the NAC application and perform the outlined tasks

Personnel & tools

NAC system administrator, NARA workstation.

Successful outcome

Login, search and retrieve are all functioning correctly.

Project Documentation

Standard Operating Procedures

The ISCPD or alternate informs all users of the restoration of the system.

Test Outcome

The production application is online and functional, which is determined by connecting and testing NAC applications functionality.

Users Notification

Contact all users and inform them of the restoration of the system.

Notification Process

Ask the system administrator to email all NAC users, notifying them of the resolution to the aforementioned issues.

Personnel & tools

ISCP Director

Successful outcome

All active NAC users are notified by e-mail that the NAC system is back online.

Project Documentation

NAC User Group E-mail List, or NARA personnel mailing list.

APPENDIX F: ALTERNATE STORAGE, SITE AND TELECOMMUNICATIONS

The cloud service provider maintains alternate storage and failover capabilities for the service they provide. This is a requisite to the FedRAMP certification. There is no additional NARA alternate storage capability.

APPENDIX G: DIAGRAMS (SYSTEM AND INPUT/OUTPUT)

The NAC system diagram is provided below.

APPENDIX H: HARDWARE AND SOFTWARE INVENTORY

The inventory is maintained in Xacta and copied below.

APPENDIX I: INTERCONNECTIONS

NAC receives weekly export data from DAS for the records created, modified, or deleted from the previous week for ingestion into NAC. The data is in XML format.

APPENDIX J: TEST AND MAINTENANCE SCHEDULE

Step

Date Due by

Responsible Party

Date Scheduled

Date Held

Identify tabletop facilitator.

March 2020

ISCP Coordinator

March 2020

March 2020

Develop tabletop test plan.

March 2020

Tabletop Facilitator

March 2020

March 2020

Invite participants.

March 2020

Tabletop Facilitator

March 2020

March 2020

Conduct tabletop test.

March 2020

Facilitator, ISCP Coordinator, POCs

March 25, 2020

March 25, 2020

Finalize after action report and lessons learned.

April 2020

ISCP Coordinator

April 2020

April 2020

Update ISCP based on lessons learned.

April 2020

ISCP Coordinator

April 2020

April 2020

Approve and distribute updated version of ISCP.

May 2020

ISCP Director, ISCP Coordinator

May 2020

May 2020

APPENDIX K: ASSOCIATED PLANS AND PROCEDURES

Artifacts related to plans and procedures such FIPS 199, BIA, and System Security Plan (SSP) are maintained as separate documents and can be found in Xacta.

APPENDIX L: BUSINESS IMPACT ANALYSIS

The Business Impact Analysis is maintained in Xacta and copied below.

APPENDIX M: DOCUMENT CHANGE PAGE

Modifications made to this plan since the last printing are as follows:

Document Version

Description of contents / revision

Editor

Change Date

0.1

Initial draft

07/2009

1.0

Final

08/14/2009

2.0

Revision – modifications to include OPA and CERA Systems

05/27/2011

3.0

Updated contact names and numbers

08/09/2011

3.1

Annual review and update

09/30/2013

4.0


05/14/2014

4.1


03/27/2015

5.0

Review and update

09/23/2016

6.0

Review and update

ISSO - John M. Nelson

05/12/2019

7.0

FY20 Annual update. RTO in sections 1.2, 1.3, and 3.1 updated to match the FY20 BIA. Notifications updated to include NARA Helpdesk. Appendix A Contact List updated. Inventory and BIA updated with FY20 information. Test and maintenance dates updated to reflect the FY20 tabletop exercise.

ISSO – Anton Davis

04/15/2020

NAC System

Inventory List FY20.xlsx

NAC_System Inventory_FY20The National Archives Catalog (NAC)ISSO: Olaleye OluwabiyiHostnameOS_familyOS_NameOS_VersionIp_addressMac_AddressEquipment_ClassManufacturerModelSerial_NoVisual_IDDescriptionFunctionda03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0e7091a9a5e27fa12N/ANon-Productionapplication serverda04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0d26b0744cc95ea39N/ANon-Productionapplication serverdcp01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0dc077ba79526fa19N/ANon-Productioningestiondcp02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-06c1dab69edcfd1caN/ANon-Productionddb02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-04ebe5490bbcfd0fcN/ANon-Productiondatabasedl01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSt2.microi-09b56c0d3177de97bN/ANon-Productionlambdads05LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0ee643f2257110dc5N/ANon-Productionsearchds06LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-032f28d1294ba6d7fN/ANon-Productionsearchds07LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0ea0da8028ae2224fN/ANon-Productionsearchds08LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0d6dd586e2c9c8d4fN/ANon-Productionsearchdw02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm3.xlargei-0cf2eafadaac19f91N/ANon-Productiondns webNAC Jump BoxLinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.xlargei-0c5e781ab42fa0ec3N/AProductionjump/nat/proxynessusLinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm3.mediumi-a726f14cN/AProductionnessusotw01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm3.largei-ae87c833N/AProductionTripwirepa01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-08d13d9cbbcb3e087N/AProductionapplication serverpa02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0664cbda97856a6c8N/AProductionapplication serverpa03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0cdad0b65d4e3365bN/AProductionapplication serverpa04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0c824ffebb35e481fN/AProductionapplication serverpcp01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0e2a2c3b7ae580ce8N/AProductioningestionpcp02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0b38a8effd7bd18d5N/AProductioningestionpdb01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSi2.4xlargei-7a7c9850N/AProductiondatabasepdb02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSi2.4xlargei-0d27a284615396f7aN/AProductiondatabasepl101LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSc5.9xlargei-0bb5b3465ddcebbceN/AProductionlambdappdb01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSi2.4xlargei-02ef3ed70a4204effN/AProductiondatabaseppdb02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSi2.4xlargei-0a5307a142790849aN/AProductiondatabaseps01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-07c682ab4b780af57N/AProductionsearchps02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-00dd8a8b399504ec0N/AProductionsearchps03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0cece82d36d74bfb6N/AProductionsearchps04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-06037210fea9ca69bN/AProductionsearchps05LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-097ad624e6b90f88bN/AProductionsearchps06LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-097bf30fc34eeae44N/AProductionsearchpw01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0d6d4c67b71844f78N/AProductionwebpw02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-04f1de9b7931d7b9bN/AProductionwebpw03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0812b687859d74dbcN/AProductionwebpw04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-06cda50b93ade5b71N/AProductionreporting webua01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-003df48ebb79b902cN/ANon-Productionapplication serverua02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-05aaca46e87425b1cN/ANon-Productionapplication serverua03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-00f46c05ceed01a57N/ANon-Productionapplication serverua04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0189bbfe124617b25N/ANon-Productionapplication serverucp01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0a38685d33b9a3f41N/ANon-Productioningestionucp02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-073ab013eebc076a1N/ANon-Productioningestionudb01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.2xlargei-def8fcf5N/ANon-Productiondatabaseudb02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.2xlargei-8e8581a5N/ANon-Productiondatabaseus01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-09831a603f5db90b1N/ANon-Productionsearchus02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0f19260e54c48948fN/ANon-Productionsearchus03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-06cbbfb5685d15eebN/ANon-Productionsearchus04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0aa2c79ad177f98bfN/ANon-Productionsearchus05LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0554be1de681d394aN/ANon-Productionsearchus06LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0a1778ad179b99ff2N/ANon-Productionsearchuw01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0b0e26f19f3a8505fN/ANon-Productionwebuw02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-097ec1d6d14cdfdd2N/ANon-Productionwebuw03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0e1b89f6a07af36baN/ANon-Productionwebuw04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0f92cd8e06a7cff9dN/ANon-Productionreportingppdb01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-02ef3ed70a4204effN/APre-Productiondatabaseppdb02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0a5307a142790849aN/APre-Productiondatabasepps01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0769ad7e3008c0fa8N/APre-Productionsearchpps02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-0d8df08fe1132086dN/APre-Productionsearchpps03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-05be3ab1f07a7ff02N/APre-Productionsearchpps04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-04fc77b6dafa501caN/APre-Productionsearchpps05LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-06f04cae5ddd9acc1N/APre-Productionsearchpps06LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSr4.4xlargei-081dee81bec2870a3N/APre-Productionsearchppw01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-007d8ddf0291bb900N/APre-Productionwebppw02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0ead4c951d02a2d2fN/APre-Productionwebppw03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0c514de6064ec80a9N/APre-Productionwebppw04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.largei-0ee251633308bca85N/APre-ProductionwebpocjumpLinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.xlargei-0bc29d8c3b618bb32N/APre-Productionjump/nat/proxyppa01LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-067f5f517f1adef72N/APre-Productionapplication serverppa02LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-003d87282c4aac469N/APre-Productionapplication serverppa03LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-0aa27366012dc0af2N/APre-Productionapplication serverppa04LinuxRHEL 6 (64 bit)6 (64 bit)N/AN/AAny/Computer/ServerAWSm4.2xlargei-01a987be32b4e9f72N/APre-Productionapplication server

&14Project: National Archives Catalog

Page &P of &N &14

NAC BIA FY20

v3.0.pdf

National Archives Catalog

System

Business Impact Analysis (BIA)

NATIONAL ARCHIVES AND RECORDS ADMINISTRATION

Date: February 25, 2020 Version: 2.1 Template Date: February 25, 2019 Template Version: 4.0

National Archives Catalog Business Impact Analysis (BIA)

i

DOCUMENT CHANGE PAGE

Modifications made to this Business Impact Analysis (BIA) for National Archives Catalog are as

follows:

Document

Version

Description of contents / revision Editor Change Date

1.0 BIA for National Archives Catalog (NAC) ISSO 12/12/2016

2.0 Update of NAC BIA with new template ISSO – John Nelson 3/20/2019

3.0 FY 2020 System Owner/ISSO Document

Review and Validation

MTD, RTO update

Resource Requirements update

ISSO – John Nelson 2/25/2020


ii

Table of Contents DOCUMENT CHANGE PAGE ...................................................................................................... i

1. Overview ................................................................................................................................. 1

1.1 Purpose ............................................................................................................................ 1

2. System Description .................................................................................................................. 1

3. BIA Data Collection ................................................................................................................ 1

3.1 Determine Process and System Criticality ...................................................................... 2

3.1.1 Identify Outage Impacts and Estimated Downtime ................................................ 2

3.2 Identify Resource Requirements ..................................................................................... 3

3.3 Identify Recovery Priorities for System Resources ......................................................... 4

4. BIA Approval .......................................................................................................................... 6


1

1. Overview This Business Impact Analysis (BIA) is developed as part of the contingency planning process for the National

Archives Catalog (NAC). It was created on December 12, 2016 and updated on February 25, 2020.

1.1 Purpose The purpose of the BIA is to identify and prioritize system components by correlating them to the

mission/business process(es) the system supports, and using this information to characterize the impact on the

process(es) if the system were unavailable.

The BIA is composed of the following three steps:

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 that an

organization can tolerate while still maintaining the mission.

Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible.

Examples of resources that should be identified include facilities, personnel, equipment, software, data

files, system components, and vital records.

Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can more clearly be linked to critical mission/business processes. Priority levels can be

established for sequencing recovery activities and resources.

This document is used to build the NAC Information System Contingency Plan (ISCP) and is included as a

key component of the ISCP. It also may be used to support the development of other contingency plans

associated with the system, including, but not limited to, the Disaster Recovery Plan (DRP) or Cyber Incident

Response Plan.

2. System Description The National Archives Catalog system was created by NARA to serve as the primary method for search,

access, and distribution of publicly available, digital NARA content. At a high level, NAC will:

Hold a copy of publicly available NARA digital content

Provide methods for downloading this content by the public

Will maintain and make available renditions (for example, images at different resolutions) of the content designed to make the content more useful for the public

Will provide methods to search this content and associated metadata so that users can easily find the content they wish to access. This will include:

Maintaining a search engine index over the content

Providing a search user interface to the content

Will provide APIs and other methods for end-users to access the content programmatically.

3. BIA Data Collection Data was collected through analysis of existing documentation, research, email communication, and interviews

with NAC stakeholders.


2

3.1 Determine Process and System Criticality Step one of the BIA process - Working with input from users, managers, mission/business process owners,

and other internal or external points of contact (POC), identify the specific mission/business processes that

depend on or support the information system.

Mission / Business Process Description

Search, access & distribute publicly available digital

NARA content

NAC provides APIs and other methods for end-

users to access and received digital content

programmatically

3.1.1 Identify Outage Impacts and Estimated Downtime Outage Impacts

The following impact categories represent important areas for consideration in the event of a disruption or

impact.

Impact category: NARA system has a requirement to search, access, or distribute digital NARA content.

Impact values for assessing category impact:

Severe = Total loss of the ability to search, access, or distribute digital NARA content

Moderate = Temporary loss of the ability to search, access, or distribute digital NARA content

Minimal = Minimal loss of the ability to search, access, or distribute digital NARA content

The table below summarizes the impact on each mission/business process if NAC were unavailable, based on

the following criteria:

Mission / Business

Process

Impact Category - NARA system user has a requirement to search, access, or distribute

digital NARA content

Severe Moderate Minimal Impact

Search, access and

distribute digital

NARA content

X The search, access

and distribute

functions will be

minimally impacted

because NAC

backups are

maintained within

the AWS Cloud

Estimated Downtime

Working directly with mission/business process owners, departmental staff, managers, and other stakeholders,

estimate the downtime factors for consideration as a result of a disruptive event.

Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time leaders/managers are willing to accept for a mission/business process outage or disruption and includes all impact

considerations. Determining MTD is important because it could leave continuity 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.

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


3

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.

Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data must be recovered (given the most recent backup copy of

the data) after an outage.

The table below identifies the MTD, RTO, and RPO (as applicable) for the organizational mission/business

processes that rely on NAC.

Mission / Business Process MTD RTO RPO

Search, access & distribute publicly available digital NARA

content

72 hours 48 hours 24 hours

Hardware and software inventories are located in the Configuration Management Database (CMDB) or the

Master Configuration Document (MCD).

NAC backups are stored within the AWS Cloud.

3.2 Identify Resource Requirements The following table identifies the resources that compose NAC, including hardware, software, and other

resources such as data files. The resources identified in the table are limited to the Production environment.

The Development (Dev) and User Acceptance Testing (UAT) environments are not included. Based on

conversations with the system owner, it was determined that the Dev and UAT environments are not critical to

the operation of NAC, as it applies to critical mission/business processes.

System Resource/Component Platform/OS/Version (as

applicable)

Description

AWS jump NAT Production (MGMT) RHEL 6 (64bit) Jump/NAT/Proxy

AWS Nessus Production (MGMT) RHEL 6 (64bit) Nessus

AWS otw01 Production (MGMT) RHEL 6 (64bit) Tripwire

AWS pa01 Production (PROD) RHEL 6 (64bit) Application server




AWS pcp01 Production (PROD) RHEL 6 (64bit) Ingestion server

AWS pcp02 Production (PROD) RHEL 6 (64bit) Ingestion server

AWS pdb01 Production (PROD) RHEL 6 (64bit) Database server

AWS pdb02 Production (PROD) RHEL 6 (64bit) Database server

AWS pl101 Production (PROD) RHEL 6 (64bit) Lambda server


4

It is assumed that all identified resources support the mission/business processes identified in Section 3.1

unless otherwise stated.

3.3 Identify Recovery Priorities for System Resources

The table below lists the order of recovery for NAC resources. The table also identifies the expected time for

recovering the resource following a “worst case” (complete rebuild/repair or replacement) disruption.

Priority – Priority is defined on a scale of 1 – 5, with 1 being the highest priority.

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.

Priority System Resource/Component Recovery Time Objective

1 AWS jump NAT Production (MGMT) 48 hours

1 AWS pw01 Production (PROD) 48 hours




2 AWS ps01 Production (PROD) 48 hours






3 AWS pa01 Production (PROD) 48 hours


AWS ps01 Production (PROD) RHEL 6 (64bit) Search server






AWS pw01 Production (PROD) RHEL 6 (64bit) Web server



AWS pw04 Production (PROD) RHEL 6 (64bit) Reporting Web server


5

Priority System Resource/Component Recovery Time Objective



4 AWS pdb01 Production (PROD) 48 hours

4 AWS pdb02 Production (PROD) 48 hours

4 AWS pl01 Production (PROD) 48 hours

5 AWS pcp01 Production (PROD) 48 hours

5 AWS pcp02 Production (PROD) 48 hours

5 AWS Nessus Production (MGMT) 48 hours

5 AWS otw01 Production (MGMT) 48 hours

contingency planning guide for federal information systems€¦ · web viewvalidation data...

Documents