Incident_Response_CIO_IT_Security_01-02.pdf

Office of the Chief Information Security Officer

IT Security Procedural Guide:

Incident Response (IR) CIO-IT Security-01-02

Revision 16

March 22, 2018

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

U.S. General Services Administration

VERSION HISTORY/CHANGE RECORD

Revision 1 – August 12, 2005 Change Number

Person Posting Change

Change Reason for Change Page Number of Change

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 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, 29

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

Revision 15 – September 14, 2017 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

Approval

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

Invalid signature

X Kurt Garbars Kurt D. Garbars Chief Information Security Officer Signed by: KURT GARBARS

Contact: GSA Office of the Chief Information Security Officer (OCISO), Security Engineering Division (ISE) 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 Policies Regarding Contractors and Contractor Facilities

1.3 Incident Response Roles and Responsibilities

2 Federal Incident Reporting Guidelines

2.1 US-CERT Impact Classifications

2.2 US-CERT Threat Vectors

2.3 US-CERT Cause Analysis

2.4 US-CERT Incident Attributes

2.5 Major Incident Definition and Requirements

2.5.1 A 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 Routine Incident Reporting

3.1.2 Incident Reporting for Externally Hosted Information Systems

3.2 OCISO’s Incident Reporting Responsibilities

3.3 OCISO’s Threat Awareness Program

4 Incident Response Process

4.1 Tier 1: Initial Determination and Reporting

4.1.1 Tier 1 Response Tasks

4.2 Tier 2: Follow-up and Restoration

4.2.1 Tier 2 Response Tasks

4.3 Tier 3: Investigation and Counteraction

4.3.1 Tier 3 Response Tasks

4.4 Incident Response Plan Testing and Exercises

4.5 Incident Response Plan Training

4.6 Incident Response for Phishing Attempts

4.6.1 Differences between Phishing Attempt, Spam, and Social Engineering

4.6.2 Identification Standards for Reporting Phishing Attempts to US-CERT

4.6.3 User Communications

4.6.4 Response Process for GSA Incident Response Team

4.7 Incident Response for Lost / Stolen Devices, PIV Cards, or Tokens 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 US-CERT

5.3.2 Other Organizations

U.S. General Services Administration ii

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.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 its 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 of Terms APPENDIX B – GSA Cyber Incident Reporting Form Instructions APPENDIX C – Incident Response and Handling Tools

Table of Figures and Tables

Figure 1: Threat Vector Decision Tree Figure 2: Incident Handling, Response, and Reporting Swimchart

Table 1: Federal Agency Incident Impact Classifications Table 2: Federal Threat Vector Taxonomy Table 3: Incident Types Table 4: Mapping of NIST IR Controls to GSA Documents

U.S. General Services Administration 1

1 Introduction

An “incident” or “information security incident” can be thought of as 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 incident to United States Computer Emergency Readiness Team (US-CERT) and/or other responsible federal authorities; and

