ATO artifacts requests: CM controls

[danswick]

### CM-2 Baseline Configuration
- [ ] Demonstrate how the DevOps team develops and manages baseline configurations through Cloud Foundry manifest files, Django config files, Cloud Foundry setup files, and the egress access control list (ACL).
- [ ] Demonstrate  these files are version controlled in Github and deployed via Github Actions.
- [ ] 🟡 [_Will need to explain two-branch system_] Demonstrate Three persistent git branches representing each stable deployable environment are maintained
- [x] [_Have not been in operation for a year_] Provide evidence the DevOps team reviews the baseline configuration annually and when there are significant changes to security needs.

### CM-2(2) Baseline Configuration | Automation Support for Accuracy and Currency
- [ ] 🟡 [_This section is incorrect. @ChrisB-16 is updating SSP_] Demonstrate FAC.gov maintains consistent baseline configurations for each environment in GitHub stable branches through composer.lock, package.lock, and Dockerfiles
- [ ] Demonstrate Github actions utilizes baseline configurations available in GitHub for each individual build of an environment, stores logs of all versions used during each build, and combines system component inventories and baseline configuration activities in one central artifact repository.
- [ ] 🟡 [_Need to review "composer" and "Gulp" language in SSP_] Demonstrate the version numbers of operating systems are stored in Dockerfiles. Composer and Gulp files store application framework versions, lists of software installed, and current patch levels.
- [ ] Demonstrate how Baseline configurations are verified at each deploy via SHA hashing

### CM-2(3) Baseline Configuration | Retention of Previous Configurations
- [ ] Demonstrate  backups are taken of the database and static site content prior to each- production deployment.
- [ ] Demonstrate all necessary docker images associated with the previous release are available to GitHub Actions, for redeployment as needed
- [ ] Demonstrate all code and configuration for previous releases are available in GitHub for immediate recall, if needed to support rollback.

### CM-3 Configuration Change Control
- [ ] How do you track, control, and approve changes for FAC?
- [ ] Provide copies of  changes that  are initiated via a ticket in the GitHub Issue system. The ticket should show approval
- [ ] Demonstrate all code is scanned at build time and deployment time via automated Github actions tasks.
- [ ] 🟡 [_This language is not quite accurate, especially w/r/t "the lead dev"_] Demonstrate All changes are stored in Github, where they are kept separate from the baseline code until approved by the lead dev.
- [ ] Demonstrate Configuration change records are automatically created via artifacts in Github (commits and pull requests) and implementation records are made in respective GitHub Issue tickets.
- [ ] [🟢 _GH action logs_]Demonstrate Verbose activity logs are created in Github actions during configuration deployment which are used to monitor and review activities associated with configuration-controlled changes.
- [ ] 🟡 [_"Governance Board" may need revision_] Demonstrate the Governance Board coordinates configuration changes via daily scrum and GitHub Issue tickets.

### CM-3 (1) Configuration Change Control | Automated Documentation, Notification, and Prohibition of Changes
- [ ] Demonstrate FAC.gov uses the GitHub Issue ticketing system to document proposed changes and completion of the scope of work
- [ ] Demonstrate GitHub Issue automatically emails appropriate DevOps Team members when tickets are created or updated
- [ ] Demonstrate GitHub  will notify the System Owner, DevOps Lead, and others who are required to be aware of proposed changes through emails
- [ ] Demonstrate GitHub  tickets themselves will contain approvals or disapprovals per task.
- [ ] Demonstrate all changes are Prohibited to the Production environment until they have been approved through the process of change management within FAC.gov
- [ ] Demonstrate All change documentation to FAC.gov are spread over three storage locations: Google Drive, GitHub  Tickets, and GitHub commits
- [ ] Demonstrate GitHub  will notify the System Owner, DevOps Lead, and others who are required to be aware of changes via email once the ticket is completed.

### CM-3(2) Configuration Change Control | Testing, Validation, and Documentation of the Changes
- [ ] Demonstrate Change code and configuration is validated in GitHub via peer review before being merged into the development branch

