Attachment 1D - Managing-Enterprise-Cybersecurity-Risk-CIO-IT-Security-06-30-Rev-24-06-26-2023.pdf

Office of the Chief Information Security Officer

Revision 24

June 26, 2023

IT Security Procedural Guide:

Managing Enterprise Cybersecurity

Risk

CIO-IT Security-06-30

DocuSign Envelope ID: 5240F84D-A253-4B38-8D0C-81BF166DE4A2

CIO-IT Security-06-30, Revision 24 Managing Enterprise Cybersecurity Risk

U.S. General Services Administration

VERSION HISTORY/CHANGE RECORD

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Revision 1 – March 22, 2006

1 Bo Berlas Included the OWASP Web Application Penetration Checklist and the OWASP Testing Project documents as embedded objects into Appendix C – GSA Risk Assessment Security Requirements.

To provide a usable checklist for testing the OWASP Top Ten Vulnerabilities.

Revision 2 – February 13, 2007

1 Bo Berlas Various updates to reflect changes in A&A process

FINAL publishing of NIST 800-53 on 12/2006

4-10

2 Bo Berlas Updated Appendix A: Risk Assessment Report Format

RA and SA are now combined into a single RA/SA report.

3 Bo Berlas Updated Appendix B: GSA Security Assessment Test Procedures

Updated Assessment test procedures based on FINAL publishing of NIST 800-53 on 12/2006

4 Bo Berlas Updated Appendix C: Plan of Action and Milestone (POA&M) Template

Attached new POA&M template for FY 2007.

5 Bo Berlas Updated Appendix D: Risk Assessment / Security Assessment Plan Template

Updated assessment plan template to reflect combining of RA and SA reports.

Revision 3 – March 20, 2007

1 Bo Berlas Changed reference to OWASP Top Ten from 2007 Release Candidate 1 back to the 2004 Update.

OWASP Top Ten, 2007 RC1 has not been finalized. GSA will adopt the OWASP Top Ten, 2007 Update upon final publication.

2 Bo Berlas New database scanning requirement.

App Detective or similar tool should be used to test database security configurations.

Revision 4 – October 16, 2007

1 Bo Berlas Updated policy reference. GSA IT Security Policy was updated June 2007.

2 Bo Berlas Changed reference to OWASP Top Ten from the 2004 Update to the current 2007 Update.

The 2007 Top Ten lists current web application vulnerabilities.

3 Bo Berlas Replaced the FY 2007 POA&M Reporting Template with the FY 2008 template.

New OMB Quarterly POA&M Reporting Requirements

Revision 5 – July 15, 2010

1 Bo Berlas Update the A&A process to be consistent with NIST 300-37 and the Risk Management Framework

Updates required to ensure agency compliance.

Various

2 Bo Berlas Inserted Roles and Responsibilities relating to A&A from the GSA IT Security Policy

Identify A&A Roles and Responsibilities

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

3 Bo Berlas New implementation guidance for NIST 800-53 controls.

To facilitate implementation of required controls

4 Bo Berlas New NIST 800-53 assessment test cases

Required to facilitate assessment of NIST 800-53 controls

Appendix C

5 Bo Berlas New OCISO A&A Review SOP Documents the process for submission of A&A packages to the OCISO and the detailed procedural steps performed by the OCISO to verify A&A compliance.

Appendix E

6 Bo Berlas New guidance for A&A of Minor Systems

To facilitate assessment of minor systems.

Revision 6 – December 16, 1 Bo Berlas Updated references for Certification, Accreditation, and Certification and Accreditation (C&A) to Assessment, Authorization, and Assessment and Authorization (A&A), respectively.

To be consistent with the current terminology in NIST 800-37.

Throughout

2 Bo Berlas Inserted guidance for forming sections 1-10 of the SSP for cloud computing system SSPs.

To address cloud specific security challenges.

Revision 7 – May 31, 2011

1 Bo Berlas Updated references to A&A to security authorization process and authorization package or A&A package to security authorization package.

To be consistent with the current terminology in NIST 800-37.

Throughout

2 Bo Berlas Inserted guidance for review of minimal impact SaaS solutions.

To document required review activities for such systems.

3 Bo Berlas Updated Appendix E to include a revised OCISO Security Authorization Package Review

SOP.

To reflect current version of the SOP.

Revision 8 – November 25, 1 Lewis/ Sitcharing

Changes made throughout the document to reflect NIST and GSA requirements

Updated to reflect and implement the most current NIST 800-53-Rev4 and GSA requirements

Various

Revision 9 – May 19, 2016

1 Wilson/ Klemens

Restructuring of the document, modifications to specific process descriptions.

Updated to reflect current acceptance of risk process and rename Minor Application process to Subsystem process and revise its description.

Restructuring and editing throughout.

Various

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Revision 10 – April 10, 2017

1 Desai Klemens Clarifying system definitions and penetration testing requirements.

Included definitions of Federal and Contractor systems. Clarified when systems are required to have penetration tests as part of their assessment.

Sections 1.2, 4.1.7

2 Klemens Update and edit document. Updating of hyperlinks, editing of document, updates to align with other GSA documents.

Throughout

Revision 11 – October 10, 2017

1 Dean Feliksa/ Klemens

Update hyperlinks and minor editorial changes.

Hyperlinks were updated so outdated, superseded documents would not be provided. Minor edits to clarify current GSA processes.

Throughout

Revision 12 – January 17, 2018

1 Feliksa/ Klemens

Integrate the NIST Cybersecurity Framework (CSF), update A&A process and POA&M information, remove Cloud Controls.

Comply with Executive Order 13800, update processes based on revised procedures, streamline document by moving cloud controls.

Throughout

Revision 13 – May 14, 2018

1 Klemens Added a provision for piloting new A&A processes. Updated Lightweight Security Authorization Process, MiSaaS, CSF content.

Allows a new A&A process to be piloted/tested. Align with revised GSA and NIST guidance.

Sections 1, 3.2.2, 3.2.6, Appendix A, Appendix C

