Shauli Rozen on Kubescape Achieving CNCF Incubation

This is Textron tv. Hey guys, thanks for the throwaway here with Shali Rosen, who is CEO for Armo, and we're talking about cube scape, which is now one of the incubation projects in the CNC F1 of many of these days. But we're specifically talking about what is it gonna take to, um, ensure runtime security in the age of cloud native.

Shelly, welcome to the show. Hi. Thank you for having me.

So, walk us through the problem you're trying to solve here with cube scape. 'cause there are just a lot of choices out there, and I'm not sure everybody's up to date on cube scape itself, but what exactly does it do and why did you decide to donate this to the CNC? Okay.

So, um, first I would say that the need for an agent that, uh, resides within your environment, either on the VMs or containers, uh, in different environments, Kubernetes environments, uh, is becoming critical in order to do cloud security. Um, I think in the past, um, there were quite a lot of discussions around agentless security, but by today everybody understands that with security, if you wanna go into random security, you need, uh, an agent or a sensor, if you will, that will be deployed, uh, and analyze the data. Specifically in our case, uh, we're using, uh, EBPF in order to, um, get all the data and, uh, and do all that work.

And I think it is becoming a critical part of cloud security, and that's why we've built it. Now, why did we make it part of the CCF F is because we believe if you wanna put a sensor in your environment, um, we advocate for it being an open source, um, sensor. We think it'll be much easier for DevOps to adopt.

Um, once, uh, a sensor is, uh, you know, an open source sensor and it's supported by the community, uh, deployed by, you know, you know, for example, cube scape is more than 100,000 installs out there. Uh, it helps us to create credibility, stability, to make sure that, um, the scale of, of the project and the scale that it can handle, uh, is large enough. So that's a big part of, you know, why we made it open source, because making it open source make basically makes it prevalent, right?

Um, and reaching incubation, uh, in the sincere is just another step of building that credibility. Um, showing that we have the right governance. We have Fortune 500, uh, companies, uh, as end users for the project.

Uh, it was important for us, uh, to do that. Well, this reduce therefore the number of agents that I need to deploy. 'cause part of the problem I think people are starting to see is that everything I have out there has an agent, and then that just adds more infrastructure consumption and more things to manage.

Yes, that is true, and I do believe it'll reduce the number of agents. Uh, you need to install, you know, security. Every security company comes there with another agent.

I think as we consolidate agents, and I think it should be consolidated into open source projects because that's the, I would say, um, the, the common denominator and the one thing that, you know, can be actually contributed and supported by many companies. I think that's the way to go. Is agent versus agentless, is that an either or conversation?

If I have an agent, do I skip agentless altogether? Or is there some, uh, middle ground between these two? Well, data wise, if you want to use Ranta information, um, you kind of like have to go to the agent route, right?

You need to have an agent that will understand what your applications are doing, what your containers are doing, what processes are running versus not. I guess the discussion is whether once you have an agent, do you still need the agentless scanning? Um, because you know the agent is already in place.

Why don't you let that do the scanning? Uh, and then I think it's, uh, a lot about cost. Uh, agentless, you know, site scanning is quite costly, you know, takes a lot of data out of the environment as well.

Um, it has the, the, the main benefit of it is that it is easy to install, but once you have an agent, I think then, then there is a question of whether you want to keep your agentless scanning or just, you know, use that agent to do the scanning. You mentioned EBPF, um, has that become sort of a defacto standard for collecting data now in these environments because, um, it seems like it runs deeper into the Linux kernel and so it's a way to see almost everything. Yeah, I think EBPF is becoming the standard way to get, you know, random information, uh, from, uh, from different workloads, uh, and applications.

Um, it is proven to be more stable than, you know, the old ways where we did like a kernel agents on our own. Uh, EBPF is more native, uh, to the kernel. There are some disadvantages for, for example, if you want to create like a Windows agent, you know, it's a bit more problematic, uh, because the EBPF is more of a Linux thing, but it really depends on the environment that you're targeting.

As long as you're targeting cloud environments, I would say probably like 95% of them are Linux based, and today all of the big clouds are supporting, you know, the latest EBP version. So it, uh, it's becoming much more prevalent. Um, and there's also a perception point there in terms of once you're using EBPF, it, the perception at least is that it is less intrusive.

You are using, you know, native capabilities now, you are still quite honestly running something, you know, on the kernel, uh, in the user space taking data back and forth. So it is still an agent, you know, I don't want to make, I make any claims that it is not, but I think it is more native and, and easier to, I would say, adopt, um, than, um, previous agents. Now, one thing I would add is that not e all EBPF agents are also born the same.

