47QMCB26R0002_Attachment B Security-Engineering-Architecture-Reviews-CIO-IT Security-19-95-Rev-2_2025-12-09.pdf

U.S. General Services Administration

Revision 2

September 24, 2025

IT Security Procedural Guide:

Security Engineering

Architecture Reviews

CIO-IT Security-19-95

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188

CIO-IT Security-19-95, Revision 2 Security Engineering Architecture Reviews

VERSION HISTORY/CHANGE RECORD

Change Number

Person Posting Change

Change Reason for Change Page

Number of Change

Initial Release – September 12, N/A ISE New guide created. N/A N/A

1 Gillikin Updates and comments. Updates before initial publication. Throughout

Revision 1 – September 30, 2022

1 ISE Updated content throughout. Scheduled update. Throughout

2 McCormick/ Klemens

Edited content and updated format. Align with the current version of GSA Procedural Guide formatting.

Throughout

Revision 2 – September 24, 2025

1 Normand/ Klemens/ Peralta

Updates included:

● Moved policy and roles and responsibilities sections to appendices.

● Updated guidance in table 2-1, table 2-5 and table 2-6.

● Added 508 compliance as a checklist item during reviews

● Edited content and updated format.

Align with current GSA guidance and update to current GSA Guide format and style.

Throughout

Approval

IT Security Procedural Guide: Security Engineering Architecture Reviews, CIO-IT Security 19- 95, Revision 2, is hereby approved for distribution.

Joseph Hoyt Acting GSA Chief Information Security Officer

For questions concerning the Security Engineering Architecture Reviews, contact: GSA Office of the Chief Information Security Officer (OCISO), Security Engineering Division (ISE) at SecEng@gsa.gov.

For questions concerning GSA Policy and Compliance, 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 Roles and Responsibilities

2 Security Architecture Review

2.1 Security Architecture Workflow

2.2 Security Architecture Workflow Steps

3 Ongoing Security Consulting/Security Engineering Support

3.1 New Technology Review/Approval

Appendix A: GSA CIO 2100.1 Policy Statements Regarding Security Engineering Architecture Reviews

Appendix B: Roles and Responsibilities

Appendix C: AWS Architecture Best Practices

Appendix D: AWS Service Approvals Ready for Delivery to ISP

Appendix E: PostgreSQL Database Encryption

List of Tables

Table 2-1. Information System Components and Boundary Considerations Table 2-2. Use of Approved Software and Security Standards Table 2-3. Data Flow and Routing Paths Table 2-4. Technical Integration with Enterprise IT and Security Services Table 2-5. Key Technical Security Considerations Table 2-6. Other Considerations Table 2-7. AWS Specific Considerations Table B-1. Roles and Responsibilities Table C-1. Reliability Best Practices Table C-2. Performance Efficiency Best Practices Table C-3. Operational Excellence Best Practices Table C-4. Security Best Practices Table C-5. Cost Optimization Best Practices

U.S. General Services Administration 1

1 Introduction

The development of increasingly complex information systems with new and emergent technologies and techniques requires focus on security activities throughout the system life cycle, ensuring systems are designed and built with security in mind from inception and remain dependable and secure in the face of ever-changing threats.

The Security Engineering Division (ISE) in the Office of the Chief Information Security Officer (OCISO) has developed the Security Engineering Framework described herein to facilitate a collaborative approach to the attainment of ubiquitous security adoption and compliant operations in the General Services Administration (GSA) information technology (IT) computing environment. The framework includes two loosely coupled security engineering services that when applied to systems development processes will further these goals. Specifically, ISE will seek to strengthen information systems and their supporting infrastructures by ensuring they are designed and built around their respective protection needs with proven security architectures;

and that required protection mechanisms are addressed and implemented early and maintained throughout the life cycle of the system. ISE services include:

● Security Architecture Review – ISE will review and approve all proposed Security Architectures prior to assessment. The goal of the review is to ensure that any proposed security architecture or proposed changes to an existing architecture comply with GSA security requirements.

● Ongoing Security Consulting/Engineering Support- ISE will serve as a subject matter expert providing on-demand security consulting/engineering support to system and security staff.

ISE services are available to both new systems during the development/acquisition stage of the system life cycle; and, for operational systems undergoing a major change during the operation/maintenance stage of the system life cycle. The ensuing sections further detail the ISE security engineering services.

1.1 Purpose

This guide describes security engineering services provided by the OCISO ISE Division. It is designed to assist agency personnel with engaging the ISE Division with both formal and ad hoc security consulting services.

1.2 Scope

The security engineering architecture considerations described in this guide are applicable to all GSA information systems and the computing resources they provide to the GSA enterprise.

These resources and services may consist of physical and virtual assets, hosted and services-based software, and the platforms that render or consume infrastructure as a service internally and externally by the GSA.

1.3 Policy

Appendix A contains the policy statements regarding security engineering architecture reviews.

U.S. General Services Administration 2

1.4 Roles and Responsibilities

Appendix B contains the roles and responsibilities associated with security engineering architecture reviews.

2 Security Architecture Review

GSA Security Engineering must review all Security Architectures prior to an assessment. The goal of the review is to ensure that any proposed security architecture or proposed changes to an existing architecture comply with GSA security requirements. In general, Security Engineering must perform a security architecture review as part of the Assessment and Authorization (A&A) process for all new systems and systems undergoing a major change. ISE will review architectures for:

