NIST 800-190 Application Container Security Risk Checklist

1. Image vulnerabilities :: Use tools that take the pipeline-based build approach and immutable nature of containers and images into their design to provide more actionable and reliable results.

2. Image configuration defects :: Adopt tools and processes to validate and enforce compliance with secure configuration best practices. For example, images should be configured to run as non-privileged users.

3. Embedded malware :: Monitor all images for embedded malware. The monitoring processes should include the use of malware signature sets and behavioral detection heuristics based largely on actual “in the wild” attacks.

4. Embedded clear text secrets :: Store the secrets outside of images and provided dynamically at runtime as needed. Most orchestrators, such as Docker Swarm and Kubernetes, include native management of secrets.

Integrate container deployments with existing enterprise secret management systems that are already in use for storing secrets in non-container environments.

These tools typically provide APIs to retrieve secrets securely as containers are deployed, which eliminates the need to persist them within images.

Regardless of the tool chosen, ensure that secrets are only provided to the specific containers that require them, based on a pre-defined and administrator-controlled setting, and that secrets are always encrypted at rest and in transit using Federal Information Processing Standard (FIPS) 140 approved cryptographic algorithms5 contained in validated cryptographic modules.

5. Use of untrusted images :: Maintain a set of trusted images and registries and ensure that only images from this set are allowed to run in their environment, thus mitigating the risk of untrusted or malicious components being deployed.

1. Insecure connections to registries :: Configure development tools, orchestrators, and container runtimes to only connect to registries over encrypted channels. Expect the specific steps will vary between tools, but the key goal is to ensure that all data pushed to and pulled from a registry occurs between trusted endpoints and is encrypted in transit.

2. Stale images in registries :: The risk of using stale images can be mitigated through two primary methods.

- First, prune registries of unsafe, vulnerable images that should no longer be used. This process can be automated based on time triggers and labels associated with images.

- Second, operational practices should emphasize accessing images using immutable names that specify discrete versions of images to be used.

3. Insufficient authentication and authorization restrictions :: All access to registries that contain proprietary or sensitive images should require authentication. Any write access to a registry should require authentication to ensure that only images from trusted entities can be added to it.

Consider federating with existing accounts, such as their own or a cloud provider's directory service to take advantage of security controls already in place for those accounts. All write access to registries should be audited and any read actions for sensitive images should similarly be logged.images should similarly be logged.

1. Unbounded administrative access :: Especially because of their wide-ranging span of control, orchestrators should use a least privilege access model in which users are only granted the ability to perform the specific actions on the specific hosts, containers, and images their job roles require.

2. Unauthorized access :: Access to cluster-wide administrative accounts should be tightly controlled as these accounts provide ability to affect all resources in the environment.

- Use strong authentication methods, such as requiring multifactor authentication instead of just a password.

- Implement single sign-on to existing directory systems where applicable. Single sign-on simplifies the orchestrator authentication experience, makes it easier for users to use strong authentication credentials, and centralizes auditing of access, making anomaly detection more effective.

- Use tools for encrypting data used with containers that allow the data to be accessed properly from containers regardless of the node they are running on.

3. Poorly separated inter-container network traffic :: Configure orchestrators to separate network traffic into discrete virtual networks by sensitivity level. While per-app segmentation is also possible, for most organizations and use cases, simply defining networks by sensitivity level provides sufficient mitigation of risk with a manageable degree of complexity.

4. Mixing of workload sensitivity levels :: Configure orchestrators to isolate deployments to specific sets of hosts by sensitivity levels. The particular approach for implementing this varies depending on the orchestrator in use, but the general model is to define rules that prevent high sensitivity workloads from being placed on the same host as those running lower sensitivity workloads. This can be accomplished through the use of host 'pinning' within the orchestrator or even simply by having separate, individually managed clusters for each sensitivity level.

5. Orchestrator node trust :: Configure orchestrators to provide features that create a secure environment for all the apps they run.

- Ensure that nodes are securely introduced to the cluster, have a persistent identity throughout their lifecycle, and can also provide an accurate inventory of nodes and their connectivity states.

- Ensure that orchestration platforms are designed specifically to be resilient to compromise of individual nodes without compromising the overall security of the cluster. A compromised node must be able to be isolated and removed from the cluster without disrupting or degrading overall cluster operations.

- Consider choosing orchestrators that provide mutually authenticated network connections between cluster members and end-to-end encryption of intracluster traffic. Because of the portability of containers, many deployments may occur across networks organizations do not directly control, so a secure-by-default posture is particularly important for this scenario.

