Zero Trust for Cloud-Native Workloads: Mitigating Future Log4j Incidents

Originally published by Tigera here.

Written by Giri Radhakrishnan, Tigera.

In my previous blog post, I introduced the brief history of zero trust, the core pillars of a zero-trust model, and how to build a zero-trust model for cloud-native workloads. In this blog post, you will learn how to mitigate vulnerabilities, such as the recent zero-day Log4j vulnerability, with a zero-trust workload security approach.

Zero trust: A quick refresher

The starting point for building a zero-trust security model is understanding your attack and protect surface. The outcome of designing your security plan should be eliminating the attack surface completely.

Enterprises are realizing that the best approach to mitigating breaches and protecting their sensitive assets from both internal and external threats is by applying the three principles of zero trust to their security plan. These three principles are:

1. Always use least-privilege access
2. Always authenticate and authorize before providing access
3. Always assume breach

While stakeholders are busy creating design architectures, collecting asset information, and considering tools required to achieve their zero trust goals, there are also new challenges that some decision-makers should consider. As microservices are becoming the de facto standard for application developers, it has introduced new technologies and methodologies for communicating with legacy systems. For these microservices, securing the entire gamut from build time to runtime, including securing workloads for ingress and egress access, is crucial for zero trust. To help you achieve this, I’ll illustrate the techniques necessary by using the Log4j vulnerability as an example.

Log4j and its vulnerability

It was truly The Nightmare before Christmas when the zero-day Log4j vulnerability was announced late last year. Log4j is a logging utility for Java-based applications that programmers can use so that user activity and application performance can be monitored. A security researcher from Alibaba’s cloud team found and reported a zero-day vulnerability (Log4shell) in the utility, and this led to panic among millions of users with applications getting hacked by attackers trying to steal data, install malware, and carry out other malicious activities. This could be performed using arbitrary/remote code execution (ACE/RCE) where hackers can remotely target endpoints running Apache’s Log4j logging framework.

Tigera’s developer advocate, Reza Ramezanpour, sheds more details on how the Log4j vulnerability works and how to protect containerized environments from Log4j or similar vulnerabilities using security policies. You can follow the steps in his blog post to spin up a demo lab to see how the Log4j attack happens.

How does the Log4j vulnerability affect workloads?

Since the Log4j utility is used extensively by many popular applications running Java, your workloads may be running some form version of the Log4j library. Without the proper security policies in place to block communication to a threat actor’s LDAP server (which is most likely used in this case), your workloads could be a target for placing crypto mining software without your knowledge. It could also result in data exfiltration, where an attacker can use payload information to find out user credentials and secret keys in a public cloud (e.g., AWS EC2).

How to identify and isolate workloads running Log4j

To identify and isolate workloads running Log4j, you need a solution that helps security and DevOps engineers work with platform teams and other stakeholders to carve out custom security policies and egress access controls for zero-trust workload security. This solution should detect, mitigate and protect:

• Detect – Use an image scanner to detect Log4j packages and associated version numbers, container images, and vulnerability IDs. Use machine learning to detect anomalies and other Indicators of Compromise (IoCs) to actively protect against zero-day threats during runtime.
• Mitigate – After identifying hosts running the affected version of the Apache logging utility, an ideal cloud-native solution will give you the ability to immediately identify the relevant workloads and pinpoint those affected. This could be achieved with a combination of network segmentation and identity-aware microsegmentation. Both of these techniques are a fundamental requirement for a zero-trust security model.
• Protect – To protect against vulnerabilities such as Log4j, the solution should allow for a solid implementation of the zero-trust approach. We know that by default, Kubernetes lets all the pods communicate with each other without any restrictions—just like how a zero trust network access solution gives access to users on a per-need basis. Therefore, workloads should be given a similar restriction by implementing ‘default-deny’ for all resources. The solution should also be built upon the core principles of a defense-in-depth strategy, where once you identify and locate the vulnerabilities in your network, you can automatically fire up security policies to deny traffic to and from the affected workloads. As part of remediation efforts, security enforcers should be looking at blocking, quarantining, or terminating the impacted pods.

Conclusion

With this holistic approach during build, deployment, and runtime in a cloud-native environment, platform and DevOps teams can work in concert with security teams for a robust zero-trust workload protection model.

Want to see how you're doing with your zero-trust security posture for cloud-native workloads? Use this free zero trust maturity assessment tool to find out.