● New Systems: During the system design phase of a new system before A&A.

● Re-Authorizations: Systems being re-authorized that have not previously had a security architecture review performed.

● Major Change: When substantive changes are made to an existing system, including but not limited to:

o Addition of major components not previously authorized that expands the authorization to operate (ATO) boundary or significantly alters the systems risk profile.

o New integration points with external systems or services.

o Changes to the authentication or encryption subsystems.

o Migration to other environments, data centers, whereby the configurations change.

o Adoption of Software as a Service (SaaS), Platform as a Service (PaaS), or

Infrastructure as a Service (IaaS).

o Integration with third party services via API or making an API available for the purpose of third-party integration.

The GSA Security Engineering Division reviews and approves the security architecture of information systems undergoing the Security Assessment and Authorization Process. This requirement is described in section 3 of CIO-IT Security 06-30 and in section 2.3.2 of GSA CIO- IT Security 14-68: Lightweight Security Authorization Process Guide.

2.1 Security Architecture Workflow

This section summarizes the Architecture Review Process.

1. The ISSM/ISSO reviews and attests the Security Architecture Checklist items to ensure their supporting diagrams and System Security and Privacy Plan (SSPP) have the required items.

2. The ISSM submits their request through the Security Engineer Architecture Review Request Google Form.

3. An ISE Security Engineer will triage the request for the following items:

a. To ensure key checklist items have been included. If they have not been addressed, the request will be rejected.

b. To determine the nature of the system and level of effort required to complete initial review.

4. Once accepted, an ISE engineer will be assigned to review supplied artifacts and will provide an estimated time frame to provide initial comments.

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://docs.google.com/spreadsheets/d/1caPem0xVuGHmopRrnRKhPdndRWX9NlckvKtsJ7JZlJE/edit#gid=1271542007 https://docs.google.com/spreadsheets/d/1caPem0xVuGHmopRrnRKhPdndRWX9NlckvKtsJ7JZlJE/edit#gid=1271542007 https://docs.google.com/forms/d/e/1FAIpQLSdLiDZHfI041b2HJKq3-q6jn1OO2VY1jUws55mWpdLN8EUQnA/viewform https://docs.google.com/forms/d/e/1FAIpQLSdLiDZHfI041b2HJKq3-q6jn1OO2VY1jUws55mWpdLN8EUQnA/viewform

U.S. General Services Administration 3

5. The ISE Security Engineer will review submitted architecture and provide feedback within the provided time frame. The ISE Security Engineer will meet with the ISSO and application teams to ensure sufficient understanding of requested updates. ISE will continue to work with the team until the documentation is sufficient.

6. ISSOs are responsible for coordinating implementation of needed changes to documentation and providing updates.

7. Once the review is complete, a final report noting any findings will be emailed to the ISSO, ISSM, and any relevant system points of contact (POCs).

8. If the system is in Archer, ISE will update Archer to note that a security architecture review was completed and the date on which it was completed. If the system is not in Archer, ISE will work with the ISSO to ensure it gets added.

2.2 Security Architecture Workflow Steps

Step 1: Review Security Architecture Checklist

The ensuing tables identify a series of checks, informed by existing requirements in NIST SP 800-53, Revision 5 and/or GSA or Federal IT Security policy used by GSA Security Engineering in the performance of security architecture reviews. The checks are not all-inclusive and generally represent areas where GSA information systems have had implementation challenges. During the review of the security architecture documented in section 9-11 of the SSPP, GSA Security Engineering will use this checklist as guidance to ensure alignment of the proposed architecture to NIST Federal/GSA security requirements and/or GSA’s security fabric (if internally hosted).

Information in the tables should not be construed as new requirements or superseding existing responsibilities for complying with information security and privacy requirements defined by existing Federal laws, Executive Orders, directives, standards, guidelines, or regulations.

Reference Appendix C for AWS security architecture best practices derived from the AWS Well Architected Framework.

Table 2-1. Information System Components and Boundary Considerations

# Checklist Item Control Reference

The ATO boundary must be well defined and include all assets, services and devices that constitute the information system. These shall include all physical and virtual resources. Using this checklist will ensure a well-defined architecture, facilitate ISE architecture approval, and ease control definitions in the SSPP.

CM-08 System Component Inventory

The system boundary contains all components, devices, services, communication paths (Virtual Private Networks [VPNs], Application Programming Interfaces [API] calls, etc.). Diagram(s) should be sufficiently detailed and identify flows with source/destination, ports/protocols, or whether the related traffic is encrypted or not. References to ports/protocols table(s) are acceptable (for large sets of ports). Tables identifying ports should reflect whether they are encrypted. Tables should easily be tracked to the architecture diagram.

CM-08 System Component Inventory

AC-20 Use of External Systems

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

U.S. General Services Administration 4

# Checklist Item Control Reference

If shared assets or services are used, they must be appropriately defined and documented as a shared service within the ATO boundary of the system or within the corresponding ATO boundary of a relevant, authorized system. All components must be accounted for within an ATO boundary.

CM-08 System Component Inventory

AC-20 Use of External Systems