You know, you can definitely screw up, uh, pardon my French, uh, your environment using the wrong, uh, EBPF agent. Uh, the different agents take different types of resources, CPU, utilizations memory, they can create quite heavy loads on the environment. And so I would encourage anyone adopting an EBPF agent to actually test it and test our ities, um, and test, you know, the requirements that that it comes up with.

So how will ARM o add value on top of that? If the agent is free, what exactly are you providing? So, uh, think about it as an architecture of a sensor and then, um, log logistics or, or, uh, um, would say, uh, logics, uh, on top of it.

So, um, amo, um, uh, cube scape is a sensor that sits in every cluster or every workload that you would like, uh, to examine. It collects all of the data. It keeps the data in native format, which is available for you to use, uh, all of your vulnerabilities of your, all of your random information and network policies that you can create Second profiles, it equips, um, you know, the DevOps and the SecOps with a lot of tools that they can utilize to harden their environment, make them better, and also detect and response.

Uh, but you would use the API, uh, in order to do that, uh, if you want a management platform on top of all of your sensors and all of your clusters, that's where AMO comes in with some more advanced capabilities, like profiling the applications and finding malicious divisions out of it, uh, and creating a full CADR platform. So another thing that ammo does, it's take the cube scape is an A DR in my mind, it collects the application data. Uh, but once it goes back to Daro platform, you can also connect your cloud data into it.

And ammo is one of the only companies today in the world. I think that, you know, attackers, they don't care about the fact that you have a cloud and the Kubernetes and the workload and all of different systems. Um, and AMO takes the data from the cloud together with the sensors to create one story, um, of the attack.

Like an attack can, can start in the application, move to the cloud, get an IM role, if you wanna understand all of that together. That's the value of the AMO platform on top of the sensor. And we just keeps, We hear a lot about DevSecOps, we hear a lot about platform engineering and there are other telemetry tools out there.

How do you think all this is gonna converge someday? Well, I hope that sooner or later, uh, and maybe one of the cloud providers, uh, will pick that glove. This, like, I was actually thinking about, you know, this concept of a universal agent.

You know, because many of us collect the same data in different places. The telemetry guys collect the data, the security guys collect the data. So one of the things, actually, a guy from a WSI was no longer there was trying to, to drive and it's, I think it's stopped, was to create a universal EBPF agent where one agent collects the data and then anyone, uh, can use it.

Uh, unfortunately, you know, it'll require a lot of collaboration and a lot of, uh, big companies, uh, giving up on a lot of things that kind of like, they hold pride. Um, so I don't know, politics might be, you know, um, might, might stand against, uh, that vision coming true. But I think, you know, in the long run, I would hope that would be the future where, you know, EDPF data just becomes available for anyone want wanting to use it.

Of course, you know, we still see people struggling with cloud security in general, and then we're trying to now do that in the age of cloud native. Um, what do you see that organizations are doing over and over again that just kind of makes you shake your head a little bit and go, folks, we could be a little bit better than that. I think the one thing that I see again and again is, you know, companies just checking the box, you know, uh, doing, um, you know, for example, looking at all of their vulnerabilities and issues, uh, but not, not double clicking on whether they're relevant in their environment or not, not really, uh, making the changes.

Um, I'll give you one example, right? Um, you see company, like almost every company are running today with a critical vulnerability in its environment. And it's not that they, uh, they don't care about it, it is just that it is a reality that they feel they need to, to live with, right?

Um, it's gonna take time until the developer will fix that vulnerability and it becomes a race. You know, what will happen first? Like, will the vulnerability be exploited first or will we fix it first?

And we know it takes two to three weeks to fix vulnerabilities. And, and one, one thing that boggles me is that companies kind of like decide to live with those vulnerabilities, uh, in an age where today you can actually harden those vulnerabilities quite easily with things like network policies and second profiles that will reduce the probability of an exploit, even if the vulnerability exists there. Um, but these are hardening capabilities which are quite advanced, and I think companies are just not there yet.

And, and that, that's the thing that I think is really missing. So you think on a certain level, we've kind of conditioned ourselves to live with vulnerabilities 'cause we're afraid that whatever we do is gonna break the application so nobody does anything, and the end result is an outcome that is, shall we say, sub Optum? Definitely.

I think, uh, you phrase it much better than I did. Um, definitely. Well, folks, I guess they say back in the day, I think somewhere along the line, FDR, we have nothing to fear but fear itself.

And maybe that should be applied to vulnerabilities. There you have it. Shelly, thanks for being on the show.

Thank you for having me. What was a pleasure? All right.

And back to you guys in the studio.