Appendix C - Incident Response Plan Template.pdf

{System Name} Incident Response Plan (IRP)

{System Name} Incident Response Plan (IRP)

NATIONAL ARCHIVES AND RECORDS ADMINISTRATION

Date: {current date} Version: {current version number}

Template Date: April 3, 2019 Template Version: 1.0

DOCUMENT CHANGE PAGE

Modifications made to this Incident Response Plan (IRP) for {System Name} are as follows:

Document Version

Description of contents / revision Editor Change Date

0.1 Initial draft of IRP Template Thomas McManuels 3/11/2019

1.0 Template finalized following NARA review

and approval.

Thomas McManuels 4/3/2019

Table of Contents

DOCUMENT CHANGE PAGE 2

1. Overview 4

1.1 Purpose 4

2. System Description 5

3. Reporting 5

4. Incident Response Methodology 5

4.1 Preparation 5

4.2 Detection and Analysis 5

4.3 Containment, Eradication, and Recovery 5

4.4 Post-Incident Activity 6

5. Key Personnel 6

6. IRP Approval 6

1. Overview This system level Incident Response Plan (IRP) is the overall plan for responding to information security incidents for the {System Name} {System Acronym}. It was prepared on {Insert IRP completion date}.

The system level IRP is one component of the National Archives and Records Administration (NARA) overall Incident Response Plan. The system level plan has been established in concert with the following:

● NARA Incident Response Plan, June, 2017

● NARA IT Security Methodology for Incident Response, January, 2018

● NIST Special Publication 800-61 Rev. 2, Computer Security Incident Handling Guide, August 2012

1.1 Purpose

The goal of the system level IRP is to react to security incidents, determine their scope, respond appropriately, and reduce the likelihood of the incident reoccurring.

The incident response life cycle:

● Preparation. Preparation includes those activities that enable the security office to respond to an incident: policies, tools, procedures, effective governance, and communication plan. Preparation also implies that the system includes controls necessary to recover and continue operations after discovery of an incident.

● Detection and Analysis. Detection and analysis is the discovery of the event or notification about a suspected incident. This phase includes the declaration and initial classification of the incident.

● Containment, Eradication, and Recovery. This is the triage phase where the affected host or system is identified, isolated, or otherwise mitigated. Evidence gathering occurs during this phase while following procedures that follow applicable laws and agency regulations. Once contained, eradication may be necessary to eliminate components of the incident. Lastly, administrators restore systems to normal operations and confirm they are functioning normally.

● Post-Incident Activity. Learning and improving after an incident is essential as the security team must evolve and prepare for new threats, improved technology, and lessons learned.

This document provides a basis for a coordinated and consistent response to system level incidents that would affect NARA. As such, this document does not contain an exhaustive set of incident response procedures; rather, it is intended to provide {System Acronym} personnel with a high-level practical source of guidance on incident response. It may also be used to support the development of other contingency plans associated with the system, including, but not limited to, the Contingency Plan.

2. System Description Provide a general description of system architecture and functionality. Indicate the operating environment, physical location, general location of users, and partnerships with external organizations/systems. Include information regarding any other technical considerations that are important for recovery purposes, such as backup procedures. Provide a diagram of the architecture, including inputs and outputs and telecommunications connections.

Note: Information for this section should be available from the system’s System Security Plan (SSP) and can be copied from the SSP, or reference the applicable section in the SSP and attach the latest version of the SSP to this contingency plan.

3. Reporting Report all IT security incidents to the IT HELP within one hour from discovery and preferably as soon as possible as the first step in the incident management process.

Phone: 301-837-2020 E-mail: IT.Help@nara.gov

Section 1.5 of the NARA Incident Response Plan contains the definition of an IT security incident.

4. Incident Response Methodology {System Acronym} managers, administrators, and users all play a critical role during each phase of the incident response methodology. Their actions at the system level augment the overall NARA Computer Security Incident Response Capability (CSIRC) while improving the overall security posture of the system.

4.1 Preparation

Provide system-specific actions taken during the Preparation Stage of the Incident Response Life Cycle. Examples may include, but are not limited to, management policies, vulnerability scans, ISSO duties, etc…

4.2 Detection and Analysis

Provide system-specific actions taken during the Detection and Analysis Stage of the Incident Response Life Cycle. Examples may include, but are not limited to, user training, intrusion detection, etc…

4.3 Containment, Eradication, and Recovery

Containment, eradication, and recovery is accomplished through the activation of the NARA

Computer Incident Response Team (CIRT) that is partly staffed with key stakeholders from the {System Name}.

4.4 Post-Incident Activity

Provide system-specific actions taken during the Post-Incident Activity Stage of the Incident Response Life Cycle. Examples may include, but are not limited to, post-mortem reporting, updated policies, etc…

5. Key Personnel In the event of an incident, the following personnel will be made available to the NARA Computer Incident Response Team for a duration and commitment to be determined by the NARA Chief Information Security Officer.

Name Position Phone Number Email Address

Key personnel can include individuals other than the system owner and/or TPOC. It may include developers, administrators, or others with technical knowledge of the system.

6. IRP Approval

System Owner:

PRINTED NAME SIGNATURE DATE