If on-premise or cloud services are used to support operation, maintenance, management, security of the services in scope of the ATO, they should be reflected in the network architecture with related flows.

Depending on the nature and type of integration and sensitivity of the data, these dependent systems may also need to obtain an ATO; usage considered for risk acceptance; or, if not risk accepted, potentially removed from the architecture. All SaaS, IaaS or PaaS that support delivery of the system must have an ATO, approved by GSA or FedRAMP.

CA-06 Authorization

AC-20 Use of External Systems

SA-09 External System Services

5 Integration points and network interconnections with external systems, networks, VPNs, APIs, and services must be well-defined in the architecture and securely implemented.

CA-03 Information Exchange

AC-20 Use of External Systems

SA-09 External System Services

6 A Trusted Internet Connection (TIC) as defined by FISMA and DHS must be utilized for all privileged, authenticated connections. Privileged access to external environments, including cloud environments shall route through the GSA MTIPs provider (when possible). Leveraging GSA’s internet connection satisfies this item.

AC-17 Remote Access

AC-17(03) Remote Access | Managed Access Control Points TIC Reference Architecture requires all Cloud traffic to be routed through Trusted Internet Connections.

7 Any system that interconnects with GSA via physical or logical network connection shall obtain IP address provisioning from GSA Network Operations. This can be coordinated through the GSA NetOps teams (netops@gsa.gov). Classless Inter-Domain Routing (CIDR) block allocations will be provided for each team or tenant of Cloud Service Providers (CSPs) to prevent overlap of addressing across on premise and remote networks across CSPs. CIDR block allocations shall be coordinated through the GSA NetOps teams.

SC-22 Architecture and Provisioning for Name/Address Resolution Service

8 For public facing systems, integration with external systems including but not limited to other cloud assets via APIs or third-party enablers shall be appropriately secured.

Reference GSA CIO-IT Security-19-93: Application Programming Interface (API) Security for guidelines to

CA-03 Information Exchange

AC-20 Use of External Systems

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://www.cisa.gov/tic https://www.cisa.gov/tic https://insite.gsa.gov/node/167050

U.S. General Services Administration 5

# Checklist Item Control Reference secure APIs, GSA CIO-IT Security-07-35: Web Application Security for securing web applications; and, GSA CIO-IT Security-14-69: SSL/TLS Implementation for securely implementing SSL/TLS connections.

SA-09 External System Services

9 All access control mechanisms, such as firewalls, router access control lists (ACLs), subnets, proxies, and cloud-based analogs, such as firewalls and network access controls configurations, shall be fully documented in the architecture diagram and supporting discussion in terms of specific access control rules, specifying source, destination, protocol, and other relevant attributes, as necessary.

SA-05 System Documentation

SC-07 Boundary Protection

10 Ensure all authentication points (including but not limited to Amazon Web Services (AWS) console, jump, machine resources, application, API, enablers, etc. [as applicable]), in the architecture diagram and described in the supporting discussion.

All systems shall utilize a GSA-approved multi-factor authentication mechanism for both privileged and non-privileged user authentication. All new and modernizing systems must undergo an ICAM Portfolio Review in accordance with GSA Order CIO 2183.1, “Enterprise Identity, Credential, and Access Management (ICAM) Policy.” Any system in scope that has not gone through this process will need to contact icam-portfolio@gsa.gov.

Per NIST 800-63B, Digital Identity Guidelines, Authentication and Lifecycle Management, MFA methods involving the sending of Personal Identification Numbers (PINS)/passwords via email is prohibited and on public networks via Short Message Service (SMS) is restricted.

Sending PINS/passwords to registered telephone numbers on Government Furnished Equipment (GFE) is allowed based on a risk analysis. MFA methods shall favor approaches that do not expose PINS/passwords to intercept risk including but not limited to Hash-based One-time Password (HOTP), Time-based OTP (TOTP), Security Assertion Markup Language (SAML)/OpenID Connect (OIDC), Personal Identity Verification (PIV), Fast ID Online (FIDO)/WebAuthn.

Note: System architectures must adhere to the considerations identified in the Admin Remote Access Guidance document. Contact SecEng@gsa.gov for the latest copy of this document.

IA-02(01) Identification and Authentication (Organizational Users) | Multifactor Authentication to Privileged Accounts

IA-02(02) Identification and Authentication (Organizational Users) | Multifactor Authentication to Non-Privileged Accounts

Note: The NIST SP 800-63 series of documents were updated to new versions (- 4s) in July 2025. This guide references and aligns to the previous versions. GSA will update this guide to reference the new standards in the next release of this guide.

https://insite.gsa.gov/node/167050 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

U.S. General Services Administration 6

Table 2-2. Use of Approved Software and Security Standards

# Checklist Item Control Reference

11 Ensure that the proposed software stack aligns with approved IT Standards. Any proposed software which is not listed in GEAR must be reviewed following the GSA IT Standards process, prior to inclusion in the defined architecture. Proposed software will undergo a Security Review, 508 Accessibility Review, and Chief Technology Officer (CTO) review by multiple teams following the IT Standards process.

The continued usage of End of Life (EOL) software requires a risk evaluation to be performed by the OCISO. An EOL software usage justification to include Plan of Action and Milestones (POA&M) tracking requirements or an approved Acceptance of Risk (AOR), are the possible documentation outcome requirements of the risk evaluation.