Revision 14 – February 1, 2019

1 Klemens Updated information on compliance/configuration scans.

Updated hyperlink references.

Added Program and Project Manager roles. Removed CTW as attachment to SSP.

Clarify GSA policy and guidance on compliance to hardening guides. Update to new format and style for hyperlinks. Added roles added to 2100.1. Data in the CTW is available in the SSP Template and Control Summary Table.

Throughout

2 Klemens Added information concerning Binding Operational Directives (BOD) requirements and clarified encryption of data at rest requirements.

Clarify GSA policy and guidance on BOD and encryption requirements.

10, 12, 14, 38, 47

3 Klemens Updated penetration testing requirements. Editing to align with current format, style, structure.

Provide the latest guidance on penetration testing requirements

34, 38, various

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Revision 15 – July 25, 2019

1 Klemens Updated SC-28 (1) control applicability and parameter.

Revised references to BODs to Cybersecurity Directives which include BODs and Emergency Directives. Revised parameter for SI-2(3).

Updated GSA parameters and guidance on NIST controls.

Multiple

Revision 16 – October 3, 2019

1 Dean/ Klemens Revised to include/update information on Showstopper Controls, configuration compliance metric, vulnerability remediation timeframes, reference additional procedural guides, and add Certification Letter as part of security authorization process.

Updated to reflect additional Federal and GSA guidance and process changes.

Multiple

2 Klemens Added PL-8 and SA-8 to the table of GSA required controls, removed LATO SSP/SAR/Test Cases from LATO process description and appendices.

Updated to reflect additional Federal and GSA guidance and process changes.

Multiple

Revision 17 – July 1, 2020

1 Dean/ Klemens Revisions include:

Retitled to “Managing Enterprise Cybersecurity Risk”

Included the GSA Risk Executive Function role

Added a requirement for independent assessment of common controls

Added Approval to Use (ATU) and GSA processes for ATUs

Added Leveraged FedRAMP Authorization to Operate (ATO) process

Updated ATO and control sections

Updated to reflect additional Federal and GSA guidance and process changes.

Multiple

Revision 18 – September 11, 1 Desai/Klemens Revisions include:

Added guidance on implementing, documenting, and assessing Cloud Service Provider (CSP) customer responsibilities.

Updated Encryption of Sensitive Data information in Showstopper table.

Updated to reflect GSA guidance regarding customer responsibility controls.

Sections 5.3, 5.4, and 13

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Revision 19 – April 15, 2021

1 Desai/Klemens/ Dean

Revisions include:

Incorporate NIST SP 800-37, Revision 2

Incorporate NIST SP 800-53, Revision 5.

Update existing GSA A&A process descriptions.

Add Protecting CUI in Nonfederal Systems Assessment process.

Incorporate Clean ATO process, including update to A&A Package approval.

Add guidance on the use of operational/live data in preproduction systems.

Incorporate Management Implementation Plan processes.

Update SAR and POA&M processes.

Update the FedRAMP XaaS section to include the requirement for assessments.

Incorporate updated NIST publications and GSA processes

Throughout

Revision 20 – May 18, 2021

1 Desai/Klemens Revisions include:

Added SC-8/SC-8(1) controls to Showstoppers and GSA additional controls.

Added CISO and AO approval required before pursuing a 90-day LATO.

Added IPv6 transition requirement.

Revised scope to clarify requirement to adhere to all GSA security guides and requirements.

Clarification on determining the appropriate ATU/ATO process to follow.

Update showstopper controls, approval requirement to use 9-day LATO, IPv6 transition requirements, revise scope section, clarify identification of appropriate process for systems.

Multiple

Revision 21 – July 21, 2021

1 Desai/Klemens Revisions include:

Added PE-8(3), PL-9, RA-8 as additional GSA controls.

Added requirement that any ATO Letter leveraging a FedRAMP ATO must be provided to the FedRAMP

PMO.

Editorial updates.

Update additional NIST controls required by GSA, add requirement to provide FedRAMP PMO any ATO Letters leveraging FedRAMP authorizations, editorial updates.

Sections 4, 8, and 9

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Revision 22 – December 30, 1 Desai/Klemens Revisions include:

Updated timeline for NIST SP 800-53A assessments to be completed.

Updated to reflect requirements per BOD 22-01 and ED 22-02, including adding to Showstoppers.

Updated AOR section to align with latest guidance.

Updated GSA CISO controls to reflect updates to 800-53 applicability and GSA guidance.

Updated to align with current Federal requirements, guidelines, and GSA guidance.

Throughout

Revision 23 – May 9, 2022

1 Desai/Klemens Revisions include:

Updated timeline for NIST SP 800-53/53A SSPPs and assessments to be completed.

Updated parameter for NIST SP 800-53 Control RA-9.

Updated CISA KEV POA&M and AOR information.

Updated to current format and structure.

Updated to align with current GSA guidance.

Throughout

Revision 24 – June 26, 2023

1 Desai/Klemens/ McCormick/ Hanna

Revisions include:

Updated CISA KEV POA&M and AOR information.

Updated Table E-1, Showstopper Items/Controls.

Revised Section 4.8: GSA Leveraged FedRAMP SaaS Solution Process

Updated control implementation guidance, as necessary.

Aligned to other guides.

Updated to current format and structure.

Updated system interconnection sections.

Removed references to Clean ATO guide (not published) and processes based on it.

Updated to align with current GSA guidance.

Throughout

2 Privacy Office – Riordan, Hanna, Speidel

Updated the Senior Agency Official for Privacy’s responsibilities and the Privacy office’s engagement in the A&A process.

Updated to align with current GSA guidance.

Throughout

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Added the Chief Privacy Officer as a signatory of the guide.

Approval

IT Security Procedural Guide: Managing Enterprise Cybersecurity Risk, CIO-IT Security-06-30, Revision 24, is hereby approved for distribution.

Bo Berlas GSA Chief Information Security Officer

