EP279 Native Cloud Security: Is 'Good Enough' Actually Winning?

Security. Hi there, welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here is ever myself, Tim Peacock, uh, Group Product Manager on Google SecOps, and of course Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. Find and subscribe to this podcast wherever you get your podcasts, as well as on our website cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us, and the rest of our Cloud Security Podcast listeners on YouTube, youtube.com/@cloudsecpodcast. Anton, we are talking about a type of security which is neither first-party nor third-party. What are we doing today?

Yeah, that's actually going to be fun because we lived in the world where you either go to your cloud provider for security of the cloud, or you go to a third-party vendor like Wiz, Oh, wait, Wiz is not truly a third-party vendor.

Ah, there you go.

Keep going. Let this be. But what I really wanna talk about is that that was the line of thinking between cloud provider or a separate company. But apparently, somebody built a very interesting middle approach where they use cloud provider controls in a very cloud provider-native manner, but they also deliver value on top of that without truly resorting to being a third party. And this is really interesting. When I first heard of them, I was super curious and impressed. And then I feel Phil Venables gave them some money. Well, not Phil personally, but Ballistic Ventures. And I thought we should probably talk to them in detail.

Ah, this is another Ballistic company.

Yes, we should probably talk to them.

Ah, I didn't realize they were a Ballistic company. I have such warm feelings towards my friends at Ballistic, so that's really nice to hear. I do want to note, listeners, the discontinuity as we turn things over to today's guest. You will notice Anton and I both teleport Do you teleport? I know I teleport.

Yeah, I teleport, but I also teleport while feeling really silly because I think we just forgot to record an opener. We should just admit that.

Listeners, Anton and I forgot to do something, which I have to tell you, there's a reason Anton is not a PM, and there's a reason I'm not a very good PM. It's— we're both very forgetful.

You are a group PM. You're a very good PM. You're almost as good as a group of PMs.

Ah, apparently I'm as good as a group of PMs. Maybe without any further jokes about the silliness of L7 titles at Google, let's turn things over to today's guest. Today, we are joined by Gal Ordo, the co-founder and CPO of Native Security. Gal, thank you so much for joining us today. Anton, the first question, despite my intro, is actually for you.

Yes. And this is because maybe I am the one that's obsessed with the question. We did an episode of our podcast quite some time ago where we debated the native controls, which are built by CSP, and the third-party controls, which are delivered by, quote unquote, third-party vendors. And suddenly, when I met the team from the company called Native, well, Vergil founded, I realized there may be a third way. And the binary choice of, do you go third party or do you go cloud provider, is actually not the entire universe. And it was very mind-opening to me. So, your existence seemed to depend on the fact that the CSP controls are superior, but there is a role for a vendor in that. So can you explain how all that works? I mean, this is sort of like a little too magical for some people to understand.

It is, it is. And I think that's part of why we started the company, right? So the story of starting the company actually goes back to my time at AWS, which is where I also met one of my co-founders. But in any case, during that time, I was meeting with some of the largest enterprises in the world. And they kept mentioning security outcomes to me that they would like to achieve, especially on the secure-by-design front, which is really where I think that cloud providers excel.

Mm-hmm.

And they would ask me, Gal, how can we achieve that? How can we install a perimeter? How can we put in some restrictions or some boundaries? And I would come back to them with these long implementation guides that would sustain the answer, would help them achieve the outcome that they want, But would take them months to implement. And the answer was always, how was I supposed to have known that? Is that actually sustainable? How can I do this not just for this one project, but rather for the dozens of different projects that I have managing my perimeter and my access boundaries and my least privilege requirements and so on and so forth? And after having heard that so many times, that's why we decided to start a company.

Hmm.

I mean, we obviously would not hold the Amazon background against you. This is better rather than having a background in a company that's still in the '90s. I mean, occasionally we see founders that know their reality really well, but that reality doesn't match others. I think this is very modern and good, but it is a fascinating story. So, I think you convinced me, and now let's see if you can convince Tim there is a third way between just go to CSP or go to a third-party vendor.

I mean, I think most listeners know that I go both ways. And so, I appreciate that there is a third path here between just the straight and So this I appreciate. One of the things that I've seen in my career is that an AWS WAF and GCP Cloud Armor, they're not the same. Their output isn't the same, their config isn't the same. And so how, when you're guiding people, do you handle this problem? How do you communicate this without falling to a lowest common denominator? Do you dumb it down to fit everybody? Do you expose the unique complexity everywhere? How does it work?

