EP148 Decoding SaaS Security: Demystifying Breaches, Vulnerabilities, and Vendor Responsibilities

Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at Google Cloud, 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 LinkedIn page. Today is a special episode because it was originally livestreamed. If you'd like to follow our livestreams in the future, do follow the page. You can get the video content on our YouTube channel as well. Anton, we are talking about—

CASB?

In 2023? No, we are really not.

No, we're not.

We're not. What are we talking about?

We are not. We are talking about securing SaaS.

That sounds like CASB.

And I was deluded by claiming that securing SaaS is really just CASB. And suddenly I think you are trying to troll me a little bit and flip the positions and pretend that you believe that securing SaaS is all about CASB. You would never do that, would you?

Me?

Troll you?

Never. I would never do that.

No, no, no. Okay.

No, no, no.

But it is a securing SaaS episode.

And it is.

And I think that there's a whole universe of things And the strange part, there would be, like, one particular surreal bit today. Most people who use software as a service assume that securing SaaS is about configuring security.

Yes.

And at the same time, most people correctly point out that the chance of a SaaS vendor being breached in some particularly nasty manner is really not high for the top-tier vendors, and that it can be handled through paper security, contracts, questionnaires, right? And is that the truth?

Is this not a year where we've seen counterexamples of that, though?

I think that's the year where we've seen counterexamples, to put it mildly. Yes. Yes.

Yes.

Okay.

Well, maybe with that teaser, listeners, let's turn things over to today's guest. All right, listeners, welcome to another livestream of the Cloud Security Podcast by Google. Thank you for joining us today. Our guest today, Adrian Sanabria, Director of Valence Threat Labs. Adrian, thank you so much for joining us today. Delighted to have you here. You are, of course, somebody who has also cool Legos in their background. So already you're doing great on the show.

Yeah.

I want to start us off by centering us on SaaS. Spent a lot of time on the Cloud Security Podcast talking about cloud security for Azure and AWS and some other smaller cloud. I think that's called GCP. But there's this whole other world of cloud services that is SaaS and where users access an app like Salesforce or Workspace or O365, depending on what kind of credential they've stolen that day. So how do we think about securing SaaS as opposed to securing, say, the 3 infrastructure clouds?

Well, it's a blurry line, right? Like, how do you access those infrastructure clouds? That's also SaaS.

It is. Yeah.

If you're using console.aws.com or whatever the GCP equivalent is or Azure equivalent. So yeah, it's really interesting because it is kind of a blurry line and we do find ourselves somewhat overlapping with infrastructure protection and stuff like that. Okta was a big supported platform. Also the SaaS interfaces of security tools like CrowdStrike. We support SentinelOne and CrowdStrike as SaaS consoles that we secure because that's how everything works today is through a web browser, through an interface in a web browser, through some kind of SaaS interface.

But wasn't it not like that in the past? Because you're a former analyst as well, right? And I do recall my former analyst years when there was this whole Secure SaaS, you know, buy CASB, do the classic SaaS stuff. And there were, on the left, people who lifted and shifted VMs and treated IaaS as kind of a caller, sadly. You know, we may rant about it, but it happened. But it sounds like the 2 worlds were further apart in the past. Am I hallucinating it? Or is there something to that?

No. And I think where it changed is behind the scenes. Quite a bit. A lot of it's we went from these monolithic web apps to API-first dumb interfaces, which maybe have a little bit of JavaScript now, but there's a lot less heavy lifting by the JavaScript and a lot more done behind the scenes through the API. It used to be you'd run a search somewhere and it would pull the entire dataset, like it would pull the entire table and then use JavaScript to do the actual query in your browser tab. And just use a ton of memory to do that. Now that, that happens behind the scenes so that it's a much lighter lift, much quicker on the front end. Also, all these applications integrate now. Like before the pandemic, Zoom was just a dumb meetings app. Now it's this whole platform. Overnight, almost, it seemed it had hundreds and hundreds of integrations. And a lot of these integrations work like if you had some kind of an inline tool, like a SASE or a CASB or something like that, that's depending on looking at inline traffic, you're not going to see this because it's SASE vendor-to-SaaS vendor where these actions are taking place, whether they be scheduled—

