47QMCA24Q0004_GSA Incident Response CIO IT Security Policy.pdf

Office of the Chief Information Security Officer

Revision 19

September 8, 2022

IT Security Procedural Guide:

Incident Response (IR)

CIO-IT Security-01-02

DocuSign Envelope ID: 2A106B52-5A6F-4FA7-9EAA-233C8014A24F

CIO-IT Security-01-02, Revision 19 Incident Response

U.S. General Services Administration

VERSION HISTORY/CHANGE RECORD

Change Number

Person Posting Change

Change Reason for Change Page Number of Change

Revision 1 – August 12, 2005

1 Scott/Heard Changes made throughout the document to reflect FISMA, NIST and GSA CIO P 2100.1B requirements.

Updated to reflect and implement various FISMA, NIST and GSA CIO P 2100.1B requirements.

Various

2 Scott/Heard Changes throughout the document to correspond with revisions made to CIO-IT Security- 01-09, CIO-IT Security-01-03 and CIO-IT Security-01-04.

Updated to reflect the correlation of the CIO-IT Security Guides; and to further express policy within them as standalone documents

Various

3 Scott/Heard Inclusion of CIO-IT Security-01-02, Handling IT Security Incident, Addendum 1

Updated to reflect Addendum 1 procedures in the master guide CIO-IT Security-01-02, Handling IT Security Incident

Various

4 Heard Inclusion of current Federal incident identification guidelines

To ensure agency compliance 4, 6 And Appendix A

Revision 2 – October 26, 2005

1 Heard Correct error in table of contents Iii

2 Berlas Revised Incident Handling Form Appropriate US Cert Form updated

Appendix A

Revision 3 – July 21, 2006

1 Berlas Updated references to current IT Security Policy - GSA CIO P 2100.1C

To reflect current policy Various

2 Berlas Updated Incident Reporting Form in Appendix A

To ensure agency compliance Various

3 Berlas Updated Guide to be consistent with requirements in OMB Memorandum M-06-19.

To ensure agency compliance Appendix A

Revision 4 – March 26, 2007

1 Berlas Updated Incident Reporting Form in Appendix A

To ensure agency compliance Appendix A

Revision 5 – June 28, 2007

1 Berlas Updated Incident Reporting Form in Appendix A

To ensure agency compliance Appendix A

2 Berlas Updated references to current IT Security Policy - GSA CIO P 2100.1D

To reflect current policy Various

3 Berlas Updated Appendix C to include the ERASER tool.

Tool is used to securely delete sensitive files related to data leakage incidents.

Appendix B

Revision 6 – April 21 2008

1 Hummel / Windelberg

Changes throughout the document to correspond with updated version of GSA CIO P 2100.1D and other guidance

The most current version of GSA CIO P 2100 and more detailed guidance on implementing policy.

Various

Revision 7 – August 14, 2009

Change Number

Person Posting Change

Change Reason for Change Page Number of Change

1 Berlas Updated reference and procedures for new IR Toolkit

Updates to IR Toolkit Various

2 Berlas Changes throughout the document to correspond with updated version of GSA CIO P 2100.1

The most current version of GSA CIO P 2100 and more detailed guidance on implementing policy.

Various

Revision 8 – July 6, 2010

1 Berlas / Cook Updated 800-53 rev3 references, as well as changes throughout document.

Updates required to ensure agency compliance.

Various

Revision 9 – April 7, 2015

1 Salamon Updated 800-53 rev4 references, NIST SP 800-61 R2 references, updates to CIO P 2100.1, incident response testing and training, ServiceNow integration for incident management, and other process updates throughout the document

Updated to reflect updated guidance and processes

Various

Revision 10 – July 9, 2015

1 Berlas/ Salamon

Updates Sections 2 and 4 to address specific reporting and response processes related to phishing attempts

Updated to reflect more specific processes that are in place

Various

Revision 11 – October 1, 2015

1 Berlas/ Salamon

Updated to reflect changes in US- CERT Reporting Guidelines, FISMA law and changes in processes

Updated to reflect updated guidance and processes

Various

Revision 12 – March 15, 2016

1 Berlas/ Salamon

Updated to reflect changes in policy, processes, and OMB guidance

Updated to reflect update to GSA CIO P 2100.1 and OMB M-16-03

Various

2 Cozart-Ramos/ Klemens

Added specific references to NIST 800-53 Rev 4 controls, formatting, technical editing.

Ensure NIST 800-53 Rev 4 controls are addressed, verify references and links, grammar/editing

Various

Revision 13 – October 11, 2016

1 Berlas/ Salamon

Updated to clarify definition of serious incidents and process for PII incidents for lost / stolen devices.

Clarify requirements Appendix A, Revision 14 – April 3, 2017

1 Berlas/ Salamon

Updated to reflect changes to US- CERT incident reporting requirements and definition of major incidents

Updated reporting and major incident requirements

Various

2 Berlas/ Salamon

Created Section 4.7 for lost / stolen incidents

Created to reflect process changes

Change Number

Person Posting Change

Change Reason for Change Page Number of Change

Revision 15 – September 14, 1 Berlas/ Salamon

Updated to clarify when to call the incident response team

Updated reporting and major incident requirements

2 Berlas/ Salamon

Clarified process for escalating serious incidents by phone or email

