Adequately document SA controls in SSP

In order for compliance reviewers to understand our system, we need to update this family of control statements to explain our system (and policies and procedures) in more precise and thorough detail.

Setup

Read the guidance in HOWTO update the SSP before working on this.

SA Google Doc

Acceptance criteria

SA-1:

[ ] This is updated like our other -1 controls. [SRTM]

SA-2:

[x] Part a: This is updated to describe how we "formally define requirements in our delivery process for identifying security requirements during the planning phase of new features being added or changes to existing features in the cloud.gov environment." (Or marked as planned.) [SRTM]
[x] Part b: This is updated to describe how we've "formally implemented capital planning and investment control processes to determine resources required, document the resources required, and allocate the resources required to protect the Cloud.Gov information system". (Or marked as planned.) [SRTM]
[x] Part c: This is updated to describe that we've done this: "establish a discrete line item for Cloud.Gov information security in organizational programming and budgeting documentation. (Or marked as planned.) [SRTM]

SA-3:

[x] Part b: We describe how we've done this, or marked it as planned: "Formally define in the Cloud.Gov SSP and documented the information security roles and responsibilities throughout the Cloud.Gov system development lifecycle". [SRTM]
[x] Part c: We describe how we've done this, or marked it as planned: "formally identified all individuals having information security roles and responsibilities as they relate to the Cloud.Gov environment" [SRTM]
[x] Part d: We describe how we've done this, or marked it as planned: "integrated the security risk management processes identified in the GSA IT Security Procedural Guide: Managing Enterprise Risk, Security Assessment and Authorization, Planning and Risk Assessment (CIO-IT Security-06-30) into the 18F Delivery Process." [SRTM]

SA-9:

[ ] Part c: We've explained we fulfill this requirement; this may involve referencing our upcoming table of services (https://github.com/18F/cg-product/issues/294). SRTM note says: "18F is bound by the acquisition policies enforced by the General Services Administration (GSA), which include CIO P2100.1 (SA-9a_18F_General), GSA Security Language for IT Acquisition Efforts, CIO-IT_Security-09-48 (SA-9b_18F_General), and the Federal Acquisition Regulation (FAR) (SA-9c_18F_General). However, 18F has not demonstrated that continuous monitoring activities are being employed by 18F for the GitHub, Trello, and Slack external service providers on an ongoing basis." [SRTM]

SA-9 (1):

[x] Part a: We've updated this statement to explain with more clarity that this is GSA's responsibility. SRTM note says "As a member of the GSA, this control implementation is outside the responsibilities of 18F personnel and is the responsibility of the Office of the CIO." [SRTM]

SA-9 (2):

[ ] We've updated this statement to explain the actual 18F/TTS/GSA policies we work with. (SRTM note says "the General Services Administration (GSA) requires that any external service provider is required to identify: the functions required for the use of such services, the ports required for the use of such services, the protocols required for the use of such services, and the other services required for the use of such services".) [SRTM]

SA-9 (4):

[ ] This is updated to reflect our actual policies and practices. SRTM note says "the General Services Administration (GSA) requires that any external service receives an Authority to Operate (ATO), which includes the alignment of organizational interests...18F did not demonstrate that the GitHub, Trello, and Slack external service providers had received an ATO from the GSA." [SRTM]

SA-9 (5):

[ ] This statement is updated to more comprehensively describe where we put system data and how we list/define those places (GitHub, Slack, and so on). We may link to https://docs.cloud.gov/ops/third-parties/ or to the services table attachment. [SRTM]

SA-10:

[ ] Part a: This is updated to reflect: "18F requires that system development/integrators perform configuration management during information system component or service design, development, implementation, and operation. Configuration and deployment of the Cloud.Gov platform is managed using BOSH, which is an open source tool for release engineering, deployment, lifecycle management, and monitoring of distributed systems." and reference https://docs.cloud.gov/ops/configuration-management/ [SRTM]
[ ] Part b: This is updated to reflect more precisely that "BOSH configurations are placed under configuration management control." and "SHA-1 hashes are provided as part of all BOSH releases to allow verification of file integrity...deployment artifacts are provided alongside all BOSH releases and include SHA-1 hashes to conduct file integrity checks prior to deployment. Once a BOSH release is ready for deployment, a developer creates a SHA-1 hash of the release and a hash check is conducted to calculate and verify the checksum/hash of the release prior to deployment in the production Cloud.Gov environment." [SRTM]
[ ] Part c: This is updated to reflect more precisely that "pull requests are utilized by 18F to document changes that have been made to a repository on GitHub. Once a pull request is sent, the appropriate parties can review the set of changes, discuss potential modifications, and push follow-up commits if necessary. Once the pull requests unit, integration and user-acceptance testing is reviewed, the pull request is deployed to the production Cloud.Gov environment." [SRTM]
[ ] Part d: This is updated to reflect more precisely that "developers of the Cloud.Gov environment submit pull requests for configuration changes pushed to a repository on GitHub. All source code changes are required to complete unit, integration, and user-acceptance testing prior to being released in the production Cloud.Gov environment...18F documents approved changes via pull requests in the GitHub tool. In addition, 18F conducts unit, integration, user-acceptance, and static code analysis to identify and document potential security impacts of proposed changes in the Cloud.Gov environment." [SRTM]
[ ] Part e: This is updated to reflect more precisely that "security flaws are tracked via the 18F continuous integration continuous deployment (CI/CD) pipeline...18F tracks security flaws via the 18F continuous integration continuous deployment (CI/CD) pipeline for each Cloud.Gov build." and also to explain any "processes and procedures in place for reporting security flaws identified as part of unit, integration, user-acceptance, and static code analysis to the System Owner (SO), Information System Security Officer (ISSO), and Security Operations." [SRTM]

SA-11:

[ ] Part a: This is updated to reflect: "This requirement is not referring to the SAP that’s developed as part of the annual assessment process. It’s referring to an internal security assessment plan that describes how you test & evaluate your code (everything you describe in parts b through e)." [PMO comment]
[ ] Part a: This is updated to describe "processes and procedures requiring developers to create and implement security plans for changes made to the Cloud.Gov environment." [SRTM]
[ ] Part b: This is updated to describe more precisely "developers are required to conduct unit, integration, and user-acceptance testing for all Cloud.Gov deployments." and "The results of all testing/evaluation is maintained in the Cloud.Gov continuous integration continuous deployment (CI/CD) pipeline." [SRTM]
[ ] Part c: This is updated to describe more details along the lines of part b (or just say see part b). [SRTM]
[ ] Part d: This is updated to describe "18F requires developers/integrators to perform testing on development changes and remediate any identified flaws prior to release into the production environment." and "18F requires developers/integrators to remediate any failures/flaws identified as part of unit, integration, and user-acceptance testing prior to release into the production environment. The results of all remediation efforts are maintained in Cloud.Gov continuous integration and continuous deployment (CI/CD) pipeline." [SRTM]
[ ] Part e: This is updated to describe more details along the lines of part e (or just say see part e). [SRTM]

SA-11 (1):

[ ] This describes in more detail that "the Cloud Foundry community utilizes the Code Climate static code analyzer on platform components such as BOSH and Cloud Controller. The results of the scan are publicly available and can be conducted by 18F at any time." and "18F conducts regular static code analysis for all Cloud.Gov deployments prior to release into the production environment." [SRTM]

SA-11 (2):

[ ] Statement is checked for accuracy and whether we can add any detail. [SRTM]

SA-11 (8):

[ ] This describes in more detail that we use the "Gemnasium third-party tool to identify dependencies in Cloud.Gov deployments and alert when security vulnerabilities are identified in those dependencies." and any other relevant details. [SRTM]

SA overall:

[ ] Check that responsible roles, parameters, implementation statuses, control originations, and control statements make reflect our system and make sense overall.

Implementation guidance

During grooming, take items from the following and list them as specific tasks above.

[x] Required JAB reviewer items (additional notes here)
[x] SRTM items identified by our 3PAO as "moderate" differential (if not already marked green there).
[x] SRTM items identified by our 3PAO as "low" differential (if not already marked done there).
[x] Word doc comments (in Google Drive) from our ISSO (which provide a helpful reader perspective on confusing bits). They don't all need to be addressed, but useful as guidance.
[x] Word doc comments (in Google Drive) from our PMO (which provide a helpful reader perspective on confusing bits). They don't all need to be addressed, but useful as guidance.
[x] Any relevant notes in the SSP check working space
[x] Check that control origination statements make sense (look for notes here and look through the controls); if you change a checkbox, make a note in that spreadsheet.

cloud-gov / product

Adequately document SA controls in SSP #271