Contact: GSA Office of the Chief Information Security Officer (OCISO), Policy and Compliance Division (ISP), at ispcompliance@gsa.gov.

Concurrence

The undersigned concurs with the Privacy Office’s responsibilities established in this guide regarding the categorization, assessment, and authorization of GSA systems.

Richard Speidel GSA Chief Privacy Officer

Contact: GSA Office of the Chief Privacy Officer (CPO) at privacy.office@gsa.gov.

U.S. General Services Administration i

Table of Contents

1 Introduction

1.1 Purpose

1.2 Scope

1.3 Policy

1.4 GSA Archer GRC Implementation

1.4.1 Agency System Inventory

1.4.2 Authorization Packages

1.5 Assessment and Authorization Roles and Responsibilities

1.5.1 GSA Administrator

1.5.2 Risk Executive (Function)

1.5.3 GSA Chief Information Officer (CIO)

1.5.4 Chief Information Security Officer (CISO)

1.5.5 GSA Senior Agency Official for Privacy (SAOP)

1.5.6 GSA Chief Privacy Officer (CPO)

1.5.7 Heads of Services and Staff Offices (HSSOs)

1.5.8 Authorizing Officials (AOs)

1.5.9 Office of CISO Division Directors

1.5.10 Information System Security Managers (ISSMs)

1.5.11 Information System Security Officers (ISSOs)

1.5.12 System Owners

1.5.13 Program Managers

1.5.14 Project Managers

1.5.15 Data Owners (i.e., Functional Business Line Managers)

1.5.16 Contracting Officers (COs)/Contracting Officer’s Representatives (CORs)

1.5.17 Custodians

1.5.18 Users of IT Resources

1.5.19 System/Network Administrators

1.5.20 OCISO DevSecOps Program (ODP) Security Engineers

2 Identifying Appropriate ATU or ATO Process

2.1 Identifying the Appropriate ATU Process

2.2 Identifying the Appropriate ATO Process

3 ATU Process Summaries

3.1 GSA Salesforce Platform Process

3.2 Federalist Site Process

3.3 RPA Process

3.4 Google Extensions and Add-ons

3.5 Google Apps Scripts

3.6 GCP Services

3.7 AWS Services

4 A&A Process Summaries

4.1 GSA Standard A&A Process

4.2 Lightweight Security Authorization Process

4.3 Low Impact Software as a Service (LiSaaS) Solutions Authorization Process

4.4 GSA Agency FedRAMP Process

4.5 Moderate Impact Software as a Service (MiSaaS) Security Authorization Process

4.6 GSA Subsystem Process

4.7 GSA Ongoing Authorization (OA) Program

4.8 GSA Leveraged FedRAMP SaaS Solution Process

5 GSA Standard A&A Process

5.1 RMF PREPARE Step

5.1.1 TASK P-1: Risk Management Roles

5.1.2 TASK P-2: Risk Management Strategy

5.1.3 TASK P-3: Risk Assessment – Organization

U.S. General Services Administration ii

5.1.4 TASK P-4: Organizationally – Tailored Control Baselines and Cybersecurity Framework Profiles (OPTIONAL)

5.1.5 TASK P-5: Common Control Identification

5.1.6 TASK P-6: Impact-Level Prioritization (Optional)

5.1.7 TASK P-7: Continuous Monitoring Strategy – Organization

5.1.8 TASK P-8: Mission or Business Focus

5.1.9 TASK P-9: System Stakeholders

5.1.10 TASK P-10: Asset Identification

5.1.11 TASK P-11: Authorization Boundary

5.1.12 TASK P-12: Information Types

5.1.13 TASK P-13: Information Life Cycle

5.1.14 TASK P-14: Risk Assessment – System

5.1.15 TASK P-15: Requirements Definition

5.1.16 TASK P-16: Enterprise Architecture

5.1.17 TASK P-17: Requirements Allocation

5.1.18 TASK P-18: System Registration

5.2 RMF CATEGORIZE Step

5.2.1 TASK C-1: System Description

5.2.2 TASK C-2: System Categorization

5.2.3 TASK C-3: System Categorization Review and Approval

5.3 RMF SELECT Step

5.3.1 TASK S-1: Control Selection

5.3.2 TASK S-2: Control Tailoring

5.3.3 TASK S-3: Control Allocation

5.3.4 TASK S-4: Documentation of Planned Control Implementations

5.3.5 TASK S-5: Continuous Monitoring Strategy – System

5.3.6 TASK S-6: Plan Review and Approval

5.4 RMF IMPLEMENT Step

5.4.1 TASK I-1: Control Implementation

5.4.2 TASK I-2: Update Control Implementation

5.5 RMF ASSESS Step

5.5.1 TASK A-1: Assessor Selection

5.5.2 TASK A-2: Assessment Plan

5.5.3 TASK A-3: Control Assessments

5.5.4 TASK A-4: Assessment Reports

5.5.5 TASK A-5: Remediation Actions

5.5.6 TASK A-6: Plan of Action and Milestones

5.6 RMF AUTHORIZE Step

5.6.1 TASK R-1: Authorization Package

5.6.2 TASK R-2: Risk Analysis and Determination

5.6.3 TASK R-3: Risk Response

5.6.4 TASK R-4: Authorization Decision

5.6.5 TASK R-5: Authorization Reporting

5.7 RMF MONITOR Step

5.7.1 TASK M-1: System and Environment Changes

5.7.2 TASK M-2: Ongoing Assessments

5.7.3 TASK M-3: Ongoing Risk Response

5.7.4 TASK M-4: Authorization Package Updates

5.7.5 TASK M-5: Security and Privacy Reporting

5.7.6 TASK M-6: Ongoing Authorization

5.7.7 TASK M-7: System Disposal

5.8 A&A Guidance for Significant Changes

5.9 A&A Guidance for Expiring Authorizations

6 Protecting Confidential Unclassified Information (CUI) in Nonfederal Systems and Organizations 7 Independent Assessment of Enterprise-wide Common and Hybrid Controls