Feedback from reviewer Various

3 Berlas/ Salamon

Updated references from M-07- 16 to M-17-12

Feedback from reviewer Various

Revision 16 – March 22, 2018

1 Berlas/ Salamon

Clarifies that unsuccessful incidents are not required to be reported

Clarification of process 19

2 Berlas/ Salamon

Added language regarding data exfiltration monitoring

Document existing process for data exfiltration monitoring

3 Berlas/ Salamon

Updated to reflect Insider Threat Program reporting

Updated reporting request from OMA for Insider Threats

4 Berlas/ Salamon

Explicitly identifies that the IR Team is the Incident Commander

FISMA reporting updates 3, 36

Revision 17 – March 20, 2019

1 Speidel Updated to include PII incident report template, checklist and breach determination and notification timeframe

Updates to process Various

2 Salamon New reporting requirements for sending incidents to Contracting Officer

Updates to process 21, 36

3 Salamon Updates to major incident handling

Updates to process and OMB reporting definitions

Various

4 Salamon Updates for tools in use Updates to process Appendix C

Revision 18 – March 26, 2021

1 Qamar Hasan Updated IR for PII (Privacy) Details for response to PII incidents

35-45

2 Salamon Update for US-CERT to CISA Name Change Various

3 Salamon Included definition of CUI New definition Various

4 Salamon Updates for Supply Chain incidents

New program 46-47

Revision 19-September 8, 2022

1 Hitchings/ Quintananieves

Updated for Cybersecurity Incident & Vulnerability Response Playbooks

Update to process to align to CISA Cybersecurity Incident & Vulnerability Response Playbooks

Various

Change Number

Person Posting Change

Change Reason for Change Page Number of Change

2 McCormick/ Klemens

Updated control mapping per NIST SP 800-53, Revision 5 controls.

Edited, formatted, and updated references and links.

Align to current NIST and GSA guidance and guide formatting and style.

Throughout

Approval

IT Security Procedural Guide: Incident Response (IR), CIO-IT Security 01-02, Revision 19, is hereby approved for distribution.

Bo Berlas Chief Information Officer

Contact: GSA Office of the Chief Information Security Officer (OCISO), Security Operations Division (ISO) at gsa-ir@gsa.gov.

U.S. General Services Administration i

Table of Contents

1 Introduction

1.1 Purpose

1.2 Policy

1.2.1 GSA CIO Order 2100.1

1.2.2 Policies Regarding Contractors and Contractor Facilities

1.3 Incident Response Roles and Responsibilities

2 Federal Incident Reporting Guidelines

2.1 CISA Impact Classification

2.2 CISA Threat Vectors

2.3 CISA Cause Analysis

2.4 CISA Incident Attributes

2.5 Major Incident Definition and Requirements

2.5.1 A Privacy Breach that Constitutes a Major Incident

2.5.2 Congressional Reporting of Major Incidents

2.5.3 Congressional Reporting of a Privacy Breach

3 Incident Reporting Process

3.1 How to Report IT Security Incidents

3.1.1 General Incident Reporting

3.1.2 Incident Reporting for Externally Hosted Information Systems

3.1.3 Incident Reporting for Vendor Identified Incidents (Including GSA Leases)

3.2 OCISO’s Incident Reporting Responsibilities

3.3 OCISO’s Threat Awareness Program

4 Incident Response Process and Tiers

4.1 Incident Response Process Overview

4.2 Incident Response Tier Structure and Overview

4.3 Tier 1: Initial Determination and Reporting

4.3.1 Tier 1 Response Tasks

4.3.2 Tier 1 Response Team

4.3.3 Objective

4.3.4 Responsibilities

4.3.5 Incident Types

4.4 Tier 2: Follow-up and Restoration

4.4.1 Tier 2 Response Tasks

4.4.2 Tier 2 Response Team

4.4.3 Objectives

4.4.4 Responsibilities

4.5 Tier 3: Investigation and Counteraction

4.5.1 Tier 3 Response Tasks

4.5.2 Tier 3 Response Team

4.5.3 Objectives

4.5.4 Responsibilities

4.5.5 Tools

4.6 Incident Response Plan Testing and Exercises

4.7 Incident Response Plan Training

4.8 Incident Response for PII

4.8.1 What is a Privacy Incident? What is a Privacy Breach?

U.S. General Services Administration ii

4.8.2 What is Personally Identifiable Information (PII)?

4.8.3 What are Examples of Privacy Breaches?

4.8.4 Incident Response: Potential PII Compromise Process

4.8.5 Methodology for Assessing the Risk of Harm

4.8.6 Examine Key Factors

4.8.7 Nature and Sensitivity of PII

4.8.8 Likelihood of Access and Use of PII

4.8.9 Type of Breach

4.8.10 Number of Individuals

4.8.11 Determine Risk Factor Rating and Classify the Breach

4.8.12 Mitigating Risk of Harm

4.8.13 Notification and/or Guidance

5 How Does the OCISO Respond to Serious Incidents?

5.1 Step 1: Verify the Source

5.2 Step 2: Verify the Incident

5.3 Step 3: Notify Other Parties

5.3.1 CISA

5.3.2 Other Organizations

5.3.3 GSA Management

5.3.4 GSA Inspector General

5.3.5 Reporting Major Incidents to U.S. Congress

