EP203 Cloud Shared Responsibility: Beyond the Blame Game with Rich Mogull

Secure running. Hi there.

Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy 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 the Cloud Security Podcast listeners on our Google Cloud Security Community page. Without any further ado, let's turn things over to today's guest.

Hello, and our esteemed guest today is Rich Mogold, SVP of Cloud Security at Firemon and CEO at Securosys. Welcome to the show.

Thanks for having me, Anton.

I would admit that I was quite triggered, but in a good way, with the recent blog that you wrote called Cloud Irresponsibilities Model. But I also want to use this as an opportunity to talk cloud security with you because you've been dealing with this stuff for, like, many years, 10 years, many decades, probably not many decades.

Yeah, I'm pushing 15 now. I think it's a solid 14 years.

Wow. So, this is 14 years of cloud, and probably you and me both see people who just met cloud for the first time, like, literally months, if not weeks ago.

I had a call like that a few days ago.

So, this is a little surreal, and I think I'm going very much off topic, but it's interesting how cloud transformation is something that's 10 years ago for you and for some of your other clients, but you also see people for whom it's now.

Yeah. If I think back to, like, when I bet on cloud early, so I got involved with the Cloud Security Alliance kind of right at the start and helped build their training program and everything. My prediction was that back then, we were at the start of a 20-year global data center transformation project. And I look at that timeline, I was wrong. It's not 20 years, it's probably 30 years if we look at the percentage of cloud workloads. that are actually in there. However, I think we fully hit the point where almost 90+% of organizations have something cloud, probably could be 99.87%. But for the people in those organizations, for many of them, it's new and they're just getting started. And it's only a small percentage has moved into cloud. So I, to me, it's like a really interesting dynamic.

Yes. And I think that I love the point about 20 years that became 30 years because Randomly speaking, on Twitter, you see people who assume that once you start, in 1 or 2 years, you're fully transformed. And that's quite insane. I mean, those people probably don't work for enterprises or don't work for large companies. Nothing happens in 1 to 2 years. Nothing. Freaking IAM configurations don't get changed sometimes.

And you don't need to move everything. Myself, like you, I'm a huge proponent of cloud. Better in almost every aspect than what you could do in a data center. I will personally, I will never build or work in another data center myself. Okay, I have a Synology in my closet here at home, but that's as close as I get. That said, if you have, you know, something that you've been building for decades and it works and it's in the data center and you're able to do what you need with it, you've got plenty of time to move that to cloud. You have to have a business driver to make that transition.

Yep.

And it isn't just, CIO read it in an airline magazine in 2014, and then in 2 years, you're all cloud. Like, I'm sure these cases happen to somebody, but not many of those stories are happy stories.

No, I mean, the ones I tend to see most are the— so I have, like, these cloud adoption patterns, and one of them is, you know, the data center migration, which is usually tied to when they're paying the invoice for their data center. So, contract expires, contract renewals in 2 years, we want to be out of the data center, we're going to move everything up. And you probably know this, that's when they go through these rehosting exercises, which are disastrous. They create incredible turmoil, they provide very few benefits, and also, like, very big differences between the cloud providers as well in terms of the philosophies that they have on those. And so, yeah, it can be a huge mess if you move the wrong But honestly, I see a lot of companies under pressure to do that now.

And I think that's a perfect opener to like the painful subject of the day. No, wait, painful subject number 1 of the day, which is of course shared responsibility. I mean, you see people who are kind of looking at these beautiful visuals, like we have, I think, blue and brown, and Amazon has like green and magenta that imply clearly that the provider does this, client does this, and they just map it to the domains. And you probably made those in 2012 or something for CSA. And they kind of like had an amazing staying power. People still post them. But when you look at the real world, it just isn't like this. And that's been lately frustrating me more and more and more. And I'm like, why are you showing me this blue and brown picture? If you use a SaaS provider who backends to IaaS, who is monitored by another provider, and it's run by a partner, and the code is written by another partner, it isn't 2 colors. It's kind of a mess. So, how do we explain all that? Yeah.

