 Hi, everyone. I'm Jose Carlos Chavez. I work at Docta as a security software engineer. Today, I'm going to talk about how to use WebAssembly to deploy a WAF deeper in the service mesh following zero trust guidelines and some compliance. What is a web application firewall? Well, a WAF, for friends, is a proxy-based tool that inspects incoming and outgoing HTTP traffic. This is an L7 tool, mainly. It analyzes traffic, looking for malicious payloads, malicious content, or unwanted content, because you can pre-define that. And it can block requests and response accordingly. It can be based on a pre-defined set of rules that include well-known vulnerabilities mitigation. And it can produce audit logs for every request that matches one or other rule. And then you can apply further analysis to it. Why using WAF in 2024? Request and response inspection is probably one of the biggest benefits you can get from WAF, because you can avoid zero-day attacks. If you hear about, for example, lock for shell that happened in 2021, or 2022, actually, client-side attacks whenever a client is sending malicious traffic, like, for example, SQL injections, or cross-site scripting, it will block by the WAF. You can receive also both attacks that you can block through a certain foot print or signature in the attack through the WAF. You can apply security rules to avoid SQL injection, cross-site scripting attacks, local remote file inclusion when the attacker is trying to somehow try and to upload a file in your server to later execute it. Size restrictions whenever you have a payload that is trying to DDOS your server. It also has something called anomalous scoring, which is very handy, because some different kind of payloads that contain different information or different contents that are malicious or not, or sometimes anomalous, might have different score. So you can set a threshold and say, whenever the anomaly score gets to this level, then block it. Otherwise, just keep it, because this might be regular traffic. But still, because you have matched rules on that, you can later do a post facto analysis and see, like, OK, this was actually malicious. Let me adapt my rule set again, or this wasn't. Let's just let it be. Or tweak a rule so it doesn't get matched. But why using WAF in service mesh exactly, right? First of all, zero trust, right? As you might know, zero trust or zero implicit trust is all about protecting or defending your components as if the attacker is inside, right? So even though you might think like a WAF might be something that should be happening at the ingress level, you also want to protect individual workloads that are more sensitive, right? As a part of a broader cybersecurity strategy. So yeah, the incoming traffic, even if it comes from a trusted source, like a service in your deployment, you also want to analyze the traffic. Of course, not with the same level of paranoia as you would do that in the ingress, right? Lift and shift, which is something that is happening very often now, you want to put all the stuff in the cloud, so the old stuff comes with the vulnerabilities, right? And you're now putting the cloud, so the exposed. You want to mean to protect that, putting a WAF in front. PCI DSS compliance, which is not only for financial websites or websites that deal with payments, also whatever website that treats with car holder information should be at the PCI DSS compliance, which now, from version 4 in 2025, in March 2025, is going to enforce a WAF, right? So you want to deploy that as well. Also remember that the biggest hack of 2023, it was a SQL injection, right? If you hear about MoveIt from the Progress Company, yeah. Although if you look at, for example, the API, the top 10 API security is all about authentication and authorization, the biggest hacks are still true SQL injection or cross-site scripting, right? So you also want to deploy the WAF as a measure of protection, again, as part of a broader security strategy. And because you want to run a cybersecurity program that is robust, right, that has different layers of protection, no matter whether they conflict, at some point they intercept or they have joint parts, you still want to have different levels of protection. And yeah, as per the survey of Solo in 2023, right, the service mesh feature for leaders that are requested, WAF is in the number two, 30%. So how do you do that now? Well, we have crossing paths, right? We have Istio, which is a service, well, you know Istio, right, it is the Istio date. Service mesh running envoy-based sidecars, right, as policy enforcers. Policy enforcement is when you have the sidecar that is enforcing all the policies that you roll out, right? One of them being authentication, authorization, and you can also roll out a WAF, as we will see. It will, you deploy a plugin that is going to filter the content at ingress level or per name space level or per application, much in application level, right? Then you have Envoy. As a proxy or as a gateway, it will allow you to run filters written in one language and compile it into WebAssembly, right? Following the proxy was an API, which is basically a set of interfaces. Then you have WebAssembly, which is a portable binary code format, which is supposed to be high performance. And you can, high performance executable programs, right? It's not native performance. It's high performance. There are some work going on, right? For example, for the garbage collection and all that. OK, Corazza WAF. WAF, of course, is a fast web application firewall compilable to WebAssembly and supports CRS4, which is the newest core rule set for security, for well-known attacks. This is how you run them. One in the, as I said, in an ingress. Another one individually in each name space. Don't forget about the face, which is authentication and also the priority, because WAF should happen at the very first level, because authentication can also be compromised. Thank you. These are the references in case you are more interested in that. So I accept questions now. Thank you. All right, any questions? Hi. Thank you. I was just wondering how the data that you collect presents itself, specifically with that WAF that you demoed or showed? Sorry, I didn't get it. Can you please repeat? How does the data present itself? How do the logs present themselves? Is it just a? How the workloads protect itself? Present. How do you see the data? How do you get the data out? So OK, we run the WAF filter in the sidecar. It will ingest all the traffic before it sends to the upstream. It will analyze in four phases. Heaters, request body, then it sends to the upstream. If it didn't resolve at the time that this was malicious traffic, right? If it didn't look at, for example, the URI, the query parameters, or the incoming request body, which can be also, for example, analyzed as a JSON payload or as a raw payload. Once these two have succeeded to pass, it will forward the request to the upstream. First, the headers and then the body. The upstream will do its thing, right? Serve it, whatever it has to serve. And then the response will, so if you enable it, the response will also be also collected, analyze it before sending to the client. If you see that there are, for example, compromised information in the response payload because it was actually an attack that tried to get credentials, for example, or sensitive information, it will also block the response. And then it will produce some debug logs about the functioning but also audit logs that will tell you, OK, this was blocked. This request was blocked because of these and these and these rules. This was the anomalous core. And then you can do further analysis on that. And those logs go to where your normal Envoy logs output? Yeah, exactly. Any other questions? So I wanted to ask you, if you change your WAF rules, and how long will it take to propagate those changes to your service mesh? Like, if you change the rule? I mean, like the WAF configurations. Once you update that and add something new, how long will it take to propagate the changes throughout the mesh? OK, so it depends on the scheduler, right? Because in the end, what you are changing is a configuration. Sorry for my hand, but the light is coming. You will change Kubernetes configuration, right? And then it will need to redeploy everything again. So I don't have exactly numbers, but it depends on your underlying platform, which is Kubernetes. But to be honest, there are other ways, for example, there are other experiments that, for example, Intel did, which you don't want to reload the entire sidecar. You just let the WAF plugin to be receiving through a ERPC stream, receive new configuration, and reload the WAF. That's still work in progress. Intel called it the rules server. And you can then apply the updates there. And that is, I wouldn't say that's a real time, because I don't like the word real time, but this is much more fast. And it can be something close to real time, because it's independent from the Kubernetes schedule. Cool. All right, awesome. Thank you, everybody. We're going to take a break now. If you have questions after, I'm sure J.C. will come in. Yeah, I can answer this later. Thank you. Yeah, thanks.