 Hello everyone, my name is Ankur Kotival and I currently work as a software engineer at Akinox. Today, we are going to talk about how to automatically derive security policies using observability data. Let's first take a look at observability. Observability is a way of understanding complex systems based on the output they generate. This data consisting of logs, metrics and traces can help us to better understand application behavior, application performance and in identifying security postures. These security policies when applied can greatly reduce the attack vector but they are not very easy to implement. In this talk, we are going to focus on using observability data to identify security postures. Let's first look at the issues we face today. It is common to analyze network and system logs for generating security policies but the manual process is inefficient and has a high chance of missing important logs. Manually analyzing observability data to come up with the least permissive security posture is in itself a very difficult task. Even if we assume to handle the certain time security for a single point in time but to maintain that security posture over a period of time is extremely difficult. For example, suppose we are able to create an apartment profile to harden our application but that application is going to change very soon which means the security profile will need to be updated again. Furthermore, these questions about how to identify important logs, generate least permissive policies and regularly update the security posture are difficult to achieve manually. Thus, it is imperative that this process has to be automated. The challenges in identifying security policies from the observability data are there is a lot of noise in the raw observability data. For example, there could be random URL connections or random file accesses. It is required to produce a minimum policy set covering maximum flows. There is no point in deriving policies rules on per flow basis as the policy becomes intractable very quickly. The discovered policies should make use of right abstraction. For example, in case of Cade's environment, the deployment labels should be used in place of other transitory constructs like IP address. And handling data aggregation is the key. The answer to all our questions is to have an automated policy recommendation engine which can analyze the observability data and can derive appropriate security posture. So when the workloads are deployed in the CI CD pipeline, the idea is to get the observability at that point in time so as to identify what the application is actually doing. When the application is updated, we get a differential view. This gives an understanding of what is changed in the application. From this, we can derive a set of system or network policies which can then be pushed into the production environment. So here, we can see two sample differential views with application behavior differing slightly in v0.1.1. This information can be used to derive a set of security policies. The idea is to achieve zero trust security setting in a DevSecOps model. It can be done by deriving least permissive security policies which can only allow essential resources required for running the application and deny everything by default. And do all this in real time, which means to generate security posture which is in sync with the application changes. Let's look at some of the questions we asked earlier. To identify important roles, we need an automated policy discovery engine which can convert the raw observability data to useful runtime security policies. To generate most restrictive policy, denying everything by default is the key. We need to use least permissive policies that can only allow essential resources required for running the application and deny everything else. The security posture should always be in sync with the application updates. This can be done by shifting left and testing the discovered policies in the early stage of software development cycle. I'm glad to tell you that we at Cubarmer are already working on such a policy discovery engine and we call it discovery engine. It is an open source recommendation engine which works as a case plugin. It consumes the visibility information from container network interfaces across multiple clusters and has the ability to auto derive a least permissive security posture from it. The engine averages aggregation techniques to reduce the number of policies discovered, uses pod labels for rule specifications and handles discovery across multi-dimension for both networks and systems. Discovery engine easily integrates with CNS like Cubarmer or Cilium and can ensure their easier adoption. So to summarize, it is not only inefficient to manually derive security posture but also has a high chance of missing important logs. Observability coupled with a policy discovery engine can provide a seamless DevSecOps setting. Such permissive policies can help achieve zero trust. Observing application behavior during testing can help in identifying runtime attack in the early phase of development and shifting left is the way ahead.