U.S. General Services Administration iii

8 GSA Implementation of CA, PL, and RA Controls

8.1 Assessment, Authorization, and Monitoring (CA)

8.1.1 CA-1 Policy and Procedures

8.1.2 CA-2 Control Assessments

8.1.3 CA-3 Information Exchange

8.1.4 CA-5 Plan of Action and Milestones

8.1.5 CA-6 Authorization

8.1.6 CA-7 Continuous Monitoring

8.1.7 CA-8 Penetration Testing

8.1.8 CA-9 Internal System Connections

8.2 Planning (PL)

8.2.1 PL-1 Policy and Procedures

8.2.2 PL-2 System Security and Privacy Plans

8.2.3 PL-4 Rules of Behavior

8.2.4 PL-8 Information Security Architecture

8.2.5 PL-9 Central Management

8.2.6 PL-10 Baseline Selection

8.2.7 PL-11 Baseline Tailoring

8.3 Risk Assessment (RA)

8.3.1 RA-1 Policy and Procedures

8.3.2 RA-2 Security Categorization

8.3.3 RA-3 Risk Assessment

8.3.4 RA-5 Vulnerability Monitoring and Scanning

8.3.5 RA-7 Risk Response

8.3.6 RA-8 Privacy Impact Assessments

8.3.7 RA-9 Criticality Analysis

9 Additional NIST Controls Required by GSA 10 Summary Appendix A: CSF Function, Category, and Subcategory Definitions Appendix B: Consolidated List of Guidance, Policies, Procedures, Templates Appendix C: A&A Process Package Document Lists/Links Appendix D: Scanning Frequency By A&A Process Appendix E: Showstopper Items and Associated Controls

Figure 5-1: Risk Management Framework Steps (from NIST 800-37, Revision 2)

Table 2-1. GSA ATU Processes Table 2-2. GSA ATO Processes Table 5-1. GSA Information Exchange Document Type/Approval Matrix Table 9-1: GSA Additional NIST Control Requirements Table A-1: NIST CSF Functions Mapped to NIST SP 800-37 RMF Steps Table A-2: CSF Category/Subcategory Definitions Table E-1: GSA Showstopper Items/Controls

Notes: Hyperlinks in this guide are provided as follows:

Appendix B - Consolidated List of Guidance, Policies, Procedures, Templates. This appendix contains hyperlinks to Federal Regulations/Guidance and to GSA web pages containing GSA policies, guides, and forms/templates.

In running text - Hyperlinks will be provided if they link to a location within this document (i.e., a different section or an appendix). Hyperlinks will be provided for external sources unless the hyperlink is to a web page or document listed in Appendix B. For example, Google Forms, Google Docs, and websites will have links.

U.S. General Services Administration 1

1 Introduction

The General Services Administration (GSA) uses two approaches to permit information systems, applications, services, features, or functions to be used.

Authorization to Operate (ATO) - An official management decision authorizing the operation of an information system and to explicitly accept the risk to agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, and the Nation.

Approval to Use (ATU) – A risk-based approval process for usage of services, features, or functions on information systems or platforms with an existing ATO.

Security Assessment and Authorization (A&A) processes within the GSA lead to an ATO and are based on the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) and the security authorization process as described in NIST Special Publication (SP) 800-37, Revision 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.” This guide describes key activities in managing enterprise-level cybersecurity risk through a system life cycle perspective including information system ATO and continuous monitoring. Every GSA Information Technology (IT) system/platform must use one of the A&A processes identified in this guide or a pilot process as described later in this section.

In Appendix E, Table E-1, GSA has identified a list of Showstopper items and NIST SP 800-53 controls associated with them, including compliance with Department of Homeland Security (DHS) Cybersecurity and Infrastructure security Agency (CISA) Binding Operational Directives (BODs) and Emergency Directives (EDs). The Showstopper items and controls associated with them, if not fully compliant, will keep a system from receiving a full ATO.

NIST SP 800-53, Revision 5, “Security and Privacy Controls for Information Systems and Organizations,” and NIST SP 800-53B, “Control Baselines for Information Systems and Organizations,” were updated on December 10, 2020. NIST SP 800-53A, Revision 5, “Assessing Security and Privacy Controls in Information Systems and Organizations,” became final on January 25, 2022. GSA has established the following groups and timelines for systems to have their System Security and Privacy Plans (SSPPs) prepared and assessments conducted in accordance with these NIST documents and GSA templates.

Group B – Systems in GSA’s Ongoing Authorization (OA) Program.

o 10/15/2022 – SSPPs updated to NIST 800-53, Revision 5.

o 9/30/2023 or an AO/CISO approved exception – Ongoing ATO (OATO) updated based on an assessment of NIST 800-53, Revision 5 controls.

Group C – GSA systems not in Group B or D.

o 10/15/2022 – SSPPs updated to NIST 800-53, Revision 5.

o System’s next scheduled A&A - ATO updated based on an assessment of NIST

800-53, Revision 5 controls.

Group D – FedRAMP Leveraged Systems.

o Within 6 months of Cloud Service Provider’s update of their FedRAMP SSPP and

Customer Responsibility Matrix (CRM) to NIST SP 800-53, Revision 5 – CRM SSPPs updated to NIST 800-53, Revision 5.

DocuSign Envelope ID: 5240F84D-A253-4B38-8D0C-81BF166DE4A2 https://www.cisa.gov/news-events/directives https://www.cisa.gov/news-events/directives

U.S. General Services Administration 2 o Within 2 months of CRM SSPP Update - ATO updated based on an assessment of CRM SSPP NIST 800-53, Revision 5 controls. See Section 4.8 for Leveraged FedRAMP SaaS guidance.

GSA may conduct pilots of additional A&A processes when a system or the evolving IT and IT security environments indicate a process different from any of GSA’s existing processes is preferred. Piloting of new processes must be coordinated with the GSA Chief Information Security Officer (CISO). Final approval of the process is indicated by the CISO concurring with any ATO resulting from the pilot.

