How Micah protected his startup's Kubernetes by deploying open-appsec using GitOps CD to provide preemptive Log4Shell protection
Micah is a DevSecOps engineer working for a startup. His team operates about 100 K8s clusters and has implemented a declarative GitOps CD process that stores all the YAML files and HELM charts in a central Code Repository. Within their K8s clusters, they are using an NGINX Ingress Controller to expose web applications.
The startup is heavily relying on open source software and using the popular Log4j libraries in many of their web-based applications. Many applications are also exposed to the Internet.
As security notifications were published about Log4J vulnerabilities, Micah was tasked to quickly implement a solution to effectively protect against anyone exploiting the vulnerabilities and gaining unauthorized access to their company's confidential information. The exploit code for the Log4shell attack scheme was already publicly available. Micah's goal was to give the application owners more time to review and upgrade to non-vulnerable versions of the Log4J library in each of their web applications, which takes 2-3 weeks.
As Micah looked into the potential exploits, he originally thought his company was already protected since they had a ModSec WAF NGINX module activated on their NGINX Ingress Controller. But after doing some research, he found out that in order to be protected against Log4Shell, he would have to add additional signatures to the ModSec configuration, and that this typically would be mostly CVE specific -- he would probably need to repeat the process again when the next Log4j vulnerability was published a few days later. Clearly, this was not effective enough since it would not preemptively and repeatedly protect automatically. It would require manual ModSecurity rule updates in the future, while leaving the company temporarily unprotected every time between updates.
Micah then searched for preemptive Log4j protection and found open-appsec to solve this issue in a completely automatic, preemptive way based on an innovative Machine Learning-based approach. This would also nicely integrate with their existing NGINX Ingress Controller.
Since there was a free Community Edition of open-appsec available, he decided to give it a try himself to verify the Website's claims. Checking the two different configuration management options, he decided to move forward with the declarative, code-only deployment, which would later also perfectly fit into their existing GitOps CD process for their various multi-staged K8s environments. Following the Getting Started guide, he was able to install Open AppSec in his K8s Lab environment within just 15 minutes in an all declarative way, including a demo web server. Once set up, he attacked the system with different well-known Log4shell exploitation attempts -- all of them were instantly blocked by open-appsec's Machine Learning engine. After some more evaluations, 3 days later the open-appsec solution was deployed, fully automated to all their NGINX Ingress Controllers via their GitOps CD process, preemptively protecting all of their K8s web applications and web APIs. The former ModSecurity module was decommissioned.