5.3.6 Reporting Incidents to the Office of Mission Assurance’s Insider Threat Program

5.3.7 Reporting Incidents to the Contracting Officer

5.3.8 Reporting Incidents to the OCISO Cyber Supply Chain Risk Management Program

5.4 Step 4: Form Incident Handling Team

5.5 Step 5: Gather Evidence

5.6 Step 6: Contain, Eradicate, and Recover from the Incident

5.7 Step 7: Follow-up after the Incident is Resolved

6 Best Practices

6.1 Key Questions to Ask

6.1.1 Is it an incident or a false positive?

6.1.2 Is the incident still in progress?

6.1.3 What is the extent of the incident? Does it involve more than one device?

6.1.4 Why is it in this particular device and how did it get there?

7 Live Response Process

8 Summary

Appendix A: Glossary

Appendix B: GSA Cyber Incident Reporting Form Instructions

Appendix C: Incident Response and Handling Tools

Table of Figures and Tables

Figure 4-1: Incident Response Process

Figure 4-2: Incident Handling, Response, and Reporting Swim Chart

Figure 4-3: What is a Privacy Breach?

Figure 4-4: PII Compromise Process Flow

U.S. General Services Administration iii

Table 2-1: Federal Agency Incident Impact Classifications

Table 2-2: Federal Threat Vector Taxonomy

Table 2-3: Incident Attribute Definitions

Table 4-1: Incident Handling Tiers

Table 4-2: Incident Types

Table 8-1: Mapping of NIST IR Controls to GSA Documents

Notes:

Hyperlinks in running text will be provided for documents upon initial occurrence in the text, for internal locations within this document (i.e., a different section or an appendix), and in Appendix C: Incident Response and Handling Tools where select websites are listed.

It may be necessary to copy and paste hyperlinks in this document (Right-Click, Select Copy Hyperlink) directly into a web browser rather than using Ctrl-Click to access them within the document.

U.S. General Services Administration 1

1 Introduction

An “incident” or “information security incident” is a violation or imminent threat of violation of information security or privacy policies, acceptable use policies, or standard security practices.

An incident response capability is therefore necessary to:

● Rapidly detect imminent threats or incidents;

● Prevent, stop, or minimize loss and destruction;

● Mitigate the weaknesses exploited;

● Restore Information Technology (IT) services;

● Investigate incidents for root causes and/or forensic evidence;

● Report incidents to Cybersecurity and Infrastructure Security Agency (CISA) and/or other responsible federal authorities; and

● Document the incident and General Services Administration’s (GSA’s) response to it.

The implementation of an Incident Response (IR) capability is critical to the protection of GSA’s information and IT assets. When fully implemented with the appropriate tools, procedures, and processes, the response to a security incident can significantly reduce the potential impact of an incident to GSA’s information, IT resources, and individuals.

This guide presents GSA’s policy, processes, and procedures for incident response. It defines mandatory reporting requirements to CISA when the confidentiality, integrity, or availability of a Federal Government information system has been identified as potentially compromised. It also outlines the external reporting process to the GSA Office of Inspector General (OIG) and United States Congress. Incident reporting to CISA aligns with updated CISA Federal Incident Notification Guidelines and aligns with CISA Cybersecurity Incident & Vulnerability Response Playbooks with a focus on the incident response aspects. This guide details three incident handling processes and the associated roles and responsibilities. Additionally, GSA has aligned its Incident Response SOPs and our Incident Response tracking document with the CISA Cybersecurity Incident & Vulnerability Response Playbooks. Section 3 explains how to report IT security incidents. Section 4 explains the incident response process and breaks it down into three tiers. Tier 1 processes consist of determining if an incident has occurred and reporting the incidents or suspected incidents. Tier 2 processes consist of activities related to following up with an actual response through the restoration of services. Tier 3 processes consist of the investigation and any counteractions. Section 5 explains how the Office of the Chief Information Security Officer (OCISO) responds to incidents that are deemed serious.

Every Service and Staff Office (SSO) must be covered by a documented and tested incident handling process to address Tier 1 and Tier 2 incident response for systems under their jurisdiction. The office receiving the initial report is responsible for distributing information within GSA, identifying supporting resources needed, and if appropriate, addressing the incident. The OCISO in consultation with the reporting office will determine whether legal counsel or law enforcement involvement is warranted. The final decision to notify such entities is the OCISO’s responsibility, with notification to the GSA Chief Information Officer. Within the

U.S. General Services Administration 2

OCISO, the GSA Security Operations Division’s (ISO) Incident Response Team (IRT) is responsible for tracking incidents, reporting incidents to CISA and to the OIG, and coordinating response efforts for incidents that require additional resources for remediation.

The incident response principles and practices described in this guide are based on guidance from the National Institute of Standards and Technology (NIST) including NIST Special Publication (SP) 800-61 Revision 2, “Computer Security Incident Handling Guide,” and NIST SP 800-53 Revision 5, “Security and Privacy Controls for Information Systems and Organizations,” and the updated CISA Federal Incident Notification Guidelines. This guide provides procedures for incident response, roles, and responsibilities, NIST SP 800-53 incident response family requirements per Federal Information Processing Standards (FIPS) Publication 199, “Standards for Security Categorization of Federal Information and Information Systems” impact level and procedures for implementing these requirements, and related best practices. This guide also provides guidance and procedures in accordance with Executive Order 14028, “Improving the Nation’s Cybersecurity,” and CISA Government Cybersecurity Incident and Vulnerability Response Playbooks which provide federal civilian agencies with a standard set of procedures to respond to vulnerabilities and incidents impacting Federal Civilian Executive Branch networks.