I mean, to me, the shared responsibilities model, I was super skeptical of it at first conceptually because I was thinking, like, oh, it's like PCI. It's where the card brands are forcing all their risk onto their customers and taking no responsibility. But then I realized, and this was early, it was only Amazon. I mean, Google, Microsoft were not offering really public cloud services yet. Yeah, I mean, Gmail and things like that, but, you know, no infrastructure service.

Okay.

And then I realized, well, it is important because it tells me what I refer to as the waterline. And above the waterline is where it's on my shoulders what I need to do, and below the waterline, the cloud provider has it.

Yeah.

And it turns out, particularly when you're new to cloud, you don't know, it really is not clear to a developer or to an admin. I've seen developers go, oh, no, it's secure and it's compliant because we run on Amazon, Microsoft, or Google. And it's like, no, because you have all these vulnerabilities in there that you're not patching. However, I think as we've gone, to go to your point, The complexity of it, trying to specify where all the checks and all the boxes go is not really possible. And it also doesn't fully represent the relationship. And auditors and regulators, they want this in a fine-grained level of this is exactly yours and this is exactly the provider's. That's not the reality at all. It just gives you a general sense, I think, how I describe it.

Or maybe a discussion starter even, because for me, the Snowflake debacle, which of course, You can't call Snowflake breach because Snowflake was never breached. Snowflake debacle was a really good example because I started looking at the press, at the media, and half of the people treat it as customers screwed up and the other half treat it as Snowflake screwed up.

Yep.

But the point is that in this case where I am a cloud provider, I build something, I add MFA, I give you the something, and I give you the way to enable MFA. You don't enable MFA. bad things happen to you, whose fault is it? Or it can be more nuanced. I enable MFA and tell you, hey, enable MFA, and then the same things happen. So it feels like there's a gradual scale at which point most people, like a jury of 12 reasonable people, flip to it's the vendor's fault versus it's the customer's fault. But I'm still getting a headache even from thinking about it. Like, this is the real world.

That's where that blog post came from. It was the Snowflake-inspired it. So for listeners, I call it the shared irresponsibilities model. And to me, it was an example of a— it's a way of describing a shared fate versus breaking out individual responsibilities. And I think we've seen examples time and time again of these situations. So, let me give you a real specific one. The Capital One breach, Amazon is testifying to regulators and to politicians.

Mm-hmm.

Even though Capital One was the one that made a mistake, and then Amazon Was blaming Cap One, and Cap One is blaming Amazon. The reality of these situations are, is that— and there's a lot of nuances to this that I haven't fully worked out yet. I mean, it's just like, you know, because you were an analyst and I was an analyst, we come up with these crazy ideas, and then we have to actually backfill the facts and make them up to meet our objectives.

That's a little too cynical, but largely not incorrect.

So the idea with shared responsibilities is, for the cloud providers, no matter what you do, if your customers are making mistakes, you're going to bear some of the blame for that. And Snowflake's a perfect example because everybody calls it the Snowflake breach and Snowflake was not breached.

Yes.

It was that Snowflake didn't provide defaults that pushed customers to a security option that would've prevented it. And in this case, they had what could have prevented it. It's not like with the CapOne breach where they didn't have the Metadata Service version 2 available yet.

Yep. Yep.

So they had it. They just— it wasn't a secure default. And a lot of this goes back to me to the original Trustworthy Computing Initiative memo from Bill Gates. And I hate to say that, especially because Microsoft's a freaking dumpster fire right now and they're in emergency recovery mode coming out of that. But in there, it was secure defaults, was one of the key principles, secure by design, secure by default, and then mind blanking on the other part. And now, it's hard because there are things that customers need that cost providers money to provide.

Mm-hmm.

And so, there's a tension in there. So, my objective with coming up with that model is, let's have this shared fate discussion because that's what we're talking about. And no matter what a cloud provider wants to say, if the customer makes the mistake at times— let me take a step back. Every single mobile phone vulnerability that has come out in the last 20 years is an iPhone vulnerability if you read the headlines, if it in any way, shape, or form affects an iPhone.

But then press or public opinion is just wrong. Yes, that's insane.

Because the reporters always say, so it could be a problem with SIM swapping. iPhone's vulnerable to SIM swapping. That's not an iPhone.

