EP186 Cloud Security Tools: Trust the Cloud Provider or Go Third-Party? An Epic Debate, Anton vs Tim

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Risk Analytics and Cloud Threat in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. 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 listeners on our Google Cloud Security Community page. Anton, this is an episode that I couldn't be more excited about, and not just because I'm a former Brown University APTA debater who's about to kick your butt in a debate.

I mean, this is something that we've meant to do for quite some time, and this had this sudden bout of motivation for actually doing this. And I think we have sort of maybe 23 billion reasons to not do it before, but ultimately we are going to do it.

We're going to do it. What are we debating?

And I think we need disclaimers. Let's put some disclaimers.

Yes, please.

This is a debate where we sort of maybe threw dice to pick positions.

Yes.

It's not necessarily what we believe deep down. Maybe we'll believe in some mixed combination of that, but for the purpose of the debate, we picked firm positions at the opposite ends of this question. This is a big question. You'll see it in a moment.

And listeners, I want to reiterate what Anton is saying. These are— I wouldn't even want to say these are our opinions. We are making an illustration of 2 positions that can both exist and both be right to certain degrees and certain extents. So they're not Tim and Anton's positions. They're not Google's positions. It's a conversation representing 2 perhaps fictitiously exaggerated viewpoints to tease out a conversation about a topic that I think for many of our listeners is central to the kinds of buying and operations decisions that they're embarking on for the next maybe 10 years of their lives. And so with that, Anton, what are we arguing about and which side did I get? Did I win the coin toss?

Yes. No, we didn't do a coin toss. We went a little bit more rational about this, but ultimately this is the age-old debate about cloud security. Namely, when you, the enterprise, the organization, the business, the government agency plans to build a program to do cloud security, do you primarily focus on the tools offered by your cloud provider? So like CSP-centric cloud security, or do you primarily base your security tools on a third-party vendor? And somebody may show up before we start the debate and say, wait a second, what about multi-cloud?

This is a multi-cloud discussion.

Yes, we do include multi-cloud in the debate. So, we can make single-cloud arguments, but single cloud nowadays is not common. Ultimately, yes, multi-cloud is in scope, and that makes it more interesting.

Yes. And so, with that, listeners, I think I have the pleasure of going first, and despite my 5 and a half years of building Security Command Center, I have drawn the position of arguing against cloud-native, cloud-provider-built security. And so with that preface, let's begin. Anton, I think there are 3 critical reasons that users should consider a third party for their multi-cloud security needs. The first has to do with trusting a provider to provide their own security. The second has to do with consistency, and the third has to do with who I believe will build it best. And so first, on the trusting someone to secure their own front thing, security has for, well, decades had as a well-established principle separation of duties, division of labor. And I don't think it's hard to imagine the potential conflicts of interest that arise Or appreciate actually the benefits of interest that arise in having a third party secure other environments. And so, look no further than press releases put out by some of the third-party security players about vulnerabilities and weaknesses that they were able to discover in a CSP's product. We never would've heard about those publicly. And as the public, we never would've understood the risk of that infrastructure had, say, Microsoft quietly discovered a flaw themselves. Right. Or had SAP quietly discovered a flaw themselves? There's a huge advantage to the public interest in having third-party security, let alone to the user's interest in having a tool which is robust and motivated to find issues. And so one, I don't think we can let the cat guard the cream. We can't have the fox guarding the henhouse. It is worthy and necessary to have a third party do security for a cloud. Two, consistency. We had a whole episode about multi-cloud security mistakes. And one of the things our guests said there is that the original multi-cloud security sin is being multi-cloud because you as a security team, you as an ops team, you as a dev team, you have to learn the nuances of other clouds. The beauty of a multi-cloud security tool provided by a third party who takes a neutral, objective point of view on the multi-cloud foibles and differences of each cloud is that they normalize this and remove the friction and the mental hardship and the anguish of trying to learn 3 different stacks. And so I think when you look at the outcomes and the team staffing needed and the consistency that you can drive, a third-party tool is going to be better than having 3 tools from 3 different cloud providers, or even one multi-cloud tool from one cloud provider, which is almost necessarily going to launder in that cloud's assumptions about how other clouds should operate and And so will never be native to the other clouds the way it is to its own. And then third, I want to talk about building good products. Third parties who have a dedicated focus on this, for whom success is a matter of company success and company failure, are going to be much more motivated to build a good product than a cloud provider who, for them, security is an ancillary business. For a startup in the area, it is their business. For a cloud provider, it's something they do because they think they have to. It's something they do to pick up another couple of percent here. It's not a focused tool the way that it is for a third party. And so I think for 3 reasons, one, the well-established principle of separation of duties and the net positive benefits to the world and the users of having third-party security research happening. 2, the benefits of consistency and true agnostic consistency, not slightly laundered inconsistency. And 3, the dedicated product focus that a third party can achieve building a dedicated tool, I think users are going to be much better served by a third-party tool.