Yeah.

How does it work in real life for people?

I think you hit the nail on the head. And it's not just AWS WAF and Google Cloud Armor, right? Like everything that I like in each of those enforcement controls that I look, they don't work the same. And sometimes there is even no one-to-one equivalency, right? If I were to use a different example, if I were to do 2 restrictions with AWS service control policies, one of them would map to a Google organization constraint and another would map to a VPC service controls, and I can do the same mapping the other way around.

Yes.

And that means that, you know, what sounds like the simple task of allowing customers to focus on security outcomes actually becomes so complex, especially when you're in the multi-cloud world. The way that we attempt to help customers is actually still give them that interface that allows them to, you know, set an internet access perimeter, for example, But then as they go and they apply the settings and they choose, for example, which accounts or projects should be adhered by that, or which services should be applicable, we also go and tell them the impact and how is it going to work. Is it only going to work on new things, or is it going to apply to existing stuff? And so on and so forth.

Yeah, that's another thing. Like org policy constraints, VPCSC, sometimes they're retro, sometimes they're forward, sometimes they're warn retro. Very confusing. I want to pick on this again with maybe a slightly different example. Like, if I'm reasoning about the security posture for my Kubernetes cluster or my AI workload, how do you possibly translate intent between the differences of Cloud Run and Fargate? And then not just the control effectiveness or control intents, but what about the errors that they report? Like, surely those errors, like if the config is this divergent, surely the errors are that divergent. So how do you possibly help somebody reason about bring errors under control.

Yeah, absolutely. And I think it all goes back to where customers start. When you talk to a CISO, a CISO is never like, a Fargate should do that or a GKE should do that. They always talk about the perimeter patterns and the overall exposure requirements and so on. And these then get translated by cloud security engineers at various enterprises to the implementation on storage accounts in Azure and S3 in Amazon. And the same across all of the different providers and then the different services as well. And then you reach those gaps. And what we are trying to do is we are trying to help with the translation in a way that would say, hey, so for this particular service, you need to use that and this is going to be the outcome and so on. And then to your point, once you do the enforcement, the errors are also different and we do the reverse translation.

Hmm.

So we do the translation to tell you, hey, this sort of access pattern was blocked here and this other access pattern was blocked there. But at the end of the day, they're all a result of the same policy. So when an engineer goes back to their CISO, they can say with certainty, hey, your requirement to make sure that our crown jewels are not exposed to the internet or that our cloud can only operate in the US and in Europe and so on and so forth, this has been implemented.

Hmm.

And then to your point, there are implementation differences. But that's where it becomes about the technical differences rather than the policy itself, which our customers want to focus on.

Let me ask you a strange question about this. I think that what you described makes sense, but I think it relies on one little thing, namely that you have to be right when you say that. I mean, I think what you've described is very easy to do if you don't care to be correct, but it is actually really difficult to do if you say, Yo, for this change, if you make this type of change in Amazon, this would happen, in GCP, this would happen, and Azure would freaking explode. I think that you have to be actually correct every time in a very deterministic manner, right? So, how did you make that happen? Tim is making a face.

Well, it's just you left a really slow pitch over the middle of the plate about Azure exploding. I'm trying so hard to not just Swing on that one. But Gal, please, please answer Anton's question before I take this cheap swipe.

No, I actually love the question. By the way, a variant that I keep on hearing is, Gal, you do this translation. Why can't my AI do that? And in reality, if you go into a ChatGPT or a Claude or whatnot and tell them, I need to install that restriction, you get 5 different answers. And each time you do that, depending on how you phrase the prompt exactly, And by the way, I don't think any of them would be the right one. So I completely understand, Anton, how you can direct this question to us. And we've been around for close to 2 years now, and we've built the team and the expertise to actually go and do those sort of research. So when we just started the company, and one of the reasons that we decided to focus on policy is that I partnered with a former Fortune 100 technology customer of mine from AWS who faced— who brought that exact problem to me. And this was a research project that on our side, just the research itself, not the implementation even, took like a month and a half or 2. So we have a very strong team of people doing that, that are former AWS and former Google and former Azure. And former enterprise security doing exactly the same kind of job. And they've worked so hard on that that we were also able to train a special model to help us with that as well, to get to the right answer. But enforcement has to be deterministic, and there is always going to be a human in the loop on our side as well. So we use AI as an accelerant, but not as a way to replace a research team.