### CM-3 (4) Configuration Change Control | Security and Privacy Representatives
- [ ] Does FAC have a representative that is part of a change configuration board

### CM-4 Impact Analyses 
- [ ] Do you perform security impact analysis as part of each change
- [ ] Demonstrate changes to the system implementation are tested in two environments (Dev and Stage) prior to production deployment, allowing potential security impacts to be observed, analyzed, and mitigated

### CM-4 (2) Impact Analyses | Verification of Controls
- [ ] Demonstrate after  deployment to production, changes are verified for proper operation.

### CM-5 Access Restrictions for Change
- [x] Will use MFA artifacts to satisfy

### CM-6 Configuration Settings 
- [ ] Demonstrate FAC.gov configuration is stored in Github and reflects the current configuration settings for components employed within the system. 
- [ ] Demonstrate Configuration is maintained in compliance with best practices based on authorization from the GSA OCISO and AO. Which best practices are employed? . NIST,CIS,STIGS

### CM-6(1) Configuration Settings | Automated Management Application, and Verification
- [ ] Demonstrate Github Actions is configured for deployment and utilizes the CF CLI to configure, initialize, and deploy the FAC.gov application and resources to Cloud.gov. 
- [ ] Demonstrate Deployments that fail during any step of the deployment checks will result in a failed deployment (Github actions stops execution and marks the action as ‘failed’) and must be corrected by a GitHub developer before being allowed to continue

### CM-7 Least Functionality
- [x] Will use AC-4 screenshots to satisfy

### CM-7(1) Least Functionality | Periodic Review
- [ ] Provide a copy of the monthly audit report after Governance Board has review the system for unnecessary or nonsecure software, components, ports, protocols, functions, and services
- [ ] Provide evidence Software, components, ports, protocols, functions, and services that are subject to removal are recorded in a GitHub  ticket

### CM-7 (2) Least Functionality | Prevent Program Execution
- [ ] All software used in the system is GSA approved (GEAR) and/or open source and not subject to license limits.

### CM-7 (5) Least Functionality | Authorized Software – Allow By Exception
- [ ] Demonstrate FAC.gov implements a deny-all permit-by-exception policy and ensures that only approved packages can be deployed wi

### CM-8 System Component Inventory
- [x] We need your most up to date inventory list. See SSPP tables 9-2 and 10-1.

### CM-8 (1) System Component Inventory | Updates During Installation and Removal
- [x] How do you track and update system inventory? Tracked and updated using Terraform. Cloud.gov provides brokered services.

### CM-8 (2) System Component Inventory | Automated Maintenance
- [x] Demonstrate a current, complete, accurate, and readily available inventory of FAC.gov components can be viewed through the Cloud.gov dashboard or through the Cloud.gov CloudFoundry CLI. _Demonstrate cloud.gov dashboard. ClamAV updated regularly during Dev Huddle_.

### CM-8(3) System Component Inventory | Automated Unauthorized Component Detection
- [x] Demonstrate FAC.gov monitors for the presence of unauthorized software through sha hashing and GSA’s Netsparker (now called Invicti) service scanning. _We review monthly Netsparker reports from the ISSO and ticket as needed. Thus far, these reports have only shown "low" issues_.

### CM-8 (6) System Component Inventory | Assessed Configurations and Approved Deviations
- [x] Provide evidence The DevOps team records proposed deviations in configuration utilizing established guidelines in a GitHub ticket. Do you have an example of a documented deviation? _Implemented timeout changes (https://github.com/GSA-TTS/FAC/issues/3906 ). Otherwise, we don’t have any deviations on record that we know of_.

### CM-8 (7) System Component Inventory | Centralized Repository
- [x] Demonstrate all components inside the ATO boundary are also cataloged in the Cloud.gov dashboard. _Screenshare CG dashboard again_.

### CM-9 Configuration Management Plan
- [x] Will use provided CMP plan

[danswick]

We completed the CM control walk-through and artifact requests last week.