So you do bring up some really strong arguments in some areas. And I think some of them are maybe conceptually weak, but practically, we know they're strong. So let me get to that.

Wow.

I feel like for the first argument about trust, it's the hardest to really confront face-on and say, no, no, no, no, this trust issue doesn't exist. Obviously, it does exist. And you see many security leaders, security technologists, frankly, maybe more security technologists than leaders, who bring up concerns about having the same person build and secure the environment. But I think my counterpoint to this would be presented in a moment. And I think that when I present it as you really want the separation between platform owner and whoever secures it, Some people will be like, wait a second, what do you mean? Surely the person who built the platform knows it best. And hence, in this argument, I can see the kernels of my counterargument, so to say.

Have we just resurfaced open box versus closed box security testing as kind of the tension here? And we agree that that's gone unresolved for 30 years and you need both?

A little bit, but I think it's in the broader domain of the entire security strategy.

Sure.

Let me, as a result, let me kind of change my first counterargument. On this very argument.

Yes.

Ultimately, CSP, cloud provider, cloud service provider, built the platform. They built it from some principles. Some of them may be thinking about security from day one or even the day before day one when it was being conceived. So there's no debate that the provider knows their platform best. And that knowledge to me translates into both practical and sort of conceptual security capabilities. I'm not just talking about using sort of unlisted or non-public capabilities. I'm thinking of your favorite baby, VMTD, which is a way to defeat certain types of malware from the backplane. But ultimately, the fact that the CSP knows the platform allows security to be just better. In essence, I'm thinking of the deeply integrated security of that sort. It's just kind of more secure. I know, more secure security. But the platform knowledge— maps to more robust security. The side argument to this argument is that it's also more integrated with other capabilities. In essence, security is not an island. It doesn't exist in a vacuum. And if you have the teams that operate the cloud, they just get better access to security tools. Just like several years ago, you brought up the point that SCC is sometimes used by, not by the SOC, not by the security team, but by the team that runs the cloud.

Of course.

And to me, this is a decent argument in favor of the same team that runs my Google, my Microsoft, my whatever other cloud environment. The same team would use the security tools that are right there rather than purchased separately. My second argument doesn't hang on any of yours. I mean, this is just a separate argument. I think it's an argument, it starts a little philosophical, but then becomes practical very quickly. Philosophically, built-in is just better than bolt-on. And yes, we have APIs. Yes, we have public APIs. Yes, we can integrate things. Yes, bolt-on circa 2024 is not the same as bolt-on circa 1994 when everything was just duct taped and paper glued titanium pieces to each other. All the bad type of bolt-on. Today we have kind of better bolt-on, but philosophically built-in should in the long term beat bolt-on. So that's the philosophical part. And practical part is that if you do opt for bolt-on and you are connecting things, especially across multiple cloud platforms, you have more seams, you have more connective tissue. And ultimately the attackers, especially the good ones, will see the seams. They would see the places that can break, places where stuff can leak. And I would make an argument in multi-cloud environments specifically, these seams between the environments, between the security layer and the management layer are a risk. And then we've seen them in APIs in some recent breaches. We've seen them in terms of identity providers, cloud from vendor Y, application from vendor X, and identity provider is vendor Z.

