Cloud-Native Security Posture Management

Lightspin CEO Vladi Sandler talks with Mike Vizard about how cloud security posture management (CSPM) is challenging in cloud-native computing environments. The video is below followed by a transcript of the conversation.

Announcer: This is Digital Anarchist.

Mike Vizard: Hey, guys. Thanks for the throw. We’re here with Vladi Sandler, who’s the CEO for Lightspin, they’re in the security space and they’ve just raised $16,000,000.00 in funding. Vladi, welcome to the show.

Vladi Sandler: Thank you very much for inviting me.

Vizard: So, you guys are in this whole cloud security posture management space around cloud native and Kubernetes—why is that different in a cloud native environment and what should people be thinking about in the context of that type of platform and Kubernetes?

Sandler: That’s a good question. We see a lot of play in this market and, having said that, no one really solved the problem today. The biggest challenge today in the cloud is the ability to prioritize and simplify our posture management, and that’s exactly where Lightspin is different. Lightspin gives you a contextual approach that helps you to prioritize your main issues, spot them using our graph-based technology in a dynamic, risk analysis way, and help you into an easy way to mitigate the issues.

Vizard: Is security more difficult in these environments because you’re dealing with microservices and there seems to be containers and there’s a lot more moving parts, per se?

Sandler: It’s a really philosophical question, because from one side, in the cloud, everything is easier, because you have a structure, not like on the on-premise environments. Everyone uses the same rules of permissions and configurations.

Having said that, there’s millions of permissions and configurations, millions of microservices and services, and unfortunately, we have created ________ for experts, and as you know, the digital transformation, especially in the period of the COVID, came to make it more difficult to do it in the right way. Most of the customers today, as we set it from our database knowledge and experience, are trying to just copy/paste the on-premise methodology and concept design concept of the cloud, which is not always working the best.

Vizard: And who’s driving this conversation these days? Is it the developer or is it the security team that’s interested in this type of platform? Who do you engage?

Sandler: One of the things that we’re trying to impress to the world is that we know how to bridge between the DevOps and the security. Because even if the CISO is the paying customer, right, in the end, the target buyer, his people, his Security Engineer will use the platform. And when the Security Engineer opens a Jira tickets, let’s say, in the platform, from this moment, it’s moving to the DevOps.

Now, if you want to be DevOps friendly and you want to help DevOps to simplify the mitigation plan, something that our technology knows how to do, and help them, they weren’t ready to do that, right? So, you have to be both agile for DevOps and security teams of your cloud.

Vizard: Right. We’ve seen developers start to provision things on their own, they use various tools such as Terraform, and there’s a lot of misconfigurations. There’s issues in the cloud itself, there’s issue with the Docker APIs, there’s issue with Kubernetes itself.

Sandler: Correct.

Vizard: Do you think that there will be a backlash coming against this whole notion of shifting left? Because we are starting to see a lot more attacks against the software supply chain, and the security people seem to be maybe having a bigger mandate around application security.

So, what’s the right balance between those two motions and do we need to change what we’re doing?

Sandler: We should do a change. We’re taking a more shifting left approach. The reason is—there is a couple of reasons. Even before supply chain attacks and CI/CD offensive approach, if you look on the relationship in the organization, everything is about time to market. Which means, if the DevOps did it or the developer, it depends who had the authority to deploy data deployments, and then ________ to do, I don’t know, did some pen tests or decided to do a pen test and discovered some critical findings of the misconfiguration or an overly permissive role, you have to convince and find the Devs to convince them to fix it because it’s on the deployment, right?

But if you can do a shifting left, detect and avoid the issues before the deployment during the build process, failing and building something, it’s the nature of DevOps. Everyone understands it’s a reasonable thing to do. So, it’s much easier for the CISO to convince the DevOps now is the right time to fix the problem, or take a decision together with the DevOps that it’s not enough critical at this stage, and we understand the risk, and we’re ready to work together to fix it maybe in the next deployment.

So, if from one side, we understand that, yeah, the shifting left, it is the right approach and solution. Another main point we see today really strong in the market, and we came from this approach as well, is to be more proactive. Most of the customers are trying to be more reactive solution based and buying a more reactive solution. And when they say that and all these people are asking, what is the differentiation between proactive and reactive solutions, and that’s really super easy. It’s like, I will analyze your home and I will tell you that you don’t have a door. But having said that, you decide to buy a dog in case someone will come, right, instead of just to buy a door. That’s the concept of a proactive solution. Deploy ________, build is running, we will detect the issues before they happen, and we’ll mitigate them one step before someone can even try to exploit them.

So, if I will answer to your question in a really simple way, the combination of those two assumptions brings an understanding that we need to help the DevOps to be more security oriented in moving more shifting left to the DevOps security approach and shifting left approach in order to simplify your cloud security posture management and probably give better capabilities to do the time to market.

