47QMCA26R0035_Access-Control_CIO-IT-Security-Rev-7_2025-02-10.pdf

Office of the Chief Information Security Officer

Revision 7

February 10, 2025

IT Security Procedural Guide:

Access Control (AC)

CIO-IT Security-01-07

Docusign Envelope ID: 1636BF85-DA76-4F0E-964C-4C3DA19ABB87

CIO-IT Security-01-07, Revision 7 Access Control (AC)

U.S. General Services Administration

VERSION HISTORY/CHANGE RECORD

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Revision 2 – January 30, 2008

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-06-30 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 Hummel/ Windelberg

Changes throughout the document to correspond with update of the current version of GSA CIO P 2100

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

Various

Revision 3 – April 1, 2015

1 Sitcharing Changes throughout to correspond with revisions made to CIO-IT- Security-06-30.

Updated to reflect correlation of the CIO-IT Security Guide and

CIO P 2100.1.

Throughout

2 Heard Changes the document to Implement

ADM O 5440.667

Updated to reflect CISO GSA IT responsibilities

Throughout

3 Heard/Mott Privacy access information included Appendix J controls included in table 1 as well as explained within the guide

Throughout

Revision 4 – May 8, 2017

1 Feliksa/Dean/ Klemens

Update to current format, style, and policies.

Updated to latest guide structure.

Revised to reflect updates to Federal policies, NIST documents, and GSA processes.

Throughout

Revision 5 – August 18, 2022

1 Dean/ McCormick/ Klemens

Revisions include:

● Updated to NIST SP 800-53, Revision 5 controls, GSA parameters, and implementation statements.

● Updated format, style, and content.

Align to current NIST and GSA guidance and GSA parameters.