But a phone, mobile phone is vulnerable to SIM swapping, even if it had the Windows Mobile circa 2007 or something.

That's always going to be the top line in the headlines. And in these situations with the major hyperscale cloud providers like your employer, you guys will always get the blame if there's something occurs on your platform. And the customers, they have 2 ways to try and get out of their breaches in terms of liability. One is they're going to blame an advanced persistent threat.

Right, of course.

The other is they're going to blame their cloud provider, and then they're going to try to wash their hands of it and have the insurance company pay for it. And that's shared irresponsibilities.

I think that's an appropriate setup for how things are. And I think that you can still try to tweak the knob and say, okay, I'm a cloud provider, I do enable MFA by default, and I provide a very easy one-page guide how to turn it off. Can this Snowflake debacle happen under those circumstances? Maybe the answer is still the same. Maybe I did give you a default MFA, but because you asked, I gave you an easy way to unset it, and you unset it. Same things happen. I fear that the outcome would be the same.

Yeah, it may be, although there's— I mean, for example, so progress. Microsoft is moving to where you can't establish— you have to have MFA on global admins. you have to have MFA on subscription owners. Amazon is moving to MFA required on root accounts this year.

Yep.

Now, I apologize, as much as I'm a cloud security expert, I don't know every platform as well as I'd love to. I don't know the current status on the Google side, but I assume it's in the same general vicinity in terms of requirements. And that's just MFA. Another example. So it's really hard to get rid of static credentials for machine identities.

Yeah, perfect. That's another one, classic. Yes.

All of the cloud providers support mechanisms to avoid the use of the static credentials. All of you are extending into the enterprise, so you cannot have static credentials. You can still have a server in a data center, talk to the cloud provider. I just did a lab for stuff we'll talk about later, and in that lab, it was on AWS. Part of it is I have to get a static credential, and I do it as a demonstration of what not to do in a very clear way. And when you go to request it, Amazon goes, great, what's the use case in the user interface?

And it'll give you 8 use cases. So, they make— they add perfectly good friction, friction, but for good, in this place.

And if you click on the, I wanna use this for this, for the command line tool, it will redirect you to doing it in a different and better way. Now, all that said—

That's actually smart.

It is. It really is. That said, if I put in a CloudFormation template or I do it on the command via command line or an API call, there's no warning.

Yeah. Okay. Which is reasonable too. It's a channel that's hard to introduce warning friction to without breaking a lot of other things.

Exactly.

Okay. So, one thing that came up to me when we were talking about it is that a broader theme above that type of shared responsibility, irresponsibility, is the line from another former colleague we had, Jay Heiser, who coined the classic about 99% of cloud breaches are customer fault or whatever it was. And I've checked with him. He coined this in 2015. So, that line is 9 years old at this point. So, in many cases, we say, hey, cloud is secure, but you're not using it securely. The problem is we're kind of short on advice what it means. So, if somebody wakes you up at 3:00 AM and says, hey, I want to use cloud security, what do I do? Like, what would you answer in a kind of like a crisp, pithy, 3 AM cloudy brain when you need to answer quickly?

Find a subject matter expert for every cloud platform you're using. That's the way—

That's cheating though, because you're saying to answer, you need to find somebody who knows how to answer. Well, a little bit.

It is, but it isn't. So the reality is there is no easy— so let's break this apart. Software as a service, different. Platform and infrastructure I lump together. You know this as well as I do, the complexity today. I mean, I got to learn cloud in the Commodore 64 days, and people jumping in now are jumping into the AI supercomputer days of cloud. Like, there were 7 services when I started on AWS, and Azure and Google weren't public services yet. Now there are hundreds from every cloud provider. Nobody knows all of it. The reality is, Start, if you have to do it immediately, if you immediately need to do something, you get a subject matter expert, you're not gonna be able to teach yourself. Then you have to start building up your knowledge and experience. There's no tool on the face of the planet, there's no consulting company that's gonna solve all your problems.

Yep.