Wait, wait, but is it a customer problem? If it's a SaaS vendor-to-SaaS vendor, sometimes customers don't even see that stuff going on. So, that sounds tricky.

It is.

I mean, shared responsibility, just like the public clouds, right? And sometimes it's not clear where that line is, where that shared responsibility begins and ends. You know, like, for example, turning on logs. Like, I remember running an investigation years and years ago. They were using Office 365, and it was a BEC case where somebody had gotten access to their email. And we got in, we started investigating, and it was clear they were on the inside because they were able to send convincing-looking emails as other employees trying to change the bank accounts for large 7-digit commercial real estate payments.

Oh.

And none of the logs were on by default. Like, we had no way of knowing when they got into the system, how long they had been in there. the extent of what they had access to. So during the investigation, we were the first one to turn on email logging.

But that's sort of like so— okay, should I say so '90s? Well, none of this stuff existed in the '90s, so it's almost like—

It's just so sad.

The '90s mistakes.

Our job is just Groundhog Day, Anton. It's just Groundhog Day every day.

But it's a groundhog as a service.

Yeah.

Okay, fine. It's just supposed to be more funny than it helps.

Yeah, the groundhog has moved. We still see '90s problems so often. Like, how often do we see some new fancy DevSecOps tool where there's a port exposed or default credentials or something like that. Like, we see these same issues popping up again and again because a lot of the people engineering this stuff are a new generation that didn't live through those times. And maybe we elder security folk didn't do a good job of passing down our lessons learned.

Oh, that's for sure we didn't.

I think we were supposed to invite Adrian because he's such a positive person and he would like shine the beautiful blue light. And now I'm more depressed than normal. So probably we should switch topics. How about incidents in the cloud? Oh, wait.

Yeah, that's different too.

So, what do we know from the actual breakage?

I saw somebody post on LinkedIn the other day, do we need CVEs for like cloud and SaaS? And it didn't make a whole lot of sense to me because to me, a CVE is something you have to fix in your environment. Like it's fix once by the vendor, fix many by the customer. Whereas SaaS and cloud infrastructure is the opposite. The stuff we constantly see Like now it's these research teams working for vendors, for CSPM, SSPM vendors. They're out trying to find vulnerabilities and issues in these services. But once the vendor fixes it, it's fixed for all customers all at once, right? So it doesn't make sense to assign that a CVE, right?

I think that might be a limited view on what a CVE is for.

No, no, I'm with Adrian.

No, no, no. Hear me out. Hear me out. Hear me out.

Wait. Okay, go.

Okay. So sure. A CVE is definitely a statement that, hey, I have to go install some patches. But it's also a signal that something was vulnerable and I was at risk for a period of time from disclosure to patch. A CVE in the cloud or CVE in a SaaS could reasonably serve the purpose of, I need to investigate whether that was used against me while it was vulnerable and unpatched. And without a mechanism like CVE, how do I as a user know—

Yeah.

That my cloud provider or my SaaS provider I'm not arguing there shouldn't be a mechanism.

There does need to be a mechanism, but I think it's confusing to lump it in with CVEs. I think it needs to be a separate database, a separate acronym.

Yeah. And most everything client-facing, the client-facing side is probably a misconfiguration. So it also wanted the CVE type. It is the defunct CCE or whatever they tried back in the day. In theory, should have helped, but ultimately misconfigured SaaS would get you. And that's something you need to fix.

Yeah. And just like with traditional vulnerabilities, we do need to understand the type. Like a lot of these issues we see in the cloud, you know, it's unclear if the researchers were the first ones to find it. And some of them are cross-tenant vulnerabilities. Like I remember one where if you knew the disk ID of a disk image in Microsoft, in Azure, you could mount it. There were no access controls.

But that's the early days. That's very early days. That's like 2013, maybe '14, right?

No, it was like 2 years ago.

2 years ago?

Yeah.

What year is this?

It's 2023, last time I checked.

Thank you.

Holy cow. We talked about it on Enterprise Security Weekly, and I've only been running that podcast for 2 years, so it was in the last 2 years.

That's wild.

Wild.

Yeah. It was wild. Wow.

Yeah.

And you could imagine people taking screenshots that would show that ID. Or uploading things to GitHub where they would still have the— like, I wouldn't think to treat that image ID as a secret, right?