ATU processes and procedures are based on evaluating the risk of using available services, features, or functions based on their characteristics and environment. Section 3 provides additional information on GSA’s ATU processes.

Any deviations from the security requirements established in GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy” must be coordinated by the Information Systems Security Officer (ISSO) through the appropriate Information Systems Security Manager (ISSM) and authorized by the Authorizing Official (AO). Any deviations, exceptions, or other conditions not following GSA policies and standards must be submitted using the Security Deviation/Waiver Request Form.

Executive Order (EO), EO 13800, “Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure” requires all agencies to use “The Framework for Improving Critical Infrastructure Cybersecurity (the Framework) developed by the NIST or any successor document to manage the agency’s cybersecurity risk.” This NIST document is commonly referred to as the Cybersecurity Framework (CSF). The CSF complements, and does not replace, an organization’s risk management process and cybersecurity program. GSA uses NIST’s RMF as its foundation for managing risk. Further information on how the CSF relates to GSA’s use of the NIST RMF is provided in Section 5 and Appendix A where the CSF categories and subcategories are defined.

1.1 Purpose

This procedural guide defines the GSA cybersecurity risk management process. It addresses the security authorization processes GSA has implemented for information systems to obtain an ATO. This guide identifies ATU processes for services, features, and functions to be used at GSA, and the process for protecting Confidential Unclassified Information (CUI) in nonfederal systems. The guide describes the key activities in managing enterprise-level cybersecurity risk as described in NIST SP 800-37. This guide assists agency and contractor personnel to understand and fulfill their security responsibilities regarding ATO, ATU, and other processes.

1.2 Scope

The requirements outlined within this guide apply to all GSA Federal employees, contractors, and vendors who oversee/protect GSA information systems and data. The guide provides GSA Federal employees, contractors, and vendors as identified in CIO 2100.1 and other IT personnel involved in performing A&A activities with the specific processes to follow for properly accomplishing cybersecurity activities. All GSA systems must adhere to one of the processes described in this guide, the security requirements specified in CIO 2100.1, and the guides listed on the IT Security Technical Guides and Standards and IT Security Procedural Guides web

DocuSign Envelope ID: 5240F84D-A253-4B38-8D0C-81BF166DE4A2 https://docs.google.com/forms/d/e/1FAIpQLSew38lCEj9FnE7Tmpi6ajMn700NYbe4fZtjo2Ol5MA9Of8eUw/viewform https://docs.google.com/forms/d/e/1FAIpQLSew38lCEj9FnE7Tmpi6ajMn700NYbe4fZtjo2Ol5MA9Of8eUw/viewform https://insite.gsa.gov/portal/content/553345 https://insite.gsa.gov/node/167050 https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides

U.S. General Services Administration 3 pages. The following definitions are provided for classifying information systems/platforms within the scope of this guide.

Federal System (i.e., Agency System). An information system in GSA’s inventory processing or containing GSA or Federal information where the infrastructure and/or applications are NOT wholly operated, administered, managed, and maintained by a Contractor.

Contractor System. An information system in GSA’s inventory processing or containing GSA or Federal data where the infrastructure and applications are wholly operated, administered, managed, and maintained by a contractor in non-GSA facilities.

1.3 Policy

As detailed within CIO 2100.1, Authorizing Officials (AO) must ensure risk assessments are performed as part of A&A activities before a system is placed into production, when significant changes are made to the system, and as specified in this guide and the guides for GSA’s other A&A processes.

1.4 GSA Archer GRC Implementation

GSA has implemented its official agency system inventory in Archer GRC. GSA is in the process of implementing authorization packages for its system inventory using Archer GRC’s A&A module. As GSA continues its Archer implementation, specific activities described in the guide will be incorporated in Archer to take advantage of its automation capabilities. Any questions regarding the use of Archer GRC at GSA should be sent to archersupport@gsa.gov.

1.4.1 Agency System Inventory

The agency system inventory in Archer GRC contains attributes such as responsible organization, system name, Federal Information Processing Standards Publication (FIPS) 199, “Standards for Security Categorization of Federal Information and Information Systems” security categorization level, ATO type, and ATO date. The inventory includes an A&A repository for storing all system A&A documents and artifacts for GSA systems.

1.4.2 Authorization Packages

Authorization packages have been created in Archer GRC for GSA’s systems and the task of implementing the authorization process for systems is just starting. The first steps in this process include inputting security categorization, privacy, and system demographics (boundary, connections, etc.) into Archer GRC, and allocating NIST SP 800-53 security controls. Future steps include conducting assessments, managing plans of action and milestones (POA&Ms), and the entire A&A process in Archer GRC.

1.5 Assessment and Authorization Roles and Responsibilities

There are many roles associated with the security authorization process. System Owners for each information system are responsible for ensuring their respective Service and Staff Office’s (SSO) systems have been through the GSA A&A process, have received an ATO from the AO, and received concurrence from the GSA Office of the CISO (OCISO). The complete roles and responsibilities for agency management officials and others with significant IT Security

U.S. General Services Administration 4 responsibilities are defined fully in Chapter 2 of CIO 2100.1. The following sections provide a high-level description of the responsibility for the primary roles with management and operational A&A responsibilities.

1.5.1 GSA Administrator

The GSA Administrator is responsible for ensuring an information security program is developed, documented, and implemented to provide security for all systems, networks, and data that support the operations of GSA.

1.5.2 Risk Executive (Function)

The Risk Executive (Function) at GSA is handled by the Enterprise Management Board (EMB), chaired by the Deputy Administrator who is also the Senior Accountable Official for Risk Management (SAORM). For cybersecurity risks, the Enterprise Risk and Strategic Initiatives (ERSI) board, co-chaired by the Deputy Performance Improvement Officer and the CISO, identifies and monitors agency-wide risks and ensures the EMB is updated on the risks and impacts to GSA. The CISO, Authorizing Officials, and subject matter experts facilitate the consistent application of cybersecurity risk management across GSA.

