What does runtime container security really mean?
End-to-end protection for containers in production is required to avoid the steep operational and reputational costs of data breaches. As news of container attacks and fresh vulnerabilities continues to prove, short cuts (or incomplete security strategies) aren’t going to work.
Runtime container security means vetting all activities within the container application environment, from analysis of container and host activity to monitoring the protocols and payloads of network connections.
Containers running in production environments actively fulfill requests from the internet or internal microservices, and are the constant subject of scans, attacks, and data exfiltration attempts by malicious actors.
Considering the dynamic nature of container environments – and the many container, host, and network surfaces which may come under attack – best practices like vulnerability scanning and hardening attack surfaces are simply not enough to achieve the complete runtime protection now required.
Traditional security lacks the visibility needed to secure containers in production
While conventional solutions such as next-generation firewalls, web application firewalls, or endpoint protection are good for securing the network perimeter and endpoints they do not have the visibility required to examine internal container network traffic. In fact, in modern cloud-based systems containers themselves are the endpoints, and most traditional endpoint protection solutions cannot monitor connections to and from.
Traditional tools are largely siloed to focus on either network or workload security, but not both. So, they aren’t aligned with the reality of modern container environments, where the host, network, and endpoints each exist within one continuous pipeline from development to production – the entirety of which must be fully visualized and secured.
Effective runtime container security is holistic
Cloud-native environments make it possible, for the first time, to join network and workload security within a single viewpoint, using tools running in sync with workloads to gain full visibility into the specifics of each workload deployment.
By correlating activity across the network, workload, and host, it’s possible for runtime container security to detect an attack “kill chain” and better ensure that the attack will be detected and thwarted.
Vulnerability scanning can’t do it alone
While vulnerability scanners can have a positive impact on security, they can only recognize known vulnerabilities and won’t help detect zero-day attacks. In reality, many known vulnerabilities never receive patches, and attackers are adept at finding and exploiting existing vulnerabilities in ways that scanning cannot catch. For example, popular languages like Java, NodeJS, Rube, and Python potentially feature hundreds of vulnerabilities for attackers to leverage.
Also, even a detected vulnerability may have been running in production for a long period; it will take time to patch and leave an environment exposed until completed. Vulnerability scanning is a best practice that helps reduce the opportunities of attackers, but enterprises still require a fuller runtime container security strategy to maintain the integrity of their environments.
Deep network visibility and protection: the key to runtime container security
Securing the network through deep visibility and protections is crucial because the network serves as the first layer of defense for keeping malicious actors from reaching the workload. At the same time, the network is the last line of defense, protecting data from being exposed. Between those first and last lines of defense, network visibility and proper network controls can prevent attacks from escalating within internal east-west traffic.
To ensure anomalous behavior has no place to hide, runtime container security should include the ability to examine the network at the packet level to provide a wholly reliable source of truth when it comes to activity within the container environment. And while layer 3 and layer 4 protections can be helpful, the ability to examine network packets at layer 7 and within payloads offers critical insight into how applications function and communicate.
If they use valid protocols, or if payloads include efforts to hack an application, analysis of layer 7 traffic will make it plain to see. Layer 7 visibility also enables advanced technologies such as deep packet inspection (DPI), which will further identify attacks, detect sensitive data, verify application access, reduce the attack surface, and enforce business policy through security.
Orchestration systems like Kubernetes and Istio must be monitored and protected
Complete runtime container security also requires securing orchestration systems, which may present vulnerabilities that offer even more attack surfaces to malicious actors, as was the case with a recently discovered flaw in Kubernetes security. At the same time, the Kubernetes API server and Docker runtime are also at risk from exploits.
Newer technologies such as Istio service mesh are also complicated to deploy, inviting misconfigurations that can allow for new attack vectors. For these reasons, it becomes vital to monitor and secure connections associated with orchestration systems, tools, and service mesh infrastructure with the same care as application workloads, in order to full protect environments featuring these solutions.
Open source security technologies are helpful, but insufficient on their own
Certain specific (yet limited) security capabilities can be gained using open source security technologies. For example, the Zeek network security monitor is able to capture network traffic and visualize network data. Other open source projects might enable vulnerability scanning, or layer 3 and 4 network policy.
Solutions including Kubernetes and Istio include security features as well. However, open source technologies tend to more narrowly focus on one security area, require careful customization, integration, and maintenance (since they generally lack commercial vendor support), and ultimately do not offer complete runtime container security.
“Network guessing” security is as reliable as it sounds (and increased overhead is costly)
There’s a sizable difference between truly complete runtime container security methods able to offer a container firewall with network deep packet inspection, and other solutions that display static diagrams that only guess at the current state of network connections within a container environment. Only genuine, real-time inspection of network traffic provides the insights required for effective security. Beware of solutions that offer pretty diagrams but lack true packet-level filtering to build their visualizations.
At the same time, container security tools necessitating code injection into applications, or sidecar containers, can be extremely intrusive and costly from a resource and management perspective. A complete runtime container security strategy should be capable of protecting the container environment, scaling as needed, and being managed like any container service, without adding overhead.
A full lifecycle security platform
Many if not most enterprises must develop a complete runtime container security strategy capable of thorough inspection of internal traffic in order to fully safeguard container environments and sensitive data. That said, it’s just as essential to secure these environments across the entire application lifecycle.
By combining DevOps code scanning, vulnerability scanning throughout the application build process, and registry scanning with runtime container security, it’s definitely possible to now ensure that applications are protected from attacks and exploits throughout the full build-ship-run lifecycle.