Container Risks

Gaining Visibility into NIST SP 800-190, Part Six

In part five of this series, I described how native AWS tools and third-party solutions can address orchestrator risks identified in section 3.3 of the NIST SP 800-190 Application Container Security Guide. In this post we’ll explore section 3.4 of the guide: Container Risks (3.4) and Container Countermeasures (4.4). We will again leverage our lab environment, which utilizes AWS EKS and Palo Alto Networks Prisma Cloud (formerly Twistlock).

Container technologies, such as Docker, LXC and Heroku, allow developers to assemble code and associated dependencies into a single package or container image. Container images can be run within their respective engines (like Docker Engine) and deployed quickly using a container orchestration technology, such as Kubernetes, Docker Swarm or Nomad.

Managing container security is key to the DevOps process. Areas like runtime software vulnerabilities, unbounded network access from containers, insecure container runtime configurations, application vulnerabilities and rogue containers should be thoroughly reviewed when planning a DevOps lifecycle involving container technology.

3.4.1 Vulnerabilities Within the Runtime Software
In the containers context, vulnerabilities with runtime software present a lower risk profile. However, they can be especially damaging when factoring in the potential for a threat actor to use the vulnerability to escape the container and attack other resources. Damaging modifications or the planting of a trojan are tactics that should be accounted for.

NIST SP 800-190 offers this guidance on Vulnerabilities within the Runtime Software:

Scanning containers for vulnerabilities addresses the issue of vulnerable runtime binaries. Utilizing policy, Palo Alto Networks’ Prisma Cloud can assess newly created containers before they’ve been instantiated. Any alert raised immediately blocks the container from being deployed. Prisma Cloud can also be configured to continually reassess containers for vulnerabilities at a predetermined scan interval, with the default being 24 hours.

Figure 1 - Container Vulnerabilities - Runtime Compliance

Figure 2 - Figure 2 – Monitor/Compliance (Containers)

3.4.2 Unbounded Network Access from Containers
In most environments, communication between containers and the host OS is unrestricted. In the event of a compromised container, the lack of network segmentation could potentially expose other containers in the environment to attack. An example of this could be reconnaissance, exploitation and subsequent lateral movement to another host within the cluster.

NIST SP 800-190 offers this guidance on Unbounded Network Access from Containers:

Prisma Cloud’s Runtime Defense technology can build predictive models for each image in an environment. These network models can identify malicious ingress activity, like containers that create unexpected network listeners, as well as identifying malicious egress traffic connections to unexpected and known malicious destinations.

Figure 3 - Runtime Defense Technology - Monitor/Runtime/Incident Explorer

In addition, the built-in Cloud Native Network Firewall (CNNF) uses machine learning (ML) to model observed network traffic between containers. The CNNF uses this traffic observation to whitelist known good traffic. Visibility and inspection into east-west traffic minimizes the potential damage of a container breach by limiting the attacker’s ability to move laterally.

Figure 4 - Runtime Defense Technology - Monitor/Events (CNNF)

3.4.3 Insecure Container Runtime Configurations
Insecure container runtime configurations can impact an organization’s threat profile. Typically, the set of system calls is limited to only those required for safe operation. If the list is expanded, containers or possibly even the host OS can be at risk. Containers running in privileged mode, with its access to all devices on a host, can increase risk by exposing the host OS and all containers within.

NIST 800-190 3.4.3 also addresses the risk from insecure containers’ ability to mount sensitive directories on the host OS. In an ideal setting, containers should be abstracted from the host OS and rarely, if ever, should be able to make changes to the host OS file system. They should also never be able to make change to locations that control a system’s basic functionality. In Linux containers, this would be /boot and in Windows containers, this would be C:\Windows.

NIST SP 800-190 offers this guidance on Insecure Container Runtime Configurations:

One way to measure compliance for runtime standards is to assess the container’s runtime configurations against the Center for Internet Security’s Docker Benchmark. The CIS Docker benchmark, used by Prisma Cloud, provides details on container options and recommended settings. Automation of such container runtime vulnerability assessments is recommended by NIST to help scale the assessment process. Within Prisma Cloud, Critical and High checks are enabled by default so security practitioners can focus on the most serious issues in their environment.

Figure 5 - Monitor/Compliance (Containers)

Native mandatory access controls within the OS, like SELinux and AppArmor, can provide additional security controls for containers running Linux OSs. These technologies help harden the container by constructing a zero-trust segmentation around the permitted binary and associated processes, allowing only specific file paths, processes and network sockets.

Secure computing profiles (seccomp) are another method of constraining the permitted resources and protecting the container at runtime. As noted in NIST SP 800-190, “common container runtimes, like Docker, include default seccomp profiles that drop unsafe system calls that are unrequired for container operations.” Prisma Cloud Labs provides curated custom seccomp profiles for widely used containerized apps, like Apache and MongoDB.

Figure 6 - Monitor/Runtime (Container Models)

3.4.4 App Vulnerabilities
While the recommendations in the NIST SP 800-190 guide provide some coverage in addressing potential container risks, vulnerabilities in the applications that the containers run still add risks of compromise. When a container is compromised in this fashion, the countermeasures mentioned throughout the series become much more critical.

Prisma Cloud Runtime Defense helps secure containers by modeling each container image and then using the models to detect abnormal activity. Runtime Defense is enabled by default.

Models have four dimensions: processes, networking, file system and system calls. Runtime Defense sensors can protect against all of the events outlined above:

Figure 7 - Defend/Runtime (Container Policy)

Prisma Cloud ships with CIS Docker Benchmark compliance check 5.12 automatically enabled. Wth the CIS Docker Compliance check in place, an alert will be raised if a container mounts its root filesystem with any permission other than read-only.

3.4.5 Rogue Containers
Due to the dynamic nature of DevOps, where new systems and services are constantly being spun up and down, unsanctioned containers can be common within the development environment. These rogue containers, potentially vulnerable to attack, could be inadvertently introduced into production environments.

Prisma Cloud addresses the concept of rogue containers with a number of controls. It’s role-based access controls allows for policies limiting who can access resources in an environment. Rules allow Prisma Cloud users to target specific hosts, images, containers and labels with pattern-matching expressions.

Figure 8 - Defend/Access (Default Deny-All Policy)

To provide additional visibility, Prisma Cloud logs all Docker and Kubernetes commands, along with the user who ran them. It also assesses containers for vulnerabilities and compliance issue before any container is run. For policy violations resulting in a raised alert, the container is blocked from operating.

The NIST SP 800-190 Application Container Security Guide is an invaluable tool for any cybersecurity professionals looking to obtain greater visibility into container security risks.

In the seventh and final blog in this series, we’ll consider the challenges surrounding host OS risks and countermeasures.