Container ecosystem development continues to progress at a rapid pace, but security challenges persist. The number of new entrants, established players rolling out container-specific products, and money being thrown into container security is mind numbing.
Just this week has seen a handful of these announcements. As an example, Tufin expanded its cloud policy-based platform to secure containers and microservices. And StackRox scored $25 million in new funding.
According to at least two analysts, while these efforts are important to bolstering container security, organizations are often still not grasping the basics.
Adrian Lane, CTO at Securosis, in a recent webinar laid out some basic container security tips that seem almost too simple. These include grabbing already used container or container images, thinking they have already been cleaned of potential malware; using vulnerable third-party containers or images; or attempting to update a running container while it’s in production.
Beyond those simple procedures, Lane suggested that organizations should more aggressively segregate containers to limit access for their creation and access rights for a running container. He noted that only around 10 percent of organizations are currently doing this, and that he often sees pushback when segregation is suggested.
“Development and IT don’t want to do isolation because it’s a lot of work,” Lane said.
Organizations can also benefit from using embedded security that comes from established cloud platforms. This includes those from Amazon Web Services (AWS), Microsoft Azure, and Google’s Cloud Platform (GCP).
Neil MacDonald, a vice president and distinguished analyst at Gartner, in a recent report noted similar steps organizations can take to ensure container security. He also pointed to ways containers can be secured once they are in production.
This includes running a security agent in the host operating system or using a specific security container to operate alongside application-specific containers. MacDonald said organizations can insert security controls into each container as they are built, but before they are released into production.
Lane concurred with that last point, noting container security measures need to be handled during development or configuration.
MacDonald also made the case for greater use of cloud workload protection platforms. These are agent-based, server workload-specific security platforms that are injected into cloud deployments to provide visibility and prevent attacks.
Serverless computing could prove more challenging for current security platforms. Serverless applications don’t rely on a fixed infrastructure; are designed to activate almost instantly; and can be programmed with a finite lifespan that cuts off all activity once a function is completed.
Serverless is seen as being potentially more secure than containers or virtual machines (VMs) for a number of reasons. They don’t rely on traditional servers and thus the presence of vulnerable binaries is eliminated; denial of service attacks are limited in scope and become billing issues; and serverless immutability eliminates reliance on potentially compromised servers.
However, serverless is generally more difficult to monitor because of the lack of a centralized server. There’s the potential for a larger attack surface due to the increased flexibility of serverless. And there remain challenges in securing third-party services during transit.
“These architectures complicate security protection strategies because there’s no OS or container to instrument,” MacDonald said. “In most cases, these services are used in conjunction with VM- and container-based architectures, so a traditional (cloud workload protection platform) provides partial protection.”
Those tackling this challenge can differentiate themselves in the market. Twistlock, for example, recently updated its security platform to use the same data sources for identifying vulnerabilities in serverless functions that it uses for container image analysis.