You know, nothing. You yourself, your organization needs to kind of learn. And then also just like the best thing you can do is be smart about what you're moving to cloud. Don't throw everything in there. Don't not have any of the guardrails. Don't, you know, yeah, own your fate. It may be a shared fate with you and your cloud provider. They're gonna want you to do things a certain way, in particular, because their salespeople are gonna be salespeople. I don't blame them for that. You have to own that part of your destiny.

So, in essence, your answer wouldn't be like, Oh, you should do this IAM tweak, or here's how you do monitoring in the cloud, or here's how you reduce the chance of configuration mistakes. You sort of go and say, hey, you need to know cloud because unless you know cloud, you can't really use cloud security because you don't know it. Like, it's that type of line of thinking.

I describe cloud as alien technology, but it looks like what you're familiar with. So, the example I like to give is you go to another planet, we're carbon-based life forms, and you land and it's— the entire planet is based on silicon-based life forms, and a dog walks up and it looks like a dog and it barks like a dog, but if you cut it open, it's not gonna look like a dog. Also, don't do that because it's a horrific way to have first contact with an alien species.

Oh yeah, I see.

Like that. And dogs are cute. But really, that's what cloud is. Like, you slice open the layer. So cloud networking, your model, And Google's model and Amazon's model and Microsoft's models are completely different. But if I go to set up a network in all three, it'll kind of look like a data center. Like it's the same.

Yeah.

Get a Class B and I've got route tables and I have something called security groups that might work kind of like, but none of them work the same. Yeah. And the details matter for security. So yeah, there's no easy button on it and. The closest easy button is get someone who knows what they're doing and then get your people trained up so they can take over.

I think there's one line that over the history of our podcast has been kind of a major enraging line for both of us co-hosts is cloud is just somebody else's computer. Because we go pretty medieval on guests who say that because it's like the absolute opposite is true. And I think the word just makes it extra offensive. Cloud is absolutely not just somebody else's computer. And it involves computers owned by other parties, but most of the stuff just points in the opposite direction. And people who are guided by just somebody else's computer probably are responsible for the majority of mistakes and breaches of their own environments, fortunately.

You know, and it is hard. I mean, we don't have enough people, and nobody wants to pay what you probably need to pay, and companies want to move to cloud without Like, there's a lot of economic and political and governance dynamics in place. And I hate to say that because I'm a nerdy technical guy. Like, all I want to do is play with the APIs and build things, but that's not where I'm going to be most impactful. And, or that's not where the biggest impact is going to come from. You need people that know that stuff, obviously, but for your organization to move in the cloud in a secure and economic and resilient and agile manner, you know, those are the 4 main benefits of cloud. And to get those benefits, yeah, you really, you can't be thinking of it as just somebody else's computer and you just throw a bunch of stuff up there and problems go away. And you're not gonna fix this, by the way, with containers.

Yes, I think there is, yeah, containers open another beautiful, beautiful rat hole that I would gather enough force of will to not pursue. But you also had a— you're developing a particularly new and interesting way to learn cloud, right? You mentioned it when we were talking about it. So, what is this, like, apart from reading the manual, what is the way to learn cloud by doing cloud?

Yeah. So, I started a thing, it's called Cloud Security Lab a Week, or CloudSLAW. And this is a weekly newsletter. So, when you sign up, you get lesson number 1 through I posted Lab 38, which means I probably have about 43 actual weekly episodes, and each one is for 15 to 30 minutes long. And I came up with this— I was trying to come up with an idea for something more interesting. I mean, my background's kurosis, is, you know, research and analysts and blogging and publishing. And I didn't just want to do a newsletter of like a news wrap-up. There's great ones out there. I mean, Matt Johansen and Dibbler and Daniel Miesler and Mike Privett, like all these wonderful, amazing people doing these things already. I'm like, well, what could I do that's different? And it was to bring the training in. So every week it's a 15 to 30 minute lab. It's in your inbox. It is just AWS today. I do have plans to expand that eventually once I can get like friends who can help me out with some of that stuff.

Mm-hmm.

Yeah.

It's all free. So I, I've only had like one sponsor ever. I'm not really making any money off of this. I'm losing a lot of time and money. But that's the idea, is that it's a zero to hero. So when you start, you do not need to know security. You don't have to have a security background. You do not need to have a cloud background at all.