Hmm.

Uh-oh. That sounds like some things would not get done right, would not be done right. So to me, this is a built-in beats bolt-on argument, which does have specific examples. And my third argument in favor of essentially trusting the CSP with security, including multi-cloud security, is that, sorry, but CSPs, of which I'm aware of, let's say, 3, like ultimately there are more, but not really. They just have more knowledge, more money, more resources, more engineers who are the best on the planet. And ultimately, we, in this case, we as Google, for example, can afford to do things really right because we believe they should be done right. We are not doing it because we want this one client. We want our cloud to be done right. So the fact that we can afford it, we can do secure by default, we can start from chips, we can do other things, and we have both money and knowledge. For some of the extra tough security problems, We've picked high-cost, high-value solutions, and we executed them perfectly. I'm not just thinking about the hardware root of trust, but there are some other examples where we've picked things to not be done on a budget.

Sure.

They were done really well with quality first, money second. And to me, this is a really good argument in favor of relying on CSP security. There are probably other subarguments. I mean, ultimately, The possibly mythical drive to consolidation really means that for some companies, they don't necessarily want several CSPs and several cloud security vendors and then a cloud security vendor orchestration vendor. Like, it starts to look like a bit of a mess. Yes, they may— if there is one cloud security provider, maybe like what Gartner would call CNAPP with a broad focus, I can see it being covering more needs. But the CNAPP can be also built by a CSP. And then you would achieve both benefits of a multi-cloud security stack with the benefits of it being done by a CSP. So in that sense, I would also say that CSP is a better place for it. Funny enough, you made a point about startups being better tools because it's ultimately their mission and focus.

Yes.

I have somewhat of a counter to this.

Oh, please.

I want to briefly bring it up at the end. That is, Sort of true if your team's livelihood and kind of life and careers depend on succeeding. I can see how people can be more motivated. But in terms of agility, sometimes a startup is faster. They can address customer needs faster. But think about it. CSPs launch a lot of services and sometimes the speed advantage is not on the third-party side. If a certain well-known cloud provider launches 200 services each year, I don't recall the exact number, I would probably consider them as building security for those services quickly. Now, I would yield half a point that in some cases this speed advantage is theoretical, that it can happen but doesn't always. Very fair. But in that case, it's easier for CSP to launch security at the same speed as they're launching services or to delay launch of services until their security capabilities. In that sense, I felt like I made a good argument in favor of CSP being at the center of your security strategy, even for multi-cloud.

I appreciate you yielding at least half a point on that argument. I have a few thoughts on your arguments, and I think they're all very interesting, and I agree with a lot of them, and I'll talk about where I agree and where I disagree. You talk about knowledge of a system and that being an advantage of the CSP. I will grant that things like VMTD or the embedded capabilities of ETD to call into, you know, Google background APIs Those are advantages, but I think they're niche advantages. And I think they're niche advantages for a niche part of the CNAPP problem space. And I think most of what needs to be done for cloud security outcomes is actually on the left-hand side where you do have a need for consistency more than a need for deep specialization. I would further say that the knowledge of a system might blind the defender to its weaknesses as they become accustomed to it and live in it every day. And so when you were talking about security being a function of the complexity of the intersections of your vendors and their systems, I think that's a very good argument. But I think there's a subtle counter to that, which is the CSPs, with the exception of AWS and with the exception of GCP somewhat, are not really users of their own clouds. And even when they are users of their own clouds, They're users in an internal sense. So when Seth is frustrated, he can just call me and complain. But if I'm a third party and truly experiencing it as a third party, I'm going to have an empathy and a perspective on the challenges that that CSP will never be able to internalize. And so I think the insider advantage or the, the CSP knows their platform best, they actually don't know it best. They know it from the inside, but they don't know what it's like from the outside.

Yeah.