• Document the incident and General Services Administration (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 and IT resources. An incident response capability is necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring computing services.

This guide presents GSA’s policy, procedures, and processes for incident response. It defines mandatory reporting requirements to the US-CERT when the confidentiality, integrity, or availability of a Federal Government information system has been confirmed as compromised.

It also outlines the reporting process for external reporting to the GSA Office of Inspector General (OIG) and U.S. Congress. Incident reporting to US-CERT aligns with updated US-CERT Federal Incident Notification Guidelines. This guide details three incident handing processes and the associated roles and responsibilities. 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 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 responsibility of the OCISO, with notification to the GSA CIO. Within the OCISO, the GSA Security Engineering Division’s (ISE) Incident Response Team is responsible for tracking incidents, reporting incidents to US-CERT and to the OIG, and coordinating response efforts for incidents that require additional resources for remediation.

U.S. General Services Administration 2

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 4, Security and Privacy Controls for Federal Information Systems and Organizations, and the updated US- CERT Federal Incident Notification Guidelines. This guide provides procedures for incident response, roles and responsibilities, NIST SP 800-53 incident response requirements per FIPS 199 impact level and procedures for implementing these requirements, and related best practices.

1.1 Purpose

This IT Security Procedural Guide: Incident Response defines IR requirements as identified in GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy”, CIO 9297.2, “GSA Information Breach Notification Policy”, and NIST SP 800-53, and US-CERT 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

Chapter 4, paragraph 2.i of GSA CIO 2100.1 states:

Incident response capability.

(1) Every S/SO/R must establish a security incident response capability for detecting, reporting, and responding to security incidents.

(2) All authorized IT users must be trained annually to promptly report suspected vulnerabilities, security violations, and security incidents to their IT Service Desk. Refer to GSA-CIO-IT Security 01-02 for additional details.

(3) ISSOs must report security incidents through the IT Service Desk to the CISO IAW GSA CIO-IT Security-01-02. The OCISO shall then report incidents to the GSA Office of Inspector General IAW that Procedural Guide.

(4) All incidents involving the loss or theft of GSA hardware, software, and/or information in physical form must be reported to the GSA IT Service Desk. Incidents involving lost or stolen GFE mobile devices (i.e. laptops or mobile phones), both inside and outside of GSA facilities, shall be reported to FPS via the appropriate Regional Hotline, as directed by the Regional Information System Security Officer or the GSA IT Service Desk. Lost or stolen GFE mobile devices occurring outside of Federal facilities shall first be reported to the local police and then reported to the GSA IT Service Desk and FPS, upon returning to the office. Lost PIV cards must be reported to the Regional OMA office after reporting to the GSA IT Service Desk. All incidents involving personally identifiable information (PII) in electronic or physical form must be reported to the GSA OCISO via the IT Service Desk within one hour of discovering the incident. There should be no distinction between suspected and confirmed PII incidents (i.e., breaches). The OCISO shall promptly notify the US-CERT, the GSA OIG, and the SAOP of any incidents involving personally identifiable information. The GSA Incident Response Team will coordinate external reporting to the OIG, SAOP, US-CERT, and the U.S. Congress (if a major incident), as appropriate.

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf https://insite.gsa.gov/portal/content/553345 https://insite.gsa.gov/portal/content/555377

U.S. General Services Administration 3

(5) 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 Personally Identifiable Information, whether physical or electronic) shall follow reporting and response procedures as defined in GSA Order CIO 9297.2, GSA Information Breach Notification Policy. Refer to GSA Order CIO 9297.1 GSA Data Release Policy, for non-releasable information to the public or persons other than the employee, except when required by law (e.g., court order). See also Chapters 7 and 8 of GSA Order CIO P 2180.1, GSA Rules of Behavior for Handling Personally Identifiable Information (PII).

(6) FIPS 199 Moderate and High impact systems must annually test the security incident response capability to determine the incident response effectiveness.

1.2.1 Policies Regarding Contractors and Contractor Facilities

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

Refer to GSA 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 information system are responsible for ensuring that an IR process has been implemented for their respective Service/Staff Office (S/SO) 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 2018 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.2.

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:

https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf https://www.dhs.gov/sites/default/files/publications/FY%202018%20CIO%20FISMA%20Metrics_V1_Final%20508.pdf

U.S. General Services Administration 4

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

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

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, IT Security Procedural Guide: Incident Response (IR), CIO-IT Security-01-02 (this guide) and GSA Order, CIO 9297.2, “GSA Information Breach Notification Policy”;

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

• Reviewing and coordinating reporting of Security Advisory Alerts (SAA), 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;

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2017/m-17-12_0.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2017/m-17-12_0.pdf

U.S. General Services Administration 5

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

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

U.S. General Services Administration 6

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

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

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 IT Security Procedural Guide CIO-IT Security 09-48, “Security Language for IT Acquisition Efforts”.

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.

https://insite.gsa.gov/portal/content/627230

U.S. General Services Administration 7

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:

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

Major Incident Decision Team. Incident Response related responsibilities of the Major Incident Decision Team (MIDT) include the following:

• The MIDT is required per the current OMB Memorandum providing Guidance on Federal Information Security and Privacy Management Requirements and is tasked with responsibility for the determining whether a major incident has occurred (requiring Congressional reporting). The MIDT includes as its members at least the following roles:

o GSA Chief Information Officer (CIO) o GSA Chief Information Security Officer (CISO) o System Owners (e.g., System Program Managers/Project Managers) o Senior Agency Official for Privacy (SAOP), if the incident involves a Privacy Breach o Security Engineering Division Director or representative

Initial Agency Response Team. 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 credit monitoring (if necessary), and any other assistance deemed necessary.

• The OCISO is responsible for ensuring the US-CERT 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.

https://www.whitehouse.gov/omb/memoranda/

U.S. General Services Administration 8

• The program office is responsible for providing the remedy to the impacted individuals (including associated costs) and will provide evidence that notification was provided to impacted individuals within thirty (30) calendar days of the date on the US-CERT Report.