Oh, wow. That's super impressive. And it's also really hard.

Yeah. You need to know the difference between an IPA and an API. But like, that's my goal, at least, is if you have any level of technical knowledge. So like all the lessons, I'm trying to teach security principles. And then with the cloud-specific details of how you do those. So, like, with IAM, we actually start by talking about what is an entity, what is an identity, and what is an identifier. And then we expand that into personas, we expand that into attributes. And, like—

The person trained on security of IDS and firewalls in the '90s would not know this. And so, that's absolutely useful to know. Yeah. That's actually a perfect example.

We're in network and workload stuff right now, and, like, covering fundamentals of for the networking, like, how does a security group work? And how do you— how does a route table work? And, like, how do those work together? And doing it all by building things in cloud to do all of that. And then teaching good habits. I don't teach SSH at all. We will never log into an instance.

Right, because you don't want— yes, that's actually an excellent example that if you SSH into cloud instances or containers, you're doing cloud the data center way, and then you're gonna go off the rails at some point.

You still can connect. We use Session Manager for, you know, just-in-time access, and then later we'll get into immutable and all of those things. So I look at this as a— I have an infinite canvas for as long as I want to do this. I will admit, after year 1 is done, I will probably go to every other week because it takes me 4 to 8 hours to build a 15 to 30-minute lab. So it's like a lot of commitment on top of work.

Yes, and it sounds like something that ideally somebody would do full-time because it is like, it's one thing to handwave and say, learn cloud by doing, but it's another thing to actually provide that type of venue where you can learn cloud by doing, cloud security in this case.

Yep.

So, I also have the painful question number 2 prepared. It's also inspired by your blog, and it's the money question. Because sometimes when the shared responsibility discussion comes up, there is a question of, I can build cloud, I can give you an easy-to-use tool to secure something, but give me more money. And some people say, no, you can't do that. And other people say, well, the tool costs money, so probably you can do that. So, do you have to put your kind of ex-analyst hat on and think, is there any framework for deciding this? Because, for example, intuitively, again, my 3 AM answer is charging for logging is evil. If I say, to enable logs, give us money, I'd be like, that's evil. But if you say, I'm going to retain your logs for 90 days, Give me money. Well, that's reasonable because storing logs for 90 days from whatever environment may be a lot of money. And, like, you can have some other number, 30 days, 7 days, 300 days. So, it's variable. It feels like this is not able to charge for it. But there are other examples, but I don't have a conceptual model in my head for this. I tried to make one, by the way, but it didn't quite succeed. So, any help? Yeah.

This is an area, and I think I may be doing a talk at— I'm going to submit for a conference on this one, on this whole concept, because people have asked me like, what should the providers give for free versus not? So if I take a step back, and to me it's this shared fate, shared responsibilities, it's okay, what's going to be beneficial to both the customers and the providers? What's going to be the greatest benefit? I always tend to prefer, and even though I have a role at a vendor, I'm still my— I'm always trying to take what's best for the user, the customer of the cloud platform. So a couple of— I think to me the line is going to be a few things. One is there's the things that we know don't really cost anything other than friction.

Yeah.

And so cloud providers have erred on the side of reducing friction. I have a very specific example I'm going to give around that. And I think that those are where we need to move back to The more secure defaults. The example is, is when I first started using AWS in the earliest days, when you created an instance, if it didn't have a security group, they would create a security group for it. A launch wizard is the term in the AWS console for the security group, and that would have no access.

No access. So, it would be blocked from the public, blocked from the internet.

Amazon eventually changed to open 22 or 3389 by default.

Oh.

Because—

Did they change back? I didn't really check this. I would assume they changed back later, right?

No, it's still the default.

No?

And the reason, my assumption of the reasoning is, is that the support request, it was a level of friction to launch an instance and connect to it, even with all the instructions and everything else, and everything in the console was too high for too large a percentage of AWS customers that they had to take that off because people were like, well, I can't make it work and I can't connect. And I see Reddit posts to this day with people making those mistakes. That's a place where I think they should drop back to. Yes.