1.5.3 GSA Chief Information Officer (CIO)

The GSA Chief Information Officer (CIO) has overall responsibility for the GSA IT Security Program. The CIO is responsible for providing guidance, assistance, support, and management processes to GSA staff and organizations to enable them to perform their responsibilities with regard to GSA’s IT Security Program.

1.5.4 Chief Information Security Officer (CISO)

Public Law 113-283, “Federal Information Security Modernization Act of 2014” (FISMA), establishes the designation of a senior agency information security officer responsible for complying with Federal security requirements. GSA has assigned this role to the CISO. The CISO is the focal point for all GSA IT security and must ensure the security requirements described in this Order are implemented agency wide. The CISO reports directly to the CIO as required by FISMA.

1.5.5 GSA Senior Agency Official for Privacy (SAOP)

The SAOP is responsible for ensuring GSA’s compliance with privacy laws, regulations and GSA policy, and the privacy control baseline in NIST SP 800-53. The SAOP designates which privacy controls can be treated as common and hybrid. The SAOP, or delegated privacy personnel, approve system categorizations and oversee proper implementation of privacy controls. The SAOP reviews authorization packages to ensure compliance with applicable privacy requirements and to manage privacy risks prior to authorizing officials making risk determination and acceptance decisions.

1.5.6 GSA Chief Privacy Officer (CPO)

The CPO is responsible for overseeing GSA's Privacy Program whose mission it is to preserve and enhance privacy protections for all individuals whose personal information is handled by GSA and to encourage transparency of GSA operations involving personal information. The

U.S. General Services Administration 5

CPO manages GSA’s Privacy Act Program and administers GSA’s compliance with privacy laws and regulations. The CPO is responsible for developing, managing, and administering GSA’s Privacy Program Plan and Privacy Strategy Plan.

1.5.7 Privacy Analysts

Privacy Analysts are responsible for ensuring implementation of adequate privacy for a system in order to document, mitigate, and minimize the privacy risks associated with collecting, using, processing, storing, maintaining, and disseminating PII. A Privacy Analyst must be assigned for every information system that contains PII and may have responsibility for more than one system, provided there is no conflict. The Privacy Analyst must be knowledgeable of the PII and processes supported by their assigned systems. Privacy Analysts, when delegated, approve system categorizations, and oversee proper implementation of privacy controls. Privacy Analysts review PTAs/PIAs for their assigned systems.

1.5.8 Heads of Services and Staff Offices (HSSOs)

HSSOs are responsible for authorizing the operation of all systems, networks, and applications for which they have responsibility. They may delegate some of their authority (e.g., the role of Authorizing Official in writing) to appropriately qualified individuals within their organizations.

1.5.9 Authorizing Officials (AOs)

AOs are responsible for authorizing the operation of all systems, networks, and applications for which they have responsibility. They may delegate some of their authority (e.g., the role of Authorizing Official in writing) to appropriately qualified individuals within their organizations.

1.5.10 Office of CISO Division Directors

OCISO Directors are the intermediary to the AO for ensuring IT security is properly implemented. The Directors are GSA’s points of contact for all IT system security matters for the IT resources under their responsibility.

1.5.11 Information System Security Managers (ISSMs)

ISSMs report to the ISSO Support Division (IST) Director in the OCISO. There is at least one ISSM per AO. The ISSM is responsible for all IT system security and privacy matters for the systems under their authority. ISSMs work with ISSOs, System Owners, AOs, and others as security and privacy controls are implemented and review A&A packages for systems under their purview. ISSMs are appointed, in writing, by the Director of IST with concurrence by the CISO. An individual appointed as an ISSM for a system cannot also be assigned as the ISSO for the same system.

1.5.12 Information System Security Officers (ISSOs)

ISSOs are responsible for ensuring implementation of adequate system security and privacy protections, including proper control implementations, in order to manage cybersecurity risk aligned with the NIST CSF functions of Identify, Protect, Detect, Respond, and Recover. An ISSO must be assigned for every information system. An ISSO may have responsibility for more than one system, provided there is no conflict. An individual assigned as the ISSO for a system cannot also be the ISSM for the same system. ISSOs must be appointed via a designation

U.S. General Services Administration 6 letter. An ISSO must be knowledgeable of the information and processes supported by their assigned systems. ISSOs review A&A packages for systems under their purview.

1.5.13 System Owners

System Owners are management officials within GSA who bear the responsibility for the acquisition, development, maintenance, implementation, and operation of GSA's IT systems.

System Owners represent the interests of the system throughout its lifecycle. Primary responsibility for managing risk rests with the System Owners. System Owners must ensure their systems and the data each system processes have the necessary security and privacy 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.

1.5.14 Program Managers

Program Managers are management officials within GSA who are responsible for developing, implementing, and/or overseeing multi-year IT initiatives that must be carried out through multiple related projects. A Program Manager focuses on the strategic goals of GSA. Program Managers are responsible for ensuring cyber risk is adequately managed and resources are allocated, monitored, and managed to support the required level of security for projects under their purview.

1.5.15 Project Managers

Project Managers are management officials within GSA who are responsible for managing a project within a larger program. A Project Manager is responsible for ensuring cyber risk is adequately managed and the schedule, resources, and tasks within a project include delivering security.

1.5.16 Data Owners (i.e., Functional Business Line Managers)

Data Owners are responsible for determining the security categorization level of systems based upon FIPS Publication 199, “Standards for Security Categorization of Federal Information and Information Systems,” and ensuring System Owners are aware of the sensitivity of data (e.g., Personally Identifiable Information, Controlled Unclassified Information) to be handled. They must coordinate with System Owners, ISSMs, ISSOs, and Custodians to ensure the data is properly stored, maintained, protected, and monitored IAW GSA policies, regulations and any additional guidelines established by GSA.

1.5.17 Contracting Officers (COs)/Contracting Officer’s Representatives (CORs)