So you're kind of like a law firm. I'm paying you because I trust you to be right and you've got a professional reputation that you're going to be right. Sure, I could ask the same question and get a different answer from AI, but the reason I'm paying you is because it's your professional job to be right.

So it's part of our job, right? But it's also not that even when you look at VPCSCs in Google organization constraints, it's not like that you do the translation, you put them and you're done. then there are living, breathing policies in your environment that are doing enforcement, and you need to manage the exceptions for them. What happens if tomorrow, say, Google releases a new way to be exposed and you need to update your policy?

Mm-hmm.

What happens if, you know, your business requirements change? And that's why when I started looking at historical approaches to doing this, other than the build your own and the consulting companies that have done that, I did not see any other sustainable approach, especially the one that deals with the operational questions. And this is where, by the way, we see the big difference as well. I'm not just there to do an assessment. I'm literally there to go help you build.

To actually do it. Yeah. You're not doing the assessment. You're doing the assessment and then doing the work, which to me is the difference between you and a human-centric approach.

Right. And by the way, in AWS, I was the person doing the assessments, right? Like, I was leading CNAPP for them. I was leading Security Hub. Tim, I know that you're doing similar stuff in Google. I was actually talking to them.

I used to be, yeah.

Yeah. Yeah.

So, you know, law firms aside, let's— Anton, you move on to some fresh fields of your next question.

Yeah, I kind of want to touch on the sort of another obvious question, maybe less obvious than the one about you being correct. But again, in my Gartner days, which at this point are quickly moving into the past, We did have to formulate the advice about, do you go to a third-party cloud security vendor, at the time, mostly CSPM, or stick to the vendor? And I think that we typically, the classic advice from the late 2010s was that native tools built by the CSP are good enough for 80% of the use cases, but maybe lack the depth of the specialized vendors, and also lack, of course, the beautiful UX. And again, I'm not blaming Tim for SCC UX, but we do know that cloud provider-built stuff isn't as beautiful as, say, made from Wiz. Oh, please.

Ah, Waze is now a cloud provider as well. So, you know.

See, I came back home. Yeah, I didn't know anybody. But where I'm going with that is that if you primarily orchestrate native controls, what about the case when the CSP does not have a control? And maybe there's some kind of an odd way by a third-party vendor to make it happen. So, how do you then help the customer? What happens if they need a feature that CSP doesn't have yet?

This is a fantastic question. And really one of the values that I put when starting the company is I don't want to focus on the lowest common denominator.

Yes.

So the first thing that we do is if you can enforce something on, say, Google and not AWS, or vice versa, by the way, we've seen both happen. We don't restrict the AWS functionality or the Google functionality. That functionality exists. within the product, and we first launched that one. At that point, we started asking ourselves, how can we think outside of the box to make sure that we can provide the same level of enforcement in the other cloud provider? So I'm going to take an example that I mentioned earlier, managing connectivity of cloud accounts or projects to the internet.

Classic.

Google has made this easy or relatively easy with VPC service controls. Like, it's an amazing product. On the AWS side, you don't have that. You have 40 or 50 different services that are susceptible to this access pattern. Some of them have central enforcement, each with a different policy type. You get like 3 or 4 different policy types that help you cover different services. And then when we did the same research on our side, we found like 10 services Some of them very popular ones like RDS, but other ones super esoteric like Elemental Media Package. Who's even heard about that?

Not me.

That can be exposed to the internet and do not have a central enforcement mechanism. That's—

Of any kind. Yes, that's exactly right.

Yeah. Yeah. And that's where we went in and said, okay, so how can we augment these native controls with additional enforcement to make sure that your environment is fully protected and nothing is exposed. And we went and we engineered complex solutions that rely on a function that we go in and install in the customer accounts that listens to changes and then goes in and updates those services. But beyond that, we've also created a policy update mechanism that would go in and do a policy update and recommend a new policy to the customer every time AWS expands its enforcement mechanisms.

Hmm.