1.1 Purpose

This IT Security Procedural Guide defines IR requirements as identified in GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy”, SA Information Breach Notification Policy,” NIST SP 800-53, and CISA Federal Incident Notification Guidelines. This guide provides specific procedures for GSA employees and contractors with significant security responsibilities to follow for implementing the IR functions for systems.

1.2 Policy

1.2.1 GSA CIO Order 2100.1

Chapter 6, Policy for Respond Function, states:

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.

2. Communications.

a. GSA employees and contractors on the Incident Response Team identified in GSA CIO-IT Security-01-02 are trained on their roles and responsibilities within 60 days of assignment and annually thereafter.

U.S. General Services Administration 3

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

c. Users must immediately report suspected vulnerabilities, security violations, and security incidents to the GSA IT Service Desk.

d. Users must immediately report lost or stolen portable storage devices to the GSA IT Service Desk.

e. All incidents involving the loss or theft of GSA hardware, software, and/or information in physical form must be reported immediately to the GSA IT Service Desk.

(1) Users must also report all losses to the Federal Protective Service (FPS) via the appropriate Regional Hotline, as directed by the appropriate ISSO or the GSA IT Service Desk.

(2) Users must also report any loss that occurs outside of Federal facilities to the local police.

(3) Lost PIV cards must be reported to the Central or Regional OMA office after reporting to the GSA IT Service Desk.

f. GSA Incident Response Teams must report incidents as described in GSA CIO-IT Security-01-02. FISMA requires “major incidents” to be reported to the U.S. Congress within seven days of detection.

g. Data breaches (i.e., loss of control, compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or any similar term referring to situations where persons other than authorized users with an authorized purpose have access or potential access to PII, whether physical or electronic) shall also follow reporting and response procedures as defined in GSA Order CIO 9297.2C CHGE 1.

h. ISSOs must report any security incidents reported to them to the GSA IT Service Desk and GSA OCISO.

i. Information will be shared by the GSA Incident Response Team, as appropriate, and IAW GSA CIO-IT Security-01-02.

j. Coordination with stakeholders will be conducted by the GSA Incident Response Team, as appropriate, and IAW GSA CIO-IT Security-01-02.

k. Information sharing with external stakeholders will be conducted by the GSA Incident Response Team, as appropriate and in coordination with the GSA CISO, IAW GSA CIO- IT Security-01-02.

3. Analysis.

a. The OCISO will communicate notifications/alerts from detection systems for investigation by GSA’s Incident Response Team via email or the GSA IT Service Desk.

Procedures must be documented for responses to detected irregularities.

U.S. General Services Administration 4

b. The GSA Incident Response Team will investigate notifications/alerts from detection systems IAW GSA CIO-IT Security-01-02.

c. The GSA Incident Response Team will determine the impact of an incident in coordination with other personnel/organization, as appropriate, during the investigation process defined in GSA CIO-IT Security-01-02.

d. The GSA Incident Response Team will perform forensics analysis of incidents/the evidence of incidents, as necessary, to support investigations as described in GSA CIO-IT Security-01-02.

e. The GSA OCISO and Incident Response Team will categorize incidents IAW GSA CIO-IT Security-01-02.

f. The OCISO will establish a vulnerability management process for identifying vulnerabilities via internal testing/scanning.

g. The OCISO will notify personnel with security responsibilities of vulnerabilities disclosed via security advisory alerts (SAA) or other external sources.

h. ISSMs and ISSOs must report on the status of SAAs to the Office of the CISO upon request.

4. Mitigation.

a. The GSA Incident Response Team, in coordination with system personnel, will contain incidents IAW GSA CIO-IT Security-01-02.

b. Incidents will be mitigated or remediated based on activities executed by the GSA Incident Response Team and system personnel, as described in GSA CIO-IT Security- 01-02 and the system’s recovery plan.

c. IAW GSA CIO-IT Security-06-30, system vulnerabilities must be:

(1) Remediated or mitigated IAW specified timeframes;

(2) Included in a Plan of Action & Milestones; or

(3) Included in an Acceptance of Risk Letter.

d. Systems must comply with the required actions specified in DHS Cybersecurity Directives. The OCISO Security Operations Division (ISO) collaborates with system personnel regarding directives and reports status to DHS, as required.

5. Improvements.

a. Incident response plans must be updated based on lessons learned during incident response or plan testing.

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

c. Incident response strategies must be reviewed and updated, if necessary, at least annually to address system/organizational changes and problems or issues encountered while responding to incidents or plan testing.

U.S. General Services Administration 5

1.2.2 Policies Regarding Contractors and Contractor Facilities

Contractors and other entities that process and host GSA information are bound by CIO 2100.1, this guide, the terms of their contracts, and Federal Information Security Modernization Act (FISMA) of 2014, Section 3551 to protect the security of this information, including the support of incident response efforts.

Refer to CIO 2100.1 for a detailed listing of incident handling related policies.

