Cloud Native Computing Foundation Open Observability Day NA 2022, 28 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Making Sense of Observability with Auto-Discovered Security Policies- Ankur Kothiwal

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Making Sense of Observability with Auto-Discovered Security Policies - Ankur Kothiwal, Accuknox

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. Discovery Engine is an open-source policy recommendation system, which can act as a plug-in for K8s environments that discovers network and system policies based on the logs collected from the various container network interfaces (CNIs). The engine leverages aggregation techniques to reduce the number of policies discovered, uses pod labels for rules specification, and handles the discovery across multiple dimensions (networks, systems). This talk will help in providing an insight into how the auto policy discovery tool works, its use-cases, and the requirement for an automated runtime policy generating engine in the changing cloud-security environment.

A

Hello: everyone, my name, is ankur kotiwal and I currently work as a software engineer at equinox. Today we are gonna talk about how to automatically derive security policies using observability data.

A

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.

A

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.

A

Let's first look at the issues we faced 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 this runtime security for a single point in time, but to maintain that security posture over a period of time is extremely difficult.

A

For example, suppose we are able to create an apartment profile to harden an application, but that application is Gonna Change very soon, which means the security profile will need to be updated again.

A

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.

A

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.

A

The discovered policies should make use of right abstraction, for example in K in case of case environment. The deployment labels should be used in place of other transitory constructs like IP address and handling data. Aggregation is the key.

A

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.

A

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.

A

So here we can see two sample differential views with application, Behavior different different slightly in v 0.1.1. This information can be used to derive a set of security policies.

A

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 two and do all this in real time, which means to generate security posture, which is in sync, with the application changes.

A

Let's look at some of the questions we asked earlier to identify important logs. 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.

A

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.

A

I'm glad to tell you that we at Cube armor 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 unleash permissive security poster from it.

A

The engine leverages aggregation techniques to reduce the number of policies discovered using spot labels for rules specifications and handles Discovery across multi-dimension, for both networks and systems discovery engine easily integrates with cnis like Cube, armor or cilium, and can ensure their easier adoption.

A

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 the policy discovery. Engine can provide a seamless, devsecop setting list. Permissive policies can help achieve zero trust, observing application behavior during testing and help in identifying runtime attack in the early phase of development and shifting left is the way ahead.

A