On your bolt-on versus built-in argument, I have very little quarrel with that. I think that's a very good argument. I think it's good to have fewer seams to break. I think that argument has not carried as much as we might've expected in the endpoint space. We see a ton of endpoint vendors out there that are not named Microsoft. So it seems hard to believe that users actually prefer one over the other that strongly. And then I think that last part about the speed advantage, I think that's gonna cut both ways. And I don't know whether— We're going to be faster, they're going to be faster. But depending on whether you're a user that adopts things right away or whether you're a user that needs things to be consistent, I think that one is going to cut both ways. And so maybe we should wrap this up and talk about, between you and me, which users do we think are going to be more swayed by my arguments versus by your arguments? What do you think? Who are you giving the debate to?

Well, I guess you remind everybody every time that I'm a reformed analyst, but maybe I'm not reformed completely. So I would think that there would be some version of it depends. hands at the end. So it's not like people would expect us to say, yeah, this side won. But then again, let's briefly consider it. I think that there would be types of people, and I've met those online, and we can link to some of the arguments they make online, where the whole trust in the cat to guard the cream— it's a quote from a well-known LinkedIn thread about this very topic, and we'll link to that in the notes— where this trust argument basically just burns All other arguments. Like, basically they whip this up and please insert some kind of a D&D analogy of a +15 sword, and basically everybody else is just like done.

Exactly.

There's no point. Like, they say, sorry, we want— we would never trust the platform vendor of any platform to secure it. We're done, full stop.

It's what we would have called in my parliamentary debate days a tight case. At that point, if that's your concept, that's your concept. There's no arguing with that.

You can attack their sanity.

I think I wouldn't go that far. I think I would attack their threat modeling and whether they're right to put that much faith in the abilities of third party versus the cloud themselves. I think we've talked about users who want to guard their crypto keys under Swiss mountains before.

Yep.

At the end of the day, if a user wants that, they want that, and we have to meet them where they are by providing effective APIs and effective third-party integrations. And so, that's one kind of user that's going to go one way, but there are other users that are going to go the other way for your arguments. And I think those users are users that are more single ecosystem or who are more fully bought into the concept of Google as a security company. I think there are other really interesting cases where a user's super focused on the threat journey and wants to take advantage of the unique telemetry and visibility that a CSP is able to offer. Or maybe they're impressed with Google's threat intelligence story overall between Mandiant and VirusTotal and Safe Browsing and SecOps and everything we do, and they want to pivot towards that. So I do think there are users for both sides of this argument.

I think that the change, if we would have this debate in a year, we would have a much more robust example of a multi-cloud security platform built by CSP. That would be us, as a hint. So, I mean, without turning this into marketing copy, I can say that when I make this argument online in the same debate, people say, wait a second, how can we trust cloud provider X to secure a cloud provider Y environment. But the strongest reason that they cannot is that it hasn't happened yet.

Hmm.

But there's nothing in their position that it cannot happen. I think that if we built— when we built a CNAPP by Google that covers all 3 popular cloud environments, and people would see that this platform is actually quite effective, effective and cost-effective, the argument for the CSP side would become much stronger.

Yes.

Except to people who really would never trust the same party and who possibly don't run antivirus built by Microsoft today because they don't— they apply the same thinking to the OS. They say, nope, it's their OS. We're not buying security from them. We're buying it from somebody else by charter.

And I think those users will probably always exist. And so I think even in a world where the CSPs, Google, Microsoft, maybe if AWS decides to get in on this. I think those providers have a good shot at winning over people to their platforms, but I also think the market opportunity will still exist for third-party products. I'm curious to see personally, academic argument or not, how much opportunity remains for a price premium in some of this space, given the, you know, insistence on open-source standards for cloud security posture management. And all of that. I think it will be an interesting 5 years for anybody in this space. And listeners, I hope you are looking forward to the next 5 years of our podcast about this space, because I certainly am.

I think that it wouldn't get commoditized. I think that's to sort of like the risk of cloud security becoming boring and flat and everybody has the same functionality to me is really low. And the reason I say that is because actually no other security area in the last Half a century turned into this, right? We have even active competition in the frigging firewall market.

Which is surprising.

It's surprising.

It defies expectations.