New or substantively changed controls in Revision 5 are: AC-2, AC-2(1), AC-2(4), AC-2(5, AC-

2(13), AC-3(14), AC-4(4), AC-6(1),

AC-6(7), AC-7, AC-11, AC-17(4),

AC-18(3), AC-20, AC-20(2).

Throughout

Revision 6 - May 14, 2024

1 McCormick/ Klemens

Revisions include:

● Updated AC-08, System Use Notification, to align with OMB M- 23-22.

● Added OMB M-23-22 to references.

Align to current Federal and GSA guidance.

15-17

2 Klemens ● Various editorial updates. Throughout

Revision 7 - February 10, 2025

1 Normand/ Klemens/ Peralta

● Added mini tables to control sections to ease the determination of control applicability.

● Updated guidance for controls:

AC-18, AC-19, AC-20, AC-20(01),

and AC-20(02), to align with the Common Control Catalog (CCC), and removed AC-02(06) to align with GSA’s CTW.

Align to current Federal and GSA guidance.

Throughout

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

● Moved policy, references, and roles and responsibilities to appendices.

Approval

IT Security Procedural Guide: Access Control (AC), CIO-IT Security-01-07, Revision 7, is hereby approved for distribution.

Parimala Rao Acting GSA Chief Information Security Officer

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

U.S. General Services Administration i

Table of Contents

1 Introduction

1.1 Purpose

1.2 Scope

1.3 Policy

1.4 References

1.5 Access Control Roles and Responsibilities

2 Access Control Overview

2.1 What Are Access Controls

2.2 Why Access Controls Are Important

3 Implementation Guidance for AC Controls

3.1 AC-01 Access Control Policy and Procedures

3.2 AC-02 Account Management

3.3 AC-03 Access Enforcement

3.4 AC-04 Information Flow Enforcement

3.5 AC-05 Separation of Duties

3.6 AC-06 Least Privilege

3.7 AC-07 Unsuccessful Logon Attempts

3.8 AC-08 System Use Notification

3.9 AC-10 Concurrent Session Control

3.10 AC-11 Device Lock

3.11 AC-12 Session Termination

3.12 AC-14 Permitted Actions without Identification or Authentication

3.13 AC-17 Remote Access

3.14 AC-18 Wireless Access

3.15 AC-19 Access Control for Mobile Devices

3.16 AC-20 Use of External Systems

3.17 AC-21 Information Sharing

3.18 AC-22 Publicly Accessible Content

Appendix A: CSF Categories/Subcategories

Appendix B: Policy

Appendix C: References

Appendix D: Roles and Responsibilities

Appendix E: Access Controls Best Practices

Appendix F: Definitions

Table 3-1. Designation of AC Controls Table 3-2: AC Control Applicability Table 3-3: Example Mini Table Table A-1: CSF Categories/Subcategories and the AC Control Family

Figure 8-1: Linking to Privacy and Security Policies Example Figure 8-2: System Use Acknowledgement Example Figure E-1: Access Credentials Figure E-2: Account Creation and Termination

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

U.S. General Services Administration 1

1 Introduction

Implementing an effective access control program adhering to General Services Administration (GSA) Order CIO 2100.1, “GSA Information Technology (IT) Security Policy” and federal mandates is the best way to ensure the protection of GSA systems and resources from loss, misuse, disclosure, or impairment. An effective program carefully applies necessary controls to ensure that users are given access only to data and resources as needed and allowed by policy and authorization. Effective access control is implemented by a combination of personnel, physical, and logical practices, procedures, features, and mechanisms. This guide focuses on logical access controls as defined in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Revision 5, “Security and Privacy Controls for Information Systems and Organizations”, in the Access Control (AC) family of security controls. Physical access controls are covered in CIO-IT Security-12-64: Physical and Environmental Protection.

Personnel access controls are covered in CIO-IT Security-18-90: Common Control Catalog (CCC) and GSA’s personnel security policies.

Every GSA system across all Service and Staff Offices (SSOs) must follow the practices described in this guide. Any deviations from the security requirements established in CIO

2100.1 must be coordinated by the appropriate Information Systems Security Officer (ISSO) through the appropriate Information Systems Security Manager (ISSM) and approved by the Authorizing Official (AO). Any deviations, exceptions, or other conditions not following GSA policies and standards must be submitted using the Security Deviation Request Google Form.

The access control principles and practices described in this guide are based on guidance from NIST, including NIST SP 800-53, Revision 5. This guide provides an overview of access control, roles and responsibilities, NIST SP 800-53, Revision 5 access control requirements per Federal Information Processing Standards (FIPS) Publication 199, “Standards for Security Categorization of Federal Information and Information Systems”, security categorization level, and procedures for implementing these requirements.

Executive Order (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 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 GSA uses the NIST SP 800- 37, Revision 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy,” commonly referred to as the Risk Management Framework (RMF) as its foundation for managing risk, assessment and authorization (A&A) of systems, and the implementation of NIST SP 800-53, Revision 5 controls. Further information on how AC controls relate to the CSF is provided in Appendix A.

Note: The GSA is in the process of developing and updating CIO 2100.1 to align to CSF 2.0, once that process is completed, the next version of this guide will align to CSF 2.0.

1.1 Purpose

The purpose of this guide is to provide guidance for the AC controls identified in NIST SP 800- 53 and access control requirements specified in CIO 2100.1. The guide provides GSA Federal employees, contractors with significant security responsibilities (as identified in CIO 2100.1), and other IT personnel involved in implementing access control, guidance on the specific https://docs.google.com/forms/d/e/1FAIpQLSew38lCEj9FnE7Tmpi6ajMn700NYbe4fZtjo2Ol5MA9Of8eUw/viewform

U.S. General Services Administration 2 procedures they are to follow for implementing AC features and functions for systems under their purview.

1.2 Scope

The requirements outlined within this guide apply to and must be followed by all GSA Federal employees and contractors who are involved in implementing access control features and functions for GSA systems and information. All GSA systems must adhere to the requirements and guidance provided with regard to the procedures, processes, and methods for implementing access control as described in this guide. Per CIO 2100.1, a system is a system used or operated:

● by the GSA; or

● on behalf of the GSA by a contractor of GSA or by another organization.

1.3 Policy

Appendix B contains the CIO 2100.1 policy statements regarding access control, privilege management, and user account management.

1.4 References

Appendix C provides links to references used throughout this guide.

1.5 Access Control Roles and Responsibilities

Appendix D provides a listing of the roles and responsibilities related to implementing, administering, and managing access control at the GSA.

2 Access Control Overview

2.1 What Are Access Controls

Access control, as it relates to this guide, pertains to granting or denying logical access to a resource, such as data/information or a system. Access is typically gained by an individual (a user of the resource), for example a GSA employee or a contractor; sometimes individuals are aggregated into groups. It is also possible to have automated system-to-system access, known as a system interconnection.

Identification, authentication, and authorization are key terms regarding access control. Each user of a resource should have a unique identifier (e.g., user ID). In some situations, access for anonymous users may be considered as an option. However, this type of access must be based on a sound risk management decision, with documented controls and approved by the AO of the resource. Authentication involves verifying a user (or device) identity through mechanisms such as Personal Identity Verification (PIV) cards, passwords, etc. More details about identification and authentication are available in CIO-IT Security-01-01: Identification and Authentication (I&A) determines what the individual or device is allowed and is not allowed to do with the resource, such as view the resource but not delete it.

An access control list (ACL) specifies what access rights are permitted to a user. Groups of users may also be classified by assigned and documented roles and the access rights may be

U.S. General Services Administration 3 assigned to the roles; in role-based access controls, users obtain only the rights assigned to the group (role) as a whole.

2.2 Why Access Controls Are Important

Employing effective access controls based on sound risk management decisions protects GSA resources from internal and external threats and provides a level of assurance that the agency can successfully perform its mission.

Effective access controls also improve the overall security posture of the GSA by:

● Ensuring the confidentiality, integrity, and availability of IT resources and data;

● Enhancing the ability to determine where a breach has occurred;

● Creating greater individual accountability for personnel;

● Limiting user access only to needed information required to perform specific responsibilities (i.e., need-to-know/need-to-share, least privilege access);

● Limiting access to sensitive resources (e.g., financial records, personally identifiable information (PII), security software programs, or data centers).

● Ensuring the GSA complies with Federal regulations and mandates.

Without effective access controls, the GSA increases the possibility of information loss or theft, regardless of its sensitivity, and limits its ability to control who has access to information.

Confidentiality, integrity, and availability of information are also an issue when access controls are not properly implemented. If a security breach affects one area of the network, and there are insufficient access controls present to contain or mitigate the breach, its reach may be expanded, affecting additional systems, components, and data. Improperly implemented access controls can result in negative consequences, ranging from a lack of information being available to compromised data integrity and/or lack of confidentiality. There is also a possibility of a negative financial impact due to the response to or recovery from a breach. Furthermore, legal issues may also occur for not complying with laws and regulations, resulting in regulatory admonishment, fines and more.

Ineffective access controls also hinder accountability for the actions of users of an IT resource, whether it is a system or its information. Appendix E provides information on access control best practices.

3 Implementation Guidance for AC Controls

In the implementation guidance text, the GSA-defined parameter settings included in the control requirements are in blue text and offset by brackets. As stated in Section 1.2, Scope, the requirements outlined within this guide apply to all GSA systems and must be followed by all GSA Federal employees and contractors involved in managing access control for GSA information systems and data. The GSA implementation guidance stated for each control applies to personnel and/or the information systems operated on behalf of the GSA. Any additional instructions or requirements for vendor/contractor systems will be included in a Vendor/Contractor System-Specific Expectations portion of the appropriate control section.

Table 3-1 identifies the designation of AC controls as Common, Hybrid, or System-Specific controls for Federal and Contractor systems. Effectively, common controls are provided by the GSA at the enterprise level or by one of GSA’s Major Information Systems (e.g., General

U.S. General Services Administration 4

Support System), system-specific controls are implemented at the system level, and hybrid controls have shared responsibilities. CIO-IT Security 18-90, the CCC, describes the GSA enterprise-wide controls and outlines the responsible parties for implementing them.

Table 3-1. Designation of AC Controls

System Type Federal Contractor

Common

AC-01, AC-02(05), AC-19(05), AC-

20(02)

AC-02(05), AC-19(05), AC-20(02)

Hybrid AC-19 AC-01, AC-19

System-Specific

AC-02, AC-02(01), AC-02(02), AC-

02(03), AC-02(04), AC-02(07), AC-

02(11), AC-02(12), AC-02(13), AC-03,

AC-03(14), AC-04, AC-05, AC-06, AC-

06(01), AC-06(02), AC-06(03), AC-

06(05), AC-06(07), AC-06(09), AC-

06(10), AC-07, AC-08, AC-10, AC-11,

AC-11(01), AC-12, AC-14, AC-17, AC-

17(01), AC-17(02), AC-17(03), AC-

17(04), AC-18, AC-18(01), AC-18(03),

AC-18(04), AC-18(05), AC-20, AC-

20(01), AC-22

AC-02, AC-02(01), AC-02(02), AC-02(03),

AC-02(04), AC-02(07), AC-02(11), AC-

02(12), AC-02(13), AC-03, AC-03(14),

AC-04, AC-05, AC-06, AC-06(01), AC-

06(02), AC-06(03), AC-06(05), AC-06(07),

AC-06(09), AC-06(10), AC-07, AC-08, AC-

10, AC-11, AC-11(01), AC-12, AC-14, AC-

17, AC-17(01), AC-17(02), AC-17(03),

AC-17(04), AC-18, AC-18(01), AC-18(03),

AC-18(04), AC-18(05), AC-20, AC-20(01),

AC-21, AC-22

Table 3-2 identifies GSA’s AC control applicability at the FIPS 199 Low, Moderate, and High levels, and for GSA’s Lightweight (LATO) and Moderate Impact Software-as-a Service (MiSaaS) authorization processes.

Table 3-2: AC Control Applicability

FIPS 199

Level/A&A Process

Applicable Controls

Low

AC-01, AC-02, AC-03, AC-07, AC-08, AC-14, AC-17, AC-18, AC-19, AC-20, AC-

Moderate

AC-01, AC-02, AC-02(01), AC-02(02), AC-02(03), AC-02(04), AC-02(05), AC-

02(13), AC-03, AC-03(14)^, AC-04, AC-05, AC-06, AC-06(01), AC-06(02), AC-

06(05), AC-06(07), AC-06(09), AC-06(10), AC-07, AC-08, AC-11, AC-11(01), AC-

12, AC-14, AC-17, AC-17(01), AC-17(02), AC-17(03), AC-17(04), AC-18, AC-

18(01), AC-18(03), AC-19, AC-19(05), AC-20, AC-20(01), AC-20(02), AC-21, AC-

High

AC-01, AC-02, AC-02(01), AC-02(02), AC-02(03), AC-02(04), AC-02(05), AC-

02(11), AC-02(12), AC-02(13), AC-03, AC-03(14)^, AC-04, AC-04(04), AC-05, AC-

06, AC-06(01), AC-06(02), AC-06(03), AC-06(05), AC-06(07), AC-06(09), AC-

06(10), AC-07, AC-08, AC-10, AC-11, AC-11(01), AC-12, AC-14, AC-17, AC-

17(01), AC-17(02), AC-17(03), AC-17(04), AC-18, AC-18(01), AC-18(03), AC-

18(04), AC-18(05), AC-19, AC-19(05), AC-20, AC-20(01), AC-20(02), AC-21, AC-

LATO AC-02, AC-03, AC-03(14)^, AC-06(05), AC-06(09)

MiSaaS

AC-02, AC-02(07), AC-03, AC-03(14)^, AC-05, AC-06, AC-06(02), AC-06(09), AC-

08, AC-12, AC-21

^-control is applicable if PII is stored, processed, or transmitted

U.S. General Services Administration 5

For readers’ ease of use, “mini tables” (see Table 3-3) that contain control/enhancement designation and applicability information are provided at the end of control statements for each AC control. The tables allow readers to see if a control/enhancement is applicable at their system’s FIPS Level/A&A process and if it is common (C), Hybrid (H), or system specific (S), eliminating the need to refer back to Tables 3-1 and 3-2 for this information.

Table 3-3: Example Mini Table

Low Mod High LATO MiSaaS Federal Contractor

Control ID ✔ ✔ ✔ C H

3.1 AC-01 Access Control Policy and Procedures

Control:

a. Develop, document, and disseminate to [personnel with IT security responsibilities as defined in GSA Order CIO 2100.1]:

1. [Organization-level] access control policy that:

(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the access control policy and the associated contingency planning controls;

b. Designate an [CISO] to manage the development, documentation, and dissemination of the access control policy and procedures; and

c. Review and update the current access control:

1. Policy [annually, as part of CIO 2100.1 update] and following [changes to Federal or

GSA policies, requirements, or guidance]; and

2. Procedures [at least every three (3) years] and following [changes to Federal or GSA policies, requirements, or guidance].

Low Mod High LATO MiSaaS Federal Contractor

AC-01 ✔ ✔ ✔ C H

Common Control Implementation:

The GSA access control policy is defined in GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy,” which addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance regarding access control for GSA systems. This policy is disseminated GSA-wide via GSA’s InSite centralized agency Directives Library website.

Access control procedures are documented in CIO-IT Security-01-07: Access Control. This guide is disseminated GSA-wide via GSA’s InSite centralized agency IT Security Procedural Guides website.

Per CIO 2100.1, the CISO is responsible for managing the development and publishing of all security policies and IT security procedural guides.

U.S. General Services Administration 6

The GSA OCISO is responsible for reviewing and updating CIO 2100.1 annually and following changes to Federal or GSA policies, requirements, or guidance. CIO-IT Security-01-07 every three years and following changes to Federal or GSA policies, requirements, or guidance.

Federal System System-Specific Expectation:

None, common control.

Vendor/Contractor System-Specific Expectation:

Vendors/Contractors may defer to the GSA policy and guide or implement their own access control policies and procedures which comply with GSA’s requirements with the approval of the Authorizing Official (AO).

3.2 AC-02 Account Management

Control:

a. Define and document the types of accounts allowed and specifically prohibited for use within the system;

b. Assign account managers;

c. Require [GSA SSO or Contractor recommended prerequisites and criteria (based on defined user role(s) matrix in GSA SSPP Template Section 9: Types of Users) as approved by the CISO and AO] for group and role membership;

d. Specify:

1. Authorized users of the system;

2. Group and role membership; and

3. Access authorizations (i.e., privileges) and [the following attributes as defined in the user role(s) matrix in GSA SSPP Template Section 9: Types of Users - Internal or External;

Privileged (P), Non-Privileged (NP), or No Logical Access (NLA); Sensitivity Level;

Authorized Privileges; Functions Performed; MFA Authentication Method] for each account;

e. Require approvals by [designated account managers as specified in AC-02.b] for requests to create accounts;

f. Create enable, modify, disable, and remove accounts in accordance with [CIO-IT Security- 01-01, Identification and Authentication, CIO-IT Security-01-07, Access Control, and GSA-defined procedures or conditions (as applicable)];

g. Monitor the use of accounts;

h. Notify account managers and [System Owner, System/Network Administrator, and/or ISSO] within:

1. [14 days] when accounts are no longer required;

2. [14 days] when users are terminated or transferred; and

3. [14 days] when system usage or need-to-know changes for an individual;

i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. [Role privileges identified in GSA SSPP Section 9: Types of Users];

j. Review accounts for compliance with account management requirements [annually];

k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

l. Align account management processes with personnel termination and transfer processes.

Control Enhancements:

U.S. General Services Administration 7

(01) Account Management | Automated System Account Management. Support the management of system accounts using [GSA SSO or Contractor recommended automated mechanisms as approved by the GSA CISO and AO];

(02) Account Management | Automated Temporary and Emergency Account Management.

Automatically [disable] temporary and emergency accounts after [no more than 90 days];

(03) Account Management | Disable Accounts. Disable accounts within [30 days for GSA users; for non-GSA users as determined by the System Owner and approved by GSA CISO and AO] when the accounts:

(a) Have expired;

(b) Are no longer associated with a user or individual;

(c) Are in violation of organization policy; or

(d) Have been inactive for [90 days for GSA users; for non-GSA users as determined by the System Owner and approved by the GSA CISO and AO].

(04) Account Management | Automated Audit Actions. Automatically audit account creation, modification, enabling, disabling, and removal actions;

(05) Account Management | Inactivity Logout. Require that users log out when [they have completed their workday];

(07) Account Management | Privileged User Accounts

(a) Establish and administer privileged user accounts in accordance with [a role-based or attribute-based access schema];

(b) Monitor privileged role or attribute assignments;

(c) Monitor changes to roles or attributes;

(d) Revoke access when privileged role or attribute assignments are no longer appropriate.

(11) Account Management | Usage Conditions. Enforce [GSA SSO or Contractor recommended circumstances and/or usage conditions to be approved by the GSA CISO and AO] for [GSA SSO or Contractor recommended system accounts to be approved by the GSA CISO and AO].

(12) Account Management | Account Monitoring for Atypical Usage.

(a) Monitor system accounts for [atypical times of day and originating IP address for a known privileged account user that are inconsistent with normal usage patterns]; and

(b) Report atypical usage of system accounts to [the ISSO and the GSA OCISO].

(13) Account Management | Disable Accounts for High-Risk Individuals. Disable accounts of individuals posing a significant risk within [24 hours] of discovery of [account compromise relating to an incident or Insider Threat event (per the OMA Insider Threat Program) as directed but the GSA CISO, AO, and/or GSA Incident Response Team].

Low Mod High LATO MiSaaS Federal Contractor

AC-02 ✔ ✔ ✔ ✔ ✔ S S

AC-02(01) ✔ ✔ S S

AC-02(02) ✔ ✔ S S

AC-02(03) ✔ ✔ S S

AC-02(04) ✔ ✔ S S

AC-02(05) ✔ ✔ C C

AC-02(07) ✔ S S

AC-02(11) ✔ S S

U.S. General Services Administration 8

Low Mod High LATO MiSaaS Federal Contractor

AC-02(12) ✔ S S

AC-02(13) ✔ ✔ S S

Common Control Implementation:

AC-02(05) is a policy-based Common Control provided by GSA Order CIO 2104.1, “GSA Information Technology (IT) General Rules of Behavior” Category Access - (3) Logoff and shutdown your GSA workstation at the end of the workday.

Inactivity logout is behavior- or policy-based and requires users to take physical action to log out when they expect to be inactive longer than a defined period of time. A system’s automatic enforcement of user inactivity logout is documented by AC-11.

System-Specific Expectations:

The focus of AC-02 is maintaining control over who is able to access GSA system resources to protect against internal and external threats. The first step in this process is to identify the types of users for the system, this is documented in Section 9.4 of GSA’s SSPP templates. Account types documented therein are allowed, any account that is not documented is not allowed (prohibited), e.g., group, shared accounts. Account managers for systems are designated by the System Owner in collaboration with the data owner. Access must be requested for any individual and their need-to-know/need-to-share documented in order for an account to be provided. As specified in the control parameter for part c of the control any prerequisites and criteria for role membership and associated privileges must be documented and approved.

GSA’s default access to any resource is DENY. ALLOW access is granted based on the approved role and privileges an account for a user is provisioned when an account is created.

When account requests are approved, the ISSO and the appropriate administrators are responsible for establishing accounts with unique account identifiers; shared accounts are not allowed.

Establishing, maintaining, and removing access rights to GSA systems in accordance with GSA-defined procedures must be conducted by system/network administrators, in conjunction with system and Data Owners, ISSMs and ISSOs. All allowed accounts must be documented and defined and include group and role memberships and access authorizations. Account usage is monitored by tracking activity, details on monitoring activity (i.e., auditing/logging) can be found in CIO-IT Security-01-08: Audit and Accountability (AU).

Supervisors of users must notify account managers and System Owners, system/network administrators, and ISSOs within two weeks of when an account change is required. For example, if an individual transfers, terminates, or their relationship to GSA or to a GSA system changes under any circumstances, accounts and authorization rights must be reviewed and modifications, disablement, or revocation of their accounts made, as appropriate.

On an annual basis ISSOs must coordinate with System Owners and Data Owners to validate continued need for an individual’s account to access a system as well as the roles and privileges for the individual/account. The ISSO must coordinate with administrators and account managers, as appropriate, when modifications are required based on the review. Similarly, when an individual leaves a group, any group account authenticators must be changed to ensure that former group members do not retain access. CIO-IT Security-03-23: Termination and Transfer contains information on handling personnel terminations and transfers.

U.S. General Services Administration 9

For AC-02(01), systems must manage accounts using automated mechanisms, the approval of which is based on the assessment conducted as part of the system’s ATO process. For example, the use of automated mechanisms to identify inactive accounts is one use case.

For AC-02(02), systems must disable temporary and emergency accounts after no more than 90 days. For example, if possible, any emergency or temporary account should be set to automatically expire in 90 days, otherwise a manual process will have to be established.

For AC-02(03), GSA user accounts that are no longer associated with a user, are expired, are in violation of GSA policy, or have been inactive for 90 days must be disabled within 30 days. For non-GSA users the time period for disablement can be determined by the System Owner, but it must be approved by the GSA CISO and AO. If appropriate, restored access for disabled accounts may be requested by the user.

For AC-02(04), system account actions (creation, modification, enabling, disabling, removal) must be automatically audited. Additional information on auditing can be found in CIO-IT Security-01-08.

For AC-02(07), systems following the MiSaaS process must follow a role-based or attribute-based access scheme to establish and administer privileged user accounts. A process must be established to monitor role and attribute assignments and changes to them. Access must be revoked when privileged roles or attribute assignments are no longer needed. For example, when an individual’s role changes, the role assignment and/or attributes must reflect and change between the previous and new role.

For AC-02(11), systems must enforce any circumstances or usage conditions for specified accounts that have been approved by the GSA CISO and AO. For example, if a specific account is only to be used at certain times of the month, the system should be configured to only allow its use during that time.

For AC-02(12), privileged accounts must be monitored for atypical usage (e.g., time of day, originating IP address) that differ from that account’s normal patterns. Since such activity could be an indicator of an insider or external threat, this behavior must be reported to the ISSO and the GSA OCISO (i.e., Incident Response Team).

For AC-02(13), system accounts belonging to individuals who pose a significant risk must be disabled within 24 hours after it has been discovered that there has been an incident related to an account compromise or a credible insider threat has been identified per GSA’s Insider Threat Program. Accounts should only be disabled as directed by the GSA CISO, AO, and/or Incident Response Team.

3.3 AC-03 Access Enforcement

Control: Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Control Enhancements:

(14) Access Enforcement | Individual Access. Provide [a self service mechanism or use GSA's Privacy Act Request for Access process] to enable individuals to have access to

Docusign Envelope ID: 1636BF85-DA76-4F0E-964C-4C3DA19ABB87 https://insite.gsa.gov/organizations/staff-offices/office-of-mission-assurance/divisions-program-offices/personnel-security-division/insider-threat-program https://insite.gsa.gov/organizations/staff-offices/office-of-mission-assurance/divisions-program-offices/personnel-security-division/insider-threat-program

U.S. General Services Administration 10 the following elements of their personally identifiable information: [as defined in the GSA PII Rules Matrix].

Low Mod High LATO MiSaaS Federal Contractor

AC-03 ✔ ✔ ✔ ✔ ✔ S S

AC-03(14) ✔^ ✔^ ✔^ ✔^ S S

^-control is applicable if PII is stored, processed, or transmitted

System-Specific Guidance:

For AC-03, GSA systems must be configured to enforce the access that users and processes have to system resources (e.g., devices, files, records). Systems are responsible for administering the user identification, authentication, and authorization scheme used in the system. Authenticators must follow GSA policies per GSA Orders CIO 2100.1, CIO 2183.1, “Enterprise Identity, Credential, and Access Management (ICAM) Policy,” and CIO-IT Security- 01-01.

For AC-03(14), systems with PII must provide users with the ability to access personally identifiable information about themselves to understand how their information is being used and to ensure it is accurate. As stated in the control parameter, GSA PII Rules Matrix identifies PII for the GSA and either a self service mechanism provided by the system or GSA’s Privacy Act Request Access process can be used to satisfy the control requirement.

3.4 AC-04 Information Flow Enforcement

Control: Enforce approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Web Services Security (WS Security), WS-Security Policy, WS Trust, WS Policy Framework, Security Assertion Markup Language (SAML), and extensible Access Control Markup Language (XACML)].

Control Enhancements:

(04) Information Flow Enforcement | Flow Control of Encrypted Information. Prevent encrypted information from bypassing [any information flow control mechanisms] by [decrypting the information, blocking the flow of the encrypted information, or by terminating communications sessions attempting to pass encrypted information].

Low Mod High LATO MiSaaS Federal Contractor

AC-04 ✔ ✔ S S

AC-04(04) ✔ S S

System-Specific Guidance:

For AC-04, the control of information flow within a system and between systems must be controlled. Information flow must be documented in the system SSPP. Controlling the flow of information between GSA systems and external systems using persistent connections is covered in interconnection security agreements specified in control CA-03, additional information is available in CIO-IT Security-06-30: Managing Enterprise Cybersecurity Risk and CIO-IT Security-24-125: Managing Information Exchange Agreements.

Docusign Envelope ID: 1636BF85-DA76-4F0E-964C-4C3DA19ABB87 https://docs.google.com/spreadsheets/d/1Yb9I9C3qCee8dnkVIIUqIZgrWsA1DoW0xYF2yPjgz0I/edit#gid=1521803081 https://docs.google.com/spreadsheets/d/1Yb9I9C3qCee8dnkVIIUqIZgrWsA1DoW0xYF2yPjgz0I/edit#gid=1521803081 https://docs.google.com/spreadsheets/d/1Yb9I9C3qCee8dnkVIIUqIZgrWsA1DoW0xYF2yPjgz0I/edit#gid=1521803081

U.S. General Services Administration 11

Information flow control within a system and interconnected systems should be governed by the frameworks and services in the control parameter. Flow enforcement is also provided by the architectures of the systems and their networks, i.e., firewall rules, router policies, etc.

For AC-04(04), systems must employ mechanisms that preclude encrypted information from circumventing flow control mechanisms. For example, if all web traffic must be visible for inspection, encrypted web traffic must either be decrypted and inspected, blocked if decryption is not possible, terminating the connection.

3.5 AC-05 Separation of Duties

Control:

a. Identify and document [GSA SSO or Contractor recommended duties of individuals requiring separation, to be approved by the GSA CISO and AO];

b. Define system access authorizations to support separation of duties.

Low Mod High LATO MiSaaS Federal Contractor

AC-05 ✔ ✔ ✔ S S

System-Specific Guidance:

For AC-05, the System Owner must ensure separation of duties which ensures that no single user has complete control over a single critical process (i.e., enough authorizations to perform fraudulent actions or inflict other damage). The roles and privileges for users are defined in the system’s SSPP in Section 9.4, Types of Users. This section defines the authorized privileges (system access) based on functions performed, which supports separation of duties. The System Owner, ISSO, and ISSM sign the SSPP, effectively approving the separation of duties described therein. The CISO and AO approve the separation of duties when the authorization package is approved by issuing an ATO for the system.

3.6 AC-06 Least Privilege

Control: Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

Control Enhancements:

(01) Least Privilege | Authorize Access to Security Functions. Authorize access for [any individual or role] to:

(a) [GSA SSO or Contractor recommended security functions (deployed in hardware, software, and firmware) approved by the GSA CISO and AO]; and

(b) [security-relevant information as approved by the GSA CISO and AO].

(02) Least Privilege | Non-Privileged Access for Non-Security Functions. Require that users of system accounts (or roles) with access to [all security functions (examples of security functions include but are not limited to: establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters, system programming, system and security administration, other privileged functions)], use non-privileged accounts or roles, when accessing non-security functions.

U.S. General Services Administration 12

(03) Least Privilege | Network Access to Privileged Commands. Authorize network access to [all privileged commands (i.e., any command requiring privileges above a standard user)] only for [GSA SSO or Contractor recommended compelling operational needs as approved by the GSA CISO and AO] and document the rationale for such access in the security plan for the system.

(05) Least Privilege | Privileged Accounts. Restrict privileged accounts on the system to [GSA SSO or Contractor recommended employees and contractors as approved by the GSA CISO and AO];

(07) Least Privilege | Review of User Privileges. FIPS 199 Moderate and High systems

(a) Review [annually as part of the annual account review (per AC-02j)] the privileges assigned to [all roles and users] to validate the need for such privileges; and

(b) Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

(09) Least Privilege | Log Use of Privileged Functions. Log the execution of privileged functions.

(10) Least Privilege | Prohibit Non-Privileged Users from Executing Privileged Functions.

Prevent non-privileged users from executing privileged functions.

Low Mod High LATO MiSaaS Federal Contractor

AC-06 ✔ ✔ ✔ S S

AC-06(01) ✔ ✔ S S

AC-06(02) ✔ ✔ ✔ S S

AC-06(03) ✔ S S

AC-06(05) ✔ ✔ ✔ S S

AC-06(07) ✔ ✔ S S

AC-06(09) ✔ ✔ ✔ ✔ S S

AC-06(10) ✔ ✔ S S

System-Specific Guidance:

For AC-06, assigned authorizations must follow the concept of “least privilege,” limiting users to only those resources necessary to satisfy organizational mission/business needs. Granting permissions beyond this scope increases the attack surface of the system, allowing users to operate in unwanted ways. When additional privileges are granted, they should be in effect for the shortest duration necessary. Appendix E contains additional information on best practices regarding least privilege.

For AC-06(01), similar to the base AC-06 control, access to security functions should be identified in Section 9.4 of the SSPP and the approvals are based on approving the SSPP and the ATO of the system. Access to any security functions not addressed in Section 9.4 must be fully explained in the SSPP when AC-06(01) is addressed.

Security-relevant information includes, but is not limited to, filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, and access control lists. Authorized personnel include security administrators, system administrators, system security officers, system programmers, and other privileged users.

Security-relevant functions include, but are not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, U.S. General Services Administration 13 and setting intrusion detection parameters, system programming, system and security administration, and other privileged functions.

For AC-06(02), privileged users/roles must use non-privileged accounts/roles when performing non-security functions.

For AC-06(03), systems must authorize network access to commands that require privileges above a standard user only when needed based on compelling operational needs of the system and its business function. The rationale for the network access to such privileges and the rationale for permitting such access must be described in the SSPP with approvals by the CISO and AO being provided when an ATO is signed based on an assessment of the control.

For AC-06(05), systems following the LATO process must provide privileged accounts (e.g., system administrator) only to those individuals approved by the GSA CISO and AO. The approval is granted by issuing an ATO based on an assessment that indicates this control has been met. In addition, as described in Appendix E, the level of investigation performed on an individual is based on the level of access that individual will need to a system.

For AC-06(07), the review of the account privileges assigned to all roles/users must be included in the annual review of accounts specified in control AC-02.j. This review is to validate existing privileges or to adjust privileges when they are no longer needed by the user or role.

For AC-06(09), systems must log the execution of privileged functions. Additional information regarding the auditing/logging of events for GSA systems is covered in CIO-IT Security-01-08.

For AC-06(10), systems must prevent non-privileged users from executing privileged functions.

Effectively, this is accomplished by ensuring that non-privileged users, i.e., users that do not have a need to perform privileged functions based on their role or business need and/or users who do not have the required investigation for executing privileged functions are not granted them when they are assigned their account or role.

3.7 AC-07 Unsuccessful Logon Attempts

Control:

a. Enforce a limit of [not more than ten (10) failed access attempts] consecutive invalid logon attempts by a user during a [30-minute time period]; and

b. Automatically [lock the account/node for 30 minutes] when the maximum number of unsuccessful attempts is exceeded.

Low Mod High LATO MiSaaS Federal Contractor

AC-07 ✔ ✔ ✔ S S

System-Specific Guidance:

All GSA systems must enforce a limit on unsuccessful access attempts (not more than 10 failed attempts within a 30-minute period) and lock the account/node for 30 minutes when the maximum number of unsuccessful attempts is exceeded.

U.S. General Services Administration 14

3.8 AC-08 System Use Notification

Control:

a. Display [a system use notification message or banner as defined in GSA CIO Order 2100.1)] to users before granting access to the system that provides privacy and security notices consistent with applicable Federal laws, Executive Orders, directives, regulations, policies, standards, and guidance and state that:

1. Users are accessing a U.S. Government system;

2. System usage may be monitored, recorded, and subject to audit;

3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties;

and

4. Use of the system indicates consent to monitoring and recording;

b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and

c. For publicly accessible systems:

1. Display system use information [when accessed via logon interfaces with human users], before granting further access to the publicly accessible system;

2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and

3. Include a description of the authorized uses of the system.

Low Mod High LATO MiSaaS Federal Contractor

AC-08 ✔ ✔ ✔ ✔ S S

System-Specific Guidance:

Publicly Accessible Systems

In accordance with Office of Management and Budget (OMB) M-23-22, for publicly accessible systems, rather than actively presenting a warning banner to users on GSA sites, those websites, systems, and applications may satisfy this control by linking to GSA.gov’s Privacy and Security policies. Figure 8-1 is an acceptable method of linking to the policies. No additional System Use Notification is required. GSA’s publicly accessible URLs are identified as ‘External’ in GSA’s URL inventory.

Figure 8-1: Linking to Privacy and Security Policies Example

For instances where users register on a site, system use language should be presented with the terms and conditions for the user to agree to. Figure 8-2 is an example where users are presented the Rules of Use at account creation. This method satisfies the acknowledgement

Docusign Envelope ID: 1636BF85-DA76-4F0E-964C-4C3DA19ABB87 https://www.gsa.gov/website-information/website-policies#privacy https://www.gsa.gov/website-information/website-policies#privacy

U.S. General Services Administration 15 required from users that the system they are using will be subject to monitoring and they recognize that they are accessing a federal government system every subsequent time they login.

Figure 8-2: System Use Acknowledgement Example

Non-publicly Accessible Systems

All non-publicly accessible GSA systems must display the authorized GSA system use notification message (as provided in CIO 2100.1) before granting system access to persons.

The system must require the person to acknowledge the system use notification before they can take additional actions on, or further access the system. Any System Use Notification message/banner that varies from GSA’s approved banner must be documented in the systems SSPP and approved by the ISSM. For example, Contractor systems may have a banner that is worded differently, however all parts of the control must be addressed.

All GSA internal systems must display the authorized GSA system use notification message (as provided in CIO 2100.1) before granting system access. The system must require the user to acknowledge the system use notification before they can take additional actions on, or further access the system. The authorized use notification includes allowed adjustments for publicly accessible systems.

3.9 AC-10 Concurrent Session Control

Control: Limit the number of concurrent sessions for each [user] to [GSA SSO or Contractor recommended number to be approved by GSA CISO and AO].

Low Mod High LATO MiSaaS Federal Contractor

AC-10 ✔ S S

U.S. General Services Administration 16

System-Specific Guidance:

For AC-10, each GSA system must limit the number of concurrent sessions for any user to a number that has been documented in the SSPP and approved by the GSA CISO and AO.

3.10 AC-11 Device Lock

Control:

a. Prevent further access to the system by [initiating a device lock after 15 minutes of inactivity;

requiring the user to initiate a device lock before leaving the system unattended]; and

b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.

Control Enhancements:

(01) Device Lock | Pattern-Hiding Displays. Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

Low Mod High LATO MiSaaS Federal Contractor

AC-11 ✔ ✔ S S

AC-11(01) ✔ ✔ S S

System-Specific Guidance:

For AC-11, systems must automatically lock a user session after 15 minutes of inactivity. Users are required to initiate a device lock when stopping work and temporarily moving away from the immediate vicinity of the system. The user must reestablish access by providing appropriate identification and authentication before the device becomes unlocked. Device locks are temporary safeguards and not an acceptable substitute for logging out of a system.

For AC-11(01), systems’ device locks must use a publicly viewable image (static or dynamic) to conceal the information visible on the display when the device was locked.

3.11 AC-12 Session Termination

Control: Automatically terminate a user session after [

(1) 30 minutes of inactivity

(2) the following timeframes, regardless of user activity:

a. Thirty (30) days for systems at AAL1

b. Twelve (12) hours for systems at AAL2 and AAL3.

Note: AAL2 and AAL3 require Two Factor Authentication].

Low Mod High LATO MiSaaS Federal Contractor

AC-12 ✔ ✔ ✔ S S

System-Specific Guidance:

For AC-12, systems must terminate a user session after 30 minutes of inactivity. Authentication assurance levels (AALs) for systems are determined when a system completes a Digital Identity Acceptance Statement as part of its development and authorization processes. Systems at AAL1 must terminate user sessions after 30 days regardless of user activity, and at AAL2 and AAL3 after 12 hours.

U.S. General Services Administration 17

3.12 AC-14 Permitted Actions without Identification or Authentication

Control:

a. Identify [no user actions] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and

b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.

Low Mod High LATO MiSaaS Federal Contractor

AC-14 ✔ ✔ ✔ S S

System-Specific Guidance:

For AC-14, systems must prohibit any user action from being performed on the system without identification or authentication.