Today’s #1 Attack: Zero-day exploits of new and previously unknown vulnerability in apps and OSs
Container Security Top Challenges: Lack of adequate and disparate security tools, vulnerabilities in images, and the need for granular access-control between containers
Based on 450 IT/information security peers’ responses, across different industries, ESG survey results show that fewer than 50% of organizations already have between a few to large numbers of containerized applications in production, and adoption is expected to accelerate to 80% by 2020. Is your organization primed and ready to protect these new workloads?
According to the survey, although there are containerized applications in production, especially new applications, many organizations are still trying to keep pace with this new dynamic environment while having to juggle both internal and external challenges.
Some examples of in-house challenges related to container security include: the use of inadequate and disparate legacy security solutions that do not support the container environment, the abundance of vulnerabilities in container images, and the need for granular control of access between containers to prevent unauthorized communication flows.
When respondents were asked to comment on the greatest hybrid cloud security challenges, they again indicated that maintaining strong and consistent security across their own data centers and multiple public cloud environments was their #1 challenge.
In addition to the many internal challenges, organizations are continuously dealing with a diverse range of threats to their cloud environments. The top reasons for this are due to new and previously unknown vulnerabilities in OSs and apps, known vulnerabilities in unpatched applications, as well as misuse of a privileged account by an insider.
Let’s shed some light on the main concerns:
1. Vulnerabilities in images
Purpose-built or open-source containers may contain known vulnerabilities, malicious backdoors, malware or vulnerabilities discovered after deployment, putting companies at risk. Ideally, DevOps practitioners should only run containers from authorized images. In practice however, security comes second when matched against speed, and developers oftentimes push images to the registry before they can be validated. In addition, re-use of existing open source components becomes standard practice.
Keep in mind, container images are distributed “as is” to the host using orchestrators. You cannot really modify or patch a running container and even if you do, your orchestration will overwrite and reload that container from the originating image. Therefore, it’s important to address known vulnerabilities and configuration errors at the development phase.
2. Lack of real-time visibility and control of the container runtime environment
It’s difficult to extract any meaningful security or operational activity data from a list of containers, or correlate the activity of containers running across multiple hosts, which may be short-lived. The reason for this is the way in which the host environment is built, where containers create a layer of abstraction that reduces visibility for legacy network-based or host-based security solutions.
The host environment is architected whereby the shared OS runs the container engine and the engine runs the containers themselves. The OS is ‘aware’ of the container engine but is not ‘aware’ of which containers are running. The container engine on the other hand, ‘knows’ which containers are running but is not aware of container payload or activity. So, if you’re running application firewalls or Host-based Intrusion Prevention Systems (HIPS) to monitor the OS, you’d be lacking both the visibility into container activity and the ability to monitor and control the same host’s container traffic.
Tracking container activity is mandatory for real-time attack detection and disruption. By conducting ongoing container behavioral analysis, network traffic control at the container level, and a whitelisting policy, you can automatically detect unauthorized activity and block and contain such attacks.
3. Overprovisioned user access permissions
Limiting the scope of user permissions can reduce the impact of errors or malicious activities. Knowing which users (e.g. developer, admin, auditor) can access which container resource and their set of permissions (command level) is a critical step in maintaining Segregation of Duties (SoD) and monitoring user activity effectively.
Setting granular role-based user access permissions (e.g. ability to start a container) per container resource or service, enables you to automatically identify misuse/abuse of these permissions.
4. Hard-coded secrets in images
Containers often need secrets to access other containers or systems, such as databases. These ‘secrets’ need to be stored securely and delivered as needed across clusters of servers and hybrid environments. Storing secrets inside a container image risks exposing them to anyone with access to that container (wherever it might be deployed), and to anyone with access to the development pipeline, as well as to potential intruders. In addition, if secrets are embedded into the image, it means that the image lifecycle would be coupled with the secrets’ lifecycle (e.g. rotation/revocation). In this case, if you want to rotate a secret, you’ll need to build a new image.
Secrets should therefore be stored in a secure repository and rotated or revoked according to an organization’s security mandates. When needed, secrets should be propagated to all relevant containers that need access to them, with no downtime to the running containers.
5. Vulnerability in hosts
Containers run on hosts, sharing OS resources. They are not VMs with their own guest OS and therefore require namespace isolation to limit interactions between containers and the shared kernel of the host OS. Containers should not have root access on the host, and the host itself should also be scanned for vulnerabilities, patched and hardened.
To learn more about how your peers are securing their container and cloud environment, download the full ESG report.