Of course not. Why would you? You would think that there's access control on it. Yeah.

So again, shared responsibility, a very blurry line here with SaaS and cloud. And so we rely on a lot of researchers to say, hey, did they build it? Like, surely not, you know, but you got to go and test it.

This is why I think CVEs in cloud are important. How else would you as a— and again, it could be some other mechanism, sure.

Right.

But I think structured vulnerability disclosure is important because if I'm a buyer and I want to decide, oh man, is that system trustworthy? Does that system have these kinds of things? How else am I going to figure that out other than a database of the history of stuff we've discovered about it? Maybe listening to podcasts. Yeah.

And there are some now. There is a cloud vulnerability database. I forget what it's called. Yeah.

It's launched by one of the cloud security, what we call a third-party vendor, I think. Yes. There are actually 2 or 3 attempts at the cloud vulnerability databases. We'll add them to resources.

Yeah.

That's great. Okay, so I wanna shift gears a little bit away from the— again, we got back to Azure for a little bit. Tell me about the recent O365 SaaS breach. What's that? Is that a breach? Is that a cloud breach? Is that something else? Where does that land?

Well, first of all, they rebranded. You gotta keep up with the rebrandings.

If I try to keep up with Microsoft rebranding, I will—

There's no more Office.

What is it?

Microsoft 365. M365, yeah.

M365?

And everything's Defender except for the things that are not Defender.

Okay, fine, whatever. The email service in the cloud that's not Workspace, that got breached. Was that a cloud breach?

So there were several in the last couple of months. Oh, are we talking about the AI data leak one, or are we talking about the one where a bunch of government agencies broke into their emails?

That one.

Yeah, the storm.

The 26 agencies that got popped because of bad token health and bad access key signing security.

Yeah, so that was an interesting one because We don't know how it happened. We know that a Microsoft engineer lost access to this key at some point, but they're either not sure or they're not telling how that engineer got compromised. And if you look at the wording, they don't even necessarily connect the engineer getting compromised to the rest of the attack. So it could be a red herring. I'm not sure. Maybe I'm reading into it too much, but there's going to be a government investigation into that. So there's a subsidiary of CISA that just does these investigations. And I predict in about 12 months, we'll have a much more detailed report telling us what happened there, but certainly access tokens played a role.

Wait, is this one of the first real big NTSB cyber investigations we're going to see?

No, I think the first one— what was the first one?

Log4j.

Yeah, Log4j was the first one.

Yeah, yeah, yeah.

So, but wait a second, I'm getting a surreal vibe from all of that. So back when I was an analyst— I'm not gonna joke about back when I was younger because it wasn't that far into the past, but—

When dinosaurs roamed the earth and Anton was an analyst.

Yeah, when the gas cloud— I kind of think gas cloud first, not before dinosaurs. Many people sort of assume that the infrastructure and a bunch of other stuff is taken care of by a SaaS security vendor. And then the other Gartner wisdom about 99% of cloud breaches being customer fault applies. So, it's almost like my mind wants to naturally go back to the world where SaaS providers, at least the top-tier ones, are pretty secure, pretty well done. But customers kind of screw up configurations, and then they cause issues. But we are seemingly in the world where SaaS providers screw up and not the client. So bring me back to the familiar, because now I'm getting even more nervous, and I want to unplug my computer from the internet or something.

The SaaS vendors, it doesn't grow your SaaS revenue to build in the most security or more security than your competitor. You want to reduce friction. You want to increase adoption. You want to increase spend. And none of that is done by making people jump through extra hoops when they authenticate, making them do step-up authentication, making them spend a bunch of time checking their configuration, making sure the configuration is correct. So yeah, there is some pressure for the SaaS vendor to pick a configuration, get it right, and typically they don't. That's not the top priority. So the customer bears the brunt of that. So a great example of that is how we handle external data sharing today. So by default, overwhelmingly, at least from my research, the number one use case for data sharing is I'm about to jump into a meeting. I've got a file I need to share with somebody. We're going to discuss this file during the meeting. We shared a file to prep for this podcast, right? Like the very common use case. But what's the expiration on that? Why isn't there an expiration on that data sharing? In many cases, that data share no longer needs to exist the moment that meeting ends, right? Sometimes it's a little bit longer. Maybe you're working with a contractor. Maybe it's 3 months out. But there's no lifecycle, there's no full governance on that data share. And the same thing with integrations, the same thing with a lot of identities in SaaS. Very optimized for getting you in the application, creating the integration, creating the data share, but little to no focus on cleaning it up afterwards. So you end up with this big mess and we find on average, here's a stat we got from our customers, 91% of data shares have not been touched in 90 days and can just be closed.