So even, you know, in Google itself with VPC-SCs and organization constraints, you constantly add new services that are being supported by those. So really the magic is to build that highly engineered enforcement mechanism that gives the customer a very similar outcome in a way that, you know, might not be ideal, but would still mean that they're protected. But also, as soon as Google or Amazon or Azure or whatever launched the better enforcement mechanism, issue an update. And this is what we partner closely with.

That's nice. That's really nice that you can flip to the native control once it's ready.

You do have to pay attention. But yes, ultimately, that's your job to pay attention.

Yeah, right.

I want to ask a very product question here. Because as I'm thinking about this, I'm having all these CPO Question thoughts here. Your customers, what are they pushing you towards? Do they want more depth on AWS, GCP, Azure? Do they want more push towards, you know, the SaaS things that maybe an Obsidian or Material would look like? Are they pushing you towards the Snowflakes and Databricks and the Salesforces, the Oracles, the Alibabas, the CoreWeaves? Like, which ways are you getting pulled? And is it all of them? Because if I were a customer, I would say, give me everything here.

It is all of them. And it's also Kubernetes. And it's also the private clouds like OpenStack.

Oh, no.

Oh, no. That sounds like work.

Nobody's asking for like Mesosphere though, right?

So far, no. So far, no. But you know, these are all great asks to have. And really, our immediate focus is to make sure that we are able to give the absolute full coverage on the public cloud infrastructure. We are moving into Kubernetes, we might be and eventually will be moving into some of those other stuff as well. But there is so much depth to the capabilities that each of the cloud providers give the customers that even on the public cloud front, we have more than enough work. And this is our focus right now.

If I were a PM on your team, I would, I would support that strategy.

Let me put it that way. I hope they do. I hope they do. And hopefully I'm not Too scary so they can tell me otherwise.

What about this nasty SaaS question? Because, you know, Tim listed a whole bunch of well-known, some less well-known, and some really not well-known providers. But ultimately, he ran through the whole list. You can't really do it for SaaS. Does anybody show up and say, but look, Workspace has great native controls, but we want something that controls Workspace and Office 365? That sounds like another job, right? It's not your job, right?

It is. And I'm not trying to do that right now because I want to be the best in public cloud. And there are other companies doing that, by the way.

There is SSPM, which is sort of trying to do a version of that. Yes. Sorry, I'm the acronym— my acronym mastery is not as good as it was before. But yes, I think that makes sense.

I mean, you're better than me in that, obviously, because of your Gartner background. And we don't even have an acronym yet. So this is just me trying to show people that cloud security is about building actually, and not just about being stuck in a visibility loop.

So let me ask one more cloud customer product question before we move on, because it's going to itch at me if I don't. Are your customers mostly 80% one cloud as a focus and like 20% other stuff? Are they, we're in every cloud, or are they, worst of all, Running workloads that span clouds? Where are people at in their multi-cloud journey?

Big sigh.

Big sigh on multi-cloud.

No, it's a complex question. And the multi-cloud question always comes up. And I think our customers are actually very representative of what the world is in terms of multi-cloud. So, for the vast majority of them, there would be a primary cloud provider, like 70 or 80% of the workloads would be someplace and then the rest in one or even 2 split clouds. The multi-cloud case that, oh, I know what I'm doing on AWS, but I don't know what I'm doing on my Google, or vice versa, by the way. This is actually a big hook. Like, we start a lot of engagements from there. Like, help me see what I have on my primary cloud. Help me align it to all of my secondary clouds. At that point, once they connect, we also show them, that in the primary cloud, there is a potential for a much better program as well. You know, our first customer, or rather one of our first customers, was an ex-AWS colleague of mine. And he was an expert. Like, he developed some of these products. And he came in and he told me, Gal, I'm sure you're not going to find any gap. And even in the first technical policy that we reviewed, and it was a simple one, he told me, We restrict all of our AWS cloud just to the US. And even when we reviewed that, we saw that they accidentally also had Thailand open and that that restriction was installed on all accounts with the exception of production. So in fact, some of the crown jewels were completely exposed. So we keep seeing that all the time.

Honestly, I totally believe that. I spent 5 years of my life building security controls and Security Command Center for GCP. If somebody said, Tim, you're now in charge of this production environment, I guarantee within a week, it would not work the way I thought it worked.

100%. 100%.

