A Micro-Firewall for Micro-Services
The advantages of microservices are clear. What’s not clear is how you secure them. In interviews with scores of CISOs and professionals responsible for microservice, service mesh, and Kubernetes platform security, the thing that became crystal clear is that the methods for securing microservices are just emerging–and they’re incomplete.
Before today, there were solutions to secure Kubernetes and Cloud infrastructure (Gartner calls this CNAPP, CSPM), where scanners try to validate code and container images. What has been missing is Layer 7 content analysis and protection.
And it’s a big miss: the point of microservices architecture is to allow rapid iteration of application functionality, to create loose interactions between components, and to distribute responsibility for parts of the application. This creates scalability and efficiency, but by design it also makes the applications harder to secure. Security teams responsible for protecting these environments are left with tools that were built for a fading monolithic architecture.
Microservice applications are not a big box store with one or two main entrances; they are an urban center with hundreds or thousands of boutiques. You can put checkpoints at the city entrances, but there are just too many actors and components for perimeter protection and library scanning to be sufficient. We constantly see this in the news: the most technologically advanced companies are still suffering sensitive data leaks.
LeakSignal plugs this hole.
My co-founders and I previously worked on the old approach to security: protecting the entrance at the CDN, LoadBalancer, and runtime agent levels. In order to protect the microservices environment, a new approach to Layer 7 content analysis is needed.
The LeakSignal Micro Firewall for Microservices.
LeakSignal plugs this hole.
My co-founders and I previously worked on the old approach to security: protecting the entrance at the CDN, LoadBalancer, and runtime agent levels. In order to protect the microservices environment, a new approach to Layer 7 content analysis is needed.
The LeakSignal Micro Firewall for Microservices.
Designed to be inserted automatically at the ingress controller, in the sidecars, and natively into the service mesh, the MicroWAF watches for signs of attack and of data leaking out and stops it from leaving. It provides unmatched visibility about which services are talking to others, whether they are exchanging sensitive data, and which tokens are accessing that sensitive data.
Microservices talk to each other through a new network layer called the Service Mesh. This is a Layer4-7 network infrastructure that takes care of routing, failover, load balancing, circuit breaking, encryption, and access control among microservices. In a microservice architecture, it doesn’t make sense to whitelist IP or MAC addresses – the environment is too dynamic and with containers those resources are shared and thus too coarse to use for access control. Virtual networks, tokens, and interfaces like CNI are used. The equivalent of the Cisco routers at this layer are open source HTTP and gRPC proxy servers with names like envoy, linkerd2-proxy, ztunnel, and nginx. We have to look inside the communications to understand tokens, policy, authorization and data contents – even parsing out JSON and Protobuf. The MicroWAF does this.
Why we need a MicroWAF and how it’s different:
1. Machine-to-Machine Communication
After attackers bypass an existing CDN or other perimeter defenses, it’s open season on finding vulnerabilities and ways to exfiltrate sensitive data. You can’t take a Palo Alto Networks or F5 firewall and install it in a service mesh. Additionally, the techniques used by those solutions (for the past 20+ years) don’t work in this new environment. There are no “client side signals” to analyze. You can’t detect traditional bad behavior when the traffic is on a local mesh-based network and communicating over gRPC.
2. Scalability
Service mesh security has to scale with the tens to thousands of services that are running at any given time. At a technical level, runtime, agent-based protection that is inserted into an existing codebase doesn’t scale at the mesh layer. Those solutions also don’t scale at the process level within internal engineering teams spread across enterprise organizations. Legacy solutions in the API Security, RASP, and Next-Gen WAF space ask customers to install a runtime agent in the codebase. This is unacceptable for service mesh protection. A MicroWAF should be lightweight and fit nicely in an existing ecosystem that consumes Envoy metrics through Prometheus or other “cloud-native” means.
3. Ease of deployment
Microservices are based on new network architectures like the sidecar pattern and ambient mesh. This will continue to evolve, but the proxies that are natively deployed within all mesh architectures support newer Web Assembly (WASM) based add-ons. WASM is the future for edge runtime environments with a well understood and supported ecosystem of virtual machines. Leveraging this insertion point opens up new possibilities for protecting sensitive data, APIs, and the mesh itself through performant, inline Layer 7 processing.
Furthermore, the Department of Defense also sees a Micro Firewall as a critical component in the recently released Zero Trust Reference Architecture.
Microservices talk to each other through a new network layer called the Service Mesh. This is a Layer4-7 network infrastructure that takes care of routing, failover, load balancing, circuit breaking, encryption, and access control among microservices. In a microservice architecture, it doesn’t make sense to whitelist IP or MAC addresses – the environment is too dynamic and with containers those resources are shared and thus too coarse to use for access control. Virtual networks, tokens, and interfaces like CNI are used. The equivalent of the Cisco routers at this layer are open source HTTP and gRPC proxy servers with names like envoy, linkerd2-proxy, ztunnel, and nginx. We have to look inside the communications to understand tokens, policy, authorization and data contents – even parsing out JSON and Protobuf. The MicroWAF does this.
Why we need a MicroWAF and how it’s different:
1. Machine-to-Machine Communication
After attackers bypass an existing CDN or other perimeter defenses, it’s open season on finding vulnerabilities and ways to exfiltrate sensitive data. You can’t take a Palo Alto Networks or F5 firewall and install it in a service mesh. Additionally, the techniques used by those solutions (for the past 20+ years) don’t work in this new environment. There are no “client side signals” to analyze. You can’t detect traditional bad behavior when the traffic is on a local mesh-based network and communicating over gRPC.
2. Scalability
Service mesh security has to scale with the tens to thousands of services that are running at any given time. At a technical level, runtime, agent-based protection that is inserted into an existing codebase doesn’t scale at the mesh layer. Those solutions also don’t scale at the process level within internal engineering teams spread across enterprise organizations. Legacy solutions in the API Security, RASP, and Next-Gen WAF space ask customers to install a runtime agent in the codebase. This is unacceptable for service mesh protection. A MicroWAF should be lightweight and fit nicely in an existing ecosystem that consumes Envoy metrics through Prometheus or other “cloud-native” means.
3. Ease of deployment
Microservices are based on new network architectures like the sidecar pattern and ambient mesh. This will continue to evolve, but the proxies that are natively deployed within all mesh architectures support newer Web Assembly (WASM) based add-ons. WASM is the future for edge runtime environments with a well understood and supported ecosystem of virtual machines. Leveraging this insertion point opens up new possibilities for protecting sensitive data, APIs, and the mesh itself through performant, inline Layer 7 processing.
Furthermore, the Department of Defense also sees a Micro Firewall as a critical component in the recently released Zero Trust Reference Architecture.
The roadmap (to be implemented by 2027) contains 45 capabilities outlined across 7 pillars, with a final goal of “a secure DoD Information Enterprise”.
The open source LeakSignal MicroWAF gives organizations a super power for Zero Trust frameworks and initiatives. It can be installed in minutes with a customizable Layer 7 policy that enforces protection of services and sensitive data. If you need more privacy and don’t want to send data to our cloud, the filter can be installed in standalone mode where metrics are simply published through Envoy and collected by Prometheus.
Join us on Slack and reach out if you’re interested in learning more, we would love to hear your feedback as we build open source solutions that people actually want and need.
The open source LeakSignal MicroWAF gives organizations a super power for Zero Trust frameworks and initiatives. It can be installed in minutes with a customizable Layer 7 policy that enforces protection of services and sensitive data. If you need more privacy and don’t want to send data to our cloud, the filter can be installed in standalone mode where metrics are simply published through Envoy and collected by Prometheus.
Join us on Slack and reach out if you’re interested in learning more, we would love to hear your feedback as we build open source solutions that people actually want and need.