Vizard: Am I doing that by involving the developers more, or is there some way to automate this process inside of the DevOps workflow so that they can do what they need to do, but they don’t have to become security experts, because it seems like training those guys is just too big a hurdle?

Sandler: Well, I think that, first of all, training is important. There is no technology in the world that can replace training. Even AI technology won’t help you here. You have to understand the starvation for experts. It is the biggest problem of 2021. You need to train your people all the time.

Having said that—yes, good technology can help. Our technology knows to analyze Terraforms and help you to build new Terraforms and analyze the configuration. So, we build for your DevOps the right configuration so your DevOps can learn from that to be more security mature. But even we, every one of our customers, we schedule a training with them one time a year to pass them the knowledge, working together with them every time they don’t understand something from our platform based on gaps that we’re detecting will help them to explain what is the problem we see and how to mitigate it. And if you do that with the right approach, I think the power of the CISO or the Head of DevOps is supposed to be the ability to analyze and see how your people actually improve their DevSecOps skills from deployment to deployment, right, and do less and less classical mistakes, which can bring us the ability to understand that we better know cloud security.

Vizard: There are a lot of these CSPM platforms out there, so ultimately, what differentiates one from the other? What should people be looking for?

Sandler: I think the CSPM, it’s the fourth generation of the solutions, mostly provide you with compliance capabilities. But based on the events of the last three years and the data breaches, when it says all the companies that have been hacked have been compliant, which proves compliance is not good enough. That’s why our VP of Sales or customers a lot of times call us CSPM on steroids or CSPM version two, because we bring the context, the ability not to look on a singular issue, but on the correlation of findings on the way to explain of how finding number one brings to finding number two brings to the issue, the get, right? We call it the attack path, and the reason for that is because, first, it helps to prioritize; second point, it’s healthy to detect the real issues in your cloud environment and not only compliance.

Because if you have 500, let’s assume, security groups with any to any IP address, right, but only one of them really connected to some server, that’s the only one that you want to spotlight to your team and emphasize it. No one has to care about the 500. Of course, if you don’t care—if you care more than only compliance.

Vizard: Mm-hmm. Is it your sense then as we kinda move forward, do I—or us in general—do we need to slow down the rate at which we’re building applications to take into account security, or can we have our cake and eat it, too? Can we keep the rate of acceleration going but make them more secure? Can I get both?

Sandler: It’s a good question. I think that we—I’m a big believer that security should be the allower, right? The ability to allow the business—again, everything is about time to market. So, the ability of agile development, and acceleration in process and scale is the name of the game in the cloud for your business—it’s easier to do your processes. It’s easier you can detect and mitigate things without affecting the production. I think the organization can bring better results and probably save more money.

Vizard: Alright. One other thing, though—

Sandler: I hope I answered your question, I don’t know. [Laughter]

Vizard: It’s a tough one. One other thing, developers kinda think that they’re just gonna fix these issues in the next sprint or they’re gonna push something off to the next update and then all these problems just build and build and build and we just don’t get to it and there’s a million other things that people have to do. And, you know, are we our own worst enemies?

Sandler: I think, could you repeat the question? I missed the question, I’m so sorry.

Vizard: Alright. One of the issues with developers is, there’s a tendency to push things off to the next sprint or they will say, “We’ll fix that bug in the next update” and then it never gets done because there’s a million other things that have to happen. So, are we our own worst enemies?

Sandler: Yeah, it’s a good point. I understand where you’re taking the question to. From my personal opinion—again, priority. Because you don’t need to cure hundreds of issues, and the developers are right, okay? Even some security person who’s selling security—developers are right. Sometimes, they need the focus. You need to help them to focus only for the important things. Everything what is not really important should be moved to the next sprint.

Now, in the security point of view, people always decide what is critical and what is high, but there is no dynamic risk for that. In most of the cases, it’s based on some concepts, right? And I don’t think that it’s always the right approach. It should be tailor made. It should be based on some dynamic risk so that even the developers themselves can better understand if it’s something they’re supposed to fix in this sprint or not.

So, if you help the developers to do a focus, there won’t be this conflict. They will only take care of the big gaps and what is not, they will split it, as you say, for the next sprint as a security projection, let’s say, let’s assume.

Vizard: Alright. Hopefully, somebody wrote that down and remembers to get to it. Hey, Vladi, welcome to the show—I mean, sorry, let me try that again.

Alright. Hopefully, somebody writes that down and remembers that. Hey, Vladi, thanks for being on the show.

Sandler: Thank you for inviting us.

Vizard: Alright, guys—back to you in the studio.

[End of Audio]