CM-02 Baseline Configuration

CM-06 Configuration Settings

SA-22 Unsupported System Components

12 The software stack, including operating system, application, database, etc. must be configured and hardened in accordance with GSA Enterprise Security Benchmarks (where they exist) or to a suitable hardening standard, such as ones provided by the Center for Internet Security (CIS).

GSA information systems, including vendor owned/operated systems on behalf of GSA, must be configured in alignment with GSA security benchmark guidelines. Hardening Guides are available on the GSA InSite IT Security Technical Guides and Standards page. Automation content for the benchmarks is available on GitHub.

CM-06 Configuration Settings

CIO 2100.1 GSA IT

Security Policy

Table 2-3. Data Flow and Routing Paths

# Checklist Item Control Reference

13 Sections 9 and/or 10 of the SSPP shall document all data flows in both narrative and diagram versions.

Diagram(s) in this section should be sufficiently detailed and identify flows to all components and support services with source/destination, ports/protocols, whether the related traffic is encrypted or not. References to the ports tables are acceptable (for large sets of ports). The tables identifying ports must reflect whether they are encrypted or not. Tables should easily be tracked to the architecture diagram. The ports, protocols, and services table should list whether the communication is encrypted. If not encrypted, there needs to be a description of the data contents, sensitivity, if the data is Government data, and which users have access to the data. This is so the ISSO/ISSM can make a risk-based decision regarding the use of unencrypted traffic.

SA-05 System Documentation

AC-04 Information Flow Enforcement

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://sites.google.com/a/gsa.gov/it_standards/ https://sites.google.com/a/gsa.gov/it_standards/ https://insite.gsa.gov/node/167050 https://github.com/GSA/security-benchmarks

U.S. General Services Administration 7

# Checklist Item Control Reference

14 Data flow through approved external or internal Continuous Integration systems (CI) and code repositories shall be documented in narrative and diagram versions in the SSPP.

SA-05 System Documentation

AC-04 Information Flow Enforcement

Table 2-4. Technical Integration with Enterprise IT and Security Services

# Checklist Item Control Reference

15 Internal (on premise) and external (cloud) Federal systems must leverage and provide accessibility to existing GSA Enterprise IT and IT Security services such as Authentication, security information and event management (SIEM), Log Management, Security Scanning, OCISO Cloud Security Tooling, etc. Integration must be documented in prose and system diagrams.

RA-05 Vulnerability Monitoring and Scanning

IR-05 Incident Monitoring

AU-06 Audit Record Review, Analysis, and Reporting

AU-06(01) Audit Record Review, Analysis, and Reporting | Automated Process Integration

AU-06(03) Audit Record Review, Analysis, and Reporting | Correlate Audit Record Repositories

Table 2-5. Key Technical Security Considerations

# Checklist Item Control Reference

16 All systems which require authentication, regardless of FIPS 199-impact level, shall implement multifactor authentication for user-level authentication. GSA systems with non-privileged users may integrate with GSA approved centralized authentication services using SAML 2.0 or OpenID Connect.

Further, systems leveraging certificate-based authentication shall not be downgraded to only username and password authentication.

Per NIST 800-63B, MFA methods involving the sending of pins via public networks via SMS or email are restricted; pin sending to registered telephone numbers to GFE as allowed on a risk basis. MFA methods shall favor approaches that do not expose pins to intercept risk including but not limited to HOTP, TOTP, SAML/OIDC, PIV, FIDO/WebAuthn.

IA-02(01) Identification and Authentication (Organizational Users) | Multifactor Authentication to Privileged Accounts

IA-02(02) Identification and Authentication (Organizational Users) | Multifactor Authentication to Non-Privileged Accounts https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

U.S. General Services Administration 8

# Checklist Item Control Reference

17 The mechanisms for creating, storing, distributing, and signing any encryption keys or certificates in the system shall be fully documented in the security architecture.

Additionally, all keys and certificates generated shall be reposed in a manner that supports a Business Continuity, Disaster Recovery, and Continuity of Operations planning consistent with NIST requirement per impact FIPS 199 impact level. For further details, see GSA CIO-IT Security- 09-43: Key Management.

SC-12 Cryptographic Key Establishment and Management

18 Encryption of Sensitive Data at Rest

**Systems that process Personally Identifiable Information (PII), Payment Card Industry (PCI) data, Authenticators (e.g., passwords, tokens, keys, certificates, hashes, etc.), and other sensitive data as determined by the AO, shall encrypt that data everywhere (i.e., at file level, database level, at rest, and in transit). All databases must be encrypted. Encryption of the whole database and at the table, column, or field levels containing the sensitive data is required. Methods including, but not limited to, application encryption or tokenization are also acceptable. For databases containing sensitive data (see SC-28) they must separately encrypt that data at the table, column, or field level (at least two managed keys, one for the database, and one for the sensitive data’s encryption)

SC-28 Protection of Information at Rest

SC-28(01) Protection of Information at Rest | Cryptographic Protection

19 Ensure encryption for web services utilizes FIPS approved ciphers, FIPS validated encryption modules, at a minimum TLS 1.2 and up, HSTS, and HTTPS only. Complete details can be found in CIO-IT Security-14-69.