1.3 Incident Response Roles and Responsibilities

There are many roles associated with implementing an effective incident response capability.

System Owners and System Program Managers/Project Managers have a direct responsibility to ensure the implementation of the IR process. The system owners for each system are responsible for ensuring that an IR process has been implemented for their respective Service and Staff Office (SSO) systems and that the appropriate people have been assigned IR related roles and responsibilities. The system program managers/project managers have direct responsibility to ensure effective implementation and management of GSA’s IR requirements for each of their systems. The GSA Incident Response Team is empowered to be the Incident Commanders, responsible for directing and managing GSA cybersecurity incidents in accordance with FY CIO FISMA Metrics.

This section highlights the roles and responsibilities related to implementation of the IR process. The roles and responsibilities outlined in this document are not all-inclusive. The roles and responsibilities are defined fully in the GSA CIO 2100.1 and GSA CIO 9297.2C CHGE 1, “GSA Information Breach Notification Policy.

GSA Chief Information Officer (CIO). Incident Response related responsibilities of the CIO include the following:

Ensuring information assurance and the protection of GSA's cyber-based critical infrastructure;

Establishing reporting requirements within GSA to assess GSA’s IT security posture, verifying compliance with Federal requirements and approved policies, and identifying agency-wide IT security needs.

Chief Information Security Officer (CISO). Incident Response related responsibilities of the CISO include the following:

Reporting to the GSA CIO on activities and trends that may affect the security of systems and applications assigned to GSA;

Implementing and overseeing GSA's IT Security Program by developing and publishing IT Security Procedural Guides that are consistent with this policy;

Periodically assessing risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems that support the operations and assets of the agency;

U.S. General Services Administration 6

Periodically testing and evaluating the effectiveness of information security policies, procedures, and practices;

Establishing and maintaining a process for planning, implementing, evaluating, and documenting remedial action to address any deficiencies in the information security policies, procedures, and practices of the agency;

Developing and implementing procedures for detecting, reporting, and responding to security incidents;

Ensuring preparation and maintenance of plans and procedures to provide continuity of operations for information systems that support the operations and assets of GSA;

Establishing and periodically reviewing and approving the staff plan for the Incident Response Team.

Authorizing Official (AO). Incident Response related responsibilities of the AO include the following:

● Ensuring adherence to GSA’s IT Security Policy;

● Ensuring all incidents involving data breaches which could result in identity theft are coordinated through GSA IT’s Office of the Chief Information Security Officer (OCISO) and the GSA Management Incident Response Team (MIRT) using the GSA breach notification plan per OMB Memorandum M-17-12, “Preparing for and Responding to a Breach of Personally Identifiable Information,” CIO-IT Security-01-02 (this guide), and GSA Order CIO 9297.2C CHGE 1.

Information Systems Security Manager (ISSM). Incident Response related responsibilities of the ISSM include the following:

● Reviewing and coordinating reporting of Department of Homeland Security (DHS) CISA Activity Alerts (AA), compliance reviews, security training, incident reports, contingency plan testing, and other IT security program issues.

Information Systems Security Officer (ISSO). Incident Response related responsibilities of the ISSO include the following:

● Ensuring the system is operated, used, maintained, and disposed of in accordance with internal security policies and procedures. Necessary security controls should be in place and operating as intended;

● Advising System Owners of risks to their systems and obtaining assistance from the ISSM, if necessary, in assessing risk;

● Assisting System Owners in completing and maintaining the appropriate security documentation including the system security plan;

● Identifying, reporting, and responding to security incidents;

● Reviewing and responding as appropriate to Security Advisory Alerts on vulnerabilities.

● Reviewing system security audit trails and system security documentation to ensure security measures are implemented effectively;

● Evaluating known vulnerabilities to ascertain if additional safeguards are needed;

ensuring systems are patched, and security hardened;

● Beginning protective or corrective measures if a security breach occurs;

U.S. General Services Administration 7

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

System Owners. Incident Response related responsibilities of the System Owners include the following:

● Ensuring their systems and the data each system processes have necessary security controls in place and are operating as intended and protected in accordance with (IAW) GSA regulations and any additional guidelines established by the OCISO and relayed by the ISSO or ISSM;

● 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 ISSM and ISSO and Data Owners to ensure implementation of system and data security requirements;

● Working with Data Owners to ensure the appropriate level of auditing and logging data is enabled and generated to support monitoring activities;

● Working with Data Owners to ensure that log data is archived for a period of not less than 180 days;

● Working with Data Owners to audit user activity for indications of fraud, misconduct, or other irregularities;

● Working with Data Owners to document all phases of monitoring activity including monitoring procedures, response processes, and steps performed when reviewing user activity.

Data Owners (a.k.a. Functional Business Line Managers). Incident Response related responsibilities of the Data Owners include the following:

● Coordinating with System Owners, ISSMs, ISSOs, and Custodians to ensure the data is properly stored, maintained, and protected IAW GSA policies, regulations and any additional guidelines established by GSA.

● Ensuring protection of GSA's systems and data in accordance with GSA's IT Security Policy and the GSA Records Management Program.

● Coordinating with IT security personnel including the ISSM and ISSO and System Owners to ensure implementation of system and data security requirements;