COs/CORs are responsible for coordinating and collaborating with the CISO or other appropriate officials to ensure all agency contracts and procurements are compliant with the agency’s information security policy. They also must ensure the appropriate security and privacy contracting language is incorporated in each contract and task order.

1.5.18 Custodians

Custodians own the hardware platforms and equipment on which the data is processed. They are the individuals in physical or logical possession of information from Data Owners. They

U.S. General Services Administration 7 must coordinate with Data Owners and System Owners to ensure the data is properly stored, maintained, and protected.

1.5.19 Users of IT Resources

Authorized users of GSA IT resources, including all Federal employees and contractors, either by direct or indirect connections, are responsible for complying with GSA’s IT Security Policy and procedures.

1.5.20 System/Network Administrators

System/Network Administrators are responsible for ensuring the appropriate security requirements are implemented consistent with GSA IT security policies and hardening guidelines.

1.5.21 OCISO DevSecOps Program (ODP) Security Engineers

ODP Security Engineers are responsible for collaborating with the system team on all aspects of system security and acting as liaison with the OCISO for security decisions and approvals.

2 Identifying Appropriate ATU or ATO Process

The next two sections list GSA’s ATU and ATO processes along with applicability/qualifying criteria to use a specific process. The applicability/qualifying criteria listed in Tables 2-1 and 2-2 identify the conditions under which each process may be used. If additional guidance is necessary or there is a question about which process to use, contact any GSA ISSM, the IST, ISP, or ISE Directors, to determine the appropriate process to follow.

2.1 Identifying the Appropriate ATU Process

Table 2-1 identifies the applicability/qualifying criteria for GSA’s ATU processes.

Table 2-1. GSA ATU Processes

ATU Process Applicability/Qualifying Criteria GSA Salesforce Platform (See Section 3.1)

• Salesforce Organizations that integrate into GSA’s Salesforce Force.com platform and are hosted on Salesforce.com's infrastructure.

• Applications developed for internal and external GSA use published on the GSA’s Salesforce Force.com platform.

Federalist Site Review (See Section 3.2)

• Sites hosted on the Federalist platform.

Robotic Process Automation

(RPA)

(See Section 3.3)

• Bots used to interact with GSA systems.

Google Extensions and Add-ons (See Section 3.4)

• Google Chrome browser extensions and add-ons for use within GSA.

Google Apps Scripts (See Section 3.5)

• Google Apps scripts for use within GSA.

U.S. General Services Administration 8

ATU Process Applicability/Qualifying Criteria Google Cloud Platform (GCP) Services (See Section 3.6)

• Google Cloud Platform (GCP) services not currently Federal Risk and Authorization Management Program (FedRAMP) approved.

AWS Services (See Section 3.7)

• Amazon Web Services (AWS) services not currently FedRAMP approved.

2.2 Identifying the Appropriate ATO Process

Table 2-2 identifies the applicability/qualifying criteria for GSA’s ATO processes.

Table 2-2. GSA ATO Processes

ATO Process Applicability/Qualifying Criteria

GSA Standard A&A Process

(See Section 5)

• All new and existing GSA information systems that do not fall under one of the other A&A processes.

Lightweight Security Authorization Process (See Section 4.2)

• New GSA application.

• Reside on infrastructures that have a GSA ATO concurred to by the CISO or a FedRAMP infrastructure as a service (IaaS) provisional ATO.

• Must be FIPS 199 Low or Moderate.

• Prior to pursuing a 90-day Limited Authorization to Operate

(LATO) the GSA CISO and AO must approve the use of the process.

Low Impact Software as a Service (LiSaaS) Solutions Authorization Process (See Section 4.3)

Cloud computing Software as a Service (SaaS) solutions that are implemented within GSA.

Will not be used in a permanent capacity at GSA (implemented for a limited duration).

Involve data already in the public domain or data is non-sensitive and determined to be FIPS 199 Low impact.

Could cause limited harm to GSA regardless of the consequence of an attack or compromise.

Have a cost for deployment not exceeding $100,000 annually.

Will not impact operations or business process should they experience a disruption in service or the inability to access the service.

Risk level of the LiSaaS solution will be determined through completion of a LiSaaS Solution Profile available on the IT Security Forms and Aids page.

GSA Agency FedRAMP Process (See Section 4.4)

• A CSP requesting GSA Agency sponsorship into FedRAMP.

• GSA accepts sponsoring the CSP.

• GSA determines CSP’s security authorization package will be considered FedRAMP compliant.

DocuSign Envelope ID: 5240F84D-A253-4B38-8D0C-81BF166DE4A2 file:///C:/Users/gabrielesmccormick/Downloads/insite.gsa.gov/node/166914 file:///C:/Users/gabrielesmccormick/Downloads/insite.gsa.gov/node/166914

U.S. General Services Administration 9

ATO Process Applicability/Qualifying Criteria

Moderate Impact Software as a Service (MiSaaS) Security Authorization Process (See Section 4.5)

• New GSA information systems.

• Reside on infrastructures that have, or are pursuing, a Federal

Risk and Authorization Management Program (FedRAMP) provisional ATO.

• Must be FIPS 199 Moderate.

• Prior to pursuing a MiSaaS ATO, the GSA CISO and AO must approve use of the process.

GSA Subsystem Process (See Section 4.6)

• Classified as a subsystem (and not a Salesforce application).

• Dependent upon resources provided by its supporting FISMA system.

• FIPS 199 Low or Moderate.

• FIPS 199 level may be equal to or below the level of the supporting FISMA system.

GSA Ongoing Authorization (OA) Program (See Section 4.7)

• The information system must have had all its NIST SP 800-53 security controls for its applicable FIPS 199 level, and any additional controls required by the GSA CISO assessed within the past 18 months and issued an ATO.

• The information system must have deployed GSA’s enterprise ISCM tools, based on applicable system requirements, defined within the GSA ISCM Enterprise Security Management Tools.

GSA Leveraged FedRAMP SaaS Solution Process (See Section 4.8)

• Leveraged SaaS must have a FedRAMP ATO.