I mean, this certainly rhymes with kind of the material security thesis of let's lock down all your old email and make you put in a different password to get access to it. So I totally buy that this is how information works in enterprises.

But what we're finding is like CISOs will say, well, nobody's touched it in 90 days. What's the worst case? They have to reshare a file? Like, just remove all that. Just clean it all up. Just sweep it all away. Attack surface gone.

Well, I think Googlers who are coping with our changes in access control might take issue with what's the worst that happens, they have to wait for a reshare. But I can see how a lot of reasonable people would come to that conclusion.

Yes. And it also sort of reminds us, by the way, it also— this whole ghost of IAM barges into our conversation and roars. Sorry, I'm mixing ghosts and dinosaurs. But the point is that ultimately these are permission problems I'd watch that movie. Yeah. It's not about bad SaaS vendor or bad customer. It's about over-permissioning and not having the right IAM culture or access management culture or whatnot. So, it's back to almost every cloud problem has an IAM problem behind it somewhere, right?

And a lot of it is just simply UX.

UX?

Yeah.

Huh.

When I go to share a file, where's the option to share it for a day? Why isn't share it for 24 hours the default option? Why don't I have an option to share it for 7 days, share it for a month?

That's a profound thought.

Expire after my calendar with this share. Tie this share to a calendar event and expire an hour after.

So did we just give somebody a cool startup idea to like build that and like get rich? And we're like, when it pops up—

That's a feature, not a company, right? That's what analysts say.

Yeah, yeah, yeah. Fair point.

Fair point. So privacy engineering is already focused on this from just managing the performance of your mobile devices. Your iPad will unload and shove over to iCloud your mobile app data to save space if you run out of space. Rather than just saying, you can't install this new app because you're out of space. Or if you haven't used an app for 4 weeks, 5 weeks, or something like that, your Android might say, hey, it doesn't look like you're using these apps. Would you like to clean them up? So this idea of cleaning up unused stuff isn't even so much for security implications or privacy implications. It's just for performance on mobile devices. And I think that maps over pretty well to enterprise SaaS. And cloud as well. Like Google, Google will do that. The first time I used GCP to run a workload, it told me, you over-provisioned this. You're not using nearly as many resources.

Oh, you saw IAM recommend that?

You could save some money by choosing a smaller instance. And I was like, that's the only cloud that's ever told me, hey, you're spending too much on this.

We're not paying him to say this, right, Tim?

No.

Just to confirm.

No.

This is very organic.

Very organic.

Yeah.

But he's also not paying us to mention the balance, right? Like, it's all kind of very fair.

Yeah, balances out.

Or he didn't pay us to mention his podcast either.

Oh, that's right. Yes, exactly.

It's all kosher here. I want to shift back onto the SaaS world and maybe ask, if I'm a director and I'm bringing on a new SaaS vendor, what are the things I'm least likely to understand about securing it when I first start using it? And what should I do different?

I think number one is understanding how the business is planning to use it. But I think there's an assumption in what you just said there that might not even be true. Maybe it's already been in use for 3 months when the IT team finds out that it exists, or 3 years or something like that, right? Like sometimes SaaS is owned completely outside of IT and security, IT are unaware of it. Who are the Salesforce admins? In many cases, they don't even work for the company. You hire like a third-party group of Salesforce experts to set up your Salesforce and run it for you. First of all, you need to understand how the business is going to use it to understand how it needs to be secured. Because Salesforce, just rolling with that example, I think there are well over 200 different configuration options. And then you could extrapolate that to more if you take in all the options within options.

So, the least understood aspect here is that ultimately, when you say, hey, let's secure SaaS because you onboarded it, you may then realize it was onboarded 3 years ago. It shouldn't be not understood in 2023 because, again, I vaguely recall this whole People whipping up a credit card and buying SaaS going back maybe 10 years ago, maybe more. So, it's a little strange how we are misunderstanding it for 10 years.

