Cloud-native applications require a new security solution. Microservices magnify the attack surface, while communicating over APIs obscure visibility. Defense in depth argues for multiple layers of security control. To help spawn new ideas, this blog is the first in a series of conceptual defense in depth approaches to securing cloud-native applications.
Up until a few years ago, web application firewalls (WAFs) were deployed traditionally in front of a monolithic application. There has been an explosion of microservices and east-west traffic, and WAFs miss most of this traffic. To address this, we decided to take ModSecurity (which is the most used open-source WAF around the world) and integrate with Envoy (which is the most used proxy in cloud-native deployments) as an HTTP filter to give you the option to enable WAF on all the pods or on the most sensitive and front-facing traffic.
As a general rule, WAF requires a lot of maintenance and is very application specific in terms of the rules it runs on the traffic. Here we provide an example and basic guidelines with the free OWASP core rule set. You should configure it to match your application to avoid a lot of false-positive alerts.
The source code and the README for the ModSecurity-Envoy integration is available here. You can compile it yourself, use the release binary, or use the docker image.
How It Works
We compiled LibModSecurityV3 as an HTTP filter in Envoy and built a new Envoy release where you can turn on/off ModSecurity via configuration and configure ModSecurity via regular configuration files as specified in the ModSecurity tutorial. This way you can just swap your Envoy sidecar in your mesh with the new Envoy.
ModSecurity is one of the most used web-application firewalls and Envoy integration is a step forward with defense in depth. Adding signature-based intrusion detection to every microservice via a sidecar is a great example of how a service mesh enhances the security of a cloud-native environment and it gets you one step closer to a zero-trust network. It is important to note, you will get high CPU overhead along with a very high number of false positives and negatives without proper configuration. A central control plane which provides visibility, simple declarative APIs, and continuous automatic policy evaluation is essential to unlocking the value of this great feature.
WAF is an advanced use-case and arguably the last step in application security in the cloud-native era. The most fundamental need that emerged in the cloud-native era is visibility and security policies between your microservices. In layman terms, allow only authorized traffic. Then you don’t need WAFs or other signature based detection tools as there is almost no traffic to run on. After your cloud-native deployment is hardened, WAF can be added to monitor the necessary traffic.
If you’re interested in a demo to see how Octarine gives you visibility and security for your microservices, please reach out here.