I would assume that by 2024, people would figure out that, you know, stuff in the cloud can be public. Your freaking SSH may be from 2014, and then people may, you know, own you in moments. And this actually happens to people. So, okay. So, this is an interesting example where friction just won and kept winning. Reducing friction kept winning.

It doesn't always win. It wins—

No, no, for sure.

Sometimes. So like friction being moved back in, like, okay, like Azure on the networking side is default open everything. And Microsoft is slowly in the portal then adding things to really push to using a network security group, where when I started with Azure, the recommendation was if you use a network security group, only do it at a subnet level. which is a thing that Azure supports that's different than Google or Amazon, and not at the individual resource level because they didn't want the friction.

Yes.

Now they have changed, but the API or the command line or, God forbid, PowerShell will still default to not requiring a network security group. Now, this said, I think that there is a financial cost to adding friction, but I think These providers have enough money to hire the best UX people on the face of the planet. You wouldn't know it, by the way, because I don't like any of the web—

I see those examples here as well, for sure. No, no debate about it. Yeah.

But the best way to align it, which will go to something I think you'll love because of the work that you do, is threat modeling. Providers know the most common ways their customers are compromised. And focusing efforts on reducing that. Now, then there's the other pieces. So, logging. I think every provider gives you 90 days of management plane logs for free. It's in API, it's not in a file you can download. You can make API calls and extract it. You only pay money if you wanna actually save it someplace, but you get rolling 90 days.

Yeah.

And again, that's my weakness on the Google side, but I'm pretty sure it's there. And I know both Amazon and Microsoft support 90 days, always there, always on, always accessible via API. It's just not saved into a file.

But you wouldn't— you can't shame a provider into not providing free 1 year of logs, for example, because that's where you probably don't have a case. But I can see us shaming a provider who says, to enable logging, give us money. Like, to me, this is a simple case. But for more nuanced things, like a feature in IAM that suggests something for you, should it be Free or not free? Like, all this stuff is very nuanced and unclear how to decide on that.

Yeah. I think the ones where I'm mentally working on it is around the threat management services. So, GuardDuty, CSPM, Security Command Center kinds of areas, like, which aspects of those should be free?

Yes.

And I think more of that should be free from every single provider. And I think those are the areas where— and not all of it. So if I look at, you know, Command Center, Defender— well, Defender is like, I don't know, 87 different products, but Defender for Cloud, the CSPM part, or Security Hub, we know that the vast majority of cloud breaches are due to like 2 or 3 things.

Yeah. Configured identity.

credentials, and it's public stuff.

Yes.

I think we're going to get movement towards those, but then they also need to be enterprise manageable. That's the other problem with those.

Correct. But if you make it excessively hard to use but free, and then provide enterprise-managed beautiful version for money, then you're also in— to me, is in the doghouse.

Yeah.

Like, that's cheating on a different level. Like, you sort of say, Here's free blah, but to use this blah, you have to like suffer and bleed. But if you want an easy-to-do way to do this, give us $100 grand. Like, to me, that's probably not great, even though my PM colleagues probably would disagree with me quite hard.

Well, I mean, look, every major enterprise has CSPM and they're paying for it today.

Yes.

So like, then why should the cloud provider? Like, well, there's enough ways to slip through the cracks because we see that. We just acquired this thing over here and it's not in our main CSPM. Yeah, I get it. Or we did this thing over here, or this developer did this and it wasn't installed properly. Like, and there's just so many smaller organizations that aren't going to be able to. So do I need the latest, greatest, best CSPM and the cloud provider should give that for free? No. But I think anything that exposing anything that's public, static credentials, then I do think that the, you know, the GuardDuty equivalents, the threat monitoring, services that, you know, there's aspects of that, maybe not all of the, like, the nuanced, you know, really in-depth, like, you've got, like, live Kubernetes monitoring stuff. You've got—

Yeah. Some of the stuff is very elaborate, and I can see why it shouldn't be, like, part of the free baseline. That's very clear.

But credential abuse.

Yeah. Or even the basic config checks.

And crypto mining ransomware signs, like, all of those.

Yeah.

And It's a moving target because the threats change over time. But I think that if I was in charge of the cloud provider and in my role as a customer advocate for security, which is different, that I'm—

