Closed woodt closed 4 years ago
Met with Aaron on Friday 12/20 to discuss ... will add notes to this ticket.
Because there is a little uncertainty in the exact ATO path we'll take, we agreed to take a "good intentions" approach to hardening that is likely to meet our ATO needs as well as improve the security of the system.
Roughly, we will be deploying two types of components:
(1) components that consist of a server running an operating system. Examples would be an EC2 instance. These components will require OS-level hardening in accordance with a benchmark/baseline. Examples include: DISA STIG; CIS Linux Benchmarks, etc. We recommend a benchmark where automated tools exist to assert compliance and generate remediation. For example, CivicActions has developed some automation to couple RHEL AMI generation with OpenSCAP scans and remediation.
(2) components that consist of a container (Docker) executing an image. For these components, operating system hardening is the responsibility of the host execution environment. However, we still recommend that images be scanned for vulnerabilities. Example scanners include: Clair (from CoreOS) and Trivy (AquaSecurity). Container image scanning should be made part of the CI/CD pipelines that produce images.
As a discovery step, we should try running Trivy against our existing images to establish an early baseline.
Here's a gitlab CI config to demonstrate how to run Trivy against a sample of our images, and attached is the output from a recent run.https://app.zenhub.com/files/153296282/74ee2c6a-2239-43ec-ade0-2dfc2f4a18e8/download
stages:
- test
trivy:
stage: test
variables:
before_script:
- export VERSION=$(curl --silent "https://api.github.com/repos/aquasecurity/trivy/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
- echo $VERSION
- wget https://github.com/aquasecurity/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz
- tar zxvf trivy_${VERSION}_Linux-64bit.tar.gz
allow_failure: true
script:
- ./trivy --exit-code 0 --cache-dir $CI_PROJECT_DIR/.trivycache/ --no-progress --severity HIGH viderum/ckan-cloud-operator:0c858ff167f3e13f52e8f540763c401921e450d1
- ./trivy --exit-code 0 --cache-dir $CI_PROJECT_DIR/.trivycache/ --no-progress --severity HIGH viderum/ckan-cloud-provisioning-api:8e40b66e09e5c81909c18a94e78d06c8ad9ec15f
- ./trivy --exit-code 0 --cache-dir $CI_PROJECT_DIR/.trivycache/ --no-progress --severity HIGH viderum/ckan-ng-harvest:1577475384
cache:
paths:
- $CI_PROJECT_DIR/.trivycache/
@woodt looks good. So what do you suggest for next steps? We now have an Ubuntu AMI built, so where should we insert the hardening? @akariv are you okay if we apply the CIS benchmark to this AMI, or should this be done as a GSA image?
For containers, should we create an issue to add trivy to ckan-cloud-docker? @akariv again, not sure if this should be done at the datopian level, or if this should be considered GSA specific.
Here's the packer template that builds the CCO AMI.
Created tickets for image hardening and for container scanning:
Aaron to take a look at tickets and close
Looks good, thanks!
This is needed to implement security controls CM-2 BASELINE CONFIGURATION and CM-6 CONFIGURATION SETTINGS.