Yes. And same with EDR. Somebody brought up an argument on social media that in the context of the CrowdStrike debacle, why would somebody buy not the best EDR? But the point is people do buy top 10 EDRs or top 7 EDRs. I lost track. But the point is that it's not everybody buys number one. And if everybody buys number one, then ecosystem risk is possibly higher.

Yes. The ecosystem risk argument is very interesting.

Because it's a monoculture, right? So it's like, yeah, it goes in circles pretty quickly. So what kind of advice we can give to our listeners' employers? Ultimately, we want to give some useful cloud security advice at the end.

Are you asking me for one tip to improve your thinking about this kind of trade-off?

I did not ask you about the reading list. So it's the one tip, one practical tip. And feel free to ask me about the same.

Yeah, gosh. I think, you know, listeners, if I were to try to condense this down to one practical tip, it would be to really think about what you need out of your tool and make a decision about where your team is at and where they're going to be at in terms of their capabilities to absorb the output of the tool that you select. And so you could look for a 28-page-long Gartner buying guide to CSPM and try to check as many boxes as you could. Or you could really think about prioritizing what you need out of the tool and select the tool that gives you those things and those things the best. That's my one practical tip.

Whether this tool is built by a CSP, a third party, a large company, a small company.

Exactly.

Or whether it's a startup or a 20-year-old.

Irrelevant as long as you think the company will be there for the lifetime of your contract.

Hmm.

What's your tip?

I would actually kind of cheat a little bit.

Oh, please.

And reuse a recommendation from a paper that somebody from my former team at Gartner has written. And the tip was that it also fits my classic 3 AM test, namely that if you have no other context, if you have no other awareness about the client realities and somebody says, Anton, should we do X or Y? I mean, for some questions, admittedly, there will be no answer. Like, it really is, it depends. For this question, I would say that my 3 AM answer and my advice from that paper was actually look first at what CSP offers.

Wow.

Because you would— and first doesn't mean always buy from CSP, forget what Tim said. The point is that it's the order recommendation. It's not the do X, not Y. It's do X first. I would say look at what CSP that you like offers. And if you have gaps, then buy tools to fill the gaps. But ultimately, you would be centered on the CSP. If you can, and then fill the gaps if you have gaps. If there are no gaps, that's great. So to me, it's the advice on order, not on doing one thing over another. And the order is CSP first.

I really like that answer. Listeners, I hope this episode has sparked debate in your own head or in your own team. If you think we got it right or got it wrong, or if you want to learn more about being a college debater, reach out to us on LinkedIn or on the community forums. We'd love to hear your thoughts on this. Anton, do you have recommended reading?

Okay. So, obviously, you can't prevent me from advising people to read my blog. But actually, in this case, I don't have a blog. I may write a blog based on this because I really love the debate. And I would also then cheat again and say that one point you made, which was very interesting about, do cloud providers really know their own cloud? Are they traditional cloud users?

Hmm.

I would actually send people down to episode 176. The Seth Vargo episode, which is the really deep, really fascinating study of Google as a GCP user. And it's technically not reading because it's a podcast. And I'm also being self-serving by recommending our own podcast, but it's a really good fit to that missing piece in the discussion. Like, wait a second, do cloud providers really know cloud?

I love that.

As customers.

I love that. Are you going to ask me for a book?

Oh, yes. Sorry, yes, that's right. Recommended reading, anything from poetry to Dune.

Yeah, I think I will go with closer to Dune, and I will recommend that everybody read Snow Crash because no book made me more interested in cyberspace than Snow Crash.

What? Everybody has read Snow Crash.

Not everybody's read Snow Crash.

You can't possibly be in freaking IT or security if you haven't read Snow Crash. What is it? You can't quote from here a protagonist and like, You argue why they didn't have wireless networking and whatnot. This is just such a classic that I would refuse to believe. I'd rather people not read Dune than Snow Crash. Snow Crash is it.

Well, listeners, if you haven't read Snow Crash after all that, you better get on it. With that, thank you for joining us for this episode of the Cloud Security Podcast by Google.

And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter @anton_chuvakin and @_timpeagle. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.