Chainguard produces hardened, minimal container images with zero-to-low CVEs. As such, Chainguard Images adhere with the majority of compliance standards where there’s a control for vulnerability/risk management, such as FedRAMP and PCI DSS v4.0 to name a few.
For many risk management frameworks, the system categorization will result in varying levels of hardening guidelines. Specifically for FedRAMP, FIPS-199 defines the security categorization which will result in a baseline set of controls (defined in NIST 800-53) that must be implemented. Since NIST 800-53 controls are technology neutral requirements, DISA Security Technical Implementation Guides (STIGs) provide technology specific configurations on how to satisfy the applicable NIST 800-53 control set. As stated in the CM-6 (a) Requirement 1:
“The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available.”
However, the requirements for how a STIG applies to an image are vague and not easily digestible. For example, some controls apply to the host operating system instead of the image. Similarly, other controls apply to the Docker service instead of the container itself. Knowing what controls are relevant for containers and how to check for them in a STIG are key to achieving and maintaining FedRAMP compliance.
DISA understands that containers have different requirements than traditional operating systems and the DOD DevSecOps Initiative released the Container Hardening Process Guide which describes the DSOPS approach to hardening and how other agencies should deal with applying STIGs to containers.
The Hardening Process Guide makes two key points on how to approach STIG compliance for containers.
In Section 5:
"With a properly locked down hosting environment, containers inherit most of the security
controls and benefits from infrastructure to host OS-level remediation requirements."
In Section 6:
"If an OpenSCAP scan returns noncompliant result(s), always evaluate the validity of those findings. False positives are common within major host OS-based containers, as the security profiles normally account for all host-level controls potentially not applicable to a container build (e.g., GUI, CAC authentication, etc.). In addition to false positives, many of the base OS STIG requirements are not applicable in the containers either."
Deploying containers on a STIG hardened host provides many of the security features that are difficult or sometimes impossible to implement inside a container. What's left is the application-level security configuration - in particular vulnerability remediation - which Chainguard provides through our guaranteed vulnerability remediation SLAs.
Once a container has been deployed, tools such as OpenSCAP must be used to validate the container's hardening. Those scans will return false positives when they detect missing components inside the container which are inherited from the host where the container is running.
It can be difficult to determine exactly which results are false positives and which ones should be applied to a container. To help disambiguate, we have put together the following list of explanations for requirements from the General Purpose Operating System STIG that are likely to turn up when scanning containers and the rationale for marking those results as false positives.
The following guide should be helpful to any administrators deploying containers in environments where STIG hardening is necessary - both as a means to understand where to expend effort performing hardening and for discussions with assessors and compliance personnel.
Auditing
Linux containers utilize the host's kernel, making it impossible to install and operate a separate auditing package inside the container itself. Instead, auditing information must be configured and collected through the audit configuration of the host.
Once configured, logs of container actions are written to the host's audit log files and are readable only by the host superuser account. These logs must be collected from the host for incident response and reporting. Storage capacity limits, audit process monitoring, remote upload of logs, and associated alerts are the responsibility of the host where the containers are running.
Isolation
Containers provide process isolation by executing their applications in a constrained environment using the Linux Namespace and cgroup subsystems. Inside the namespace, container processes are only permitted to access a limited set of system resources defined when the container is launched.
Processes are further restricted by limits imposed through the cgroup for access to system resources such as system memory or cpu utilization. Cgroups protect the host resources and other containers running on the host from being impacted by Denial of Service attacks on a targeted container.
Together, namespaces and cgroups isolate security functions of the host operating system from non-security functions of applications running inside the container. The separation makes it possible for container failures to not directly impact the operation of the host and its security functions when caused through processing of invalid inputs or other runtime errors. In the event of a container failure during initialization, shutdown, or abort, the host operating system's security capabilities will continue to function as configured.
Minimal images
Chainguard Images contain only the minimal software needed for the container to perform its intended function. Non-essential capabilities such as software installers, shell environments, executables, and process launching functions have been removed from the images and may not be installed once the container is running.
The limited implementation enables only the necessary software to operate on the running container and restricts the installation of additional software on the image during operating. Software that is installed is prevented from being modified by fixed permissions on libraries and executable files.
The host's container execution environment further reduces the risk of unauthorized modification of software through Linux container isolation capabilities including namespaces and cgroups. These restrictions prevent unauthorized modification of the host operating system environment.
ASLR (address space layout randomization)
ASLR configuration is the responsibility of the host operating system where containers run. Applications executed inside a container on a host that has ASLR enabled will automatically be protected by the configuration. No additional action is needed to ensure that container-based applications are protected.
Host firmware
Linux containers inherit the firewall configuration of their host operating system which dictates which ports on the container can be accessed from the network. Selection of which ports to make accessible on the applications running on the container is the responsibility of the host firewall configuration — an additional application-level firewall inside the container is not necessary.
Host filesystem
Linux containers utilize the host filesystem for storage of their files and configuration. Protecting data at rest inside containers from unauthorized access or modification must be configured at the host operating system such as encrypted virtual filesystems. The host filesystem is also responsible for the size, utilization, and capacity of the physical disks that are used by containers running on that host.
Vulnerability scanning
Container vulnerability scanning is performed by the team deploying the container and can be executed from the host operating system or against the container image when it is stored in a registry. Continuous scanning can be used to detect vulnerabilities that have been identified / announced since the previous scan and determine when updated images should be built and deployed in the environment.
Time
Linux containers inherit the system time from the underlying host — a separate time service is not operated within the container. The host owner is responsible for configuring the host's time service to generate the timestamp used by its auditing system, perform periodic synchronization, and ensure that only authorized time servers are used as the authoritative source. Time synchronization of the host clock is automatically reflected in the time used by the container.
STIG (Security Technical Implementation Guides)
These containers can be validated against the General Purpose Operating STIG and other applicable STIGs using the OpenSCAP tool. OpenSCAP can validate configuration of container images by reviewing the configuration of the image filesystem and can perform interactive checks by executing commands against running containers.
Interested in participating in the Chainguard STIG Early Access Program?
The STIG is now available through the Early Access Program (EAP). If you’re interested in participating in the EAP, please fill out the interest form or email compliance@chainguard.dev and someone will be in touch with you shortly!
