 Hello folks, today we will see how Aquinox have secured the 5G HDDN project. HDDN project is an ORAN-compliant micro-ONOS based cloud-native near real-time RIC and X applications platform. HDDN project is based on micro-ONOS architecture, leveraging microservices, and it's using GRPC APIs for inter-process communications. We are going to secure RAN in the box deployment, RIAB, which deploys HDDN infrastructure, including EPC, emulated RAN, and ONOS controller services over Kubernetes. We have HDDN in the box deployment here. There's an ONOS operator managing various micro-ONOS control plane components and X applications running inside a Kubernetes cluster. Cubarm is a cloud-native runtime security enforcement system that restricts the behavior, such as process executions, file accesses, and network operations on containers and virtual machine at the system level. Cubarm leverages EBTF for deep observability and Linux security models for enforcement. Cubarm is going to help with analyzing X application behavior. It will help us harden ONOS control plane elements. It will help us harden and apply zero-trash principles to X applications. Let us focus on a particular X application and see how Cubarm is going to help us secure it. ONOS KPM1 is an X application running over ONOS HDRAN to monitor the KPM. ONOS KPM1 collects KPIs reported by E2 nodes through KPM service model, version 2.2. This is a graph generated by Cubarm to understand how the KPM1 and other microservices of the micro-ONOS architecture interact over the network. We can see here that the ONOS CLI starts interaction with KPM on service to fetch all the metrics that it needs. In turn, ONOS KPM1 subscribes to E2T through ONOS Topo to gain various KPIs at a particular set monitoring interval. Cubarm not only generates this graph, but even provides you with a granular view of what's happening inside the KPM1 application itself. We can see here what all processes are accessing what files and network primitives inside the KPM1 product. We can see how primarily the KPM1 binary is responsible for sensitive file accesses and network interactions. Let's try to harden the KPM1 application. Cubarm provides you with a recommended set of policies which will help secure based on frameworks like MITRE, ACITSS, NIST, NSA, and CIS. We will also take a look at how we can set up zero-trust rules as well. We saw in the application behavior report that how only KPM1 binary was accessing the sensitive file paths and network paths. Cubarm auto discovers policies such that you lock down your access to network primitives and sensitive assets, such as to certain known binaries only. Let's see these enforcement and action. Here's a report from Cubarm suggesting what all ways we can harden our application itself. There are a lot of recommended policies, but we are going to focus on a few of them. Applications come with all the required bundle application with them. So package management execution at runtime is a threat. So if we now try to access package management tools here, let's say I want to add a particular malicious binary here. We see permission was denied and we got an alert saying that package management execution inside container is denied. And it was blocked by Cubarm with all the relevant data which process was executed. What was the parent process? What are the specific PIDs, which PIDs? What was the pod, which pod? So we have all the context, so as we can take other remedial actions if needed. Similar to package management execution, they should know there are root certificate files which should not be modified at runtime. These certificate files are tested certificate directories and it should not, any drift in them is a security threat. So suppose this is a certificate private file. Now, if I try to modify this file, I get a permission denied and relevant telemetry event was generated for me seeing that, okay, credentials modification is denied. And similarly, I have all the entire data in what context this event happened. Let's take a look at certain attack scenarios now. We already talked about how downloading malicious binary to scan other resources and modifying trusted root certificates is a security concern. But now let's see how we can protect a compromised X application. Talked about earlier. Onos CLI interacts with Onos KPM on to fetch these metrics and Onos KPM on is responsible to interact with Onos E2T and Onos Topo to subscribe and gain these metric data. So that means Onos KPM on has access to Topo and E2T. That suggests that any binary inside the Onos KPM on is able to access these services as well. Like we used WGet here to connect to Onos Topo and got the data. This in general is a security concern because Onos Topo can manage entity relationships and topology. It should not be allowed to non-trusted apps. So let's work on a policy here such that this is a sample policy which only allows TCP, UDP, ICNP, these protocol accesses to the Onos KPM on binary itself. Now that we, let's apply this policy. Now that we have applied this policy, if we try to access Onos Topo 5152, now we see that okay, bad address because UDP socket was denied access. So DNS resolution is not available. But what if we try to connect to the IP directly? Similarly, the socket creation was permission denied because network access is not available to any binary other than KPM on inside the KPM on port itself. So that helps to elevate the compromised ex-application behavior. Similar to network, other forms to spread so malicious actors try to laterally move to other containers as well. And they need access to service account tokens and secrets for that. Service account tokens can be used to move laterally inside Kubernetes, Kershler and compromise other SD and micro Onos components as well. So let's try to secure these them as well. So we have a zero-trash policy to secure our sensitive assets. We deny access to these certificate Onos certs as well as the service account token to everyone. But we allow back the access to service account token and the certificate folder to KPM on binary itself. Now that we have applied this, let's try to, you know, we got the permission denied and we had all the relevant context as well. But does that affect the functioning of the KPM on application itself? No, we can still retrieve these metrics. So KPM one is able to access these certificates, the network and every primitive is still available to KPM on binary itself. But it's micro segmented now, such that other binaries inside the KPM on board are not able to access them. So when, so we discussed the attack and so malware attempted to access spread over malicious other containers. So we restricted service account token to stick being strictly controlled and only allowed specific processes to access this service account. The other attack factor that we talked about is downloading malicious binary to scan other resources. So package management tools, execution is restricted and we anyway, we also restrict access, execution to only trusted binaries as well. The final attack factor that we talked about is in a known X application, use a known X application to connect to HDRAN components to disguise malicious intent. But we have already discussed that network access is allowed only to certain known binaries itself. So this attack is contained as some key takeaways here. 5G control plan is the new attack domain of interest due to multiple vendors deploying workloads at RIC and hence increased attack radius. One needs to isolate and microsegment these both tools. Zero trash 5G ability is the ability to apply least permissive policies will help us secure the 5G control. Cubarmor enables the zero trash 5G security. Cubarmor provides you with deep observability using EBTF telemetry. It provides you with granular auto-generated policy for container isolation. It also helps you with security best practices and hardening policy recommendation for these X applications and workloads. Thank you.