How do I select a container security solution for my business?
The adoption of container architectures is growing steadily, but security and compliance remain top concerns for enterprises, a recent survey revealed.
To select a suitable container security solution for your business, you need to think about a variety of factors. We’ve talked to several industry professionals to get their insight on the topic.
Ben Carr, CISO, Qualys
Before selecting any vendor solution, it is essential that you understand your organizations specific requirements and target state. Mitre’s ATT&K matrix for containers can be used to understand the attack surface that applies to your application(s). Define and prioritize your use cases – starting right – protecting your running containers and hosts – to all the way left – scanning for vulnerabilities in the registry, during CI/CD, and in the code.
Once your use-cases have been defined, run a well-defined and objective POC. Post POC, evaluate the vendor’s product fit in the overall ecosystem of security tools. For example, if you use a vendor’s product for vulnerability assessment for your virtual machine workloads, should you use a different product for container workloads? You should also evaluate the vendors’ ability to support integration with various tools. Does the vendor provide a rich API? Does it offer out-of-the-box plugins for tools used in your organization?
Most importantly, don’t derive your requirements solely from an analyst report; otherwise, you will end up picking a product that has the most checkmarks, but in the end may or may not meet your business needs.
Yasser Fuentes, Technical Product Manager, Bitdefender
Cybercriminals and nation-state threat actors are increasingly shifting attacks towards cloud workloads simply because that is where data and applications now reside for many organizations. With most cloud workloads built using containers and microservices running on Linux, extending security visibility and control across heterogeneous hybrid-cloud infrastructures is paramount.
CISOs and IT managers often overlook small yet critical requirements for protecting containers that could introduce serious risk. For example, security solutions that are dependent on the Linux kernel itself to operate properly can cause delays in updating to the latest Linux distributions resulting in security coverage gaps.
When selecting a container security solution, Linux kernel dependency is just one factor to consider, the following are other mistakes to avoid:
Consider the entire ecosystem. Securing each container and its image is critical, but don’t ignore the rest of the container ecosystem. The orchestration platform, cloud environment, and container host all represent attractive vectors for threat actors.
Ignoring automation as a fundamental requirement. Security automation should be a mandatory capability for quickly protecting and updating containers across the entire environment whenever new risks are identified.
Don’t’ focus on pre-runtime security only. Runtime threat protection, detection and response are vital for container environments as zero-days continue to evolve into more elusive and persistent threats.
Fei Huang, CSO, NeuVector
Legacy firewalls and other incumbent security measures do not provide sufficient protection for enterprises’ modernized containerized environments – as news headlines continue to show. While some understand this before migrating to containers, too many only realize it when security incidents begin popping up.
Enterprise CISOs and other security leaders need to consider the following when selecting a container security solution:
Can I cover the entire application lifecycle? Containers need to be secured from the very beginning of development, through testing, and into deployment (where enterprise applications are most vulnerable without thorough security).
Can I stand up to stringent compliance mandates? Continually meeting the data security requirements laid out by PCI, GDPR, HIPAA and other government and industry regulations necessitates a solution strategy that can ensure security policy enforcement and provide sufficient compliance reporting.
Can I stop unknown vulnerabilities? Known threats are one thing, but any container security strategy must also be able to protect sensitive data from zero day attacks, insider threats, and any vulnerabilities that don’t yet have a patch available.
Will I slow down development? Automated container security processes and policies are a crucial part of any container solution strategy. Security is critical, but cannot slow down application development.
Tim Mackey, Principal Security Strategist, Synopsys
Before selecting container security solutions, it’s critical to look at how many of your existing security practices contradict container security practices. An example comes from patch management processes where an agent scans a virtual environment to determine if patches are missing. If this practice is applied to container infrastructure, it implies that an interactive login is required for all containers and potentially that an agent be installed in the container image.
Both actions increase the attack surface for the container while imposing a significant performance penalty. The better solution is to recognise that container instances are provisioned as replicas of a golden container image. Instead of patching each replica, patch the golden image and then redeploy the containers.
Patch management isn’t the only example of how securing container infrastructure differs from a traditional IT model. Log management, network configuration and deployment considerations around containerised applications differ from traditional IT. As a result, they require specialised knowledge and tooling to solve. When evaluating container tooling, base selection criteria on current cloud requirements, not legacy IT best practices.
Considering how quickly cloud technologies like Kubernetes evolve, it’s equally important that procurement selection criteria be focused on requirements for the next year, not on potential future requirements. This helps ensure you see immediate benefits from a chosen solution without paying for complex functionality that might become standard functionality in Kubernetes.
Mike Milner, Head of Cloud Native Security, Trend Micro
There are many components that go together to make a container platform, and each aspect needs to be secured. If you’re running in the cloud, you need to make sure you’ve configured the cloud environment correctly. You need to secure the hosts that run the containers, the container images need to be scanned, your orchestrator needs to be monitored for misuse, running containers need to be monitored for exploitation. You can piece together capabilities for each of these aspects, but my recommendation is to look for a solution that can handle all of these aspects together in one platform, with broad support across multiple clouds and platforms.
Containers rarely work in isolation. Your applications are using other cloud resources like databases and object storage. They run on a network. To really understand and improve your security risk you need to have visibility into all these different components. And if you do have a security incident, you need to be able to analyze data from every component in one place to find and respond to the threat. You also need to consider the maturity of the platform and the company that supports it. Security threats are constantly evolving. Understanding and evolving to face those threats takes a long-term commitment.
Dan Nurmi, CTO, Anchore
It’s critical to approach container security challenges seriously and with the intention to get a complete picture of the software environment. Here’s three approaches for selecting a software container security solution:
Set a goal. Understand your ‘end state’ with regard to container adoption. Analyze how your organization ultimately intends to utilize containers. Will you develop software as containers, run software that is provided as containers, or build a service based on containers? Depending on that answer, your choice of container security tooling and processes will vary.
Develop a road map. It’s more about process than technology. Different security tools provide different types of capabilities. These can range from pure generation of security-centric data for analysis by security engineers to automatically enforcing strict security policies against your container environments. Mapping your existing (and/or new) security processes to the capabilities of available technology is critical.
Go defense in depth. Most complex organizations do not have a single ‘view’ where any one tool or technique will produce sufficient security coverage. Choosing multiple solutions to best fit the aspect of your environment they are intended to secure is better than choosing one tool that provides shallow coverage across disparate systems. Overlap is okay – multiple tools securing the same aspect of your environment is solid good practice.
Kurt Sand, General Manager, DevOps Security, CyberArk
First, step back and evaluate container security solutions in the context of your overall approach to securing applications, CI/CD pipelines and DevOps admin credentials, not just containers. Attackers are looking for an entry point into your organization and will find a weak link to exploit to reach other areas. If you are a large organization with multiple container environments, project teams, and CI/CD pipelines, unless you secure them all, you are vulnerable to attack.
Second, for functions such as secrets management, ideally the product would integrate with a broad range of native solutions such as Amazon Elastic Kubernetes Service (EKS) which developers may already be using so as to minimize code changes, and to provide sharing of secrets between container platforms and tools. Avoid “islands of security” which creates secrets sprawl.
Third, work with vendors focused on security that can meet the scale and geographic diversity of your organization. For example, secrets management tools that work in development environments, may fail in production, at scale.
Fourth – security is a team game – internally you’ll need to coordinate with development managers, security leaders, etc., to ensure adoption. Externally, it is unlikely a single solution will meet all your needs – from secrets management to code scanning – so find vendors that integrate with each other.
Shemer Schwarz, Senior Director Of Product Management, VMware
Security leaders I speak to continually bring up the following use cases around the need for better container security: 1) Kubernetes security posture management, 2) container image scanning and vulnerability management, and 3) runtime security.
For CISOs, improving visibility into Kubernetes workloads, developer activity and rules configurations should be at the top of your agenda when selecting a container security solution. You can’t understand your environment if you don’t have visibility into how your infrastructure and workloads are configured. Look for a container security solution that provides the visibility needed for SOC and DevOps teams to identify risk, prevent attacks, and securely configure cloud infrastructure.
Container image scanning is another key feature to consider. DevOps teams leverage image scanning to get visibility into what’s running in the production environment and see what vulnerabilities exist. Security teams can then review the image running in production and prioritize vulnerabilities by severity.
Lastly, the best way to secure your environment and ensure no deviation from compliance is to embrace automation. Select a container security solution that continuously monitors changes in the configuration state of an application to help you better understand your security posture and enforce policies consistently across your environment.