1. Vulnerabilities within the runtime software :: Use tools to look for Common Vulnerabilities and Exposures (CVEs) vulnerabilities in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes.

2. Unbounded network access from containers :: Control the egress network traffic sent by containers. At minimum, these controls should be in place at network borders, ensuring containers are not able to send traffic across networks of differing sensitivity levels, such as from an environment hosting secure data to the internet, similar to the patterns used for traditional architectures.

Use a combination of existing network level devices and more app-aware network filtering. App-aware tools should be able to not just see the intercontainer traffic, but also to dynamically generate the rules used to filter this traffic based on the specific characteristics of the apps running in the containers. Dynamic rule management is a challenging and critical due to the scale and rate of change of containerized apps, as well as their ephemeral networking topology.

3. Insecure container runtime configurations :: Configure orchestrators to separate network traffic into discrete virtual networks by sensitivity level. While per-app segmentation is also possible, for most organizations and use cases, simply defining networks by sensitivity level provides sufficient mitigation of risk with a manageable degree of complexity.

4. Mixing of workload sensitivity levels :: Automate compliance with container runtime configuration standards.

Consider using se a variety of tools to “scan” and assess their compliance at a point in time, but such approaches do not scale. Instead, organizations should use tools or processes that continuously assess configuration settings across the environment and actively enforce them.

Additionally, mandatory access control (MAC) technologies like SELinux and AppArmor provide enhanced control and isolation for containers running Linux OSs.

Secure computing (seccomp) profiles are another mechanism that can be used to constrain the system-level capabilities containers are allocated at runtime. Common container runtimes like Docker include default seccomp profiles that drop system calls that are unsafe and typically unnecessary for container operation. Additionally, custom profiles can be created and passed to container runtimes to further limit their capabilities. At a minimum, organizations should ensure that containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps.

5. App vulnerabilities :: Implement additional tools that are container aware and designed to operate at the scale and change rate typically seen with containers. These tools should be able to automatically profile containerized apps using behavioral learning and build security profiles for them to minimize human interaction. These profiles should then be able to prevent and detect anomalies at runtime.

Containers should also be run with their root filesystems in read-only mode. This approach isolates writes to specifically defined directories, which can then be more easily monitored by the aforementioned tools. Furthermore, using read-only filesystems makes the containers more resilient to compromise since any tampering is isolated to these specific locations and can be easily separated from the rest of the app.

6. Rogue containers :: Consider instituting separate environments for development, test, production, and other scenarios, each with specific controls to provide role-based access control for container deployment and management activities. All container creation should be associated with individual user identities and logged to provide a clear audit trail of activity.

Use security tools that can enforce baseline requirements for vulnerability management and compliance prior to allowing an image to be run.

1. Large attack surface :: Use these minimalistic OSs to reduce their attack surfaces and mitigate the typical risks and hardening activities associated with general-purpose OSs.

2. Shared kernel :: Do not mix containerized and non-containerized workloads on the same host instance. For example, if a host is running a web server container, it should not also run a web server (or any other app) as a regularly installed component directly within the host OS. Keeping containerized workloads isolated to container-specific hosts makes it simpler and safer to apply countermeasures and defenses that are optimized for protecting containers. 3. Host OS component vulnerabilities :: Implement management practices and tools to validate the versioning of components provided for base OS management and functionality.

Use tools provided by the OS vendor or other trusted organizations to regularly check for and apply updates to all software components used within the OS software components used within the OS.

4. Improper user access rights :: Ensure that all authentication to the OS is audited, login anomalies are monitored, and any escalation to perform privileged operations is logged.

5. Host file system tampering :: Ensure that containers are run with the minimal set of file system permissions required.

Consider using tools that can monitor what directories are being mounted by containers and prevent the deployment of containers that violate these policies.

6. Hardware Countermeasures :: Hardware root of trust is not a concept unique to containers, but container management and security tools can leverage attestations for the rest of the container technology architecture to ensure containers are being run in secure environments.

TPM-enabled devices can check the integrity of the machine during the boot process, enabling protection and detection mechanisms to function in hardware, at pre-boot, and in the secure boot process. This same trust and integrity assurance can be extended beyond the OS and the boot loader to the container runtimes and apps. Note that while standards are being developed to enable verification of hardware trust by users of cloud services, not all clouds expose this functionality to their customers. In cases where technical verification is not provided, organizations should address hardware trust requirements as part of their service agreements with cloud providers.