● Working with the System Owner to ensure the appropriate level of auditing and logging data is enabled and generated to support monitoring activities.

● Working with the System Owner to ensure that log data is archived for a period of not less than 180 days;

● Working with the System Owner to audit user activity for indications of fraud, misconduct, or other irregularities;

U.S. General Services Administration 8

● Working with the System Owner to document all phases of monitoring activity including monitoring procedures, response processes, and steps performed when reviewing user activity.

● Working with the System Owner to provide the initial Agency Response Team (IART) evidence that it has provided any required breach notification and/or services within the required timeframe.

Acquisitions/Contracting (Contracting officers [CO]/Contracting Officer’s Representatives [COR]). Incident Response related responsibilities of Acquisitions/Contract include the following:

● Coordinating with the CISO or other appropriate official as required ensuring that all agency contracts and procurements are compliant with the agency’s information security policy;

● Working with the CISO to facilitate the monitoring of contract performance for compliance with the agency’s information security policy;

● Ensuring that all IT acquisitions include the appropriate security requirements in each contract and task order;

● Ensuring all GSA contracts, Request for Proposals (RFP), and Request for Quotes (RFQ) involving Privacy Act information adhere to the Federal Acquisition Regulations (FAR) Privacy Act provisions (Subparts 24.1) and include the specified contract clauses (Parts 52.224-1 and 52.224-2), as appropriate;

● Ensuring new solicitations where the information system is contractor owned and operated on behalf of GSA or the Federal Government (when GSA is the managing agency) includes the security contract language from CIO-IT Security 09-48, “Security Language for IT Acquisition Efforts.”

● Working with the System Owner to provide the IART evidence that it has provided any required breach notification and/or services within the required timeframe.

Custodians. Incident Response related responsibilities of the Custodians 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 GSA policies and standards as relayed by the Authorizing Official.

Users of IT Resources. Incident Response related responsibilities of Users of IT Resources include the following:

● Reporting any observed or suspected security problems/incidents to their local IT Service Desk.

System/Network Administrators. Incident Response related responsibilities of System/Network Administrators include the following:

U.S. General Services Administration 9

● Ensuring the appropriate security requirements are implemented consistent with GSA IT security policies and hardening guidelines;

● Implementing system backups and patching of security vulnerabilities;

● Working with the Custodian/ISSO to ensure appropriate technical security requirements are implemented;

● Identifying and reporting security incidents and assisting the OCISO in resolving the security incident.

Initial Agency Response Team (IART). Incident Response related responsibilities of the Initial Agency Response Team include the following:

● Breaches that involve a limited number of individuals and a limited amount of breached PII will be considered minor. Breaches that impact up to 1,000 individuals will be handled by the Initial Agency Response Team.

● The Chief Privacy Officer leads this group and assists the program office by providing a notification template, information on identity protection services (if necessary) and any other assistance deemed necessary.

● Within the required timeframe of an incident being escalated to it, the Initial Agency Response Team is responsible for both confirming whether a breach in fact occurred and assisting the program office as it provides any breach notification and/or services to the impacted individuals.

● The OCISO is responsible for ensuring the CISA Report is submitted and the Office of Inspector General (OIG) is notified. The Initial Agency Response Team will determine the appropriate remedy. If a unanimous decision cannot be made, it will be elevated to the Full Agency Team.

● The program office is responsible for providing the remedy to the impacted individuals (including associated costs). It will also provide evidence that notification was provided to impacted individuals within ninety (90) calendar days of the date of the incident’s escalation to the Initial Agency Response Team, absent national security or law enforcement agency involvement, an incident or breach implicating large numbers of records or affected individuals, or similarly exigent circumstances. The Senior Agency Official for Privacy (SAOP) will determine the appropriate timeframe for incidents not escalated to the Full Response Team (see below).

● If the impacted individuals are contractors, notification will be handled by the contract officer, working with the vendor. The Chief Privacy Officer will provide a notification template and other assistance deemed necessary.

● The SAOP is the SES responsible for the privacy program at GSA. The Chief Privacy Officer handles the management and operation of the privacy office at GSA.

Full Response Team (FRT). Incident Response related responsibilities of the Full Response Team include the following:

● A major breach involves a large amount of PII. Breaches that impact more than 1,000 individuals or significant types of PII will be deemed as “major” and will be handled by the Full Response Team. Based on the risk assessment, breaches that impact fewer than 1,000 may still be moved under the purview of the Full Response Team should

U.S. General Services Administration 10 they involve a large amount of PII or that may cause substantial harm, embarrassment, inconvenience, or unfairness to any individual.

● This team consists of the program manager of the program experiencing or responsible for the breach, the SAOP, the Chief Information Officer (CIO), OCISO, Chief Privacy Officer, Office of Strategic Communications (OSC), Office of Congressional and Intergovernmental Affairs (OCIA), and the Office of General Counsel (OGC), Mission or system owners, Security Operations Division Director or representative. The OSC and OCIA are included for awareness and coordination purposes.

● Within the required timeframe of an incident being escalated to it, the Full Response Team is responsible for both confirming whether a breach in fact occurred and assisting the program office as it provides any notification and/or services to the impacted individuals absent national security or law enforcement agency involvement, an incident or breach implicating large numbers of records or affected individuals or similarly exigent circumstances. The Full Response Team will determine the appropriate timeframe for breaches under its purview.