● Digital signature encryption algorithms Reference: NIST Cryptographic Algorithm Validation Program (CAVP), CAVP Testing: Digital Signatures Algorithm Specifications

● Block cypher encryption algorithms

Reference: NIST CAVP, CAVP Testing: Block Ciphers

● Secure hashing algorithms Reference: NIST CAVP: CAVP Testing: Secure Hashing.

● Cybersecurity and Infrastructure Security Agency

(CISA), Binding Operational Directive 18-01:

Enhance Email and Web Security

SC-08 Transmission Confidentiality and Integrity

SC-08(01) Transmission Confidentiality and Integrity | Cryptographic Protection

SC-13 Cryptographic Protection

20 If high availability is a functional or security requirement, such as in the case of FIPS 199 Moderate or High Systems, the system shall utilize geographically separate infrastructure or availability zones to assure high availability.

CP-06 Alternate Storage Site

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Digital-Signatures https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Digital-Signatures https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Block-Ciphers https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Block-Ciphers https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Block-Ciphers https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Secure-Hashing https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Secure-Hashing https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Secure-Hashing https://www.cisa.gov/binding-operational-directive-18-01 https://www.cisa.gov/binding-operational-directive-18-01 https://www.cisa.gov/binding-operational-directive-18-01

U.S. General Services Administration 9

# Checklist Item Control Reference

* A High Availability architecture is required for FedRAMP;

but not a Limited ATO (LATO) based on GSA CIO-IT Security-14-68: Lightweight Security Authorization Process.

CP-06 Alternate Storage Site | Separation From Primary Site

CP-07 Alternate Processing Site

CP-07(01) Alternate Processing Site | Separation from Primary Site

21 The network access controls shall be implemented in a least-permissive manner, assuring that only authorized and essential network communication occurs between elements of the system and across system boundaries.

AC-06 Least Privilege https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides

U.S. General Services Administration 10

Table 2-6. Other Considerations

# Checklist Item Control Reference

22 Ensure that the proposed architecture includes all applicable essential security controls as identified in GSA CIO-IT Security-09-48: Security and Privacy Requirements for IT Acquisition Efforts. Examples include multi-factor authentication, SIEM integration, and Vulnerability Scanning. Refer to the guide for a comprehensive list.

SA-04 Acquisition Process Applicable NIST 800-53 Control Baseline (i.e., Low, Moderate, or High)

23 Systems processing payment card information shall comply with the GSA PCI Guidelines guidance.

GSA PCI DSS Program Implementation Plan seceng@gsa.gov

24 Integration with GSA’s Security Stack (Federal Systems):

System integration includes;

● Sending all logs listed in CIO-IT Security-01-08:

Auditing and Accountability (AU) to GSA’s central Enterprise Logging Platform (ELP) to support information system monitoring.

● Retaining logs for a minimum of 12 months online and 18 months in cold storage.

● Using GSA OCISO perimeter firewall services.

● Integration with GSA’s internal infrastructure security tools (agent and agent-less) for:

o Configuration setting monitoring (e.g., BigFix, MaaS360, GoogleMDM).

o Whitelisting/blacklisting and restricting user installation of software (e.g., CarbonBlack).

o Scanning to identify vulnerabilities (e.g., Tenable Security Center (TSC), Invicti).

o Antivirus and malicious code protection (e.g., FireEye HX, Endgame/Elastic Security Defend).

o Inventory management (e.g., BigFix, Forescout/Secure Connector, MaaS360, GoogleMDM). Integration with GSA’s security container-based management solutions

● Cloud Service Provider Integrations (e.g., Prisma Cloud Enterprise).

Note: The tools referenced above relate to GSA’s internal infrastructure and systems those tools can be integrated with, including tools used within GSA’s cloud environments.

Additional tools providing the same function may be used in Contractor systems if approved by the GSA CISO and AO.

Additional details on GSA’s security stack can be found in this Google Sheet.

GSA ISCM Enterprise Security Management Tools

25 Verify that the system/application satisfies GSA’s IT accessibility and Section 508 requirements.

(Section.508@gsa.gov)

Section 508 of the Rehabilitation Act of 1973

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides https://docs.google.com/spreadsheets/d/1bkIntyt0GtEybqeIn7iI3E0mknjemiLiUVkgiuXFb-c/edit#gid=941618463 https://docs.google.com/spreadsheets/d/1bkIntyt0GtEybqeIn7iI3E0mknjemiLiUVkgiuXFb-c/edit#gid=941618463 https://docs.google.com/spreadsheets/d/1bkIntyt0GtEybqeIn7iI3E0mknjemiLiUVkgiuXFb-c/edit#gid=941618463 https://insite.gsa.gov/employee-resources/information-technology/it-accessibility-section-508 https://insite.gsa.gov/employee-resources/information-technology/it-accessibility-section-508 https://www.section508.gov/manage/laws-and-policies/#:~:text=Section%20508%20of%20the%20Rehabilitation%20Act%20of%201973 https://www.section508.gov/manage/laws-and-policies/#:~:text=Section%20508%20of%20the%20Rehabilitation%20Act%20of%201973

U.S. General Services Administration 11

Table 2-7. AWS Specific Considerations

# Checklist Item Control Reference

26 Host backend database and services on private VPCs that are not visible on any public network.

SC-07 Boundary Protection