• All customer responsibilities in the CSP’s Customer

Responsibility Matrix (CRM) must be addressed in a CRM SSPP.

• Must be FIPS 199 Low or Moderate.

3 ATU Process Summaries

Additional details about the GSA ATU processes listed in Table 3-1 are provided in the following sections.

3.1 GSA Salesforce Platform Process

Document Reference: CIO-IT Security-11-62: Salesforce Platform Security Implementation

Result: Salesforce Organization or Application ATU

Summary of Process: Specific to Salesforce Organizations and applications developed for internal and external GSA use published on GSA’s Salesforce Force.com platform.

Organizations and applications are approved for use based on implementation of NIST SP 800-53 controls, security configuration settings, user permissions, and completing the ATU process as detailed in CIO-IT Security-11-62.

Approval Process: After the ISSM accepts/approves the ATU package it becomes a part of the SSPP and allows the application to be added to the Salesforce inventory along with POA&Ms reflecting any identified vulnerabilities.

DocuSign Envelope ID: 5240F84D-A253-4B38-8D0C-81BF166DE4A2 https://docs.google.com/spreadsheets/d/1bkIntyt0GtEybqeIn7iI3E0mknjemiLiUVkgiuXFb-c/edit#gid=941618463 https://docs.google.com/spreadsheets/d/1bkIntyt0GtEybqeIn7iI3E0mknjemiLiUVkgiuXFb-c/edit#gid=941618463

U.S. General Services Administration 10

3.2 Federalist Site Process

Document Reference: CIO-IT Security-20-106: Federalist Site Review and Approval Process.

Result: Federalist Site ATU

• Summary of Process: As of April 1, 2023, no new requests for onboarding to the Federalist for hosting are being accepted. Site URLs currently hosted on the Federalist must be scanned in accordance with GSA’s parameter for NIST SP 800-53 control RA-5, Vulnerability Scanning, and as described in Section 8.3.4. The Federalist is in the process of being decommissioned with its ATO expiring on September 30, 2023.

Approval Process: No new approvals being processed.

3.3 RPA Process

Document Reference: CIO-IT Security-19-97: Robotic Process Automation (RPA) Security.

Result: RPA ATU

Summary of Process: Each request to approve a GSA RPA Bot must include a completed Privacy Threshold Assessment (PTA) to determine if a Privacy Impact Assessment (PIA) is required and a completed RPA Attributes Questionnaire, which includes questions/requirements based on the type of bot (i.e., simple, complex), rules of behavior, and interaction with systems. If an API is involved with the Bot process, the API information must be included in a Process Design Document (PDD) or a completed API Security Questionnaire.

Approval Process: After reviewing the questionnaire and required artifacts, the RPA ISSO may approve simple bots. After reviewing the questionnaire and required artifacts for complex bots, the RPA ISSO relays them to the RPA ISSM for approval.

3.4 Google Extensions and Add-ons

Document Reference: Google Extensions, Add-Ons and Browser Maintenance

Result: Addition to the lists of GSA Approved/Rejected Extensions or Add-ons

• Summary of Process: Each request for a Google Extension or Add-on must follow the process described at Google Add-On Request and Google Chrome Extension Request.

Requests for new extensions or add-ons (i.e., those not already approved or rejected) require a Service Catalog request.

• Approval Process: Service Catalog requests for new extensions and add-ons are routed to the Security Engineering Division (ISE) for review. After ISE completes the review, the approved/rejected lists are updated, and the requestor notified along with rationale if rejected.

DocuSign Envelope ID: 5240F84D-A253-4B38-8D0C-81BF166DE4A2 https://insite.gsa.gov/node/166914 https://insite.gsa.gov/employee-resources/information-technology/do-it-yourself/google-workspace/extensions-addons-and-browser-maintenance https://gsa.servicenowservices.com/sp/?id=list&table=u_chrome_extension&filter=&sys_id=&v= https://gsa.servicenowservices.com/sp/?id=list&table=u_google_add_on&filter=&sys_id=&v= https://insite.gsa.gov/employee-resources/information-technology/it-assistance-and-help-desk/service-catalog/requesting-google-addons?term=chrome%20extension https://insite.gsa.gov/employee-resources/information-technology/it-assistance-and-help-desk/service-catalog/google-chrome-extension-request

U.S. General Services Administration 11

3.5 Google Apps Scripts

Document Reference: GSA Order 2100.1, Chapter 4, Policy for Protect Function, Section ll.

Result: Google App Script ATU

Summary of Process: Internally developed scripts are implicitly allowed but require review by the ISE Division and may be restricted from use pending the results of the ISE review. Internally developed scripts must follow the GSA naming convention as described in GSA Order CIO 2100.1. Externally developed scripts are prohibited but may be allowed following OCISO review.

Approval Process: Use the Google App Script Approval Form to request approval for internal and external scripts. After ISE completes its review, the script will be approved or rejected, and the requestor notified along with the rationale if rejected.

3.6 GCP Services

• Document Reference: A CIO-IT Security Procedural Guide being developed, in the interim contact seceng@gsa.gov for information.

Result: GCP (Non-FedRAMP) Services ATU

Summary of Process: Specific to GCP services not currently FedRAMP approved.

Requestors must provide the following details to ISE in order to request GCP services:

GCP Service Type;

GCP Service Name;

Service Namespace;

Short Service Description; and Service Description.

Approval Process: Requests for GCP services to be reviewed should be submitted to seceng@gsa.gov. ISE will approve or reject the GCP service based on a security review of the service. Approved services may require additional usage conditions/restrictions for use at GSA.

3.7 AWS Services

Document Reference: ISE Master AWS Services Tracking List (see About This Sheet Tab)

Result: AWS (Non-FedRAMP) Services ATU

Summary of Process: Specific to AWS services not currently FedRAMP. Requestors must provide the following details to ISE in order to request AWS services:

AWS Service Description;

AWS Service Name; and Core Security Information (see ISE AWS Service Template for details)

Approval Process: Requests for AWS…