● The Full Response Team is designed as the team that is required per the current OMB Memorandum providing Guidance on Federal Information Security and Privacy Management Requirements and is tasked with responsibility for determining whether a major incident has occurred (requiring Congressional and Inspector General reporting).

The CISO will lead for major non-privacy incident determinations and the SAOP will lead for major privacy incident determinations.

2 Federal Incident Reporting Guidelines

CISA coordinates defense against and responses to cyberattacks. Notifying CISA of a computer security incident is mandatory when the confidentiality, integrity, or availability of a Federal Government information system has been potentially compromised. Notification of incidents which have no potential functional or information impact such as passive scans, attempted access, or thwarted exploits may be submitted to CISA voluntarily. However, CISA has asked that encrypted lost or stolen devices and unsuccessful phishing attempts1 no longer be reported to CISA as incidents. CISA has updated its reporting requirements to the following:

Requirement: Agencies must report information security incidents, where the confidentiality, integrity, or availability of a federal information system of a civilian, Executive Branch agency is potentially compromised, to the NCCIC/US-CERT with the required data elements, as well as any other available information, within one hour of being identified by the agency’s top-level Computer Security Incident Response Team (CSIRT), Security Operations Center (SOC), or information technology department. In some cases, it may not be feasible to have complete and validated information for the section below (Submitting Incident Notifications) prior to reporting. Agencies should provide their best estimate at the time of notification and report updated information as

1 Unsuccessful phishing attempts may be sent to phishing-report@us-cert.gov, in which there will be an automated process for CISA to extract indicators and the GSA IR team will voluntarily do this, as detailed in Section 4.6.

U.S. General Services Administration 11 it becomes available. Events that have been found by the reporting agency not to impact confidentiality, integrity or availability may be reported voluntarily to US-CERT; however, they may not be included in the FISMA Annual Report to Congress.

GSA will put forth a best effort to report all mandatory incidents within one-hour of notification to the GSA Incident Response Team and provide all available information. GSA will not delay reporting to provide further details (i.e., root cause, vulnerabilities exploited, or mitigation actions taken) as this may result in high risk to the system or enterprise. If the cause of the incident is later identified, the threat vector may be updated in a follow-up report.

CISA has directed agencies to determine their own thresholds for identifying “potential” impact to confidentiality, integrity, or availability. Based on this guidance, the GSA Incident Response Team will define potential incidents as those in which there is reason to suspect that an impact to confidentiality, integrity, or availability has occurred or will occur imminently. This would exclude the reporting of vulnerabilities in which there is no evidence of exploitation (i.e., a vulnerable condition). Common scenarios handled by the GSA Incident Response team and the scenarios in which reporting requirements are triggered are documented in Incident Response Standard Operating Procedures.

2.1 CISA Impact Classification

Incidents may affect multiple types of data. Therefore, when classifying an incident, GSA may select multiple options to identify the information impact. Incidents with a potential functional, information, or recovery impact must be IMMEDIATELY reported to the GSA IT Service Desk and the OCISO. Details of the reporting process are explained in Section 3, Incident Reporting Process. Table 2-1 helps to identify the impact of the incident. The terms “classified information” and “proprietary information” are defined in IAW Committee on National Security Systems (CNSSI) 4009, “Committee on National Security Systems (CNSS) Glossary.” The term “personally identifiable information” is defined IAW with OMB M-17-12.

Note: Incidents involving non-cyber PII exposures spillages (i.e., unsecured hard copies) must be reported to CISA. However, non-cyber incidents that do not involve PII should not be reported to CISA.

U.S. General Services Administration 12

Table 2-1: Federal Agency Incident Impact Classifications

Impact Category Category Severity Levels

NO IMPACT – Event has no impact.

NO IMPACT TO SERVICES – Event has no impact to any business or Industrial Control Systems (ICS) services or delivery to entity customers.

MINIMAL IMPACT TO NON-CRITICAL SERVICES – Some small level of impact to non-critical systems and services.

Functional Impact – A measure of the impact to

MINIMAL IMPACT TO CRITICAL SERVICES –Minimal impact but to a critical system or service, such as email or active directory.

business functionality or ability to provide services

SIGNIFICANT IMPACT TO NON-CRITICAL SERVICES – A non-critical service or system has a significant impact.

DENIAL OF NON-CRITICAL SERVICES – A non-critical system is denied or destroyed.

SIGNIFICANT IMPACT TO CRITICAL SERVICES – A critical system has a significant impact, such as local administrative account compromise.

DENIAL OF CRITICAL SERVICES/LOSS OF CONTROL – A critical system has been rendered unavailable.

NO IMPACT – No known data impact.

SUSPECTED BUT NOT IDENTIFIED – A data loss or impact to availability is suspected, but no direct confirmation exists.

PRIVACY DATA BREACH – The confidentiality of personally identifiable information (PII)2 or personal health information (PHI) was compromised.

Information Impact – Describes the type of

PROPRIETARY INFORMATION BREACH – The confidentiality of unclassified proprietary information3, such as protected critical infrastructure information (PCII), intellectual property, or trade secrets was compromised.

information lost, compromised, or corrupted.

DESTRUCTION OF NON-CRITICAL SYSTEMS – Destructive techniques, such as master boot record (MBR) overwrite; have been used against a non-critical system.