PL-08: Security and Privacy Architectures

27 Enable encryption at rest for ALL Elastic Block Storage (EBS) volumes. Enable encryption at rest in other services (e.g., S3, RedShift, etc.) for sensitive data including but not limited to PII and PCI. Glacier, Redshift, and Storage Gateway encrypt data at rest by default.

SC-28 Protection of Information at Rest

28 Ensure all flows are documented in the architecture diagram. Further, encrypt all flows, including:

● Outbound traffic to the Internet

● Inbound traffic from the Internet; web traffic should enforce HTTPS only, with HSTS. All new domains should be pre-loaded.

● Communication to AWS services

● Flows to back-office networks (i.e., to GSA)

● Inter-VPC communication flows

● Intra-VPC flows when bridging public and private subnets and when transmitting sensitive traffic data (e.g., PCI, PII, security authenticators, other business sensitive information as identified by data owner).

PL-08: Security and Privacy Architectures

SC-08(01): Transmission Confidentiality and Integrity | Cryptographic Protection

CISA BOD 18-01

29 Virtual Private Cloud (VPC) peering transmits data in the clear through AWS’s backbone; it may be acceptable in certain use cases, for example when data is non-sensitive (e.g., Network Time Protocol (NTP), Domain Name Service (DNS) when not publicly resolving); or, when the protocols traversing the peering connection is itself encrypted (e.g., Secure Sockets Layer [SSL], Secure Shell [SSH], Self- Referral Disclosure Protocol [SRDP]). The latter tends to be problematic over time as not all flows can be limited to just secure protocols; hence the need for a VPN solution for inter-VPC connections. GSA has experimented with OpenSwan, StrongSwan, and Cisco Cloud Services Router (CSR); the latter has proven most effective.

SC-08(01): Transmission Confidentiality and Integrity | Cryptographic Protection

30 Egress flows require the ability to regulate traffic via Uniform Resource Locator (URL), not just port, protocol, and Internet Protocol (IP). AWS Security Groups (SGs) provide, allow, and deny rules for inbound and outbound traffic for VPCs at layer 4; an outbound proxy solution with rules and policies that allows controlled outbound layer 7 traffic inspection is ideal. Traffic inspection may be opportunistically enabled when necessary to support incident investigations.

SC-07 Boundary Protection

IR-04: Incident Handling

U.S. General Services Administration 12

# Checklist Item Control Reference

31 SSL termination should extend through to the web server. If terminating at Elastic Load Balancer (ELB), extend through to the VPC with Application Load Balancer (ALB) - SSL offloading.

SC-08(01): Transmission Confidentiality and Integrity | Cryptographic Protection

32 If leveraging AWS services for boundary protection, systems need to implement AWS Web Application Firewall (WAF) with inbound allow/deny rules (and manage deny rules over time based on threat information from GSA and external entities). Further, systems need to implement Shield Advanced for enhanced Denial of Service (DOS) protection.

SC-07 Boundary Protection

PL-08: Security and Privacy Architectures

33 Inter-VPC flows including cross-tenant flows and flows to shared VPCs (e.g., transit, security, etc.) need to be limited based on port/protocol to what is minimally required.

SC-07 Boundary Protection

PL-08: Security and Privacy Architectures

34 Egress/ingress perimeter security devices that include AWS WAF, Shield Advanced, AWS SGs/Network ACLs (NACLs), and proxy/firewall for outbound URL filtering and SSL packet decryption (when necessary) is suitable.

SC-07 Boundary Protection

PL-08: Security and Privacy Architectures

35 Ensure AWS services used are either FedRAMP authorized or approved for usage by GSA. Reference the ISE Master AWS Services Tracking List.

If desired service is not reviewed or FedRAMP approved, you may submit a request to seceng@gsa.gov.

CM-07(05): Least Functionality | Authorized Software Allow-By- Exception

36 Required Key AWS Security Services:

● Enable CloudTrail in ALL regions

● Enable VPC Flow Logs per ENI, subnet or VPC;

create CloudWatch metrics from log data; log to CloudWatch logs; and alarm on metrics

● CloudWatch

● Shield and Shield Advanced

● Inspector

● Config

● Trusted Advisor

SecurityHub, GuardDuty, Macie, CloudFront and AWS WAF are other services that could be enabled to address a capability gap.

PL-08: Security and Privacy Architectures

37 Required IAM configurations for GSA Incident Response Support

● GSA Incident Response team

● GSA Security Operations team

● ISSO/DevSecOps Engineer to support ongoing security monitoring/A&A/security assessment

IR-04: Incident Handling

IR-03: Incident Response Testing

Docusign Envelope ID: 520CF41A-B9F6-44B5-BFFF-CBB2FEC44188 https://docs.google.com/spreadsheets/d/1kJrPqu10x80LaGQ_oXFDuoPkBdnaXrXTQVF_uJ14-ok/edit?gid=0#gid=0

U.S. General Services Administration 13

Step 2 – Provide Security Architecture for Review

Security architecture reviews can be submitted to the Security Engineering Division via the Security Architecture Checklist Form. The Checklist form is intended to assist ISSOs/ISSMs with engaging the Security Engineering Division for security architecture reviews. This checklist contains the high-level considerations as defined in this guide that Security Engineering looks at when reviewing system architecture. The process is intended to clearly set review expectations and facilitate a pre-submission self-evaluation to identify and resolve key issues that often contribute to delays. Adherence to the checklist review items and the practices in this guide will ensure timely review and approval of system security architectures.