• 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 Senior Agency Official for Privacy (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 Agency Response Team. Incident Response related responsibilities of the Full Agency 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 Agency Response Team. Based on the risk assessment, breaches that impact fewer than 1,000 may still be moved under the purview of the Full Agency Response Team should they involve a large amount of PII.

• 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 Communications and Marketing (OCM), Office of Congressional and Intergovernmental Affairs (OCIA), and the Office of General Counsel (OGC).

2 Federal Incident Reporting Guidelines

The US-CERT coordinates defense against and responses to cyber-attacks. Notifying US-CERT 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 US-CERT voluntarily. However, US-CERT has asked that encrypted lost or stolen devices and unsuccessful phishing attempts1 no longer be reported to US-CERT as incidents. US-CERT 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

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

https://www.us-cert.gov/incident-notification-guidelines https://www.us-cert.gov/incident-notification-guidelines mailto:phishing-report@us-cert.gov

U.S. General Services Administration 9 best estimate at the time of notification and report updated information as 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 in order 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.

US-CERT 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 US-CERT Impact Classifications

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. Use Table 1 below to identify the impact of the incident. The term “classified information” is defined in IAW CNSSI 4009. The term “proprietary information” is defined in IAW NIST SP 800-61. The term “personally identifiable information” is defined IAW with OMB Memorandum M-17-12.

Note: Incidents involving non-cyber PII exposures or classified data spillage (i.e. unsecured hard copies) will not be reported to US-CERT. The GSA Senior Agency Official for Privacy (SAOP) will coordinate all response efforts related to non-cyber incidents involving PII.

Table 1: Federal Agency Incident Impact Classifications

Impact Category Category Severity Levels

Functional Impact – A measure of the impact to business functionality or ability to provide services

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.

https://www.dni.gov/files/NCSC/documents/nittf/CNSSI-4009_National_Information_Assurance.pdf https://www.dni.gov/files/NCSC/documents/nittf/CNSSI-4009_National_Information_Assurance.pdf https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2017/m-17-12_0.pdf

U.S. General Services Administration 10

Impact Category Category Severity Levels

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

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.

Information Impact – Describes the type of information lost, compromised, or corrupted.

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.

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

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.

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 by NIST, “proprietary information” is “information that is not public knowledge and that is viewed as the property of the holder, with the holder of that information responsible to declare it and treat it as proprietary”.

U.S. General Services Administration 11

Impact Category Category Severity Levels

DESTRUCTION OF CRITICAL SYSTEM – Destructive techniques, such as MBR overwrite;

have been used against a critical system.

Recoverability – Identifies the scope of resources needed to recover from the incident

REGULAR – Time to recovery is predictable with existing resources.

SUPPLEMENTED – Time to recovery is predictable with additional resources.

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

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

The Federal Agency Incident Impact Classification table is available on the US-CERT website.

** Per OMB M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information , the term PII means any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. However, incidents involving non-cyber PII exposures or classified data spillage (i.e. unsecured hard copies) should not be reported to US-CERT and will be reported to GSA’s Privacy Office as required by policy, consistent with updated federal incident reporting guidelines.

*** GSA Policy specifies that all mobile data storage devices (including laptop hard drives, USB external disk or Flash storage, etc.) must be encrypted with a FIPS 140-2 certified encryption module. If a device is lost or stolen that violates this policy or the keys that protect the device could be recovered, the incident must be treated as an incident with information impact and reported immediately as such. In addition, US-CERT has requested that simple loss or theft of 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 US- CERT as follows:

• Phishing attempts where ENT domain credential 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.

https://www.us-cert.gov/incident-notification-guidelines https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2017/m-17-12_0.pdf

U.S. General Services Administration 12

• Sensitive 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 US-CERT, other phishing attempts will not be reported as incidents, but submitted separately to phishing-report@us-cert.gov in accordance with Section

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

2.2 US-CERT 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.

Table 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 US-CERT. US-CERT provides the following guidance for use this table:

Note: Incidents may affect multiple types of data; therefore, 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: 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 attachment.

Exploit code disguised as an attached document, or a link to a malicious website in the body of an email message.

External/Removable Media

An attack executed from removable media or a peripheral device.

Malicious code spreading onto a system from an infected USB flash drive.

Impersonation/Spoofing An attack involving replacement of Spoofing, man in the middle attacks, rogue mailto:phishing-report@us-cert.gov

U.S. General Services Administration 13

Threat Vector Description Example legitimate content/services with a malicious substitute.

wireless access points, and SQL injection attacks all involve impersonation.

Improper Usage

Any incident resulting from violation of an organization's acceptable usage policies by an authorized user, excluding the above categories.

User installs file-sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system.

Loss or Theft of Equipment

The loss or theft of a computing device or media used by the organization. A misplaced laptop or mobile device.

Other An attack does not fit into any other vector

U.S. General Services Administration 14

2.3 US-CERT Cause Analysis

The decision tree shown in Figure 1 is used to identify the appropriate threat vector:

Figure 1: Threat Vector Decision Tree

U.S. General Services Administration 15

2.4 US-CERT Incident Attributes

To support the assessment of national-level severity and priority of cyber incidents, including those affecting private-sector entities, the US-CERT’s National Cybersecurity & Communications Integration Center (NCCIC) will analyze the following incident attributes utilizing the NCCIC Cyber Incident Scoring System (NCISS):

• Functional Impact,

• Information Impact,

• Recoverability,

• Location of Observed Activity

• Observed Activity,

• Actor Characterization,

• Cross-Sector Dependency, and

• Potential Impact.

US-CERT Note: Agencies are not required or expected to provide Actor Characterization, Cross- Sector Dependency, or Potential Impact information. These are assessed independently by NCCIC/US-CERT incident handlers and analysts. Additionally, Observed Activity is not currently required and is based on the attack vector, if known, and maps to the Office of the Director of National Intelligence’s (ODNI) Cyber Threat Framework.

This information will be utilized to calculate a severity score according to the NCISS. The NCISS aligns with the priority levels of the Cyber Incident Severity Schema (CISS):

• Emergency (Black): Poses an imminent threat to the provision of wide-scale critical infrastructure services, national government stability, or the lives of U.S. persons.

• Severe (Red): Likely to result in a significant impact to public health or safety, national security, economic security, foreign relations, or civil liberties.

• High (Orange): Likely to result in a demonstrable impact to public health or safety, national security, economic security, foreign relations, civil liberties, or public confidence.

• Medium (Yellow): May impact public health or safety, national security, economic security, foreign relations, civil liberties, or public confidence.

• Low (Green): Unlikely to impact public health or safety, national security, economic security, foreign relations, civil liberties, or public confidence.

• Baseline – Minor (Blue): Highly unlikely to affect public health or safety, national security, economic security, foreign relations, civil liberties, or public confidence.

• Baseline – Negligible (White): Unsubstantiated or inconsequential event.

https://www.us-cert.gov/NCCIC-Cyber-Incident-Scoring-System https://www.dni.gov/cyber-threat-framework/lexicon.html https://obamawhitehouse.archives.gov/sites/whitehouse.gov/files/documents/Cyber%2BIncident%2BSeverity%2BSchema.pdf

U.S. General Services Administration 16

The following incident attribute definitions are taken from the NCCIC NCISS.

Attribute Category Attribute Definitions

Location of Observed Activity:

Where the observed activity was detected in the network.

LEVEL 1 – BUSINESS DEMILITERIZED ZONE – Activity was observed in the business network’s demilitarized zone (DMZ)

LEVEL 2 – BUSINESS NETWORK – Activity was observed in the business or corporate network of the victim. These systems would be corporate user workstations, application servers, and other non-core management systems.

LEVEL 3 – BUSINESS NETWORK MANAGEMENT – Activity was observed in business network management systems such as administrative user workstations, active directory servers, or other trust stores.

LEVEL 4 – CRITICAL SYSTEM DMZ – Activity was observed in the DMZ that exists between the business network and a critical system network. These systems may be internally facing services such as SharePoint sites, financial systems, or relay “jump” boxes into more critical systems.

LEVEL 5 – CRITICAL SYSTEM MANAGEMENT – Activity was observed in high-level critical systems management such as human-machine interfaces (HMIs) in industrial control systems.

LEVEL 6 – CRITICAL SYSTEMS – Activity was observed in the critical systems that operate critical processes, such as programmable logic controllers in industrial control system environments.

LEVEL 7 – SAFETY SYSTEMS – Activity was observed in critical safety systems that ensure the safe operation of an environment. One example of a critical safety system is a fire suppression system.

UNKNOWN – Activity was observed, but the network segment could not be identified.

Actor Characterization The type of actor(s) involved in the incident (if known). This element is not selected by the reporting entity.

Cross-Sector Dependency A weighting factor that is determined based on cross-sector analyses conducted by the DHS Office of Critical Infrastructure Analysis (OCIA).

This element is not selected by the reporting entity.

Potential Impact An estimate of the overall national impact resulting from a total loss of service from the affected entity. This element is not selected by the reporting entity.

US-CERT Note: Agencies are not required or expected to provide Actor Characterization, Cross- Sector Dependency, or Potential Impact information. These are assessed independently by NCCIC/US-CERT incident handlers and analysts. Additionally, Observed Activity is not currently

U.S. General Services Administration 17 required and is based on the attack vector, if known, and maps to the ODNI Cyber Threat Framework.

2.5 Major Incident Definition and Requirements

FISMA requires the Office of Management and Budget (OMB) to define a major incident and directs agencies to report major incidents to Congress within 7 days of identification. OMB M- 18-02 defines a major incident as follows:

A "major incident" is any incident that is likely to result in demonstrable harm to the national security interests, foreign relations, or economy of the United States or to the public…