 you know, I prepared that, so I thought I'll talk about that. I'll talk about securing connections, defending telco workloads in the cloud era. So primarily, before diving into the topic a bit about myself, I'm Barunacharya, I go by demon1024 over the internet, over Twitter, LinkedIn, wherever you want me to look for. I'm a maintainer and I lead the development for QBarmer, which is a CNCF Sandbox project. I work as a software engineer at Accunox and I'm actively mentoring over Google Summer of Code and Linux Foundation mentorship. Also, I'm a proud CNCF ambassador. So what to expect out of this talk? It's been a long day. We have been digesting a lot of information, so I just want to give you some context about what more you are going to learn today. So primarily two things, what kind of attack vectors are there for 5G and telco workloads and how you can prevent them. But that's one of the things. The other thing is, how do you orchestrate this security against these attack vectors? Because telco workloads are dynamic in nature. You are creating clusters, there are multiple clusters you manage across, I don't know how many regions. So orchestrating is also an important aspect. So we are going to dive deep into both of them. How many of you in folks know about Nefio? Nefio is a Linux Foundation networking project. That's good to see. So I'm going to base my entire talk about around workloads running on Nefio. Nefio is a Kubernetes orchestration where it helps you do telco domain automation in an intent-driven way. It manages a lot of infrastructure and has a lot of design considerations around automating actual telco workloads. The demo application today will be Free5GC. It's a standard demo application used across Nefio as well as other 5G telco demos. So I thought I'd use that. The Free5GC deployment contains a management cluster, some regional cluster, some edge clusters, orchestrated across control plane and work on planes. So how do you enforce security on that? We have maybe hundreds of tools in the CNCF security landscape. Do I just start using everything? But before trying to decide on what exactly to use, I'm going to take one tool from that, CubeArmor. You might have already predicted that being part of CubeArmor. So I'm going to use CubeArmor to showcase some of the attack vectors and prevention of those attacks inside this Nefio plus Free5GC demo scenario. We are going to see how to observe things through CubeArmor, how to secure endpoints, how to actually harden your infrastructure with that. So in our Free5GC deployment, we have network functions like NRF, UDM, PCF, WebUI. All these network functions live inside our Free5GC deployment. I'll take one of them being WebUI. WebUI is a user-facing tool helping you registration and subscription of various edge-related things, and let's see maybe WebUI in action. So this is how WebUI works about. You can register user end devices, you can manage subscriptions, and a lot of things around that. But essentially, it's a user-facing application. If you find a vulnerability in that, you can probably start literally moving around the entire infrastructure because at the end, WebUI, even if it's behind a password, it's interacting with the rest of the 5G control plane stack that we have. So it's important to start securing that. Okay. So this is the visibility we gained. I have created this from the information that we get from Cubarmor that what's happening inside the WebUI application. We can see that WebUI tries to access its own configuration file. It has access to the DNS resolvers. It is trying to communicate with MongoDB which it uses for database. So if somehow some attacker sneaks into WebUI, it gains a lot of accesses. So the demo attack scenario is we imagine that WebUI is compromised and turned rogue. So what can it do? It can interact with a fellow network function called network repository function where which actually can provide with all the endpoint details of rest of the network functions available. So you don't want that happening because now it can not only fetch the information but it knows what to maybe try to exploit next and start moving around. So how do you prevent this? We have a zero-touch policy that I have personally created based on information that we saw here that web console needs to do so and so things, what all things. So if you see here, there's a policy saying allow TCP UDP raw for the free 5GC web console binary. So even if an attacker now sneaks into your WebUI workload, the attacker itself cannot do anything. It's the only, it's the WebUI only that can do things. So from a demo perspective, I invite my friend Barun again to show you the demo. So we have applied this policy. I have executed into the WebUI pod and we try to use W get to access the NRF endpoints. And as soon as I try to access that, I can gain information about UDM which is another network function. So I can knit together this information and probably start looking into that. But what I'm going to do now is I'm going to apply this policy. We create this policy to block, like this is a policy to block TCP UDP for other binaries inside that pod. So now if I try to exec into that and as soon as I try to double look it, it saves me bad address because it does not have access to UDP itself so it cannot resolve that DNS. But even if I try to access through like standard IP sider, it won't be able to do that because we don't have TCP access as well. And you get alert around what happened inside that pod. So what next is that there are a couple of attack vectors here through we already took. So these attack vectors are, I'm not crafting them. MITRE fight has a list of attack vectors that they have compiled, which are relevant for 5G today. Both MITRE and NESA have published this attack vectors. It's live on their website. You can visit fight.mitre.org and you can check out what kind of attack vectors are there. But essentially I'm just taking that as an example of possible explorations. At the end, if you have a zero-trust policy, you can probably have them, you have your workload secure against any future possible attack vectors as well. So similarly, there's another tactic called the registration of malicious network function with 5007, but it uses the same principle under the hood. You are going to use a rogue NF to start interacting with the network repository function. And we already try to, we are already secure against that. So we already saw that, okay, inside the web UI binary, we saw that, okay, web console binary is still able to access all the entities, but the malicious actor is not able to do anything. But some other concerns could be, but it's not just about securing entities inside your pod. You need to have multi-layer security. You need to have security on your services itself, like they communicate over TLS or not. So this is a report, it's a demo application. So it's obvious that it's using plain text, but ideal case in your production environment, you need to look for these things that, okay, you are using TLS, you have network policies around, and whatnot, because if somehow, someone, attackers are always looking for loopholes. They can try to sneak inside anything. One last example from the attack perspective is that Gnode B component manipulation. So Gnode B is responsible for managing your user end devices, and what you can probably do is, what if someone is inside the Gnode B pod? They change their configuration that, okay, they change the network slices or the number of UEs it can register. A lot of configuration goes into that. So what if you can do that? So I'm going to play this. So I have an access to a sample this is the same free five GC deployment, and what I'm going to do is now try to access the Gnode B configuration file using cat right now. So I've already applied the policy. So even if I try to start, so it was not called config.yml. So I as an attacker try to look into what is exactly the configuration called, but as soon as I try to do that, you see that it was permission denied. So it's important that we secure these configuration files and data points so that you are not able to modify it. As well as it's important that are normal. So there's an NRCLI helper around here, which we'll see that, okay, it can still access the configuration file and report you that, okay, this is the configuration details. So that's what the model is about. We can enforce security that, okay, we can allow what is supposed to happen and you can set what is not supposed to happen. We look at it from a file perspective as well as a network perspective. But now you might say that do I keep writing these policies on my own? That's not something I would like, right? We have a lot of dynamic workloads. And if, so I showcased all of the demo scenarios using QBARMAR as a project, but what if you don't have QBARMAR on one of your clusters or for some reason you cannot orchestrate QBARMAR onto your clusters, you maybe have some different tooling altogether. So how would you go about that? Today, as a general perspective, you what you try to do is you identify security engines, you create policies around those security engines and there are challenges, right? What if you want to, like you are probably using Celium today, what do you want to move to Calico tomorrow? You would need to, you might say, okay, I was just using Kubernetes network policy, that's a standard policy. But that kind of policy does not have, like there are certain things that Celium policy has more advanced than standard network policy and you want those kind of features as well. So how would this migration affect that? Do I keep all of this in mind? What if my workloads are dynamically created? So there are a lot of things to think about it. So, Nephio has been talking about intent-driven approach to telco automation. What if we bring the same concept to security as well? What if I as a user can just define that, okay, what is supposed to happen rather than defining how it is supposed to happen? I do not say that, okay, it's a Celium policy or a Calico policy, I just say that deny UDP access or deny, like I want to prevent DNS manipulation altogether. That's the intent I define. I don't have to worry about there would be, if it's going to be a Celium, multi-CNI, Calico, I don't know what more CNIs do you have. Or from a runtime perspective, whether you have QBARmer, Falco, Tetragon, I don't know how many kinds of runtime security you have. So, what could be an intent here? You could say probably do not allow privilege escalation. Now, this could be, it's not just about choosing which tool, it's not about either or problem. It is possible that the same intent could be used by multiple security engines out there and you need security at both the levels. So, something like do not allow privilege escalation, you would probably have an admission controller policy saying do not admit pods with Capsis admin, okay. But what if you are inside a pod and you break out and start having a Capsis admin, you can probably define a QBARmer policy saying deny a Capsis admin inside so and so. So, you need to cover all your bases when it comes to security. But how do you do that? This is a high level approach towards what we have been working towards for intent-driven security. It's, it borrows concept from the PVC PV model that you have. You create a security intent, you have a security intent binding and then the security intent binding is watched by an operator which then based on policy engines like QBARmer, CELium, Kyven, OPA, whatever policy you have, there will be adapters to look at that and translate and recommend your policy depending on your security intent. So, now demo for that. The project that we have named it is called Nimbus and I'll talk more about how to look at that and type it out. But essentially, as a user, you create a security intent and your security operator, which is Nimbus here, watches that security intent. Okay, that was too quick. And your workloads and then your workloads and... Okay, sorry. So, your workload, then it watches for your workloads, matches that security intent with the security intent binding and accordingly generates the final set of recommendation policies based on your workloads there. Let's see it in live action. So, what we do is we have a sample application. We are trying to protect engine XR and we have QBARmer as well as Nimbus, as well as our network policy agent running. What we are going to do is we are going to create a security intent saying do not allow package management tools, do not allow maybe service account token and do not allow DNS manipulation altogether. So, these are the three intents that we are going towards. But now we create a binding saying that, okay, I want all of these three intents applied to my engine export. So, I create the security intent binding mapping and once those are created, what Nimbus is going to do is it will try to analyze, it will see that okay, whether QBARmer is available or network policies are available and it will start showcasing your policies according to that. So, for example, we have three security intents, a single security intent binding. It created an intermediary resource, but at the end, you have QBARmer policy as well as network policy generated for you. So, to start with, we are going to see that we'll explore the software, we do not want to apply package management execution in our production containers. That's something you do not want to, you do not want someone running after installing our production environment, right? That's too much of a risk to handle. So, it created a policy saying, okay, these are all the package management list and it will deny that. But, and we are going to try to violate that, I guess. Yeah, we go into that pod and now that this policy has been applied by Nimbus, as soon as I try to execute any package management, it is going to permission deny and again all the same information again. But something like DNS is something that both QBARmer and network policy need to handle. It's not something that is, that should be limited to like, you need to handle that at both layers. So, as you can see for DNS manipulation, we created both a network policy as well as a QBARmer policy, according to what we deem fit and it's being applied. So, that's how Nimbus operates. It has both, it checks what all engines are available and accordingly create policies towards that. So, that's what I've been talking about as to what you could have taken away from the stock. We have a 5G control pane. It has a lot of attack vectors. You are deploying a lot of workloads in a very dynamic manner. So, there's a need to isolate individual workloads and then have security on that. Zero trust can probably help you out, but for zero trust you need that visibility as well to understand what's happening inside your containers and accordingly harden, start hardening my X application network functions and workloads. And finally, because these workloads are so dynamic in nature, you never know what kind of policies or what kind of engines to expect for. And you could probably take the same intent-driven approach that nephew has towards security as well to handle the dynamic nature of 5G. So, yeah, thank you. This is a QR code for Q-Barmor. You can check out the Q-Barmor project. If you want to know more about the Nimbus project, it's still in works, but all of this that I told is being made as part of 5GSEC.com. And yeah, that's all. If you are around tomorrow, today already the booths are closed. So, I'll be available at the Q-Barmor booth as well as the AcuNox booth. These are the number in the solution showcase. Thank you. Any questions? Okay. Oh yeah, you have a question? Okay, I cannot hear you. Can someone give him a mic? How does this enhance to have, other than the Kubernetes network policy and port security policies, PSPs, other than the intent driven architecture? So, there were two aspects there. So, like, network policies themselves. So, part of the reason people try to go towards certain agents is that the standard policies are not enough. Like, network policy, you can apply a network policy, but then you need the visibility into when the policy is being violated, right? Normal standard Q-Barmor Q-Proxy does not support that visibility. You need Selium maybe or Calico or Enterprise version to gain that visibility. From a other perspective, I guess the runtime perspective, network policies only enforce upon port to port security, right? What happens inside the port? So, as I showed, you probably know that WebUI should be able to access NRF, right? But you never get to know that WebUI has been compromised. Now, whether it's WebUI accessing the NRF or is it the compromised malicious actor trying to access NRF? And that's where runtime security comes in the picture and you have Q-Barmor to help you with that. PSPs themselves are restricting. So, with PSPs, it's not PSPs anymore, it's port security admission. You create policies for what, at admission layer, right? What happens after admission has done, you never know if an attacker has sneaked in or not. Or you can only prevent against attacks that have not happened, like something like Lock 4J, which happened. It was an attack from an actual production application, Lock 4J, where you can now do remote code execution from Lock 4J. But if you had defined a policy at runtime, saying that my Java application is only supposed to do so and so things, as soon as it tried to execute Bash or anything like that, you know that it should have been denied. And with these kinds of approaches, you can do that. Does that help? Sure, thank you. Any more questions? Nope, so that's my QR code. If you have any feedback towards my session, I would glad to have that. Thank you.