Let me ask you a strange, possibly somewhat cynical question, because I think we need to start closing the episode soon. Tim, feel free to ask about the security theater if you feel like it. But I want to ask about another strange hypothetical to which we kind of all secretly know the answer. Still. So, what if the CSPs suddenly, A, improve their UI/UX experience and become more multi-cloud? Because we do have some multi-cloud features and other people make— have certain— Azure, I think, has some things where they control or at least see what others do. So, would you then cease to exist if one or more CSPs do perfect UI and... barge into the turf of other CSPs by securing their environments?

Love this question. And I'm going to divide my answer into 2. First of all, I think that each CSP going and improving their, their controls and their experience actually benefits Native as a company and its customers. When the experience within each provider, when the technical primitives within each provider are the best, I can focus on providing more security outcomes and more secure-by-design enforcement for my customers rather than having to go and build monstrosities such as the one with the functions that I described like 10 minutes ago.

Thank you for calling that a monstrosity because I was going to, but I kept my mouth shut.

Honestly, it is. It is. But I would rather build it myself than have one of my customers build it, right?

Totally.

Like, I was working with Fortune 100s that showed me monitoring dashboards and whatnot. I would rather give it to them rather than them having to do it. So, within each individual cloud, this would be— in fact, it would help me drive a better experience as well. So, I collaborate very closely with those service teams. On the multi-cloud interoperability, this is where We at Native have the base assumption that each provider knows its inner workings the best way and is able to do the best enforcement for that. And this is why we call the company Native. We based our entire vision on that. When it comes to, you know, when Google goes and does Azure stuff or vice versa, Google is essentially a third party to Azure.

Mm-hmm.

Mm-hmm.

And that's where you have seen the multi-cloud initiatives from Google, from Azure, from AWS that they announced focus on multi-cloud CNAPP and API monitoring and detection. And when we started the company, we were like, we want to focus on what the native controls are best at. That's secure by design enforcement at the source. And I don't see Google successfully doing that for Azure.

I think this is a conversation we could have for probably a week and a half, you and me, given the things I've worked on, given the things you've worked on. I wish we could, but we can't because we are a 30-minute podcast, not a, you know, whatever a week and a half worth of minutes is podcast. Uh, my wife can do that math in her head. I cannot. So I have to ask, Gal, traditional closing questions. One, do you have a piece of advice to help CISOs get better at adopting native security controls? And then 2, do you have recommended reading? And that could be anything. And I will pitch one piece of recommended reading myself, which is Anna Karenina. The thing you said about providers knowing themselves best, I used to pitch that all the time, and I called it the Anna Karenina theory of cloud. I said every happy cloud is alike, every unhappy cloud is different in its own way, which is a bastardization of the opening line. And my point was you should work with a provider who knows their cloud the best, which is themselves.

Yeah. Yeah. So on the first question, do I have a piece of advice?

Yeah.

What I pitch to my customers when I do talking engagements is focus on the outcome that you want to achieve. By focusing on the outcome that you want to achieve and not the technical controls and what they let you do, that's where you can actually achieve those outcomes. You know, I've worked with customers where they came to me and they were like, This is what VPC-SCs can do, or this is what AWS SCPs can do. But then I ask them, great, and how does this help you? And I've heard complete silence. So my recommendation is always walk backwards from the requirement, from what you want to achieve, then do the translation, and then decide if you want to achieve this natively or with a third party or whatnot. By the way, I'm not pitching that the native controls are always best. I'm pitching that they should be optimally used for what they're best at. So, there's that. Then, to your question on a recommended reading, Anna Karenina is a good one, like, and not one that I would expect.

Okay. Let's just leave it at that then. Okay. Okay. Okay. I don't think it's cheating. I think that's perfect. I think that's back to the CISO therapy theory of security.

I love it.

So, thank you very much for being on the show. This really went well, and I hope the wait was worth it.

Perfect.

Yeah.

Gal, if you're ever in San Francisco, let's get a coffee or a beer and talk about all the pain of building native security controls.

I'll keep you posted, but I'm actually at Next next week.

Oh, you're at Next next week. So are we.

Oh, lovely. See you there.

So we'll see you there.

Yeah, I'll hit you up. Perfect.

Awesome. Hit us up. We'll talk soon. Thank you so much for joining us.

Yeah. Bye, Anton. Bye, Tim.

And now we are at time. Thank you very much for listening and of course for subscribing. Please subscribe so you can get new episodes piping hot And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, We can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google.

Security running.