Review documentation, such as the SSPP (at a minimum Sections 9, System Description, and 10, System Environment), can be directly uploaded via the Google Form. Sufficient documentation must be provided to GSA Security Engineering supporting a determination as to whether the system will meet essential security requirements and align with architectural requirements.

Security Engineering further recognizes that an Agile Software Development Lifecycle (SDLC) approach to system development may result in an iterative, rapidly changing security architecture and recommends that system owners and architects involve GSA Security Engineering early in the design process. The GSA ISE may assign, upon request, an engineer to participate in meetings periodically to facilitate security adoption. Any changes made to the system’s security architecture after ISE approval will require a re-evaluation of those changes to ensure ongoing compliance with security requirements. As part of the full A&A and Lightweight Security Authorization processes, ISE must approve the final security architecture prior to go-live. Security Engineering encourages system owners to account for this review when determining project scheduling.

Step 3 – ISE Security Architecture Approval

The Security Architecture review process is focused specifically on systems that will follow the A&A process, either the Limited or full ATO, and systems undergoing significant change or redesign as described in NIST SP 800-37 Revision 2, Appendix F, Section for Event-Driven Triggers and Significant Changes.

Once the required documents are received from ISSOs/ISSMs, Security Engineering will perform a review, generally within 3-5 business days (complex architectures may take more time) and provide feedback. If necessary, ISE will schedule a meeting with the relevant stakeholders to present the results of the review and to address any concerns. ISSOs are responsible for coordinating implementation of needed changes to documentation and submitting updates. Security will review updates and work with stakeholders to address residual issues. Formal approval will be conveyed via email and report. Upon Security Engineering approval, implementation of the system and/or A&A assessment can proceed. Major changes (if any) made to the system’s security architecture after ISE approval will require follow-on review and approval.

3 Ongoing Security Consulting/Security Engineering Support

In addition to the services enumerated in the preceding sections of this guide, ISE will provide Security Engineering and Consulting support for key IT initiatives seeking to utilize new and emergent technologies or undergoing major architectural changes to ensure such systems are

U.S. General Services Administration 14 designed and built securely from the start. ISE engineers will provide design and architecture guidance following the best practices in this guide.

3.1 New Technology Review/Approval

GSA Security Engineering will provide feedback, and in some cases, approval of new technologies and services. Services or technologies not currently FedRAMP or Agency approved may be submitted for a Security Engineering review. Upon request, Security Engineering will review new technologies including services in AWS, GCP, and Microsoft Azure and present findings to the GSA CISO for approval consideration. Approval of cloud services not FedRAMP authorized is a function of risk and may be with or without usage conditions;

approval is not assured.

For the AWS Service Review Process, see Appendix D. To request reviews of non-AWS cloud services (or other technologies), send an email to SecEng@gsa.gov describing the request, along with a list of relevant stakeholders and technology implementers. Consider including vendor representatives among the stakeholders. Security Engineering will review the request (generally within 14 business days) and render an approval determination. If necessary, a meeting with the stakeholders will be scheduled. Please provide relevant documentation, analysis, or justification to Security Engineering one week prior to the meeting.

If a meeting is needed, be prepared to discuss the technology and the specific way the technology will be utilized in the GSA system and any mitigation controls. The decision on whether to approve a new technology or service will depend in part on technologies’ intended use and mitigating controls in place. Security Engineering may request a detailed explanation or analysis of the technology to assist with the review.

GSA Security Engineering reviews new technology in coordination with the CTO following the IT Standards approval process. New technology reviews and security recommendations will be performed by ISE as a matter of routine. The GSA CISO will be consulted for exceptional technologies. For new software consideration, please submit a Software Review Request (SRR) in ServiceNow.

U.S. General Services Administration 15

Appendix A: GSA CIO 2100.1 Policy Statements Regarding Security Engineering Architecture Reviews

Note: When CIO 2100.1 is updated, the policy statements within it will supersede the policy statements below.

CIO 2100.1Q contains the following policy statements related to Security Engineering Architecture Reviews.

Chapter 1, The GSA Information Technology Security Program

13. Cloud Services. No GSA user or SSOs including Regional Offices, shall conduct or acquire any type of pilot involving the use of GSA data or GSA logon credentials to a cloud service, platform, application, or tool without first consulting with the OCISO's Security Engineering Division (ISE). Such coordination can be made by contacting ISE representatives at SecEng@gsa.gov.

a. No procurement for such products/services shall be completed without coordination through the OCISO and having obtained a valid ATO granted by a GSA AO based on the processes defined in GSA CIO-IT Security-06-30 or a FedRAMP provisional ATO.

b. GSA users or SSOs may leverage GSA authorized Cloud Service Provider services reviewed by the GSA Security Engineering Division (ISE) and approved by the GSA CISO.

Contact SecEng@gsa.gov for the current list of approved services.

Chapter 4, Policy for Protect Function

5. Information Protection Processes and Procedures.

g. ISE must approve all Security Architecture designs prior to implementation.

