├── .github └── workflows │ └── security-considerations.yml ├── .gitignore ├── AC-Policy.md ├── AT-Policy.md ├── AU-Policy.md ├── CA-Policy.md ├── CM-Policy.md ├── CODEOWNERS ├── CONTRIBUTING.md ├── CP-Policy.md ├── IA-Policy.md ├── IR-Policy.md ├── LICENSE.md ├── MA-Policy.md ├── MP-Policy.md ├── Makefile ├── PE-Policy.md ├── PL-Policy.md ├── PS-Policy.md ├── RA-Policy.md ├── README.md ├── SA-Policy.md ├── SC-Policy.md ├── SECURITY.md ├── SI-Policy.md └── TTS-Common-Control-Policy.md /.github/workflows/security-considerations.yml: -------------------------------------------------------------------------------- 1 | name: Security Considerations 2 | 3 | on: 4 | pull_request: 5 | types: [opened, edited, reopened] 6 | branches: [main, master, develop] 7 | 8 | jobs: 9 | security-considerations: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: cloud-gov/security-considerations-action@main 13 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *pdf 2 | _tmp.md 3 | tmp*md 4 | bq_tts.md 5 | -------------------------------------------------------------------------------- /AC-Policy.md: -------------------------------------------------------------------------------- 1 | # Access control policy 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * AC-1, AC-4, AC-20 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * AC family controls 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * AC-2, AC-4, AC-25 11 | 12 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 13 | 14 | ## Purpose 15 | 16 | Limit information system access to authorized users or processes acting on behalf of authorized users. Enforce "least privilege" methodologies for all system actions. 17 | 18 | ## Scope 19 | 20 | See the **_Applicability_** section of the GSA IT Security Policy. 21 | 22 | ## Policy overlay 23 | 24 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 25 | 26 | 30 | 31 | # Procedures 32 | 33 | cloud.gov's access control procedures starts with an offer letter to an individual from the GSA Office of Human Resources Management (OHRM). As the individual is on-boarded to the federal government, their personal information is recorded, biometrics are taken, preexisting identification is validated, and finally a personal identity verification (PIV) card is issued in full accordance with Homeland Security Presidential Directive 12 (HSPD-12). 34 | 35 | Successfully issuing a PIV card allows internal users to obtain credentials for GSA SecureAuth, GSA's enterprise identity system. GSA SecureAuth is used to gate access control to cloud.gov's Operations User Account and Authentication (UAA) Server, which is integrated with GSA SecureAuth. 36 | 37 | Technical onboarding to cloud.gov is initiated by the cloud.gov Director, Deputy Director, or Program Manager via creation of an Onboarding issue in the cloud.gov issue tracking system. The issue should include the On-boarding Checklist (https://github.com/cloud-gov/product/blob/main/.github/ISSUE_TEMPLATE/onboard-any-team-member.md) which ensures the internal user gains proper access and permissions to any systems or tools they need, inclusive of access to Amazon Web Services (AWS). Access to AWS is strictly limited to the System Owner, Cloud Operations, and Cloud Compliance (read-only). The Cloud Operations team member assigned to the issue acts on it once the individual has GSA SecureAuth access and a GSA email account. 38 | 39 | The System Owner (or representative) and a quorum of the Cloud Operations meet on a quarterly 40 | basis to review and confirm all team accounts meet requirements for compliance 41 | with account management needs. Typically these meetings occur in March, June, 42 | September and December. In advance of the meeting, members of the compliance team 43 | and cloud operations will generate reports of group memberships and role 44 | assignments. During the meeting, the participants 45 | will review memberships and their alignment with current 46 | job responsibilies, and make changes, or assign issues, to make corrections. 47 | All team member roles should align with contingency plan roles on the "cloud.gov Team Roster" 48 | (Google Docs). Should the team size exceed 24, account review will include 49 | account activity audits to ensure access is still required for job functions. 50 | 51 | When a privileged team member has been absent (leave, illness, detail assignment) 52 | for more than 30 days, or is scheduled to be absent for 30 or more days, the System Owner 53 | disables their privilege rights from their accounts (AWS, cloud foundry and GitHub). 54 | When the individual returns to work, the System Owner reinsates/restores those account privileges. 55 | 56 | When a privileged team member is terminated, reassigned or loses their need to know rights, 57 | the System Owner permanently disables their privilege rights and access from all accounts within 24 hours 58 | of departure. 59 | 60 | See SSP controls AC-2, AC-2(1), AC-2(2), AC-2(3), AC-2(4), AC-2(5), AC-2(7), AC-2(9), AC-2(10), AC-2(12), AC-3, AC-7, AC-8, AC-11, AC-11(1), AC-12, AC-14, AC-17, AC-17(1), AC-17(2), AC-17(4). 61 | 62 | cloud.gov's customers gain access to the system in a similar fashion. The Client UAA Server can integrate with any enterprise identity system that supports the Security Assertion Markup Language (SAML) standard. Cloud Operations and the customer follow a simple procedure (https://cloud.gov/docs/ops/federated-identity/) in order to complete the integration. For cloud.gov customers using the cloud.gov identity provider, customer accounts will be deactivated after not logging into the system after 90 days. 63 | 64 | See SSP controls AC-2(9), AC-2(10), AC-21. 65 | 66 | The cloud.gov infrastructure service does have an emergency fallback 67 | "breakglass" account with keys that are kept in secure storage. Any 68 | use of the breakglass credentials generates alerts to Cloud Operations. We 69 | have code to rotate those credentials on-demand. 70 | 71 | See SSP controls AC-2(1) 72 | 73 | 74 | Within cloud.gov, both the permissions of users (whether internal or external) and the logical flow of data through the system is tightly controlled and regulated. Manual movements of data are strictly prohibited. Everything is subject to the virtual network, application, and container restrictions that are instantiated through cloud.gov's adherence to immutable "infrastructure as code." 75 | 76 | See SSP controls AC-4, AC-4(21), AC-17(3), AC-17(9), AC-19, AC-20 (2), and the CM controls. 77 | 78 | GSA systems always adhere to the principle of role segmentation and least privilege wherever possible. 79 | 80 | See SSP controls AC-5, AC-6, AC-6(1), AC-6(2), AC-6(5), AC-6(9). 81 | 82 | # Version history 83 | 84 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/AC-Policy.md 85 | 86 | * 2016-10: Initial version for authorization 87 | * 2017-09: Security policy link updates 88 | * 2019-12: Update links to GSA security policy 89 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 90 | * 2021-02: Customer accounts will be deactivated after not logging into the system after 90 days. 91 | * 2021-11: Reviewed by @pburkholder, no changes 92 | * 2022-04: Include additional guidance for details, leave, extended absences, and terminations 93 | * 2024-05: Updated links to GSA Security Policy and Onboarding Checklist 94 | -------------------------------------------------------------------------------- /AT-Policy.md: -------------------------------------------------------------------------------- 1 | # Security awareness and training policy 2 | 3 | 4 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 5 | 6 | * Chapter 3, _Policy for Identify Function_, which covers: 7 | * AT-1 policy control 8 | * Chapter 4, _Policy for Protect Function_, which covers: 9 | * AT family implementation controls 10 | 11 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 12 | 13 | ## Purpose 14 | 15 | Provide the highest quality training in modern security practices, ensure announcements regarding new risks to information systems circulate immediately, and facilitate collaboration across the Service to develop new technologies or methodologies to compensate risk. 16 | 17 | ## Scope 18 | 19 | See the **_Applicability_** section of the GSA IT Security Policy. 20 | 21 | ## Policy overlay 22 | 23 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 24 | 25 | 29 | 30 | # Procedures 31 | 32 | If cloud.gov staff fail to comply with GSA security training requirements, their access to all GSA information systems is terminated. This includes access to cloud.gov systems. 33 | 34 | See AT-2, AT-2 (2). 35 | 36 | The cloud.gov Program Manager ensures that Cloud Operations staff with significant information system security roles complete role-based security-related training upon being granted access, and subsequent refresher training at least annually. 37 | 38 | Whenever a new person joins the Cloud Operations team, the cloud.gov Program Manager assigns the team member a GitHub issue documenting a checklist of required training materials. The same process is applied to each team member annually as if they were a new team member. 39 | 40 | Training records for GSA-mandated training are kept for at least one year, cloud-gov specific records are kept for at least five years. 41 | 42 | See AT-3, AT-4. 43 | 44 | # Version history 45 | 46 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/AT-Policy.md 47 | 48 | * 2016-10: Initial version for authorization 49 | * 2017-09: Security policy link updates 50 | * 2019-12: Update links to GSA security policy 51 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 52 | * 2021-11: State retention policy for training records 53 | * 2024-05: Update links to GSA Security Policy 54 | -------------------------------------------------------------------------------- /AU-Policy.md: -------------------------------------------------------------------------------- 1 | # Audit and accountability management policy 2 | 3 | See [CIO 2100.1P – GSA IT Security 4 | Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 5 | 6 | * Chapter 3, _Policy for Identify Function_, which covers: 7 | * AU-1 policy control 8 | * Chapter 4, _Policy for Protect Function_, which covers: 9 | * AU-4 10 | * Chapter 5, _Policy for Detect Function_, which covers: 11 | * Most AU family contorls 12 | * Chapter 6, _Policy for Respond Function_, which covers: 13 | * AU-6, AU-7s 14 | 15 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 16 | 17 | ## Purpose 18 | 19 | Ensure all actions taken on the information system are transparent, valid, and prevent repudiation. 20 | 21 | ## Scope 22 | 23 | See the **_Applicability_** section of the GSA IT Security Policy. 24 | 25 | ## Policy overlay 26 | 27 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 28 | 29 | 33 | 34 | 35 | # Procedures 36 | 37 | Our audit procedures ensure we gather events to assess our security posture, 38 | threat assessment, and support post-incident recovery and forensices. At a 39 | minimum, we audit: 40 | 41 | * Account management events; 42 | * Object access; 43 | * Policy change; 44 | * Privilege functions; 45 | * Process tracking; 46 | * System events/errors; 47 | * Administrator activity; 48 | * Authentication/authorization checks; 49 | * Data deletions, access, changes, and permission changes; 50 | * Network flow logs; 51 | * External network access; 52 | 53 | When making system changes we ensure we are auditing events to support these goals. To that end, audit records contain a certain minimum set of data elements in order to support after-the-fact-investigations. Each log file or container contains information sufficient to uniquely identify the logging source and the timestamp of the initial log record. All systems and services that generate log data have defined ownership, such that the responsible group or customer can be identified and contacted if necessary. 54 | 55 | Cloud Operations has implemented CloudTrail and CloudWatch for its account and system monitoring of AWS virtual infrastructure. These tools provide visibility into user activity by recording API calls made on an AWS account and its cloud infrastructure. CloudTrail captures and records important information about each API call for the list of auditable events. 56 | 57 | cloud.gov provides an audit trail through the BOSH tasks command. This command shows all actions that an operator has taken with the platform. Additionally, operators can redirect Cloud Foundry component logs to a Logstash syslog server using the syslog_daemon_config property in the metron_agent job of cf-release. For end users, cloud.gov records an audit trail of all relevant API invocations of an app. The CLI command cf events returns this information. 58 | 59 | Loggregator, the Cloud Foundry component responsible for logging, provides a stream of log output from hosted applications and from cloud.gov system components that interact with applications during updates and execution. 60 | 61 | All applications will partially inherit some of the ELK stack auditing functions and capabilities that reside on the cloud.gov PaaS. Application System Owners must ensure their application’s activities are monitored and captured within audit logs. 62 | 63 | Audit logs will be made available to client organizations and for mutual support in response to security breaches, system and user access, incident reporting and continuous monitoring. Cloud Operations will generate and distribute audit reports, provide dashboard access for audited events, and send audit log data to SIEM and log analysis systems as needed. 64 | The cloud.gov Program Manager has established processes for regularly reviewing audit log information, and reporting security issues if discovered. Reviews will occur at a minimum of weekly and are integrated with processes for incident response, in order to ensure standardization and cross-functional collaboration. All alerts are investigated. 65 | 66 | cloud.gov uses CloudTrail, CloudWatch, Prometheus, and Grafana to integrate audit monitoring, analysis and reporting into an overall process for investigation and response to suspicious activities. In addition, the cloud.gov team employs PagerDuty as an automated mechanism to immediately alert security personnel of inappropriate or unusual activities that have security implications. 67 | As a result, all information within the system is available for audit and available for after the fact investigations. 68 | 69 | cloud.gov provides an audit trail that shows all actions that an operator has taken with the platform. For users, cloud.gov records an audit trail of all relevant API invocations of an application. 70 | 71 | Application System owners are responsible for making sure audit events are captured based on AU-2(d) parameter requirements for their web applications. 72 | 73 | See AU-2. 74 | 75 | Cloud Operations updates the defined auditable events on a quarterly basis or when changes in the threat environment occur or are identified by risk assessment. This quarterly Security Policy and Account Review meeting is on the cloud.gov team’s GSA Google Apps calendar as a recurring event. The meeting is conducted with a quorum of the Cloud Operations team present and reviews incidents, alerts, logs, metrics, postmortems and events for the prior period. Once reviewed, alerting policy and procedures are updated to reflect identified issues. All updates and changes in the threat environment will be included in updates provided to the FedRAMP Joint Authorization Board (JAB). 76 | 77 | See AU-2(3). 78 | 79 | CloudTrail, CloudWatch, Snort, Tripwire, Clam AV, Prometheus and Grafana collect, monitor, and maintain audit logs for both AWS and cloud.gov. 80 | 81 | The events monitored include but are not limited to successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events for both AWS and cloud.gov. These events are tracked for all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes. 82 | 83 | cloud.gov information system generates audit records for **everything**. All events are timestamped, and are comprehensive enough to answer the who, what, and where of any event. Due to the complete virtualization of the environment, and the comprehensiveness of our tooling, all information representing the state of the system, and any action taken on it is captured. 84 | 85 | See AU-3, AU-3(1). 86 | 87 | Cloud Operations defines the amount of storage dedicated to audit logs records on their EC2 instances and S3 buckets. cloud.gov uses elastic file storage that allows the information system to grow storage capacity as required. The use of elastic file storage reduces the likelihood of such capacity being exceeded within the information system. Cloud Operations team members are responsible for maintaining the configuration that enforces the audit settings. 88 | 89 | The log management framework provides the capability to retain logs for 180 days online, with sufficient capacity as to mitigate the risk of exceeding storage space. In the event the threshold is exceeded, administrators can add additional storage capacity without impacting the system. 90 | 91 | See AU-4. 92 | 93 | cloud.gov has the ability to elastically grow the audit storage capacity, which reduces the likelihood of such capacity being exceeded within the information system. Cloud Operations has implemented alerting to notify of insufficient audit storage capacity or if no new logs have been written to the ELK stack or CloudWatch Logs within a five-minute timeframe. 94 | In the event that the audit storage capacity has been reached, cloud.gov will stop the Loggregator from streaming logs to any third-party tools and alert Cloud Operations of any processing failures. 95 | 96 | See AU-5. 97 | 98 | Through the use of CloudTrail, CloudWatch, BOSH, Nessus, ClamAV, Snort, GitHub, and the ELK logging system, the Cloud Operations team monitors and reviews audit logs for unapproved and unusual activities on a continual basis. 99 | 100 | We use reporting rulesets developed by the Snort, Nessus and ClamAV teams, which look for, identify, and report potentially inappropriate or unusual activity to be reviewed regularly. In all cases, these tools scan for deviations from historical traffic patterns either in type or quantity. 101 | Security vulnerabilities and system inconsistencies are reviewed by the Cloud Operations team (notified by email, text message and voice phone call). Security vulnerabilities which are not classified as high are reviewed weekly and resolved by Cloud Operations. Regular security reports are automatically generated by Nessus and sent to the System Owner, GSA’s Information Security team and other partner agencies as required. 102 | See SI procedures for more detail. 103 | 104 | The Cloud Operations team acts on findings that result from its regular audit process according to its incident response guidelines (https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md), including notifying GSA Information Security, the System Owner, and the ISSO. 105 | 106 | See AU-6. 107 | 108 | cloud.gov uses the automated mechanisms CloudTrail, CloudWatch, and Grafana to integrate audit monitoring, analysis and reporting into an overall process for investigation and response to suspicious activities. Prometheus receives data from multiple sources and makes that data available for regular auditing. 109 | 110 | Cloud Operations employs automated CloudWatch logs to collect and track metrics to monitor in real time infrastructure log data and resources. 111 | 112 | See AU-6(1). 113 | 114 | Cloud Operations and GSA Information Security have set up comprehensive and automated systems, detailed in the sections under cloud.gov Security Domain Stack. Audit records are under constant analysis, and can be immediately correlated across any tool. 115 | 116 | See AU-6(3). 117 | 118 | CloudWatch Logs provides on-demand audit review for any actions taken on or in the AWS environment. 119 | 120 | Prometheus and Grafana provide the capability to evaluate any action taken on the cloud.gov layer. 121 | 122 | The ELK stack, which captures logs related to applications hosted on top of cloud.gov, has the capability to provide audit reduction, analysis, and report generation capability. Specifically, Kibana has the capacity to build search queries on numerous criteria regarding application logs, and produce reports and exports. 123 | CloudWatch Logs, Prometheus, Grafana, and ELK do not alter the original content or time ordering of audit records. All audit files can be viewed in their raw and JSON standard formats. 124 | 125 | See AU-7. 126 | 127 | Cloud Operations uses CloudTrail to monitor AWS deployments in the cloud by getting a history of AWS API calls of the cloud.gov account, including API calls made via the AWS Management Console, the command line tools, and higher-level AWS services. 128 | 129 | See AU-7 (1). 130 | 131 | cloud.gov pulls from multiple NTP sources including http://tf.nist.gov/tf-cgi/servers.cgi for all the cloud.gov servers to generate timestamps for audit records. All the cloud.gov NTP servers are synchronized with Amazon’s NTP canonical server. These timestamps can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). 132 | 133 | See AU-8 and AU-8 (1). 134 | 135 | To maintain the integrity of log data, Cloud Operations carefully manages access around the generation and storage of audit log files. The ability to view or modify log data is restricted to Cloud Operations authorized users. Audit logs from CloudTrail are stored and protected in specified S3 buckets for cloud.gov, which are limited to read-only access and multifactor authentication by Cloud Operations staff. This ensures the logs cannot be modified without proper authorization. 136 | 137 | Audit logs from the cloud.gov platform are only accessible to Cloud Operations personnel and can only be viewed via the ELK stack. Any backend access to the EC2 hosts supporting the ELK stack in violation of policy triggers an alert to the entire Cloud Operations team. 138 | 139 | Further, the ElasticSearch component of ELK has been proxied such that our implementation filters and prevents modifications to existing logs via the HTTP PUT method, and only accepts the creation of new log entries via the HTTP POST method. 140 | 141 | See AU-9. 142 | 143 | The cloud.gov team implements a backup strategy to send all cloud.gov audit logs to encrypted S3 buckets where data is redundantly stored across multiple facilities and multiple devices in each facility. All S3 buckets are only accessible to authorized cloud.gov staff for logging and monitoring purposes. Cloud Operations performs weekly backups of all cloud.gov audit logs to the S3 buckets. 144 | 145 | See AU-9 (2). 146 | 147 | The System Owner authorizes access to management of audit functionality to only designated Cloud Operations staff. 148 | 149 | See AU-9 (4). 150 | 151 | Audit logs are kept according to NARA and GSA retention standards 152 | to provide support for after-the-fact investigations of security 153 | incidents and to meet regulatory and organizational information 154 | retention requirements. 155 | 156 | cloud.gov retains logs in accordance with [OMB Memo M-21-31, 157 | "Improving the Federal Government’s Investigative and Remediation 158 | Capabilities Related to Cybersecurity 159 | Incidents"](https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf), 160 | as clarified in December 2022 by CISA in ["Guidance for Implementing 161 | M-21-31: Improving the Federal Government’s Investigative and 162 | Remediation 163 | Capabilities"](https://www.cisa.gov/sites/default/files/2023-02/TLP%20CLEAR%20-%20Guidance%20for%20Implementing%20M-21-31_Improving%20the%20Federal%20Governments%20Investigative%20and%20Remediation%20Capabilities_.pdf) 164 | 165 | Our standard practice is to keep all logs readily accessible on-line for 12 166 | months, and in cold storage for an additional 18 months. AWS CloudWatch Logs 167 | are kept on-line for 36 months (or 30 months when that option is available). 168 | 169 | *Exceptions:* 170 | 171 | Per CISA guidance: 172 | 173 | > Q: Can an agency drop events which it deems irrelevant to incident detection or response? 174 | > A Yes, agencies may filter events they deem irrelevant “before, during, or after a cybersecurity incident." ... 175 | 176 | AWS WAF Logs are kept on-line for 6 months. WAF log retention is 177 | expensive and has no cold storage option, and when WAH requests 178 | pass, the full request handling is logged by AWS ALBs, GoRouters 179 | and other infrastructure elements. Therefore, WAF logs havea limited 180 | relevancy and a six-month retention period is sufficient for any 181 | denial of service attack investication. 182 | 183 | 184 | See AU-11. 185 | 186 | cloud.gov provides comprehensive audit record generation capability for all components: CloudWatch Logs for AWS, grafana.fr.cloud.gov for cloud.gov metrics, and logs.fr.cloud.gov for applications on cloud.gov. 187 | 188 | Cloud Operations are responsible for maintaining the configuration that enforces the audit settings. 189 | Cloud Operations team members select which auditable events are to be audited by specific components of cloud.gov where audit capability is deployed. 190 | 191 | 192 | 193 | 194 | See AU-12. 195 | 196 | # Version history 197 | 198 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/AU-Policy.md 199 | 200 | * 2016-10: Initial version for authorization 201 | * 2017-09: Security policy link updates 202 | * 2019-12: Update links to GSA security policy 203 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 204 | * 2021-11: Update to reference Grafana and Prometheus instead of obsoleted components 205 | * 2023-07: Update AU-11 guidance for M-21-31 and AWS WAF exception 206 | * 2024-05: Update links to GSA Security Policy and Incident Response Guideline 207 | -------------------------------------------------------------------------------- /CA-Policy.md: -------------------------------------------------------------------------------- 1 | # Security assessment and authorization 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * CA-1 policy control, CA-2, CA-3, CA-7, CA-8, CA-9 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * CA-2, CA-7 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * CA-2, CA-3, CA-7 11 | * Chapter 6, _Policy for Respond Function_, which covers: 12 | * CA-2, CA-7 13 | 14 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 15 | 16 | ## Purpose 17 | 18 | Implement the [NIST Risk Management Framework](http://csrc.nist.gov/groups/SMA/fisma/framework.html), and ensure compliance with all relevant laws, regulations, policies, and Executive Orders. 19 | 20 | ## Scope 21 | 22 | See the **_Applicability_** section of the GSA IT Security Policy. 23 | 24 | ## Policy overlay 25 | 26 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 27 | 28 | 32 | 33 | 34 | # Procedures 35 | 36 | As a cloud service provider that is also part of the General Services Agency (GSA), a federal agency, GSA TTS ensures cloud.gov invests in comprehensive risk management assessments. 37 | 38 | The main assessment procedures used are the [Federal Risk and Authorization Management Program (FedRAMP)](https://www.fedramp.gov/). Further, GSA TTS engages an [accredited third-party assessment organization](https://www.a2la.org/accreditation/fedramp) (3PAO) to provide an independent review of the cloud.gov system and organizational operations. 39 | 40 | Assessments of cloud.gov operations are performed in tandem with vulnerability scanning, malicious user testing, insider threat assessments, and other tests regularly conducted by the following teams: the cloud.gov team, TTS Technology Portfolio, GSA Information Security, and a 3PAO. The system is also under continuous monitoring from cloud.gov's Cloud Operations team. 41 | 42 | GSA TTS takes any results seriously, and it remediates issues as soon as possible. Plans of action and milestones (POA&Ms) are maintained to ensure any findings are resolved, compensated for, or accepted as an operational requirement. 43 | 44 | See CA-2, CA-2(1), CA-2(2), CA-2(3), CA-5, CA-7, CA-7(1), CA-8, CA-8(1). 45 | 46 | The cloud.gov system does not establish any direct connections to external system. Network connections are on a deny-all, permit-by-exception basis. 47 | 48 | See CA-3, CA-3(3), CA-3(5) 49 | 50 | The FedRAMP JAB through the program management office (PMO) is the Authorizing Official (AO) for cloud.gov. 51 | 52 | See CA-6 53 | 54 | # Version history 55 | 56 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/CA-Policy.md 57 | 58 | * 2016-10: Initial version for authorization 59 | * 2017-09: Security policy link updates 60 | * 2019-12: Update links to GSA security policy 61 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 62 | * 2021-11: Fix "remediations", clarify no direct connect, permit-by-exception 63 | * 2024-05: Update links to GSA Security Policy 64 | -------------------------------------------------------------------------------- /CM-Policy.md: -------------------------------------------------------------------------------- 1 | # Configuration management 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * CM-1, CM-8 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-8, CM-9, 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * CM-2, CM-3, CM-8, CM-10, CM-11 11 | 12 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 13 | 14 | ## Purpose 15 | 16 | Always deploy information systems into a known state before instantiation, and to maintain information systems in an immutable state as much as feasible. To the greatest degree possible, the configuration of systems should not be altered after they are deployed — they should be rebuilt and replaced from a known and secure baseline state. 17 | 18 | ## Scope 19 | 20 | See the **_Applicability_** section of the GSA IT Security Policy. 21 | 22 | ## Policy overlay 23 | 24 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 25 | 26 | 30 | 31 | # Procedures 32 | 33 | cloud.gov's specific configuration management procedures are packaged with the actual code of the cloud.gov system. Below is an overview of our procedures along with citations to controls and relevant GitHub repositories. 34 | 35 | ### 36 | 37 | The cloud.gov team maintains a [Configuration Management Plan](https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/configuration-management.md) that governs configuration changes. The plan outlines the procedure for to make any and all changes impacting the configuration of the system. 38 | 39 | See CM-9. 40 | 41 | Cloud Operations first provisions the initial infrastructure tool, Concourse (a continuous integration pipelining tool), into the desired "infrastructure as a service" account, using this [procedure](https://github.com/cloud-gov/cg-provision). Concourse then ensures that all configurations of further automated deployments are controlled, whether they are the result of running Terraform or BOSH. 42 | 43 | Cloud Operations encodes cloud.gov's infrastructure into a set of [Terraform](https://www.terraform.io) configuration files. Terraform files are checked into the [cloud.gov GitHub repositories](https://github.com/cloud-gov), and local git repositories, in order to ensure distributed version control and availability of the code. 44 | 45 | See CM-2, CM-2(2), CM-2(3), CM-6(1). 46 | 47 | Cloud Operations works with relevant stakeholders, decision-makers, and GSA Information Security to determine any necessary changes, and their impacts, to the configuration of the system. All changes to the configuration of the system are tracked both in GitHub and AWS CloudTrail. Only the System Owner and Cloud Operations are allowed to make configuration changes, and all changes are made to reasonably ensure the configurations require the least amount of functionality necessary. 48 | 49 | See CM-3, CM-4, CM-5, CM-5(1), CM-5(5), CM-7, CM-8, CM-8(1) 50 | 51 | # Version history 52 | 53 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/CM-Policy.md 54 | 55 | * 2016-10: Initial version for authorization 56 | * 2017-09: Security policy link updates 57 | * 2019-12: Update links to GSA security policy 58 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 59 | * 2021-11: Correct GitHub to link to cloud-gov org 60 | * 2024-05: Update links to GSA Security Policy and Configuration Management Plan 61 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @cloud-gov/platform-ops 2 | 3 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | **Contribution Policy** 2 | 3 | Cloud.gov is an open source project operated by the U.S. General Services Administration (GSA) to support federal agency missions. While we value transparency and collaboration, we must balance openness with the responsibilities of operating a secure, compliant, and trusted federal platform. 4 | 5 | ✅ **Who can contribute** 6 | We welcome contributions from: 7 | 8 | - Employees of U.S. federal agencies 9 | - Contractors working under a current agreement with a U.S. government entity 10 | - GSA-approved contributors as part of official interagency collaboration 11 | 12 | ❌ **Who we cannot accept contributions from** 13 | To avoid the appearance of government endorsement, manage supply chain risk, and maintain the integrity of our compliance posture, we do **not** accept unsolicited contributions from: 14 | 15 | - Individuals unaffiliated with the U.S. government 16 | - International contributors or organizations 17 | - Unvetted accounts or first-time contributors submitting minor changes 18 | 19 | If you're unsure whether your contribution fits, feel free to open an issue first so we can discuss it. 20 | -------------------------------------------------------------------------------- /CP-Policy.md: -------------------------------------------------------------------------------- 1 | # Contingency planning 2 | 3 | 4 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 5 | 6 | * Chapter 3, _Policy for Identify Function_, which covers: 7 | * CP-1 8 | * Chapter 4, _Policy for Protect Function_, which covers: 9 | * CP-2, CP-4, CP-6 CP-7, CP-8, CP-9, CP-12, CP-13 10 | * Chapter 5, _Policy for Detect Function_, which covers: 11 | * CP-2 12 | * Chapter 6, _Policy for Respond Function_, which covers: 13 | * CP-2, CP-3, CP-10 14 | * Chapter 7, _Policy for Recover Function_, which covers: 15 | * CP-2, CP-10 16 | 17 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 18 | 19 | ## Purpose 20 | 21 | Identify scenarios of likely events that would substantively disrupt the confidentiality, integrity, or availability of the information system. Use those scenarios to conduct actual simulations of said disruptions, and use data collected from the simulation to iteratively improve training, methodologies, but above all - improve the automation of our information systems to self-heal from any disruptions. 22 | 23 | ## Scope 24 | 25 | See the **_Applicability_** section of the GSA IT Security Policy. 26 | 27 | ## Policy overlay 28 | 29 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 30 | 31 | 35 | --- 36 | # Procedures 37 | 38 | See the [cloud.gov Contingency Plan](https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/contingency-plan.md). 39 | 40 | # Version history 41 | 42 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/CP-Policy.md 43 | 44 | * 2016-10: Initial version for authorization 45 | * 2017-09: Security policy link updates 46 | * 2019-12: Update links to GSA security policy 47 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 48 | * 2021-11: Reviewed by @pburkholder, no changes 49 | * 2024-05: Update links to GSA Security Policy and Contingency Plan 50 | -------------------------------------------------------------------------------- /IA-Policy.md: -------------------------------------------------------------------------------- 1 | # Identification and authentication policy 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * IA-1 policy control 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * IA family 9 | 10 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 11 | 12 | ## Purpose 13 | 14 | Balance restrictions designed to prevent unauthorized access against the need to provide unhindered access to informational assets. 15 | 16 | ## Scope 17 | 18 | See the **_Applicability_** section of the GSA IT Security Policy. 19 | 20 | ## Policy overlay 21 | 22 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 23 | 24 | 28 | --- 29 | # Procedures 30 | 31 | Identity and authentication in cloud.gov is entirely gated by cloud.gov's User Account and Authentication (UAA) Servers and their integration with GSA SecureAuth. Authentication to the underlying Amazon Web Service (AWS) is through the AWS Identity and Access Management (IAM). 32 | 33 | For both UAA and IAM endpoints, user accounts are coupled to their federal government identities, represented by their personal identity verification (PIV) card, and all of the verification that process entails. UAA and IAM require multi-factor authentication (MFA) across the board. MFA devices are segmented between the two services, helping to ensure security through diversity. Further, cloud.gov adopts a "zero-trust" network posture - no networks are trusted, unless valid credentials (inclusive of MFA) are authenticated. 34 | 35 | See IA-2, IA-2(1), IA-2(2), IA-2(3), IA-2(5), IA-2(8), IA-2(11), IA-2(12), IA-3, IA-4, IA-4(4), IA-5, IA-5(1), IA-5(2), IA-5(3), IA-5(4), IA-5(6), IA-5(7), IA-5(11), IA-6. 36 | 37 | As a result of implementing easy integration with customer enterprise identity systems, cloud.gov helps agencies centrally manage identities and supports the use of PIV-card enabled systems, if applicable. 38 | 39 | IA-8, IA-8(1), IA-8(2), IA-8(3), IA-8(4). 40 | 41 | IA-5(7): cloud.gov ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys by requiring all team members who use Git to managed code to: 42 | 43 | a. install [caulking](https://github.com/cloud-gov/caulking) during their onboarding process 44 | b. demonstrate compliance during their onboarding 45 | c. demonstrate compliance quarterly during biweekly architecture review 46 | 47 | # Version history 48 | 49 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/IA-Policy.md 50 | 51 | * 2016-10: Initial version for authorization 52 | * 2017-09: Security policy link updates 53 | * 2019-12: Update links to GSA security policy 54 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 55 | * 2021-11: Add IA-5(7) caulking procedure 56 | * 2024-05: Update links to GSA Security Policy 57 | -------------------------------------------------------------------------------- /IR-Policy.md: -------------------------------------------------------------------------------- 1 | # Incident response 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * IR-1 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * IR-2, IR-3, IR-8, IR-9 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * IR-4, IR-5, IR-8 11 | * Chapter 6, _Policy for Respond Function_, which covers: 12 | * IR-3, IR-4, IR-5, IR-8 13 | * Chapter 7, _Policy for Recover Function_, which covers: 14 | * IR-4, IR-8 15 | 16 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 17 | 18 | The cloud.gov system also relies on GSA IT Incident Response, and they in turn follow GSA's [IT Security Procedural Guide: Incident Response (IR) CIO-IT Security-01-02](https://www.gsa.gov/system/files/Incident-Response-%5BCIO-IT-Security-01-02-Rev-19%5D-09-08-2022docx.pdf), dated 2022-09-08. Future updates should be located with other [IT Security Procedural Guides](https://www.gsa.gov/policy-regulations/policy/information-integrity-and-access/it-security-procedural-guides). 19 | 20 | ## Purpose 21 | 22 | Iteratively reduce both the number of incidents as a proportion of our total information system inventory, and reduce the mean time to recover from incidents. 23 | 24 | ## Scope 25 | 26 | See the **_Applicability_** section of the GSA IT Security Policy. 27 | 28 | ## Policy overlay 29 | 30 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 31 | 32 | 36 | --- 37 | # Procedures 38 | 39 | The cloud.gov Program Manager organizes incident response training sessions, offered to the whole cloud.gov team at least annually, and requires that all Cloud Operations team members take the training. The training may be led by the Program Manager, a Cloud Operations team member, or another security specialist at GSA TTS. 40 | 41 | The cloud.gov team onboarding checklist (https://github.com/cloud-gov/product/blob/main/.github/ISSUE_TEMPLATE/onboard-any-team-member.md) requires that all team members take incident response training within 60 days of joining the team. 42 | 43 | This training is a meeting reviewing and explaining the cloud.gov IR Guide (https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md) and discussing questions and examples. The team takes notes on the training, stored in a Google Doc in the cloud.gov team Google Drive folder. The team records attendance in that document. 44 | 45 | If the cloud.gov system changes in a radical way, the Program Manager adapts the incident response training to meet the needs of the new system. The Program Manager then requires Cloud Operations team members to take the training again. 46 | The Program Manager requires all Cloud Operations team members to take the incident response training at least once a year. 47 | 48 | See IR-2. 49 | 50 | The cloud.gov team, as directed by the Program Manager, creates test plans and exercises in accordance to NIST 800-61, and presents these to the cloud.gov Authorizing Official for their approval. 51 | 52 | cloud.gov tests its incident response capabilities with an annual table top exercise. The test takes the form of a teleconference (GSA Google Hangout) meeting where a security specialist (such as the Program Manager, a Cloud Operations team member, or another security specialist from GSA TTS) guides the Cloud Operations team through a role-playing exercise with a simulated potential security incident. The team takes notes throughout the test, and afterward the team discusses the test and identifies weaknesses to fix with additional training or process improvements. The team files and tracks improvements with GitHub issues. 53 | 54 | See IR-3, IR-3 (2). 55 | 56 | cloud.gov implements automated processes to detect and analyze malicious activity within the platform. If these processes detect malicious activity, they automatically report the activity to the Cloud Operations team. 57 | 58 | cloud.gov has an Incident Response Guide (https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md) that documents the procedures that staff should take in the case of an incident, as required by the GSA TTS and GSA Incident Response Policy. 59 | 60 | See IR-4, IR-5, IR-6. 61 | 62 | The Cloud Operations team implements automated processes such as ClamAV and Tripwire to detect anomalies. When these processes detect an anomaly, they escalate an alert to Cloud Operations team members using PagerDuty. 63 | 64 | cloud.gov automatically stores logs so that Cloud Operations and GSA Information Security can access relevant information when investigating a potential incident. AWS level logs are automatically stored in CloudWatch Logs. 65 | 66 | See IR-4 (1), IR-6 (1). 67 | 68 | As described in the cloud.gov security incident response guide and contingency plan, Cloud Operations can notify customers about incidents and potential incidents using StatusPage (https://cloudgov.statuspage.io/), when this is appropriate for the incident. StatusPage allows customers to subscribe to updates by email or text message. 69 | 70 | Customers can report potential incidents (and request support) via email, as documented at [https://docs.cloud.gov/help/](https://cloud.gov/contact/). The Security Incident Response guide explains to customers that they should email the cloud.gov support address if they encounter potential security problems (https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md). 71 | 72 | cloud.gov customers can subscribe to StatusPage to automatically receive alerts about the availability of cloud.gov services. 73 | 74 | See IR-7, IR-7 (1). 75 | 76 | As part of GSA TTS, the cloud.gov team has direct and cooperative relationships with the Infrastructure team and the GSA Information Security team. 77 | Within GSA Information Security, the cloud.gov team also works directly with its assigned ISSO, whose responsibility during incident response events facilitates cooperative relationships between cloud.gov’s incident response capability and external providers of information system protection capability. 78 | 79 | GSA Information Security has direct relationships with other providers of federal incident response capability, inclusive of US-CERT. 80 | 81 | See IR-7 (2). 82 | 83 | The cloud.gov team has developed an Incident Response Guide (https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md) to implement incident response capabilities. 84 | 85 | The Incident Response Guide is continually reviewed and updated by the cloud.gov team. In addition, the cloud.gov team updates the IR Guide after it tests the guide, which happens at least annually and after any major system/organizational changes. 86 | 87 | The cloud.gov team distributes changes to the Incident Response Guide to the whole cloud.gov team. 88 | 89 | See IR-8. 90 | 91 | The cloud.gov Incident Response directs cloud.gov team members to watch out for and immediately report any potential security incident, which includes reporting suspected information spills (such as sensitive or classified information in the wrong places). In the event of a suspected information spill, cloud.gov team members follow the reporting process in the cloud.gov Incident Response Guide. 92 | 93 | The GSA TTS handbook [section on protecting sensitive information](https://handbook.tts.gsa.gov/general-information-and-resources/sensitive-information/) includes a reminder that spilled (or leaked/exposed) sensitive information must be reported via the response process. 94 | 95 | The System Owner, Program Manager, and Cloud Operations team members have primary responsibility for implementing the actual response to security incidents, including technical measures. GSA Information Security is responsible for assisting the cloud.gov team in responding to security incidents. 96 | 97 | See IR-9, IR-9 (1), IR-9 (2), IR-9 (3). 98 | 99 | The cloud.gov Incident Response Guide identifies notification to parties exposed to unauthorized information of their obligations for handling that information among the long-term remediation steps to be recorded by the Incident Commander. 100 | 101 | See IR-9 (4). 102 | 103 | # Version history 104 | 105 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/IR-Policy.md 106 | 107 | * 2016-10: Initial version for authorization 108 | * 2017-09: Security policy link updates 109 | * 2019-12: Update links to GSA security policy 110 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 111 | * 2021-11: Add GSA IR procedural guide. 112 | * 2024-05: Update links to GSA Security Policy and Incident Response Guide 113 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | As a work of the United States Government, this project is in the 2 | public domain within the United States. 3 | 4 | Additionally, we waive copyright and related rights in the work 5 | worldwide through the CC0 1.0 Universal public domain dedication. 6 | 7 | ## CC0 1.0 Universal Summary 8 | 9 | This is a human-readable summary of the [Legal Code (read the full text)](https://creativecommons.org/publicdomain/zero/1.0/legalcode). 10 | 11 | ### No Copyright 12 | 13 | The person who associated a work with this deed has dedicated the work to 14 | the public domain by waiving all of his or her rights to the work worldwide 15 | under copyright law, including all related and neighboring rights, to the 16 | extent allowed by law. 17 | 18 | You can copy, modify, distribute and perform the work, even for commercial 19 | purposes, all without asking permission. 20 | 21 | ### Other Information 22 | 23 | In no way are the patent or trademark rights of any person affected by CC0, 24 | nor are the rights that other persons may have in the work or in how the 25 | work is used, such as publicity or privacy rights. 26 | 27 | Unless expressly stated otherwise, the person who associated a work with 28 | this deed makes no warranties about the work, and disclaims liability for 29 | all uses of the work, to the fullest extent permitted by applicable law. 30 | When using or citing the work, you should not imply endorsement by the 31 | author or the affirmer. 32 | -------------------------------------------------------------------------------- /MA-Policy.md: -------------------------------------------------------------------------------- 1 | # Maintenance 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * MA-1 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * MA-2, MA-3, MA-5, MA-6 9 | 10 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 11 | 12 | ## Purpose 13 | 14 | Not applicable. cloud.gov is completely virtualized via AWS GovCloud. cloud.gov leverages the Provisional Authorization for AWS GovCloud for all physical maintenance. See below for a discussion of software maintenance. 15 | 16 | ## Scope 17 | 18 | See the **_Applicability_** section of the GSA IT Security Policy. 19 | 20 | ## Policy overlay 21 | 22 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 23 | 24 | 28 | 29 | # Procedures 30 | 31 | Software maintenance on cloud.gov is accomplished via the procedures of [Configuration Management (CM)](https://github.com/cloud-gov/cg-compliance-docs/blob/main/CM-Policy.md) and [System and Services Acquisition (SA)](https://github.com/cloud-gov/cg-compliance-docs/blob/main/SA-Policy.md). Please see those control families for details. 32 | 33 | 34 | # Version history 35 | 36 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/MA-Policy.md 37 | 38 | * 2016-10: Initial version for authorization 39 | * 2017-09: Security policy link updates 40 | * 2019-12: Update links to GSA security policy 41 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 42 | * 2021-11: Fix one link to cloud-gov GitHub 43 | * 2024-05: Update links to GSA Security Policy 44 | -------------------------------------------------------------------------------- /MP-Policy.md: -------------------------------------------------------------------------------- 1 | # Media protection 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * MP-1 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * MP-2, MP-3, MP-4, MP-5, MP-6, MP-7, MP-8 9 | 10 | 11 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 12 | 13 | ## Purpose 14 | 15 | Not applicable. cloud.gov is completely virtualized via AWS GovCloud. cloud.gov leverages the Provisional Authorization for AWS GovCloud for all media protection. 16 | 17 | ## Scope 18 | 19 | See the **_Applicability_** section of the GSA IT Security Policy. 20 | 21 | ## Policy overlay 22 | 23 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 24 | 25 | 29 | 30 | # Procedures 31 | 32 | Not applicable. 33 | 34 | 35 | # Version history 36 | 37 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/MP-Policy.md 38 | 39 | * 2016-10: Initial version for authorization 40 | * 2017-09: Security policy link updates 41 | * 2019-12: Update links to GSA security policy 42 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 43 | * 2021-11: Reviewed by @pburkholder, no changes 44 | * 2024-05: Update links to GSA security policy 45 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | MD_FILES=$(wildcard ??-Policy.md) 2 | PDF_FILES=$(patsubst %.md, %.pdf, $(MD_FILES)) 3 | 4 | ## all : make all the PDFs 5 | .PHONY : all 6 | all: $(PDF_FILES) 7 | 8 | ## bq_tts.md : generate the intermediate blockquoted TTS commmon policy 9 | bq_tts.md: TTS-Common-Control-Policy.md 10 | cat $< | sed -e 's/^/> /' > $@ 11 | 12 | ## pdf : generate a single PDF 13 | %.pdf: %.md bq_tts.md 14 | m4 -I./ $< > tmp_$< 15 | cat tmp_$< | sed -e 's///' | pandoc -o $@ -V colorlinks=true -V linkcolor=blue -V urlcolor=blue -V toccolor=gray 16 | # rm tmp_$<.md 17 | 18 | ## clean : rm PDF and temp files 19 | clean: 20 | rm -f *pdf *tmp.md tmp*md bq_tts.md 21 | 22 | ## variables : Print variables. 23 | .PHONY : variables 24 | variables: 25 | @echo MD_FILES: $(MD_FILES) 26 | @echo PDF_FILES: $(PDF_FILES) 27 | 28 | .PHONY : help 29 | help : Makefile 30 | @sed -n 's/^##//p' $< 31 | 32 | -------------------------------------------------------------------------------- /PE-Policy.md: -------------------------------------------------------------------------------- 1 | # Physical and Environmental Protection 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | 6 | * Chapter 3, _Policy for Identify Function_, which covers: 7 | * PE-1 8 | * Chapter 4, _Policy for Protect Function_, which covers: 9 | * PE-2, PE-3, PE-4, PE-5, PE-6, PE-8, PE-9, PE-10, PE-12, PE-13, PE-14, PE-15, PE-16, PE-17, PE-18, PE-19, 10 | * Chapter 5, _Policy for Detect Function_, which covers: 11 | * PE-3, PE-6, PE-20 12 | * Chapter 6, _Policy for Respond Function_, which covers: 13 | * PE-6 14 | 15 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 16 | 17 | ## Purpose 18 | 19 | Not applicable. cloud.gov is completely virtualized via AWS GovCloud. cloud.gov leverages the Provisional Authorization for AWS GovCloud for all physical and environmental protection. 20 | 21 | ## Scope 22 | 23 | See the **_Applicability_** section of the GSA IT Security Policy. 24 | 25 | ## Policy overlay 26 | 27 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 28 | 29 | 33 | 34 | # PE Procedures 35 | 36 | Not applicable. 37 | 38 | 39 | # Version history 40 | 41 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/PE-Policy.md 42 | 43 | * 2016-10: Initial version for authorization 44 | * 2017-09: Security policy link updates 45 | * 2019-12: Update links to GSA security policy 46 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 47 | * 2021-11: Reviewed by @pburkholder, no changes 48 | * 2024-05: Updated links to GSA Security Policy 49 | -------------------------------------------------------------------------------- /PL-Policy.md: -------------------------------------------------------------------------------- 1 | # Security planning 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * PL-1, PL-8 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * PL-2, PL-8 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * PL-2 11 | 12 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 13 | 14 | ## Purpose 15 | 16 | Create system security plans, diagrams, rules, privacy impact assessments, and operational procedures that are easy to understand, enforce, implement, and that reduce complexity wherever it can be found. 17 | 18 | ## Scope 19 | 20 | See the **_Applicability_** section of the GSA IT Security Policy. 21 | 22 | ## Policy overlay 23 | 24 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 25 | 26 | 30 | 31 | # Procedures 32 | 33 | Using the most current FedRAMP SSP template, 18F developed, and GSA TTS maintains, a system security plan which includes the cloud.gov PaaS and encompasses the cloud.gov applications. The security plan is developed in accordance with NIST Special Publication 800-18 R1 Guide of Developing Federal Information System Security Plans, as well as FedRAMP guidance. The System Security Plan: 34 | 35 | 1. Is consistent with cloud.gov architecture; 36 | 2. Explicitly defines the authorization boundary for cloud.gov PaaS; 37 | 3. Describes the operational context of cloud.gov PaaS in terms of missions and business processes; 38 | 4. Provides the security category and impact level of cloud.gov including supporting rationale; 39 | 5. Describes the operational network for cloud.gov; 40 | 6. Describes relationships with or connections to other information systems; 41 | 7. Provides an overview of the security requirements for cloud.gov; and 42 | 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions. 43 | 44 | GSA TTS distributes copies of the cloud.gov security plan and communicates subsequent changes to the plan to the cloud.gov System Owner, ISSO, ISSM, AO and other designated members within the GSA TTS staff and agency. 45 | The Information Security Officer, in conjunction with key GSA TTS management officials, reviews the cloud.gov SSP at least annually or whenever there is a significant change to the information system. 46 | The Information Security Officer updates the cloud.gov SSP to address changes to the platform and its network of operation or problems identified during plan implementation or security control assessments, and thereafter whenever a significant change occurs. 47 | The Information Security Officer protects the security plan from unauthorized modification by maintaining it as a write-access-controlled Google Doc or alternatively in a version-controlled documentation repository (https://github.com/cloud-gov/cg-compliance ) that can only be modified by designated members from GSA TTS and the agency. 48 | 49 | The cloud.gov team intentionally makes most of the system security plan publicly available as open source documents in GSA TTS repositories (including https://github.com/cloud-gov/cg-compliance and https://github.com/cloud-gov/cg-compliance-docs ). We follow GSA TTS’s Open Source Policy (https://github.com/18F/open-source-policy/blob/master/policy.md ): our non-sensitive work should be public and open source whenever possible. The cloud.gov team does not share sensitive information (such as PII that may be in the SSP) publicly, and follows GSA TTS guidance around this point: https://handbook.tts.gsa.gov/general-information-and-resources/sensitive-information/ 50 | 51 | See PL-2. 52 | 53 | The Cloud Operations team plans and coordinates security-related activities affecting the platform with the Authorizing Official, System Owner, ISSM, and ISSO before conducting such activities in order to reduce the impact on other entities. 54 | 55 | See PL-2 (3). 56 | 57 | All GSA TTS staff members are required to sign an acknowledgment indicating that they have read, understand, and agree to abide by the GSA Rules of Behavior, before authorizing access to information and the information system. 58 | 59 | cloud.gov documentation provides a public list of Rules of Behavior for all cloud.gov account holders, available under “Using your account responsibly” on this page: https://cloud.gov/docs/getting-started/accounts/ 60 | 61 | When logging into the cloud.gov system, all cloud.gov account holders (internal and external users) are required to agree to the cloud.gov account holder Rules of Behavior. The website (as seen at https://login.fr.cloud.gov/login ) provides a warning with a “Read more details” link, and the detailed description of requirements includes a link to the rules at https://cloud.gov/docs/getting-started/accounts/ ). This is a public page that anyone can view. Users must click “Agree and Continue” before they can log in. 62 | 63 | See PL-4 and PL-4 (1). 64 | 65 | The system implements a centralized security stack that can support multiple applications; ensuring adherence to NIST 800-53 controls and FISMA, as well as GSA TTS and GSA Information Technology (IT) Security Policies. Information security architecture is integrated into the information system by addressing information system requirements throughout the SDLC process. The FedRAMP JAB provides feedback to the Cloud Operations team on the security architecture and the Cloud Operations team receives regular guidance from the JAB board. 66 | 67 | cloud.gov uses industry best practices and applies hardening security benchmarks to all virtual machine instances. For perimeter protection, each subnet is assigned individual elastic network interface (ENI), so security groups can be applied to each of the interfaces; firewall rules are applied for isolated traffic between subnets. This adds an additional layer of protection. 68 | 69 | The determining factors of Confidentiality, Integrity, and Availability of the cloud.gov system are its FIPS 199 information types, which are listed in Section 2 of its SSP. The resulting Security Categorization, FIPS 199 Moderate Impact, governs the cloud.gov security architecture, which NIST SP 800-27A defines as “A description of security principles and an overall approach for architecture complying with the principles that drive the system design.” The information security architectural approach is documented in the cloud.gov System Security Plan, which describes implementation of said principles. 70 | 71 | The cloud.gov platform leverages IaaS via Amazon Web Services, which received a FedRAMP ATO in June 21, 2016. This allows the cloud.gov platform to inherit some security controls such as physical security and share responsibility of other controls such as media protection. For web applications the GSA TTS Cloud Operations team ensures that a web vulnerability scanner (OWASP Zap) is run on a monthly basis. GSA TTS web applications use industry best practices and federal hardening guidelines for web servers and application services like Java. 72 | 73 | The cloud.gov ISSO, cloud.gov System Owner, and FedRAMP JAB review applicable security architectures prior to major implementations or security assessments. The cloud.gov ISSO(s) reviews and updates the information security architecture within the System Security Plan on an annual basis or when a significant change takes place to reflect updates in the enterprise architecture. Due to the dynamic and elastic nature of cloud computing, the operations team monitors real-time updates of its information security architecture using the AWS Management Console and other management tools. 74 | The cloud.gov operations team follows the risk management framework (RMF) which includes conducting annual risk assessments for its information systems and infrastructure. Any changes are then updated in systems security plans, plan of actions and milestones POAMs, security assessment reports (SAR). 75 | 76 | All changes to the cloud.gov platform are routed through the GSA TTS Change Control process using the GitHub ticketing and tracking system which monitors changes including, but not limited to, ensuring that information security architecture changes are appropriately reflected in updates to system security plans (SSP), Cloud Operations team documentation and other security architecture-related documentation. 77 | 78 | 79 | The cloud.gov Program Manager ensures that planned aspects of the cloud.gov security architecture are reflected in organization procurements/acquisitions and captured within the appropriate controls of this System Security Plan (SSP). Planned architectural changes, once approved, are incorporated into the annual SSP update cycle. 80 | 81 | 82 | See PL-8. 83 | 84 | 85 | # Version history 86 | 87 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/PL-Policy.md 88 | 89 | * 2016-10: Initial version for authorization 90 | * 2017-09: Security policy link updates 91 | * 2019-12: Update links to GSA security policy 92 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 93 | * 2021-11: Update links to TTS policy, and update organization name 94 | * 2023-08: Fix broken links 95 | * 2024-05: Update links to GSA Security Policy 96 | -------------------------------------------------------------------------------- /PS-Policy.md: -------------------------------------------------------------------------------- 1 | # Personnel security 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * PS-1, PS-7 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * PS-1, PS-2, PS-3, PS-4, PS-5, PS-6, PS-7, PS-8 PS-9 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * PS-7 11 | 12 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page.. 13 | 14 | ## Purpose 15 | 16 | Reduce the risk of insider threats or internal conspiracies to circumvent the confidentiality, integrity, or availability of information systems. Sanction individuals found violating GSA policies, procedures, or taking any other action that knowingly violates the confidentiality, integrity, or availability of information systems. 17 | 18 | ## Scope 19 | 20 | See the **_Applicability_** section of the GSA IT Security Policy. 21 | 22 | ## Policy overlay 23 | 24 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 25 | 26 | 30 | 31 | # Procedures 32 | 33 | For personnel categorization, position risk designation is assigned by the GSA Office of Human Resources Management (OHRM), GSA TTS Talent, and GSA TTS Supervisors. We follow the methodology prescribed in the Office of Personnel Management’s (OPM) Federal Investigations Notice, No. 10-06. Risk designations are re-categorized whenever responsibilities change, the impact level of the system or the information in it changes, or at least once every three years. 34 | 35 | See PS-2. 36 | 37 | For personnel screening, we use the OPM process. 38 | 39 | See PS-3. 40 | 41 | Review of ongoing operational need for current logical and physical access by individuals are initiated and facilitated by the System Owner and Program Manager. The cloud.gov System Owner or Program Manager modifies permissions granted to individuals to correspond any changes in the individual requirements. GSA TTS notifies the cloud.gov System Owner or Program Manager within 5 days of a formal transfer action. The cloud.gov System Owner or Program Manager initiates the revoking process within the same day of an individual being transferred outside of the team. 42 | 43 | Retrieval of all information system-related property which includes HDPS-12 cards, authentication tokens, mobile devices, laptops, etc. is a common control provided by GSA. cloud.gov revokes privileged access if an individual is reassigned or transferred outside of the team. 44 | 45 | See PS-5. 46 | 47 | Since cloud.gov is provided by a federal agency to other agencies, GSA TTS signs standard US Treasury forms (7600A and 7600B) to create inter-agency agreements (IAAs) that allow other agencies to access and use cloud.gov. The GSA TTS Agreements team develops agreement text with the GSA Office of General Counsel (OGC) to ensure the boilerplate of all cloud.gov access agreements meet all legal, regulatory, policy, and Executive Order requirements. 48 | 49 | The System Owner reviews all access agreements at least yearly, or upon request from GSA TTS Agreements, GSA Information Security, or OGC. GSA TTS requires that all agencies have an active, signed, and fully-funded agreement to maintain access and use of the system. 50 | 51 | See PS-6. 52 | 53 | GSA enforces the same requirements on contractors that it does on staff, and contractors follow all normal procedures for onboarding and gaining access to cloud.gov systems. 54 | 55 | See PS-7. 56 | 57 | 58 | Whenever Cloud Operations, or any other team or individual, discovers that any GSA, TTS or cloud.gov information security policies or procedures have been violated, they must immediately follow the [cloud.gov incident notification procedures (which also notifies GSA Information Security teams)](https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md) and notify the System Owner, information system Authorizing Official, and the individual's direct supervisor via GSA email, separately. All notifications must occur within 24 hours of detecting a policy or procedure violation. 59 | 60 | The System Owner is responsible for immediately terminating the individual's access to the information system. The System Owner is also responsible for coordinating a cross-divisional ["incident retrospective"](https://drive.google.com/drive/folders/1B_hmrY_pQCaAYfovZQOvSjYGonPoOrES) exercise and report within 5 business days of the incident. All post-mortem reports should include remediations to reduce the chance of, or prevent, similar incidents in the future. The report is sent to the information system's Authorizing Official. 61 | 62 | The Authorizing Official is responsible for reviewing the report and is solely responsible for recommending actions to the individual's direct supervisor. If the Authorizing Official is satisfied by the remediations purposed, and the time-lines for implementing the remediations, the Authorizing Official may allow the System Owner to re-enable the individual's access to the information system. Regardless if access is re-enabled, the Authorizing Official must provide a recommendation on further sanctions or action. 63 | 64 | Recommendations on sanctions or actions may include one, or many of the below: 65 | 66 | * Written warning 67 | * Required coaching or re-training 68 | * Improvement plans 69 | * Re-assignment 70 | * Formal sanction in the employee's Electronic Official Personnel Folder (eOPF) 71 | * Termination 72 | 73 | The individual's direct supervisor is responsible for concurring or dissenting on any recommendations, and is responsible for implementation and deadlines for ultimate completion of concurred actions. If applicable, the direct supervisor is also responsible for coordinating with GSA's Office of Human Resources Management (OHRM) or GSA's Office of General Counsel. All actions and sanctions will be conducted in accordance with [9751.1A HRM _Maintaining Discipline_](https://www.gsa.gov/directives/files?file=2023-07%2FMaintaining%20Discipline%20HRM%2097511A.pdf). 74 | 75 | The individual's direct supervisor is also accountable to issue a report to the Authorizing Official on the completion of any actions. If the Authorizing Official is not satisfied by completed actions, either in their quality or the timeliness of their completion, the Authorizing Official can instruct the System Owner to re-terminate the individual's account. 76 | 77 | If the individual in question is part of a professional services or support contract, and not a federal employee, the same procedure is to be followed, with the exception that the Contracting Officer's Representative is informed in the place of the non-existent supervisor. 78 | 79 | See PS-8 and PS-4. 80 | 81 | # Version history 82 | 83 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/PS-Policy.md 84 | 85 | * 2016-10: Initial version for authorization 86 | * 2017-09: Security policy link updates 87 | * 2019-12: Update links to GSA security policy 88 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 89 | * 2021-11: Rename post-mortem to inc. retro, and link to Google Drive, Fix org name 90 | * 2024-05: Update links to GSA Security Policy, Incident Response Checklist, and 9751.1A HRM 91 | -------------------------------------------------------------------------------- /RA-Policy.md: -------------------------------------------------------------------------------- 1 | # Risk assessment policy 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | - Chapter 3, _Policy for Identify Function_, which covers: 6 | - RA-1, RA-2, RA-3, RA-5 7 | - Chapter 4, _Policy for Protect Function_, which covers: 8 | - RA-3, RA-5 9 | - Chapter 5, _Policy for Detect Function_, which covers: 10 | - RA-3, RA-5 11 | - Chapter 6, _Policy for Respond Function_, which covers: 12 | - RA-3, RA-5 13 | 14 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 15 | 16 | ## Purpose 17 | 18 | Provide governance over a formal, documented risk assessment structure that addresses purpose, scope, controls, roles, responsibilities, management commitment, coordination and compliance. 19 | 20 | ## Scope 21 | 22 | See the **_Applicability_** section of the GSA IT Security Policy. 23 | 24 | ## Policy overlay 25 | 26 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 27 | 28 | 32 | 33 | # Procedures 34 | 35 | All GSA teams, being part of a federal agency, follow the risk assessment and management process outlined in [NIST Special Publication (SP) 800-37](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf), _Risk Management Framework for 36 | Information Systems and Organizations_. 37 | 38 | Initial security categorization is a collaborative and inter-disciplinary activity, with all final decisions made by the Authorizing Official. Risk assessment is similarly cross-functional, with the Cloud Operations team being primarily responsible, as directed by the Program Manager. GSA Information Security teams are consulted throughout, and the Authorizing Official seeks concurrence from the GSA Chief Information Security Officer whenever possible. The Authorizing Official seeks to minimize any need to issue waivers or risk acceptances from GSA IT Security policy (see Chapter 1, Section 5) that do not have concurrence from the GSA Chief Information Security Officer. 39 | 40 | See RA-2, RA-3. 41 | 42 | Cloud Operations and GSA Information Security work together to scan all of relevant portions of the cloud.gov stack. This includes dynamic scanning of any controls the cloud.gov team is responsible for inside of AWS GovCloud, the operating system baseline of AWS EC2 instances, containers, Cloud Foundry modules, GSA TTS built modules, or any other open source software the team has instantiated within the environment to support cloud.gov. Static code analysis is also performed on the GSA TTS built modules. 43 | 44 | Note that _customers_ of cloud.gov are responsible for conducting static code analysis on the baseline of the applications they are deploying into cloud.gov containers. 45 | 46 | Access to scanning tools, scan results, and logs is broadly shared amongst the cloud.gov team to ensure a rapid response to any findings. Similarly, on-demand access is granted to the Authorizing Official to aide in any systemic understanding of the system's risk posture. 47 | 48 | In some cases Common Vulnerabilities and Exposures (CVEs) found by container scans may be false positives. Exceptions for these CVEs are implemented, and documented, in the [common-pipelines](https://github.com/cloud-gov/common-pipelines/blob/main/container/grype.yaml) repository. To implement an exception the reason for the exception must be documented, and the change must be reviewed and approved by a member of the security team. 49 | 50 | See RA-5, RA-5(1), RA-5(2), RA-5(3), RA-5(5), RA-5(6), RA-5(8). 51 | 52 | # Version history 53 | 54 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/RA-Policy.md 55 | 56 | - 2016-10: Initial version for authorization 57 | - 2017-09: Security policy link updates 58 | - 2019-12: Update links to GSA security policy 59 | - 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 60 | - 2021-11: Correct to using GSA TTS as organization name 61 | - 2024-05: Add container scanning and exlusion information, update links 62 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Compliance documentation 2 | 3 | This repository documents 18F security policies and procedures, which for example are used by the cloud.gov product team. 4 | 5 | For cloud.gov compliance documentation, see: https://github.com/cloud-gov/cg-compliance 6 | 7 | This is a public repository following [18F's Open Source Policy](https://github.com/18F/open-source-policy/blob/master/policy.md). See our [LICENSE.md](LICENSE.md) and [CONTRIBUTING.md](CONTRIBUTING.md) files for additional information. 8 | 9 | ## Generating PDFs for assessors 10 | 11 | To generate PDFs of all the Markdown files, install `pandoc` (e.g. 12 | `brew install pandoc`), and `basictex` (e.g. `brew install basictex`) then: 13 | 14 | ```shell 15 | make all 16 | ``` 17 | 18 | ## Editing documents 19 | 20 | We've created the `...Policy.md` documents to all include the file, `TTS-Common-Control-Policy.md`. 21 | As Markdown in GitHub, that's simply a linked URL. To generate PDFs, we use the `m4` 22 | commands `changequote` and `include` to make an intermediate tmp file, then pipe that 23 | through to `sed` and `pandoc` to strip the "magic" comments and generate the final 24 | output. 25 | 26 | In short, maintain the following snippet in the input files to include the TTS common 27 | controls: 28 | 29 | 33 | 34 | (The `changequote` is superfluous, we could just do ``include(`bq_tts.md')``) 35 | 36 | ## Public domain 37 | 38 | This project is in the worldwide [public domain](LICENSE.md). As stated in [CONTRIBUTING](CONTRIBUTING.md): 39 | 40 | > This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/). 41 | > 42 | > All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest. 43 | -------------------------------------------------------------------------------- /SA-Policy.md: -------------------------------------------------------------------------------- 1 | # System and services acquisition 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * SA-1, SA-2, SA-5, SA-9, SA-11, SA-12, SA-14 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * SA-3, SA-4, SA-8, SA-9, SA-10, SA-11, SA-12, SA-14, SA-15, SA-16, SA-17, SA-21 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * SA-4, SA-9, SA-18 11 | 12 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 13 | 14 | ## Purpose 15 | 16 | Continue forming teams of cross-functional skill sets that include security and privacy experts. Always keep a reserve of funding, time, and staff in order to provide for unexpected increases in the need for architectural and security engineering assistance, at any phase in an information system development life cycle. 17 | 18 | ## Scope 19 | 20 | See the **_Applicability_** section of the GSA IT Security Policy. 21 | 22 | ## Policy overlay 23 | 24 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 25 | 26 | 30 | 31 | # Procedures 32 | 33 | The cloud.gov program uses two-week planning sprints. Before each sprint, work is prioritized, inclusive of security needs. The cloud.gov CSP is part of the Technology Transformation Service (TTS) within GSA; cloud.gov coordinates with TTS and GSA leadership to appropriately plan for cloud.gov’s budget and staffing needs. 34 | 35 | cloud.gov has also been filed and registered as a major IT investment through the Electronic Capital Planning Investment Control (eCPIC) process with the Office of Management and Budget. As such, it is required to file reports on spending/budget with OMB. These reports include a breakout of spending on cloud.gov’s security analysis. 36 | 37 | See SA-2. 38 | 39 | cloud.gov practices a Scrumban process when developing new features or fixing existing issues, including security fixes and enhancements for cloud.gov. Each feature or issue is assigned to a card in the system, where it goes through a process of being identified, prioritized, explored, delivered, and finally demonstrated. Each card is reviewed by the team as a whole throughout its lifecycle to identify any security risks or concerns, which are recorded on the card as "acceptance criteria" that must be addressed before development is complete. 40 | 41 | Once development is complete, a team member submits the code to the version control system as a "pull request", where at least one other team member further reviews it before merging it into the code base. New features are deployed into our staging area where they undergo further security review and stakeholder acceptance testing, as well as automated acceptance tests. 42 | The System Owner is responsible for ensuring appropriate staffing for security needs. The Cloud Operations team implements, configures, and maintains security controls. 43 | 44 | GSA Information Security supports and monitors the cloud.gov team, including the ISSO who serves as a liaison between GSA Information Security and the cloud.gov team. 45 | 46 | The cloud.gov 3PAO provides third-party verification and assessment of cloud.gov security. 47 | 48 | As part of cloud.gov account management and access control, each service has a list of privileged accounts with the identities of the cloud.gov team members who have those privileges. See AC and IA control families for more details. 49 | 50 | See SA-3. 51 | 52 | The cloud.gov program utilizes agile development processes. Changes are made early, often, and iteratively. Functions, ports, and protocols are part of this process. All such configuration is captured in version control and deployed in a fully automated process. Due the complete virtualization of cloud.gov in the AWS GovCloud, and the almost complete automation of the system, these changes can be made immediately and safely as requirements evolve. 53 | 54 | See SA-4 (9). 55 | 56 | cloud.gov itself does not accept personal identity verification (PIV) cards. Customers may configure an enterprise identity provider that directly accepts PIV cards, either as a primary authenticator or a multi-factor authenticator (MFA). 57 | 58 | See SA-4 (10). 59 | 60 | Cloud Operations always obtains complete documentation, including administrator and user documentation, for any technology that is used within cloud.gov. The maintenance of administrator- and user- facing documentation, in the form of version-controlled changes in a code repository or our documentation repository, is an assumed requirement for all changes. Currently, cloud.gov only uses technology whose documentation can be shared publicly. 61 | GSA TTS values transparency and collaboration. All documentation for technologies used by cloud.gov is either linked to directly from https://cloud.gov/docs/, or is shared broadly within GSA via Google Apps for Government. 62 | 63 | See SA-5. 64 | 65 | cloud.gov applies security best practices, including but not limited to: 66 | 67 | 1. Representing the entire system as “code”, so all changes and side effects can be quickly identified 68 | 2. Deploying the system via automated scripts and pipelines, ensuring no mistakes are made in instantiation 69 | 3. Minimizing the network surface area, applying security controls, isolating applications and data in containers, and encrypting connections. 70 | 4. Implementing role-based access controls, applying and enforcing permissions to isolate user to their space. Baseline configurations settings are reviewed on a continual basis to comply with federal mandates and compliance standards. 71 | 5. Documenting changes to the baseline configuration in GitHub for review. Part of this process includes a thorough security analysis of the proposed change prior to the configuration change being implemented on the operational system. 72 | 6. Deploying with every application a standard set of tools for security and monitoring of each application to identify security issues. 73 | For more details please refer to the cloud.gov Configuration Management Policy and security controls CM-2, CM-3, and CM-6. 74 | 75 | See SA-8. 76 | 77 | The Authorizing Official is ultimately accountable for ensuring oversight and compliance in the use of external information systems, and reviews the addition of any external information system with the System Owner and GSA Information Security. The Authorizing Official also accepts the risk of operating any external information system that has not been assessed to a FedRAMP Security Controls Baseline. 78 | The Authorizing Official, System Owner, and GSA Information Security work together to ensure external information systems meet this control where applicable. See the GSA IT Standards Profile and the GSA IT Information Security Policy for additional information. 79 | cloud.gov uses its own monitoring program, or FedRAMP Continuous Monitoring program for external services. 80 | 81 | See SA-9. 82 | 83 | cloud.gov always conducts risk assessments for all technologies and services. See the risk assessment (RA) procedures for details. If a planned change includes integrating a new external service (a service outside the cloud.gov FedRAMP authorization boundary) or changing an external service configuration/usage in a way that may have a security/compliance impact, the cloud.gov Authorizing Official is advised and asked to approve the plan. 84 | 85 | See SA-9 (1). 86 | 87 | All configuration management (CM) on cloud.gov and AWS is performed by developers, so all information related to CM can be found in the CM policies, procedures, and control family documentation. 88 | 89 | See SA-10. 90 | 91 | Deployment artifacts are stored in AWS S3 and distributed by BOSH via the “blobstore”. SHA-1 hashes are checked to verify file integrity throughout the deployment process. 92 | 93 | See SA-10 (1). 94 | 95 | A security assessment plan is created by the FedRAMP Accredited Third Party Assessment Organization (3PAO). It is used for annual assessments conducted by the 3PAO for continuous monitoring of cloud.gov. cloud.gov performs unit and integration testing on the system upon each deployment. Security testing is done automatically and tracked using tools like Nessus, OWASP ZAP and Concourse. Remediations are made by implementing changes to the configuration on configuration management, redeploying and testing. Flaws identified by automated tools are remediated or marked as false as soon as possible. 96 | 97 | See SA-11. 98 | 99 | 100 | For code developed by GSA/TTS, Cloud Operations ensures that a 101 | language-appropriate tool is scanning code for common errors before 102 | our deployment system attempts to release code. Cloud Operations 103 | and any other relevant internal teams are also automatically notified 104 | of any findings. 105 | 106 | Most code managed by cloud.gov are yaml configurations that are not 107 | well-suited to standard code analysis, 108 | 109 | All developer code must be scanned for potential secret leaks before any Git 110 | commit. See IA-5 (7) for details. 111 | 112 | All code is continuously scanned for potentially vulnerable depencides 113 | using GitHub Dependabot 114 | 115 | Where additional scanning for known vulnerabilities on code 116 | dependencies is relevant, Cloud Operations is also working on 117 | ensuring additional automated scanning tools will run. This work 118 | is in progress and will complete in FY2022. 119 | 120 | See SA-11 (1). 121 | 122 | cloud.gov commonly incorporates open source code where the author cannot be held responsible for dynamic scanning. In such cases, cloud.gov takes on responsibility for dynamic scanning. Nessus is the primary tool used for performing dynamic analysis. 123 | 124 | See SA-11 (8). 125 | 126 | 127 | # Version history 128 | 129 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/SA-Policy.md 130 | 131 | * 2016-10: Initial version for authorization 132 | * 2017-09: Security policy link updates 133 | * 2019-12: Update links to GSA security policy 134 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 135 | * 2021-11: Clarify SA-11, code scanning, fix references to 18F 136 | * 2024-05: Update links to GSA Security Policy and Cloud.gov documentation 137 | -------------------------------------------------------------------------------- /SC-Policy.md: -------------------------------------------------------------------------------- 1 | # Systems and communications protection 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * SC-1, SC-6 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * 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 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * SA-5, SA-7, SA-44 11 | 12 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 13 | 14 | ## Purpose 15 | 16 | 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. 17 | 18 | ## Scope 19 | 20 | See the **_Applicability_** section of the GSA IT Security Policy. 21 | 22 | ## Policy overlay 23 | 24 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 25 | 26 | 30 | 31 | # Procedures 32 | 33 | 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. 34 | 35 | Cloud Operations uses AWS multi-factor authentication to access AWS. 36 | 37 | See SC-2, SC-7 (7), SC-7 (8). 38 | 39 | The cloud.gov team uses AWS S3 to store non-public information. 40 | 41 | 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. 42 | 43 | See SC-4. 44 | 45 | cloud.gov uses well-formed Virtual Private Cloud (VPC) firewall rules to reduce the attack surface of hosted components. 46 | 47 | To maintain service resiliency, cloud.gov uses AWS Availability Zones and Elastic Load Balancing, along with real-time resource monitoring and alerting. 48 | 49 | See SC-5, SC-6. 50 | 51 | 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. 52 | 53 | See SC-7, SC-7 (3), SC-7 (18). 54 | 55 | The Cloud Operations team establishes a traffic flow policy for each managed interface. These deny network traffic by default and only allow defined exceptions. 56 | 57 | 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. 58 | 59 | 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. 60 | 61 | See SC-7 (4), SC-7 (5), SC-8, SC-8 (1), SC-13, SC-23. 62 | 63 | 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. 64 | 65 | See SC-7 (13). 66 | 67 | cloud.gov terminates all network connections when sessions end. AWS ELBs are configured to terminate idle connections after 60 seconds of inactivity. 68 | 69 | See SC-10. 70 | 71 | For TLS certificates, cloud.gov only uses certificate authorities that meet 72 | GSA's requirements in [IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69](https://www.gsa.gov/system/files?file=SSL-TLS-Implementation-%5BCIO-IT-Security-14-69-Rev-7%5D-06-12-2023.pdf); 73 | currently our certicate authority is [Let's Encrypt](https://letsencrypt.org/) 74 | 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. 75 | 76 | 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. 77 | 78 | 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. 79 | 80 | 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. 81 | 82 | See SC-12, SC-12 (2), SC-12 (3), SC-17. 83 | 84 | Cloud Operations ensures cloud-gov is always running the latest fully-patched 85 | versions of cryptographic software provided by our operating system vendors. 86 | 87 | Cloud Operations uses the FIPS-certified endpoints and services offered by our IaaS provider when 88 | they have been included in the test suites used by provision systems. Use of 89 | untested endpoints poses operational risks. 90 | 91 | See SC-13 92 | 93 | 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. 94 | 95 | Internally cloud.gov implements PowerDNS and Consul to resolve the names of internal Cloud Foundry components. 96 | See SC-20, SC-21, SC-22. 97 | EBS volumes, RDS, and S3 buckets are encrypted at rest. All system information is in these components. 98 | 99 | See SC-28, SC-28 (1). 100 | 101 | cloud.gov maintains a separate execution domain for each executing process by running within its own self-contained environment (a Garden container). 102 | 103 | See SC-39. 104 | 105 | # Version history 106 | 107 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/SC-Policy.md 108 | 109 | * 2016-10: Initial version for authorization 110 | * 2017-09: Security policy link updates 111 | * 2019-12: Update links to GSA security policy 112 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 113 | * 2021-11: Clarify SC-7(4), SC-13 policies, add CredHub, remove Comodo 114 | * 2023-12: Clarify use of Let's Encrypt 115 | * 2024-05: Update links to GSA Security Policy 116 | 117 | 118 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | **Reporting Security Issues** 3 | 4 | Please refrain from reporting security vulnerabilities through public GitHub issues. 5 | 6 | Instead, kindly report them via the information provided in [cloud.gov's security.txt](https://cloud.gov/.well-known/security.txt). 7 | 8 | When reporting, include the following details (as much as possible) to help us understand the nature and extent of the potential issue: 9 | 10 | - Type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.) 11 | - Full paths of related source file(s) 12 | - Location of affected source code (tag/branch/commit or direct URL) 13 | - Any special configuration required to reproduce the issue 14 | - Step-by-step instructions to reproduce the issue 15 | - Proof-of-concept or exploit code (if available) 16 | - Impact of the issue, including potential exploitation by attackers 17 | 18 | Providing this information will facilitate a quicker triage of your report. 19 | -------------------------------------------------------------------------------- /SI-Policy.md: -------------------------------------------------------------------------------- 1 | # System and information integrity policy 2 | 3 | See [CIO 2100.1P – GSA IT Security Policy](https://www.gsa.gov/directives/files?file=2024-02%2FCC048589%20Final%20Directive%20CIO%202100.1P%20GSA%20Information%20Technology%20Security%20Policy.pdf) 4 | 5 | * Chapter 3, _Policy for Identify Function_, which covers: 6 | * SI-1, SI-2, SI-4, SI-5 7 | * Chapter 4, _Policy for Protect Function_, which covers: 8 | * SI-2, SI-4, SI-7, SI-12, SI-13, SI-14, SI-16, SI-17 9 | * Chapter 5, _Policy for Detect Function_, which covers: 10 | * SI-3, SI-4, SI-8 11 | * Chapter 6, _Policy for Respond Function_, which covers: 12 | * SI-4, SI-5 13 | 14 | The latest version can be found on the [GSA IT Security Policies](https://www.gsa.gov/policy-regulations/policy/information-technology-policy/gsa-it-security-policies) page. 15 | 16 | ## Purpose 17 | 18 | Ensures information systems have not been compromised through system errors, malicious attacks, or unauthorized access during operation and transmission. 19 | 20 | ## Scope 21 | 22 | See the **_Applicability_** section of the GSA IT Security Policy. 23 | 24 | ## Policy overlay 25 | 26 | 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](https://github.com/cloud-gov/cg-compliance-docs/blob/master/TTS-Common-Control-Policy.md). 27 | 28 | 32 | 33 | # Procedures 34 | 35 | The cloud.gov team identifies cloud.gov system flaws, tracks and reports them, and corrects them. 36 | 37 | The Cloud Operations team monitors upstream projects (including Cloud Foundry) for new releases, implements the new releases (including promptly installing newly-released security-relevant patches), and tests patches for effectiveness and potential side effects on information systems before installation. The testing takes place in development and test environments. 38 | 39 | Flaws discovered during security assessments, continuous monitoring, incident response activities, and information system error handling are addressed through the cloud.gov configuration management process. 40 | 41 | The Cloud Operations team uses automated mechanisms, including automated monthly scans, to determine the state of flaw remediation in information system components. cloud.gov management and security staff track the status of flaws identified with automated vulnerability scan tools using the monthly scan results. 42 | 43 | High-risk vulnerabilities are mitigated within thirty days (30); moderate risk vulnerabilities mitigated within ninety days (90). All findings that are not remediated immediately are tracked in the cloud.gov Plan of Action and Milestones (POAM). 44 | 45 | cloud.gov keeps all flaw identifications and remediations stored in machine readable data within its issue tracker. Time between identifications and remediations is always tracked, and is also reflected in the Plan of Actions and Milestones (POAM). 46 | 47 | See SI-2, SI-2 (2), SI-2 (3). 48 | 49 | cloud.gov employs tools at information system entry and exit points to detect and eradicate malicious code with real-time scans, with virus definitions updated hourly. These send alerts to the Cloud Operations team if malicious code is detected. The Cloud Operations team follows the [Security Incident Response Guide](https://github.com/cloud-gov/internal-docs/blob/main/docs/resources/Plans-and-Procedures/security-ir.md) upon detection of any potential security incident. 50 | 51 | All GSA TTS-developed open source code that is used in the cloud.gov system is scanned using static analysis tools. When anyone proposes a change to the code (a pull request), the static analysis tool automatically runs and displays results. 52 | 53 | See SI-3, SI-3 (1), SC-3 (2), SC-3 (7). 54 | 55 | The Cloud Operations team monitors the cloud.gov virtual infrastructure to detect potential attacks and intrusions from internal and external sources, including using automated monitoring tools. Cloud Operations monitors for attacks, indicators of potential attacks, and unauthorized connections, as well as monitoring inbound and outbound communications traffic for unusual or unauthorized activities or conditions. 56 | 57 | All potential incidents identified by these tools are automatically processed through a centralized system that sends the information to a database and a centralized notification system. 58 | 59 | The cloud.gov Program Manager and System Owner ensure intrusion and monitoring tools are protected from unauthorized access by only granting access to certain members from the Cloud Operations team. All monitoring and intrusion information data is protected by limiting accounts to authorized privileged users only and is maintained in secured repositories for review by those members. 60 | The cloud.gov team uses additional sources such as Pivotal, US-CERT Advisories, OMB Mandates, commercial and open source security communities, and other sources to provide indication of increased risk to organizational operations and assets, individuals, other organizations. 61 | See SI-4, SI-4 (1), SI-4 (2), SI-4 (4), SI-4 (5), SI-4 (14), SI-4 (16), SI-4 (23). 62 | When the cloud.gov team receives security directives from GSA Information Security, Cloud Operations implements the directives in accordance with the requested time frames, or notifies the issuing organization of the degree of noncompliance. 63 | See SI-5. 64 | cloud.gov verifies the correct operation of services that detect malicious code, viruses, file integrity, network traffic, and security compliance of the OS using a continuous integration tool (Concourse) and automated monitoring tools. The Cloud Operations team is notified of a failure in security verification via PagerDuty. 65 | 66 | See SI-6, SI-7, SI-7 (1), SI-7 (7). 67 | 68 | All inputs passed to CLI interpreters are pre-screened to prevent the content from being unintentionally interpreted as commands. 69 | All user input submitted via web forms is sanitized to prevent it being interpreted as a system command. 70 | See SI-10. 71 | PagerDuty sends cloud.gov alerts only to a limited set of cloud.gov team members who have privileged access to cloud.gov components (System Owner, Program Manager, Cloud Operations team members). This PagerDuty configuration is the responsibility of the Program Manager, who may delegate this to Cloud Operations team members. 72 | See SI-11. 73 | 74 | 75 | # Version history 76 | 77 | Complete version history: https://github.com/cloud-gov/cg-compliance-docs/commits/master/SI-Policy.md 78 | 79 | * 2016-10: Initial version for authorization 80 | * 2017-09: Security policy link updates 81 | * 2019-12: Update links to GSA security policy 82 | * 2020-11: Update links to GitHub and GSA policies, split controls by CSF, add version history 83 | * 2021-11: Correct org name to GSA TTS 84 | * 2024-05: Update links to GSA Security Policy and Incident Response Guide 85 | -------------------------------------------------------------------------------- /TTS-Common-Control-Policy.md: -------------------------------------------------------------------------------- 1 | 2 | # TTS Common Control Policy 3 | 4 | GSA/TTS has implemented all of the [General Services Administration (GSA)](http://www.gsa.gov)'s formal and documented common control policies. All policies are disseminated to employees and contractors via the [GSA Internal Directives System](https://www.gsa.gov/directives-library) and through required re-occuring trainings via the [GSA Online University](https://gsaolu.gsa.gov). 5 | 6 | The GSA Directives Program, under the Executive Secretariat Division in the Office of Administrative Services (OAS), manages GSA's internal directives issuance process and works with GSA's program offices (inclusive of the GSA Office of the Chief Information Officer and the Technology Transformation Service) to ensure policies stay current given any updates to law, regulation, or operational procedures. 7 | 8 | These policies are managed as part of the general information security policy for the entire GSA organization. 9 | 10 | ## Purpose 11 | 12 | To ensure the consistency of all information security policies. 13 | 14 | ## Scope 15 | 16 | All GSA employees and contracts are subject to these policies. 17 | 18 | ## Roles and responsibilities 19 | 20 | The GSA Office of the Chief Information Security Officer, otherwise known as GSA Information Security, is responsible for ensuring that all employees and contracts are familiar and trained in these policies, and to ensure that appropriate procedures are established and tested. The TTS Technology Portfolio Director acts as the liaison between GSA Information Security and TTS programs, including cloud.gov. The Cloud Operations team is responsible for all procedures and implementations within cloud.gov. 21 | 22 | ## Management commitment 23 | 24 | The GSA Chief Information Security Officer is ultimately responsible for these policies. 25 | 26 | ## Coordination 27 | 28 | GSA Information Security works in close coordination and collaboration with all of the Services of the GSA, including the [Technology Transformation Service (TTS)](https://www.gsa.gov/tts). TTS is home to multiple infrastructure and security experts, so implementations, and recommendations for policy additions and improvements, are constantly coordinated between GSA Information Security, TTS Technology Portfolio, and cloud.gov. 29 | 30 | ## Compliance 31 | 32 | The cloud.gov System Owner is ultimately responsible for ensuring that the procedures within cloud.gov adhere to these policies, and in ensuring cloud.gov maintains its authorization status with the FedRAMP JAB. The FedRAMP program management office (PMO) acts as the Authorizing Official for cloud.gov. 33 | 34 | ## Reviews 35 | 36 | GSA Information Security and the TTS Technology Portfolio review all policies and procedures when new ATOs are required, or once every 3 years, whichever comes first. The teams also review modifications to policies and procedures when modifications become necessary due to changes in law, regulation, or operations. 37 | --------------------------------------------------------------------------------