See CIO 2100.1P – GSA IT Security Policy
- Chapter 3, Policy for Identify Function, which covers:
- SC-1, SC-6
- Chapter 4, Policy for Protect Function, which covers:
- SC-2, SC-3, SC-4, SC-5, SC-7, SC-8, SC-11, SC-12, SC-13, SC-15, SC-16, SC-17, SC-19, SC-20, SC-21, SC-22, SC-23, SC-24, SC-25, SC-28, SC-29, SC-31, SC-32, SC-36, SC-37, SC-38, SC-40, SC-41, SC-43, SC-49
- Chapter 5, Policy for Detect Function, which covers:
- SA-5, SA-7, SA-44
The latest version can be found on the GSA IT Security Policies page.
Create information systems with the most sophisticated, strongest, and reasonable cryptographic methodologies available. Structure networks with the lowest amount of access and trust possible, achieving "zero trust" network systems and designs wherever possible. Ensure communication channels fail into "closed states" if the confidentiality or integrity of the communication channel is disrupted.
See the Applicability section of the GSA IT Security Policy.
For information on roles and responsibilities, management commitment, coordination among organizational entities, compliance, reviews, and updates please see the Technology Transformation Service's (TTS) Common Control Policy.
Only privileged cloud.gov team roles (such as System Owner and Cloud Operations) have privileged Cloud Foundry API access, granted via User Account and Authentication (UAA) Server group membership. The cloud.gov team manages information system functionality surrounding and supporting the Cloud Foundry components via AWS, GitHub, and Concourse. Users do not get access to these facilities.
Cloud Operations uses AWS multi-factor authentication to access AWS.
See SC-2, SC-7 (7), SC-7 (8).
The cloud.gov team uses AWS S3 to store non-public information.
cloud.gov generates customer-specific least-privilege credentials which are restricted to reading and writing only data in shared resources belonging to that customer. cloud.gov advises customers to not share cloud.gov-generated customer-specific credentials for S3 with others.
See SC-4.
cloud.gov uses well-formed Virtual Private Cloud (VPC) firewall rules to reduce the attack surface of hosted components.
To maintain service resiliency, cloud.gov uses AWS Availability Zones and Elastic Load Balancing, along with real-time resource monitoring and alerting.
See SC-5, SC-6.
Cloud Operations team members configure cloud.gov boundary protections. Cloud Operations team members monitor and control communications at the external boundary of the system and at key internal boundaries within the system. cloud.gov limits the number of external network connections; the only access points visible on a public network are AWS load balancers.
See SC-7, SC-7 (3), SC-7 (18).
The Cloud Operations team establishes a traffic flow policy for each managed interface. These deny network traffic by default and only allow defined exceptions.
The Cloud Operations team protects the confidentiality and integrity of the information being transmitted across each interface by enforcing TLS for HTTP based connections and SSH system access. This includes all public interfaces and applications. All traffic handled by cloud.gov is routed through an AWS ELB where the HTTPS connection is terminated. All traffic to AWS ALBs to tenant applications is over HTTPS. All traffic from tenant applications to cloud.gov-provided services is over TLS.
If the team needs an exception to these traffic flow policies, there must a be a mission-related justification, such as pentest requirements. The team reviews exceptions to the traffic flow policy at least annually and removes exceptions that are no longer supported by an explicit mission/business need. Exception requests should have an expected duration, and be discontinued after that period.
See SC-7 (4), SC-7 (5), SC-8, SC-8 (1), SC-13, SC-23.
Essential management facilities for operations, monitoring, deploying changes, alerting, and other administrative needs are isolated from customer-facing components via use of a separate Tooling VPC in AWS and a security group policy which prevents traversal from the production VPC to the Tooling VPC.
See SC-7 (13).
cloud.gov terminates all network connections when sessions end. AWS ELBs are configured to terminate idle connections after 60 seconds of inactivity.
See SC-10.
For TLS certificates, cloud.gov only uses certificate authorities that meet GSA's requirements in IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69; currently our certicate authority is Let's Encrypt Cloud Operations obtains certificates from Let's Encrypt to encrypt and verify public connections. The certificates are stored in the AWS Identity and Access Management server certificate store to be used on Elastic Load Balancers.
Cloud Operations generates internal encryption keys and cryptographic certificates using the latest generally available version of OpenSSL. Cloud Operations encrypts and uploads server certificates and keys as secrets to AWS S3. Local copies of these certificates are deleted permanently. Concourse loads all secrets from either S3 or CredHub, decrypts them, and uploads them to BOSH over an encrypted internal connection. BOSH in turn installs the certificates and keys into the hosts based on each service’s needs.
None of the keys and certificates generated by Cloud Operations are distributed to other team members. Only automated systems have access to any cryptographic material.
Cryptographic keys and certificates are rotated at least yearly. Once a new key/certificate pair is generated, the previous one is removed from S3 by overwriting the encrypted file.
See SC-12, SC-12 (2), SC-12 (3), SC-17.
Cloud Operations ensures cloud-gov is always running the latest fully-patched versions of cryptographic software provided by our operating system vendors.
Cloud Operations uses the FIPS-certified endpoints and services offered by our IaaS provider when they have been included in the test suites used by provision systems. Use of untested endpoints poses operational risks.
See SC-13
By using and configuring AWS Route 53, cloud.gov combines DNS management with our HTTP Strict Transport Security (HSTS) endpoints to achieve data origin authentication and integrity verification along with the authoritative name resolution data the system returns in response to external name/address resolution queries.
Internally cloud.gov implements PowerDNS and Consul to resolve the names of internal Cloud Foundry components. See SC-20, SC-21, SC-22. EBS volumes, RDS, and S3 buckets are encrypted at rest. All system information is in these components.
See SC-28, SC-28 (1).
cloud.gov maintains a separate execution domain for each executing process by running within its own self-contained environment (a Garden container).
See SC-39.
Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/SC-Policy.md
- 2016-10: Initial version for authorization
- 2017-09: Security policy link updates
- 2019-12: Update links to GSA security policy
- 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history
- 2021-11: Clarify SC-7(4), SC-13 policies, add CredHub, remove Comodo
- 2023-12: Clarify use of Let's Encrypt
- 2024-05: Update links to GSA Security Policy