It's more that it's been deferred, I think, by most security teams than that it's not well understood. Well, and it's not well understood because it's been deferred for so long. You'll have teams say, well, let's figure out patching first, before we moved on. I was talking to an old friend of mine, and he was telling me the other day he had to teach the Linux admins how to turn on patching in Red Hat. There was no repo enabled for updating software.

What? What century is that?

Yeah, I know.

I shouldn't even say what year is this? Like what century is that?

Yeah. Red Hat Enterprise and no enabled repos, no way to apt update or apt upgrade anything. So that's where we're living, where SaaS seems like, okay, like that's something I'll tackle in the future. But the problem is most of our business stuff has moved there already. Workloads moved in 2 directions. The custom in-house stuff moved to cloud and then everything else moved to SaaS. And you have to have a really good justification to not use SaaS. Like, let's stand up this internal HR platform, or are we going to use Workday or BambooHR, something like that? You're going to go the SaaS route.

So, if you structure it to top 3 misunderstood aspects of SaaS security, I guess maybe I want to reserve the number 3 for CASB just does it. So, what are the other 2?

One of them is that they're all unique. There's no standards for SaaS configuration. Like, in one SaaS, maybe all the security options you want are there, in another one, Half of them are there.

And another one, you have to pay extra for the security features.

Yes, exactly.

You just had to make it even more depressing, Tim.

Sorry.

Yeah.

My bad.

So one of them is just the uniqueness of each one. Each one is a snowflake, pardon the pun, and you have to learn each one from scratch. On some platforms, for example, MFA is a one-step process. You just enable MFA for an identity. And in another, you have to both enable and enforce it. And if you forget that second step, then you haven't actually done MFA correctly.

What?

Yeah, that's also Microsoft.

Sure, I can see that. Maybe MFA is something you enable and then users have to configure it if they want it, or you can enforce it. I get it. I understand some poor PM who couldn't migrate all his users or her users or their users. That sounds awful. And it leaves us with this kind of situation.

And there's different layers of enforcement. Like when I log into a lot of services, I get an option that says, don't make me MFA again for 30 days or maybe ever. Like, once I do it once on this device, just give me an OAuth key that lasts indefinitely. And that's where we see cybercrime taking advantage of that. And there's a special kind of malware called info stealers that do nothing but sweep up all your SaaS OAuth keys and sell them on a black market or use them to get into a company and deploy ransomware.

So wait a second, I feel like we haven't talked about CASB enough. And the reason why we did an episode on podcast on SaaS security, and which we'll link in the resources, but the thing The thing is that I was very skeptical. And again, maybe it's my old Gartner brain or something. I was like, yeah, why are we talking about this new platform for securing SaaS? CASB does it. And then, of course, now we have SSPM. So, we have the CASB bucket. We have SSPM bucket. SaaS security posture management. People, our audience, have been beating on us a little bit for not explaining all the acronyms. CASB, I'm not going to explain. The acronym is kind of too embarrassing.

Cloud Access Security Broker.

Okay. Teamwood. Fine. That counts.

But I'm not sure that explains it. It's meant to be software that helps you use cloud stuff securely.

But it's the only security acronym with a B, so that's already kind of a little disturbing.

Yes.

Yeah, broker is a weird word to have in an acronym. Yeah.

Yeah.

I mean, I think broker ended up in there because a broker helps you use other stuff, right? It kind of makes sense. Anyway, go on, Anton. Sorry.

So the question is, Adrian kind of quietly implying that maybe there's another category of SaaS security tech that we need to have. So how does it all fit with securing SaaS? Do we have CASB, do we have other?

Early on, long before I joined Valence, I referred to the new SaaS security companies as CASB V2.

Okay.

And I largely saw CASB as a failure in what it tried to do. It pivoted a lot during its very quick and hot burn that it went through before they all exited. Is it?

That's too harsh. This is harsh. CASB is a failure is too harsh. I'm sorry. I'm not offended, but I'm like surprised.