GSA CIO-IT Security-06-30: Managing Enterprise Cybersecurity Risk contains the following statements applicable to security engineering architecture.

Appendix E, Table E-1: GSA Showstopper Items/Controls states:

1. Multi-Factor Authentication (MFA) for Privileged & User-level Access

All systems shall utilize a GSA-approved multi-factor authentication mechanism for both privileged and non-privileged user authentication. All new and modernizing systems must undergo an ICAM Portfolio Review in accordance with GSA Order CIO 2183.1, “Enterprise Identity, Credential, and Access Management (ICAM) Policy.”

If an assessment identifies MFA has not been implemented, per policy requirements, then the system will not be approved for a 3-year ATO or OA, until MFA is implemented.

https://www.gsa.gov/policy-regulations/policy/information-technology-policy/it-security-procedural-guides

U.S. General Services Administration 16

Appendix B: Roles and Responsibilities

The following table provides a general description of the roles and responsibilities for personnel involved in the Architecture Review as referenced in CIO-IT Security-06-30.

Table B-1. Roles and Responsibilities

Role Responsibilities

Information System Security Manager

(ISSM)

● Oversees and coordinates ISSO activities to ensure the architecture submission sufficiently addresses required artifacts and elements identified in this guide.

● Only ISSM can submit requests for security engineering architecture review.

Information System Security Officer

(ISSO)

● Coordinates security engineering and architecture reviews with relevant stakeholders.

● Works with the ISSM to conduct a review and provides attestation through the security engineering checklist that all items are addressed prior to the submission to Security Engineering for architecture review.

Security Engineer

● Reviews system security architectures submitted by ISSOs, ensuring they are designed and built around their respective protection needs with proven security architectures in alignment with the security practices defined in this guide.

● Provides any findings or issues with the system in an official report sent to the ISSM and ISSO. ISSM and ISSOs are responsible for coordinating implementation of needed changes.

U.S. General Services Administration 17

Appendix C: AWS Architecture Best Practices

This appendix aligns with AWS recommendations for a well architected framework. The framework is based on five pillars: reliability, performance efficiency, operational excellence, security, and cost optimization. In general, systems designed in AWS are balanced by trade-offs between pillars tailored to individual system needs. Trade-offs mainly occur between the reliability, performance, and cost pillars. The security and operational excellence pillars are generally not part of trade-off decisions.

The remainder of this document will provide specific best practice recommendations for each pillar to help facilitate a well architected system.

Reliability

Design the system in anticipation of failure. Incorporate the ability to automatically recover from infrastructure or service failures. Utilize scaling to dynamically acquire computing resources to meet demand and mitigate disruptions such as misconfigurations or transient network issues.

Scaling will allow you to stop guessing capacity needs and respond to change in demand.

Table C-1. Reliability Best Practices

Best Practice Recommendations

Scaling ● Scale horizontally (additional nodes) and vertically (additional resources within nodes) to increase aggregate system availability.

● Design an elastic architecture that can grow and shrink on demand.

● Utilize parallel processing to split workloads into parts that execute simultaneously.

Multiple Locations ● Develop all systems in multiple availability zones (AZs).

● Moderate and High system classifications should leverage multi-regional deployments.

Network Topology ● Plan for connectivity requirements to legacy data centers.

● Have high availability / multiple connections.

● Implement VPN between data centers and for user connectivity.

● Proper VPC/Account allocation - Use separate accounts for each

VPC and avoid integrating all VPCs into a singular account.

Typically, you should have Production, Staging, and Development/Test, each in their respective accounts and consider production as an immutable environment that is strictly controlled with full-on automation (i.e., changes are ALL pushed via API and not manually via direct machine access or through the AWS Console).

● Proper VPC allocation - 1-2 VPCs per account (see above).

● Proper subnet allocation. Limit the number of subnets to what is minimally required ensuring appropriate segmentation of public/web tiers and internal database tiers.

● Ensure no overlapping of private IP addresses.

U.S. General Services Administration 18

Best Practice Recommendations

Failure Management ● Test Recovery Procedures and responses to unexpected events and component failures.

● Learn from operational events and failures by capturing and reviewing all operational events and using them for improvements.

● Ensure adequate backups are performed.

● Automatically recover from failure.

● Test production systems at full scale load.

Performance Efficiency

Utilize available computing resources efficiently to meet system requirements and to maintain that efficiency as demand changes and technologies evolve. Rely on data-driven decisions and continually review choices made to ensure taking advantage of an evolving platform. Continually benchmark, load test, and monitor the environment to have the data needed to inform change.

Table C-2. Performance Efficiency Best Practices

Best Practice Recommendations

Democratize Advanced Technologies

● Consume new technology and rely on services rather than hosting and building your own.

Keep the Data Close to Customers to Minimize Latency

● Use multi-AZ/multi-region architectures.

● Leverage AWS CloudFront to distribute data to edge locations.

● Use managed services that automatically scale, if using RDS, redeploy across AZs and read replicas; if using RedShift, deploy clusters cross AZs

Use Serverless Architectures

● Leverage services such as storage that can host a web server, removing the operational burden.

Experiment More Often ● Quickly carry out comparative testing on different types of storage, services, and components.

Mechanical Sympathy ● Use technology that aligns best with desired goals.

Component Selection ● Component Selection (Compute, storage, database, network) - Select…