CRITICAL SYSTEMS DATA BREACH - Data pertaining to a critical system has been exfiltrated.

CORE CREDENTIAL COMPROMISE – Core system credentials (such as domain or enterprise administrative credentials) or credentials for critical systems have been exfiltrated.

DESTRUCTION OF CRITICAL SYSTEM – Destructive techniques, such as MBR overwrite; have been used against a critical system.

REGULAR – Time to recovery is predictable with existing resources.

Recoverability – Identifies the SUPPLEMENTED – Time to recovery is predictable with additional resources.

scope of resources needed to recover from the incident

EXTENDED – Time to recovery is unpredictable; additional resources and outside help are needed.

2 As defined in OMB Memorandum M-17-12, “personally identifiable information” refers to “information which can be used to distinguish or trace an individual's identity.

3 As defined in CNSSI 4009, “proprietary information” is “Material and information relating to or associated with a company's products, business, or activities, including but not limited to financial information; data or statements;

trade secrets; product research and development; existing and future product designs and performance specifications; marketing plans or techniques; schematics; client lists; computer programs; processes; and knowhow that has been clearly identified and properly marked by the company as proprietary information, trade secrets, or company confidential information. The information must have been developed by the company and not be available to the Government or to the public without restriction from another source.”

U.S. General Services Administration 13

Impact Category Category Severity Levels

NOT RECOVERABLE – Recovery from the incident is not possible (e.g., sensitive / Controlled Unclassified Information (CUI) data exfiltrated and posted publicly).

The Federal Agency Incident Impact Classification table is available on the CISA website.

** Per OMB M-17-12, the term PII means information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can be used to distinguish or trace an individual's identity, the term PII is necessarily broad. To determine whether information is PII, the agency shall perform an assessment of the specific risk that an individual can be identified using the information with other information that is linked or linkable to the individual. In performing this assessment, it is important to recognize that information that is not PII can become PII whenever additional information becomes available - in any medium or from any source - that would make it possible to identify an individual. However, incidents involving non-cyber exposures (e.g., unsecured hard copies) involving PII should be reported to CISA. Other non-cyber exposures should not be reported to

CISA.

*** GSA Policy specifies that all agency data on portable storage devices (e.g., laptop hard drives, mobile devices, USB flash drives, SD cards, external hard drives), must be encrypted with a FIPS 140-2/140-34 certified encryption module. If a device is lost or stolen it should be reported to the IT Service Desk and GSA Incident Response team. If it was determined that the device was not encrypted, it is a violation of GSA policies and will be treated as an incident with information impact and reported. In addition, CISA has requested that simple loss or theft of a PIV card without any attempts for unauthorized usage shall not be reported as an incident but must be reported to the Regional Office of Mission Assurance (OMA) office, as directed by the GSA IT Service Desk staff.

****Phishing attempts reported to the GSA Incident Response Team will be reported to CISA as follows:

● Phishing attempts where ENT domain credentials or credentials to other GSA systems are used to gain unauthorized access; or results in malicious code being successfully executed on a GSA server or workstation will be reported with the appropriate functional, information, and/or recoverability impact classification.

● Sensitive / CUI information revealed via a spear phishing email or other means will also be reported as an incident with the appropriate information and recoverability impact classification.

● Per direction from CISA, other phishing attempts will not be reported as incidents, but submitted separately to phishing-report@us-cert.gov in accordance with Section 4.6.

4 NIST has issued FIPS 140-3, however FIPS 140-2 modules will be accepted through September 21, 2026. For additional information see NIST Cryptographic Module Validation Program (CMVP).

U.S. General Services Administration 14

However, the GSA Incident Response Team, at its option, may choose to report unsuccessful phishing incidents as deemed necessary.

2.2 CISA Threat Vectors

To clearly communicate incidents throughout the Federal Government and supported organizations, it is necessary for government incident response teams to adopt a common set of terms and relationships between those terms. All elements of the Federal Government should use the common taxonomy outlined in Table 2-2.

Table 2-2 is a high-level set of concepts and descriptions developed from guidance in NIST SP 800-61 Revision 2. GSA, as a Federal civilian agency, must utilize the following threat vectors taxonomy when sending cybersecurity incident notifications to CISA. CISA provides the following guidance for use this table:

Note: Incidents may affect multiple types of data; therefore, Federal Government departments and agencies (D/As) may select multiple options when identifying the information impact. The security categorization of federal information and information systems must be determined in accordance with Federal Information Processing Standards (FIPS) Publication 199. Specific thresholds for loss-of-service availability (e.g., all, subset, loss of efficiency) must be defined by the reporting organization. Contact your Security Office for guidance on responding to classified data spillage.

Table 2-2: Federal Threat Vector Taxonomy

Threat Vector Description Example

Unknown Cause of attack is unidentified.

This option is acceptable if cause (vector) is unknown upon initial report. The threat vector may be updated in a follow-up report.

Attrition

An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services.

Denial of Service intended to impair or deny access to an application; a brute force attack against an authentication mechanism, such as passwords or digital signatures.

Web An attack executed from a website or web-based application.

Cross-site scripting attack used to steal credentials, or a redirect to a site that exploits a browser vulnerability and installs malware.

Email An attack executed via an email message or…