 Welcome back to the DockerConCube conversation, DockerCon 2021 virtual. I'm John Furrier, host of theCUBE. We have Om Muljidani, show of founder and CTO and CISO for Acurex, hot startup, hot company. Om, thanks for coming on theCUBE for DockerCon and talking cybersecurity and cloud native. Super important. Thanks for coming on. Appreciate it, John. Thanks for having me. So here at DockerCon, obviously the conversations around developer experience, making things more productive. Obviously cloud scale, cloud native with Docker containers, with Kubernetes all lining up, right in line with the trend that's now going mainstream in all commercial enterprises. I mean, developer productivity, security is a huge time sink if you don't get it right. So, you know, shifting left as everyone's talking about, but this is a huge challenge. Can you talk about what you guys do at your company and specifically why it relates to this conversation for developers at DockerCon? Sure. So John, as we understand today, there are millions of, you know, code comets that are happening in cloud native environments on daily basis. You know, in a recent report Airbnb reported, they checked in 125,000 plus times hem charts in a year. And what that means is that, you know, the GitOps revolution is here. And that also means that, well, you've got your Kubernetes clusters, syncing up with infrastructures code, such as hem chart, customize, and YAML files, right? Almost several times a day. Now, what that also means is that the opportunity to make sure that your clusters are being deployed securely by these infrastructures code templates and deployment as code template is available before the deployment happens and not after the deployment. Also, in order to reduce the cost or detecting security challenges, the best option and opportunity is during the development time and during the deployment time, which is the pipeline time. And that's what we offer. We shift your cloud native security posture detection to left. We detect all your security posture related issues while the code is in development in a design phase, as well as while it is about to get deployed. That is within the GitOps pipelines or your traditional DevOps pipelines. And not only we detect, but we self-heal the code as well, specifically infrastructure as code. So we detect the problems and we fix the problems by generating the remediation code, which we like to call it as remediation as code. The detection mechanisms are called as policy as code. That's the primary use case that we offer. We help developers reduce the cost of remediation and also mean time to remediation for security problems. And also you save them a boatload of hassle too, going back and figuring out how they wrote the code at that time and kind of what happened always is a problem. I got to, okay, so I want to get into this policy as code. You mentioned that. Also you mentioned GitOps revolution. Let's get to that in a second. But first I want you to explain to the folks, what is cloud native security and what does that mean and what kind of attacks emerge as that surface area becomes apparent? Absolutely. So cloud native security is a very interesting new paradigm. It's not just related with one single control plane, like take for example, Kubernetes. It's not just that. It's also the supply chain elements that go into the deployment of your cloud native clusters like say a Kubernetes cluster. You need to secure not just the application code, which is running inside your container images, but also the container image itself, then the pod, then the namespace, then the cluster. And also you need to do all the other cyber hygienic, hygiene related things that you were doing previously. So it's so much of complexity because availability of different control planes, you need to be able to make sure that you are doing security, not just right, but at a very, very cost effective, in a very, very cost effective manner. And the kind of attacks that we are predicting, we're going to see in cloud native world are going to be very different from what we have seen so far. Especially there's a new attack type that I'm, I've coined. I call that as cloud native waterhole attack. What it means is that, imagine that most of the cloud native infrastructures are developed out of a lot of different open source components and pieces. So imagine you pulling up a container image from a open source container, and that container image contains a magma. Container image can directly land into your cluster and not only can enter into your so-called secure cluster environment, usually the cluster control planes are not exposed to internet, but deployment of one supply chain element like a malarized container image can expose you an entire cluster. And that's what is waterhole attack when it comes to cloud native waterhole attacks through supply chains. So these are some very innovative and noble attacks that we predict are going to come to our way in next 12 to 18 months. So you say it's a waterhole attack. That's the coin term that you made. So basically what you're saying is a container could be infected with all the properties that it's containing into a secure cluster. It's almost penetrated like malware would or spear phishing attack. It targets the cluster and then infects it. And so not only that, because your container images that you're pulling in from your registries, registries can be located anywhere, right? If you do not do proper sanitization and checking off your supply chain components such as a container image, it can land in secure zones like this. So not only in a cluster, it can become part of a system namespace very soon. And that's where the risks are that, you had a perimeter, at least of some sort when it was non-cloud native environments. And now you have a kind of false sense of security that I have a Kubernetes cluster which is sort of air gap in one way, like there's no exposure to internet of the control plane. Control plane API is not supposed to internet. That doesn't mean anything. A container enters into your cluster can take over the entire cluster. All right, so that's cool. So I love that attack, kind of attack. So back to cloud native security definition. So you're defining cloud native security as cloud native clusters? Is it specific around Kubernetes or what's specific with a cloud native security? What's the category if water holds the attack vector? What's cloud native security mean? So what it means is that you need to worry about multiple different control planes in a cloud native environment. It's not just a single control pane that you have to worry about. You have to worry about your, as I said, Kubernetes control plane. You have service measures on top of it. You could have server less layers on top of it. And when you have to worry about so many different control pains, what it also means is that the security needs to become part of and has to get baked into the entire process of building cloud native environment, not a afterthought or it shouldn't happen after the fact. So any containers for containers that watch the containers, security for the security to watch the security. So it's, so let's get, we'll get to the, I want to get back to the solution, but one more thing on this one piece. So you're a CISO there. You have a lot of chops in there from your background. I know that. So if people out there, other CISOs are looking at expanding day one, day two, ongoing AI ops, GitOps, day two operations, whatever you want to call it, cloud native environments, how do they consider figuring out how to deploy and understand cloud native security? What do they have to do? If you're a CISO knowing what you know, what steps are you taking? It's funny that, you know, there's a big silo today between the CISO organizations and the DevOps and GitOps teams. So the number one, you know, priority in my opinion that the CISOs, you know, have to really follow is having visibility into their developers. So developers who are developing not just code, but also infrastructure as code. So there is a slight difference between writing Python code versus writing, say, ham charts or customized templates, right? So you need, as a CISO, you know, a CISO org needs to have full visibility into, okay, out of 100 developers, how many do I have who are writing deployment as code? And then how many of them are continuously checking in code and introducing security issues? Those issues have to be visualized while the issues are written in code and as they are getting checked into the repositories. So catch the security issues while the code is getting checked into the repository and the next best stages, catch the issues while the pipelines are picking up the code from the repository. So CISOs needs to have visibility into this. I call it as shift left visibility for CISOs. So CISOs need to know, okay, what are my top 10 developers who are writing infrastructure as code? How many of those developers are committing wonderful code? How many of these pull requests, which are being raised, have got security violations? How many of them have been fixed and how many have not been fixed? That's what is the visibility that can, you know, provide opportunities for CISO organizations to react. Yeah, and more things to put KPIs around too, to understand where the gaps are and where the potential blind spots are. Okay, shift left visibility for CISOs. You've got the GitOps revolution. You've got the waterhole attacks. You have multiple control planes. Obviously complex. The benefits of cloud native though are significant and people doing modern applications are seeing that. So clearly this is direction that everyone's going. The consensus is clear. So how do you solve this? You mentioned policy as code. I'm kind of connecting the dots here. If I'm going to understand what's going on in real time as the code is in flight, as it's checking in, for instance, this is kind of in the pipeline, as you say. So this has to be solved. What is the answer to this? Because it's clearly the way people want it. No one wants to come back and say, oh, we got hacked or developers being pulled off tasks to re-figure out what they fixed or didn't do. What's the policy as code angle? So, of course, there could be more than one way is to solve this problem. The way we are solving this problem is that first thing, we are bringing all top type of infrastructures code and the control planes into a single uniform format, which we like to call it as cloud as code. The reason why we do that, so that we can normalize representation of these different data sets in one single normalized format. And then we apply open policy agent, which is a CNCF graduated project, which is kind of the de facto standard to do any kind of policy as code use cases in the cloud native world today. So we apply open policy agent to this middleware that we create, which basically brings all these different control plane data, all the different infrastructures code into a normalized format. We apply OPA and we use policies to apply OPA on this data. This way, what happens is that we write, for example, we want to write a policy. You don't want certain parts to be exposed to internet in a given namespace. You can write such a policy. This policy you can run on live cluster as well as on the hem charts, which is your development side of the artifact, right? Because we're bringing both these data sets into middleware. So in short, one of the solutions that we are proposing is that different control planes, different infrastructures code has to be brought into a normalized format. And then you apply frameworks like OPA, open policy agent, to achieve your policies code use cases. What is the traction for this direction? OPA in particular, obviously control planes. I get that. I can see the benefit of having this abstraction layer with the normalization. I think that would enable a lot of innovation on top of it. Makes a lot of sense. Totally cool. What's the traction? What's the vibe? Are people reacting to this? Some people might say, whoa, whoa, hold on. You're taking on too much, your eyes are bigger than your stomach. You're taking on too much territory. Whoa, slow down. I want to own that control plane. There's a lot of people trying to own the control plane. So again, it's a little bit of politics here. What's your thoughts on the momentum? What's the support? What's it look like? Yeah, I think you are getting it right, the political side of the things. So one response is that, look, we have launched our open source project called TerraScan last year and we're doing pretty well. It's a full OPA based project which allows you to do policy use code on not only new cloud control planes like Kubernetes and others, but also the traditional control planes provided by CSPs like cloud security, cloud service providers. So TerraScan can be used not just for hand charts and customized, but also for telephone. What we are promoting is a open culture with TerraScan. We want community to contribute, become part of it. Yes, we are promoting a middleware here, but we want to do it with the help of the community and our reaction, what we are getting is very, very good. We, in our commercial offering also we use OPA. We have good adoption going on right now. We believe we'll be able to work with the developer community who have this thing going for us. I love cloud as code. It's so much more broader than infrastructure as code and obviously the control plane benefits. You know, when I talk to customers, I want to get your reaction to this zone because I really appreciate your experience and leadership here. I talk to customers all the time and I won't say name, I won't name names, but they're big, big in fintech and big in life sciences and other areas. They all say, we want to bring best of breed together, but it's too hard to make it all work. We can get it done, but it's a lot of energy. So obviously building code and getting into production, that is just brute force anyway. They got to get that done and they're working on their pipelining, but getting other best of breed stuff together and making it work is really hard. Does this solve that, are you helping solve that problem? Is this an integration opportunity? Yes, and that is true. And we have realized it long back. So that's why we do not introduce any new tooling into the existing developer workflows. No new tool whatsoever. We integrate with all existing developer workflows. So if you are a modern GitOps shop and you're using Flux or Argo, we integrate Terrascan seamlessly integrates with Flux and Argo. You don't even get to know that you already have what policy is code enabled if you're using Flux, Argo, or any equivalent GitOps toolkit. Likewise, if you are using any kind of, say existing developer pipeline or workflows such as the pipelines available on GitHub, GitLab, GitBucket, and other pipelines, we seamlessly integrate. Our motto is very, very simple. We don't want to introduce one more tool for developers. We don't want to introduce one more tool for security. We want to integrate different things, yeah. No one wants another tool in the tool shed. I mean, it's like, it's like really like the tool shed. I think it's all these tools laying around. But everyone, again, this is back to the platform wars. In the old days, you know, when I was younger, breaking into the early days of the web platforms were everything. You had to build your own proprietary platform. Some open source being used, but most of it was full stack. Now platforms are interoperating with hybrid and now edge. So I want to get your thoughts on them. And I'm just really a little bit off topic, but it's kind of related. How should companies think about platform engineering? Because you now have the cloud scale, which in a way is half a stack. You don't really, if you're going to have horizontal scalability and you're going to have these kind of unified control planes and infrastructure as code, then in a way, you don't really need that full stack developer. I mean, I could program the network. I don't need to get into the weeds on that. I got now an open policy agent with Terescan. I really can focus on developing. And this is kind of like an OS concept. So how should companies think about platforms and hiring platform engineers and to something that will scale and have automation and all the benefits and goodness of the cloud scale? I mean, you actually nailed it when you began. We've been experiencing now since last, at least 18 months that, and if I were specifically also, I'll touch base on the security side of things as well, but platform engineering and platforms, especially now, everything is about interoperability. And what we have started experiencing is that it has to be open. The credibility any platform can gain is only through openness, interoperability and also neutrality. If these three elements are missing, it's very hard to push and capture the mind share of the users to adopt the platform. And why do you want to build a platform to actually attract partners who can build integrations and also to build apps on top of it or plugins on top of it. And that can only be encouraged if there is totally openness. Key components have to be open source, especially in security. I can give you several examples. The future of security is absolutely open source. The credibility cannot be gained without that. A quick example of that is Cystic. I mean, who thought they're gonna be pulling such a huge funding round? Of course, that all is on the background of Falco, right? So what I'm trying to get and same for Selim, right? So what I'm clearly able to see is the signs are that especially in cybersecurity community, you are delivering open source based platforms, you will have the credibility because that's where you will get the mind share, developers will come and work with you. Of course, I have no shame naming fellow vendors who are doing this right, and this is the right way to do it. And I think it's totally true. And you see the validation on that, just to verify your point out that we're having a little love fest here on open source, it's pretty obvious. The end user communities are not the hardcore end users like the hyperscalers. Classic enterprises are starting not only contribute, participate, but add value more than they've ever have. The question I want to ask you is, okay, I totally agree on open, as data becomes super important, because remember data is only as good as what you have. And the more data, the better the machine learning, the better the data scale, sharing is important. So open sharing kind of ties into open source. What's your thoughts on data, data policy? Is this going to extend out into data control planes? What's your thoughts there? I'd love to get your input. We are a little bit early in that part. I think it's going to take a little while for the industry bosses to come to terms with that. Data lakes and data control planes eventually will open up, but I see there is resistance in that space today, but eventually it's going to come around. That has to, because that will be the next level of openness once the platforms mature. As an example, today you want to write any kind of, say policies for your same products, right? You have option available to write policies and customize in your languages, but then many platforms are coming up which are supporting policies to be written in languages which are open, and that's data which is going to open up very soon. So you will not be measured in terms of how many policies you have as a product, but you will be measured. Can you consume open policies or not? So that's it, it's going to go there. It's going to take a little while, but I think industry is going to move that. It makes sense. Get the apparatus built on the infrastructure side. Once you have some open policy capability, that's going to build an abstraction on top of it. Then you can program data to be more policy driven or dynamic based upon contextual and behavioral dynamics. So it makes a lot of sense. Oh, great insight here. Love the conversation. Congratulations on your success. Love the vision, love the openness. I'll see we think data as code is big too. I'll see media is data where cube is open. We have the same philosophy. So thanks for sharing. Love the vision. Take a minute to plug the company. What are you guys looking to do? You guys hiring, take a minute to put the plug out for the company. Absolutely. We are absolutely hiring great engineers. You know, a great start-up mind folks who want to come and work for a very, very innovative environment. We are very research and development driven and have got various positions available today. We are trying to do something which has not been attempted before. Our focus is 100% on reducing the cost of security. And you know, in order to do that, you really have to do things that previously were not done in development environments. And that's where we're going. We're open source, you know, big open source initiators with big open source lovers. And we welcome people come and apply our positions. Reduce the cost of security. Do the heavy lifting for the customer with code and have great performance. That's the ultimate goal, great stuff. Cloud-native security, threat modeling, DevSecOps, shifting left in real time. You guys got a lot of hard problems you're attacking. Well, you know, some of the good things that we are doing is also because of the team that we have, right? Most of our core team comes from very heavy threat modeling, threat analysis and threat intelligence background. So we have, we are blending a very unique perspective of allowing developers to tackle the threats which they're not supposed to even understand how they work. We do the heavy lifting from threat intelligence point of view. We just let the developers work on the code that we generate for them to fix those threats. So we are shifting threat intelligence and threat modeling also to left. We are one of the first companies to create threat models just out of infrastructure's code. We read your infrastructure's code and we create a digital twin of your cloud-native runtime even before it has been actually built. So we do some of those things which we like to call it as advanced reach path prediction where we can predict whether you have reach paths or not in your runtime environment that would have been created. And then the Holy Grail obviously the automation and self-healing is really kind of where you got to get to, right? That's the whole, that's the whole ball game right there, you know making that productive. Oh, thank you for coming on theCUBE here at DockerCon 2021 and sharing your insights, co-founder and CTO and CISO. Oh, I'm Will Cedani. Thank you for coming on. Appreciate it. Appreciate it, John. Thank you for having me. Okay, CUBE coverage of DockerCon 2021. Your host, John Furrier theCUBE. Thanks for watching.