Yes. No, no, that's very precise and very perfect for many reasons that I— yes.

Then I would— how are our customers being breached? And then if I can knock out 90% of that, By making half a dozen changes that aren't going to— I mean, it's gonna cost me something, but I think it's gonna cost me less than the impact of people like rehoming because—

Or people thinking they would move to another cloud, erroneously assuming it's better there, but they would still leave you. I mean, that to me is a good argument.

Well, we don't see security being a market influence in terms of which cloud provider.

Yes.

Realistic.

That's been true since we were at Gartner, by the way, which annoys a lot of people, but it's the truth. You know it's the truth. I know it's the truth. It's not the—

Yeah. Not all providers are created equal, particularly on security, and maybe it's getting better. One in particular, I mean, let's call it out. I'm not saying this just because you and Amazon haven't had issues. Microsoft's really screwed a lot of things up. And yet that's the biggest area of growth.

The cross-tenant stuff is annoying. Yeah. Yeah. Cross-tenant vulnerabilities that they had is kind of like, no, don't do that.

Yes. Really, including their own stuff. And there's even more that's not even necessarily public. So if I look there, but yet most of the work in terms of like people asking me questions and everything coming in these days is about Azure. It's not about Google. It's not about AWS. Even though I'm more in AWS.

Wait, really? Is it because there are more problems or is it because more people use it? I'm honestly asking.

More large enterprises appear to be moving to Azure right now.

So wait a second. So it's 2 trends. It's inferior security and it's increasing popularity. Well, I'm laughing and rolling under my desk here.

I mean, Microsoft knows how to sell to enterprises in a way that Google and Amazon don't as well.

Yeah.

But the other part of it is, is there's particular industries like healthcare and retail where Amazon competes. So, there are companies in healthcare and retail that don't want to be putting their stuff up on Amazon. And then Microsoft is deeply wedded in the financial services industry. I'm not saying all of them, but I'm saying I am getting a lot more requests around that, even though I have specialized in, you know, focusing more on a different platform.

That makes sense. And thank you for this. And I think that went into a very fun corner of the cloud security world. I really appreciate, you know, you taking us there. One final question, and this is the one that I kind of thought long and hard. So, I just want your kind of best advice after all your experience, all your years, and also not just years, but experiences in cloud stack. Like, if somebody asks you, what's your number one lesson so far on making either making the cloud more secure or using the cloud securely, kind of your call, like, what would you say? Like, what's number one lesson others can use?

So the number one thing, like, you want me to just say the biggest thing I've learned over the years?

For example, yes.

The rate of evolving of cloud is not going to slow down. Constantly new services. And to me, like, I sit here at this point, I'm in my, you know, 50s, and I've been in this industry for 25 years. You think I could relax now, and I can't. I have to be learning, every single day and keeping up to what the providers are doing and the latest research. And it is difficult. Also fun because it's not boring, but there's no jobs in cloud that you can learn and it's— you're gonna be doing the same thing in 2 to 3 years.

Yes, that's fair. Or if you are somehow doing this, then you're probably causing big problems to you and your career and your business. Yes.

Like, so give you an example, the platform we built, The first version of it was all like instance VM-based.

Mm-hmm.

Then like, oh, containers, then serverless, then the next version of serverless. We have re-architected that platform 5 times because as the providers evolve, every time we're like, we can do this and we can do that and we can do that and it makes it better and we're delivering more customer value. Like, we're not static. And we're constantly evolving that along. And maybe not perfectly, but that's how you get the benefits for cloud. And if you lock in on something and you— and some things don't need to change as much as that has.

For sure. There's always examples when things are mostly static, but these are islands of static. There's no cloud of static. Yeah.

I mean, even just IAM and training materials and things that I've built, like, I have to redo it every few years. For sure. It's just you got to keep up to date and embrace it. Don't get upset about it.

Perfect. Thank you very much for this. And I think that— thank you very much for this advice specifically. And of course, for being on the show. Really appreciate it.

Thanks for having me. It was awesome to see you face to face again.

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, 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 at Anton_Chuvaikin and TimPico. 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. Secure ready.

Secure ready.