The aftermath of a security incident is the worst time to realize that your Kubernetes protections weren’t good enough. When thorough Kubernetes security measures are in place, potential threats are detected and remediated before they can do harm. Achieving this level of security requires a purposeful strategy calibrated to your unique Kubernetes environment and risk profile. It also requires knowing which questions to ask as you build out your container network security strategy.
There’s no sugarcoating it: in the rush to modernize application deployment with Kubernetes, security continues to play second fiddle to ensuring development speed for many organizations. Look no further than what 1,200 dev and DevOps professionals reported at the most recent KubeCon event. But security and speed cannot be an either-or proposition, nor does it need to be. Here are four critical questions that must be asked to understand where vulnerabilities persist and where steps need to be taken to ensure adequate protection within your container network.
Does your network inspection achieve complete visibility?
Comprehensive visibility into traffic at every network layer is arguably the single most crucial requirement for effective runtime container security. Whereas something like a service mesh will offer observability into defined network activity, service meshes provide little insight into the anomalous network traffic most likely to represent nefarious activity or kill-chains used by escalating threats.
A security strategy that includes Layer 7 network inspection offers a key advantage. By understanding how each specific application service communicates with others, you can achieve clear differentiation between normal and anomalous traffic. Having full visibility into network traffic makes it possible to then identify and stop attacks in their tracks before they can infiltrate applications or workloads. Data breaches are similarly prevented since any anomalous network traffic from compromised applications is recognized and mitigated.
What isn’t protected by your security deployment or service mesh?
Avoiding breaches necessitates seeking out and addressing blind spots in your Kubernetes protections. If observability is only available for defined network elements, complete security will require extending network visibility to view undefined elements, as well. For example, if the load on particular services connecting to sensitive data is increasing for no discernable reason, greater visibility is essential to understand that event. It might be that an attacker or inside threat with a working password is accessing infrastructure without performing otherwise identifiable attack activities. Kubernetes safeguards must be able to observe undefined/unknown elements and detect anomalies within an ostensibly legitimate activity. Specifically, communication within a pod and pod-to-pod communications in the Kubernetes network must be protected in scenarios where pod containers are compromised.
What are the limitations of your existing web application firewall protection?
Web application firewalls (WAFs) protect against threats arriving via external network traffic. However, they have no way to identify or block malicious internal traffic inside the container environment. Preventing attacks that escalate from within internal traffic requires a container-specific firewall strategy to monitor and inspect all container traffic within an application-aware context and automatically recognize and eliminate threats in real-time.
Are you addressing security drift?
Some shortcomings aren’t apparent until a strategy is put to the test. As your environment evolves and scales up use of containers and microservices, security drift occurs and naturally introduces vulnerabilities. For example: An organization required to maintain PCI compliance may find that its legacy data loss prevention (DLP) solution–which always passed audits in the past–is no longer effective within the business’ new container and Kubernetes context.
Even in cases where you can identify security drift, the ability to prevent security drift in the first place is far more beneficial. As is most often the case, proactive Kubernetes security protections are preferable to processes that are merely reactive. It means the difference between identifying new vulnerabilities once active threats have exploited them and recognizing anomalous network activity to prevent exploits of even unknown vulnerabilities.
How fast can your Kubernetes security mitigate threats?
If an attack were to occur, when would you know? How quickly would your existing security processes react? If your organization’s answer isn’t satisfactory, it’s likely time to revamp your approach. The right strategy will be able to immediately, automatically and decisively protect your environment as soon as an attack demonstrates suspicious behavior, and before it can do any harm.
To hear more about cloud-native topics, join the Cloud Native Computing Foundation and cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021