So, I don't think we've yet seen us live alongside a CASB, but we do replace them. And we see this all the time in security. We see a category that's largely defined by one or two vendors, and then all the other vendors follow that model, and it's the wrong model. It's not a model that has market fit, that lands with customers. And then we see the next generation come in and try a different approach. You know, anti-malware didn't take the wrong approach initially, but the adversaries switched. And if you didn't pivot quickly enough to the next-gen approaches, when we got CrowdStrike and Silence and all that, you were kind of dead in the water. And we saw a lot of companies directly impacted by not moving quickly enough. And so CASB, I think they did start to pivot towards more API models than forward and reverse proxy. They were very excited and I was very excited about the idea that I can adopt SaaS, but not this feature. And I can add this feature.

Okay.

But the idea that they're taking away JavaScript and injecting JavaScript on the fly, I can do step-up authentication where it doesn't exist. The SaaS vendor doesn't give me that. Like, I want to change somebody's payroll or change where it direct deposits. Maybe I want my CASB to require step-up authentication for that. And you could do that with a CASB. Or I want to use Yammer, but I want them to use Slack for chat or Teams for chat. I don't want them to use the built-in chat within Yammer. So, you take away the chat box using an inline CASB. And just turns out, even if they said they wanted that, nobody took the time to set it up. So most of the customers I talked to, the use cases they would get around to that they would have time for were much more basic, much more simple. And I think the other thing that kind of killed it is the CASBs were very focused on shadow IT and discovering as much as possible, which became very overwhelming. We just talked about how each of these SaaS—

But needed though, right?

Well, but it created a problem. We just talked about how every SaaS is a unique snowflake and you have to study and understand each one to be able to configure it correctly. So now I just told you, you have 1,000. I discovered your entire long tail of SaaS use within your organization. Where do you start? Whereas now you look at this current gen of SaaS security companies like ours, it's very much more focused on Microsoft 365, your Google Workspace. There's a lot of work to do there already. And it's much more of a hygiene governance focus than discover all your shadow IT and lock it down. So much more business enablement, much more like, hey, we're going to let the business continue using this SaaS, but we're going to give you the visibility you need to go in there and without disturbing them, without killing productivity, going in there and fixing things up as you go, rather than come in as blockers.

Well, Adrian, this has been a fascinating and wide-ranging conversation. We are unfortunately at the time where I have to ask our closing questions. One, do you have a tip to help people improve their SaaS security? And 2, do you have some recommended reading for our listeners?

Yeah, so the tip, I would say integrate identities as much as you can. Don't let people use the native stuff. Then you don't have to worry about a lot of the built-in SaaS settings like MFA and stuff like that. If you push everybody to Okta or push everybody to Google or Microsoft, you can rely on the configuration you've already done there and get the benefit of scale from that. So take advantage of single sign-on and integrations like that that take some of that work off your hands. What was the second question?

Recommended reading.

Well, so recommended reading, we do have a report that goes through a lot of the stuff that we're talking about. It's got examples of breaches. So if you look for the 2023 Valence State of SaaS Security Report, it has examples of breaches to go along with a lot of the stuff that we've talked about. It goes through the different use cases that we see in SaaS security. We kind of break it down into the different components, misconfigurations we talked about, identities, we talked about external data sharing, and also integrations, those SaaS-to-SaaS integrations that you wouldn't see inline. And then has all the data that we pulled. I got to play with the data that we actually got from our customers. And I mentioned that 91% stat. There's a whole bunch of interesting stats in there. that are in that report, and then we give recommendations and predictions. And one of my predictions was that AI LLM will lead to an explosion of new SaaS, so there'd be more than ever to deal with.

Got it. Well, Adrian, thank you so much for joining us today. Listeners, thank you for joining us on the live stream. I see lots of fun comments. I want to thank everybody for the engagement. And Adrian, your fellow podcaster in the security space, Rafal Los, is calling you out on some of your comments about Exits and the Caspi space. So, well, he has a podcast too, so you know what to do, Raf. Raf knows what to do. We'll, uh, we'll all get together and argue about Caspi. It'll be a—

it'll be great.

God, I was gonna say that'll be a great time. I don't know about that. All right, thanks, folks.

Depends on your perspective.

Yeah, sure does. With that, thank you all for joining us today.

Well, thank you very much. I appreciate it.

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, @anton_chuvakin and @_timpeako. Tweet at us, email us, argue with us, and if you like or hate what you hear, We can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.