Container Security Issues and Approaches

Compared to VMs, containers are much smaller and more efficient. For an application to run in a virtual machine, the application runs on a guest operating system, and the guest operating system requires a hypervisor on a server. Containers share the host operating system kernel with other containers via API calls. Organizations that adopt containers need to accept responsibility for securing them and should stay informed about new container vulnerabilities as the industry discovers them. Sharing of the host operating system kernel is one of the primary benefits of containers, but it’s also the crux of security concerns with containers. The lack of proper isolation between containers and the kernel during runtime means that a vulnerability in the shared OS kernel can be used to gain access to or exploit the containers. Another element of concern in securing containers is their volatile and dynamic nature. Hundreds or thousands of containers can be created or destroyed in an instant to scale with demand. 

Given the above, the challenges to enforce, monitor and resolve security issues of containers, are demanding. In most organizations, this poses a real challenge given the dynamic nature of most environments. The solution rests squarely with a 3^rd party solution but does compel careful evaluation based on some requisite baseline standards.

Use vulnerability management as part of your container development lifecycle

By using effective vulnerability management throughout the container development lifecycle, you improve the odds that you can identify and resolve security concerns before they become a more serious problem.

❓ Checklist item: Does the tool have a method to incorporate scanning and enforcement in the CI/CD process?

Scan for vulnerabilities before pushing images to the registry

A container image registry is a service that stores container images and is hosted either by a partner or as a public/private registry such as DockerHub and Quay.

As a final check after container development is complete, you should perform a vulnerability scan on containers before pushing the images to the registry.

❓ Checklist item: Are the images scanned by the tool before being uploaded to the local repo?

Continue scanning in the registry

New vulnerabilities are discovered all the time, so scanning for and identifying vulnerabilities is a continuous process. Continue to scan container images in the registry both to identify any flaws that were somehow missed during development and to address any newly discovered vulnerabilities that might exist in the code used in the container images.

❓ Checklist item: Does the tool incorporate runtime controls allow to detect and stop suspicious behaviors such as port scanning, connecting to IP address with bad reputation and Fork Bomb denial of service attacks?

Map image vulnerabilities to running containers

You need to have a means of mapping vulnerabilities identified in container images to running containers, so security issues can be mitigated or resolved. 

❓ Checklist item: Does the tool have the ability to map vulnerabilities, not only in images, but in the containers they run in? Moreover, do the discovered vulnerabilities use CVE’s, CVSS and other standard severity measurements?

Ensure that only approved images are used in your environment

There’s enough change and volatility in a container ecosystem without allowing unknown containers as well. Allow only approved container images. Have tools and processes in place to monitor for and prevent the use of unapproved container images. An effective way of reducing the attack surface and preventing developers from making critical security mistakes is to control the flow of container images into your development environment. Image signing or fingerprinting can provide a chain of custody that enables you to verify the integrity of the containers.

❓ Checklist item: Does the tool incorporate Image Assurance which enables persistent controls to ensure image integrity throughout its lifecycle and preventing unapproved or unvetted images from running?

Enforce least privileges in runtime

The concept of least privileges is a basic security best practice that also applies to containers. When a vulnerability is exploited, it generally gives the attacker access and privileges equal to those of the compromised application or process. Ensuring that containers operate with the lowest privileges and access required to get the job done reduces your exposure to risk.

❓ Checklist item: Does the tool have the ability to prevent containers from obtaining escalated privileges? (e.g. access to host network, user or host namespaces, root, etc.)

Reduce the container attack surface by removing unneeded privileges

You can also minimize the potential attack surface by removing any unused or unnecessary processes or privileges from the container runtime.

❓ Checklist item: Does the tool have the ability to perform added security controls in real-time? (e.g. port blocking, fork guard, drift protection, IP reputation, port scanning detection)

Whitelist files and executables that the container is allowed to access or run

Reducing the number of variables or unknowns helps you maintain a stable, reliable environment. Limiting containers so they can access or run only preapproved or whitelisted files and executables is a proven method of limiting exposure to risk. A whitelist provides a measure of control and manageability as you learn what files and executables are required for the application to function correctly. A whitelist not only reduces the attack surface but can also provide a baseline for anomalies and prevent the use cases of the “noisy neighbor” and container breakout scenarios.

❓ Checklist item: Does tool have the ability to perform whitelisting and blacklisting of executables?

Enforce network segmentation on running containers

To help protect containers in one segment from security risks in another segment, maintain network segmentation (or nano-segmentation) or segregation between running containers.

❓ Checklist item: Does tool have the ability to firewall and monitor network activities in real-time? (e.g. identifies all inbound and outbound network connections to/from other containers, services, IP addresses, and the public internet.)

Monitor container activity and user access

As with any IT environment, you should consistently monitor activity and user access to your container ecosystem to quickly identify any suspicious or malicious activity.

❓ Checklist item: Does tool have the ability to monitor user access and alert suspicious activity?

Monitor container resource activity

Monitor your resource activity, like files, network, and other resources that your containers access. Monitoring resource activity and consumption is useful both for performance monitoring and as a security measure.

❓ Checklist item: Does tool have the ability to monitor resource activity?

Log all container administrative user access for auditing

Maintain an accurate audit trail of administrative access to your container ecosystem, container registry, and container images. These logs might be necessary for auditing purposes and will be useful as forensic evidence after any security incident.

❓ Checklist item: Does tool have the ability to connect to a SIEM to not only alert but log and backup system data?