EP130 Cloud is Secure: Are you Using It Securely - True or False?

Security.

Hi there. 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 and argue with us and the rest of our listening community on LinkedIn. Anton, we are usually talking about like infrastructure security or platform as a service security, but today we get a little further afield into like the nether reaches of cloud security and talk about SaaS security and CASBs and all these things I forget to think about. This is a fun episode.

Indeed. And the other fun angle is that it's with one of my former colleagues from the days before I became a reformed analyst, and then when I was just called an analyst rather than a reformed one.

What do analysts talk about over lunch? Oh, like when you guys are hanging out in the Gartner office, what do you talk about?

Well, first thing is Gartner, I think, had a remote working culture from the late Oh, wow.

You didn't have lunch together.

Okay. Maybe it's mid-'90s. I'm not sure. But the point is that it's probably the company with the longest-running remote work culture kind of on the planet. So, it really means you never meet your colleagues for lunch unless it's at a conference when everybody is talking about things happening in the industry, but it's also a once-in-a-year occurrence, not once-a-week occurrence. So, it's kind of a little surreal.

That's funny. I was trying to picture you and all these Gartner people like sitting around a table arguing about which MQ to make next. And I guess that isn't how that happens. Well, listeners, with that brief imaginative foray into the offices of Gartner, which apparently don't exist, let's turn things over to today's guest. I'm delighted to introduce our guest, Steve Riley, Field CTO at Netskope. Anton, why don't you get us started with questions today? And Steve, thank you so much for joining us.

My pleasure. Thanks for inviting me.

Sure. So, this episode would likely be focused on something I've been kind of obsessed with a little bit. And it's the whole cloud is secure, but are you using it securely? And I don't think, Steve, it wasn't you who coined it. It was Jay Heiser, right?

Yep.

In our Gartner days. Yeah. So, but it's the line that goes back at this point, what, almost a decade?

Well, let's see. I think cloud computing got its start in 2009. So, a decade and a half almost.

Time flies when you're having fun.

In the cloud. And so, when you hear it today in 2023, cloud is secure, but clients just aren't using it securely. By the way, I removed the question mark that we had in the original paper. What is your reaction to this? Like, how do you, you know, what do you think? How do you feel? What's your reaction to this?

I think it's largely the truth. But if you wanna figure out why it is the truth, I think very early on in that analysis, it's important to draw a distinction between security in SaaS and security in IaaS, because they have very different starting points, which often result in very different outcomes.

So, the line was for IaaS originally?

It was, yes. And the specific instigator for that report was open S3 buckets. You know, it's something that we read about all the time. And so, we're asking ourselves—

What year is this?

Hello?

Hello?

Calendar, anybody?

Apparently it's 2009.

Yes, yes, 1882, mine says. So to be clear with folks right now, out of the box, out of the bucket, S3 is secure. When you create a bucket or an object in a bucket, you have to assign an ACL, but the service assigns an ACL for you. Only the creator has access. Nobody else does. That is the default way S3 works, is the default way Azure Blobs work, is the default way that Google's equivalent works. Now, when you read about these open buckets, someone has changed that ACL from the default, and it's reasonable to ask why. Well, most of these open buckets turn out to be the entire world has read access. Sometimes the entire world has read/write. And that sounds, I don't mean to be super critical, but it sounds like laziness. The owner of a bucket needs to share it with a few people for 20 minutes. So the easiest thing to do is just give the world read or read-write access, and then, you know, you'll fix it later, right? No, you forget about it. And that's often what happens.

You say laziness, I say bad UX, or I say cloud provider made a mistake in not making it easy. I mean, I'm almost a little bit criticizing ourselves, right? Because we work for a cloud provider. But I used to think exactly that, that it's just laziness, and it is users' fault, and they're just not doing it right. But it's their bucket, not users'. It's the bucket built, and all the tech around it is built by the provider, right? So, wouldn't they make it hard choice, wrong choice hard, secure choice easy? Is it a little bit on them?

Yeah. Think back to the way on-premises security constructs worked. We had directories, we had access control lists, we had objects, and we had permissions and rights and all these things. My take is that in IaaS it's different, not necessarily harder. That said, think back to when you were managing an on-premises file share. Maybe it was a little intuitively obvious how you would set up those permissions and the access control lists. It isn't necessarily equivalently obvious, right? I mean, there are 2 forms of ACLs in S3. One is just the one you can do in the UI where you can put individual user accounts or groups and choose, you know, read, write, whatever. But the better way to do that is with little piles of JSON. Now, I think you're not going to go very far in modern cloud if you aren't JSON fluent. On the other hand, nobody dreams in JSON.

God, I hope not.

So what are the good ways of making sure that your JSON is exact? There are lots of GUI tools you can use to parse— well, to write the JSON for you. You describe what you want it to be and it will output the JSON. But more importantly, there are also policy evaluators now. I don't know about GCP, but AWS has a policy evaluator built in where you can Feed it that little bit of JSON and it'll tell you what the result is. So it's different, it's maybe not quite so intuitive, but you know, I'm a big fan in the idea of delineating responsibility. And yes, it's the provider's responsibility to ensure that the hardware and software that create all that infrastructure for the buckets is secure and resilient, but it's the bucket owner's responsibility to create the right ACL on top because it's their data.

Okay. I agree with you, of course. And I still have some kind of lingering doubts in my mind, like, how much work— can providers do more? You know, we are trying to do the shared fate, whatnot. But ultimately, I think you build a case that it really is the user's fault in many cases for these situations, for the open buckets. I think let's not obsess about it.

I'm gonna say it's almost— it's mostly the user's fault.

Mostly.

But I do wanna fall back and say that because Even though it's been 14 years, for many folks, cloud is still new, and it is sufficiently different that it's easier to make these kind of beginner mistakes, right? So maybe the actual job—

wait, wait, wait, wait, wait. It's easy to make beginner mistakes. Provider's fault. Provider's fault.

So you interrupted me, Anton. I was going to say that maybe it is the obligation of the provider to make it even easier to learn these clouds. And you know what, there's another reason why that matters, is because a lot of orgs think multi-cloud is the way they want to go. I have opinions on that that maybe we could talk about later. I think it's hard enough to be an expert in just one of these, let alone 2 or all 3 of them. So the more the providers can do to expertise all of their customers, the better off we'll all be.

Okay, so I want to pick at this a little bit. We obviously all understand now what Anton thinks when he hears this phrase about people not using cloud securely. What do users hear? What does the CISO think when they hear this phrase? What does the security director think? How, how do other people perceive this problem?

Well, in the case of SaaS, I think people make a lot of assumptions. And those assumptions are quite wrong. Unlike IaaS, where it's kind of like secure by default and you have to intentionally change things if you want to enable some sharing, in the SaaS world, open by default is, well, it's the default, right? It's open by default. And it's interesting to think about why that is. And that is because the SaaS providers have decided that sharing and collaboration is more important than locking things down. We could have an argument over whether that was the right choice, but that's not really going to be useful for anybody here. That is the reality. So for SaaS world, people need to be made aware that they have an obligation to fine-tune the security settings to be stricter than they are out of the box so that people don't share too much, you know, and that's a big problem in SaaS.

That is eye-opening and possibly mind-opening.

Huh.

Interesting. I did not think that at all. I was kind of mistaken, frankly, because I think your knowledge of this is better than mine. So, I assumed SaaS would be more secure by default if there's a comparison compared to IaaS because it's just more stuff you can do in IaaS. So, it is fascinating that it is not the case and I was wrong. Interesting. That's—

you asked about customers, and that's the perspective I would like customers to take, even though they might be thinking about it now, is that yes, you've got this great collaboration platform. Now you're of course going to be storing sensitive data in it eventually. The moment we subscribe to these tools, let's begin thinking about what the best strategy is to strike the right balance between staying secure and getting work done. And the right balance is not usually out of the box.

Interesting.

How do they find that balance? I assume there's not SaaS yoga we can sign up for.

Well, okay, maybe there is. That SaaS yoga would be called data classification, right?

Oh no, no, no, we are back in the '80s now. Data classification, that's your advice?

Well, hold on a second. So everybody says, I want to manage and I want to monitor and control the movement of sensitive information. That is a better way of saying DLP because DLP has so much baggage. Yes, got it. So, I want to monitor and control the movement of sensitive information. How do you know what's sensitive if you haven't slapped a label on it? Now, fortunately, there are modern-day tools that can scan content using things like heuristics and prior behavior and even AI/ML that can do maybe a better job at the initial classification than a human, but then the human can come back and modify it later. That's why I'm a big fan of involving business units in these discussions, because they own the data. InfoSec doesn't, right? All we can do is make people aware of risk, but we can't be responsible for risk. The business units have to, but they also have to help us understand how that data is being used so we can guide them on the right risk decisions. So some basic things about data ownership, provenance, duration, and style or type or classification, all these make it much easier to then devise that SaaS security strategy that everyone desperately needs.

So, I agree with that, of course, but I wanted to sort of— so, in my mind, there's still a difference between data classification circa 1980s DoD style and telling which data is sensitive. I think this type of a mini-classification sensitive data awareness probably isn't anywhere near as painful and failure-prone as, like, data classification. So it's almost like the term seems overloaded, right?

It is, like DLP. So maybe we need a better term.

Right, like DLP, correct. Yes.

In my mind, I'm thinking that there's 3. There's public, there's private, and there's confidential.

Yes.

I mean, maybe you need more, but I feel like those are great starting points. You know, public is clearly Public, right? Confidential is, you know, it's the eyes only. It's the not everybody in the company gets to see it. It's the, you know, only those who need this as a part of their role. It's the one that maybe we would use a CASB to say you can only access that on a managed device, not on an unmanaged device. So that leaves the middle one, which I initially called private. Maybe internal is a better word. Public, internal, confidential.

Yeah.

Let's go with that. I like that better.

I remember putting it in the Gartner paper on DLP, so it must be at least somewhat right.

Sure.

And I remember gently kicking in the shins of somebody who suggested 4 levels because I felt like this 4th level is going to be a pain in the butt because nobody would know what is— actually, I don't even remember what the 4th level was. Public, confidential, really confidential, really, really confidential. I don't recall. But the point is that there were 4-level schemes, which annoyed me quite a bit, and I felt like they're unusable. But the 3-level scheme seemed— okay, fine, we are off the track. So let's, uh, all right, severely, we are severely off there, but in a useful direction.

Can we please bring it back to 2023?

So in your mind, it's also 1980s or '90s or whatever.

You're gonna go put on the Talking Heads and imagine the era before I was born at this point, folks.

I'm gonna drag another—

what's that smell like?

I'm gonna drag another 1980s security concept to the conversation, unfortunately, because that's on our roster, namely defense in depth. And I apologize, it was not a setup to say we're going to go through the old security concepts but in the cloud. But it's a very useful line of thinking. I've met people who are royally confused about what defense in depth even means for SaaS, for IaaS. They don't know how to even think about it. Some people say for SaaS, there is no defense in depth. It's just Username, password. If somebody knows it, you're toast, which makes me kind of question the whole SaaS business in the first place, but I hope they're wrong. So defense in depth, cloud, IaaS, SaaS, any thoughts, any views?

I don't like the term.

Oh.

I prefer just layered defenses because it's more conceptually graspable than defense in depth is. I want layers of defenses. That's because if one layer is misconfigured, Mm-hmm. Or is attack-prone, the other layer perhaps can compensate for that. I want to give you the best example I've ever seen of layered defenses. And actually, this kind of comes back to the storage buckets we began this conversation with. Remember that every bucket and every object in every bucket has an access control list on it.

Mm-hmm.

What happens if you decide to encrypt that bucket? And subsequently every object in the bucket. A key gets generated for each object in the bucket, and guess what? The keys also have ACLs.

Right, correct.

So if Alice is supposed to access an encrypted file, her identity must be present on both the file's ACL and the key's ACL. If Bob isn't supposed to interact with that file, but for some reason his identity got on one of the ACLs, say the object itself, because Bob's identity isn't on the key, he won't be able to decrypt that object. So this idea of encrypting everything all the time, everywhere, everything all the time, in IaaS buckets automatically creates a 2 layers of defense that I think is incredibly strong.

Unless you auto-apply the same permissions you had for the bucket for the keys, which I've seen people do somehow. In this case, you lose the layers. It's like, remember in the good old times in Windows, people would encrypt the hard drive with a Windows password, which means the same, right? It wasn't funny 10 years ago because it was kind of a default, as far as I recall.

Yep.

Yeah. Okay. So I think I like that. But so what about the SaaS? How would you think of defense in depth for SaaS? I really want to know. I genuinely can't think of— please don't say buy Casby. Actually, maybe do say buy Casby. Maybe it is a layer.

Maybe it's buy Material Security and let them delete all your old emails unless you really need to get to it and do 2-factor.

What about the new emails?

Well, so, you know, but what does layered defenses encompass? Does it include only defenses against an adversary, or does it also include defenses against mistakes, right?

Our CISO likes to think, always remind us of the second part. Phil Venables has has reminded us every time that cloud layer defense better cover attacks and mistakes. So yes.

Right.

And I think that was a good lesson in our SRE episode as well, talking about how do we make it easy to do the right thing and hard to do the wrong thing.

So a lot of SaaS applications— well, let's say a lot of the important tier 1 SaaS applications, the ones we would all recognize by name, maybe even around dinner table conversations, who knows?

I hope not.

They have decided that resilience— what's that?

You need to have more fun at dinner.

Oh, you know, I want to tell you something. We'll come back to this in a second. I can remember a time when I was at Microsoft and at a TechEd conference having dinner with a product group, and that particular product group had like the best quarter ever. And so there was some celebration at dinner, but then most of the time at dinner we spent talking about Sex, politics, and religion. And now I— that's fascinating. Hang on. The mechanism by which you materialize on Earth, the mechanism by which you organize your society, and then the mechanism by which some people think they will go after. How come? I mean, these are the most important topics humans should talk about, right? We shouldn't be ignoring them. Anyway, so back to—

I might venture that not all of that first category is necessarily procreative, and the non-procreative part is important and worthy of inclusion as well. But I think I want to move us right along to a different area where— are you drinking out of a— it's a great mug.

Yes.

Awesome.

It's a 450 milliliter beaker with a handle, of course.

And does it have caffeine on the side?

With a handle?

It does, but this is just water.

Well, I want to talk about zero trust and switch gears a whole lot because people always enjoy zero trust.

Is it the drinking game? Zero trust, he drinks? No? Yes? That one?

Yes.

Okay. Yes.

So I want to talk about zero trust. I want us to go back to like 2010 when it got introduced. What have you seen change in zero trust since then?

Well, actually, the original concept came out in the middle '90s when there were some academic papers on trust in digital systems. And then, not to claim ownership of anything, but way back in 2005, I was writing and speaking about this idea called death of the DMZ. where I was saying authenticate everything, authenticate every actor, authorize every transaction, audit every activity, and encrypt. Sometimes I would change that to encrypt everywhere. But yeah, I mean, essentially this notion is removing the environment as a position of advantage. So in the specific example of zero-trust networks, The fact that you have an IP address on a network gives you a position of advantage. You know where that IP address will take you. So how can we eliminate that as a position of advantage? Now, I like to think about how the concepts have sort of morphed over time. When Neal MacDonald and I were trying to think about, you know, what was Gartner's position on this—

Oh God, yes, I remember that time, which was kind of exciting. It was exciting.

Oh yeah, yes, yes. The position we took was that zero is the starting point. There is no trust at the beginning of an interaction. Context must be evaluated. The signals that are present in the environment must be evaluated, things like time of day, day of week, geolocation of the data and the human, health of the device, the relative strength of the identity in that particular example or in that particular instance. But then you look at all those signals.

Yeah.

And you extend a certain level of trust that's representative to what the environment says you can.

Mm-hmm.

So if Diane is on an unmanaged device and she's logging in from an unknown location at an unfamiliar time, that is a lower trustworthy interaction than Diane on her managed device logging in from the same place she normally does at the same time she normally does. That's a much higher trust interaction. And some of the zero trust purists don't like that idea because, oh, we want to eliminate trust. Well, no, I want to eliminate implicit trust and replace it with explicit trust, trust that is evaluated. Well, signals that are evaluated and a specific amount of trust is extended.

We had this argument with John Kenderaugh about exactly that point. So, I think he is the ZT purist. Exactly. He's not zero as a starting point. He's like, Damn the torpedoes, zero trust. I'm oversimplifying.

You know, I acknowledge that, and maybe it's a difference in understanding more than anything else, but ultimately we both agree on the idea of looking at the context, at the signals, and not granting more than what is just needed or what makes sense at that moment in time.

I really like this remove network as position advantage. I think that's one of the more interesting articulations of ZT I've heard in a while.

more coherent than a bunch of other stuff. Like, what is this zero trust detection stuff? Is this silly? Like, people are over— yeah, overdoing it. But I think this type of stuff is very logical.

So here's the way I like to think about it. Zero trust is an adjective. It should be followed by a noun. What is the thing you want to remove implicit trust from? Zero trust networks makes sense.

I like that a lot, Steve.

A zero trust coffee pot? Yeah, doesn't make much sense because you don't really have trust in a coffee pot anyway. You don't need to remove implicit trust in that case, or even detection for that example.

I have implicit trust that it contains coffee and not tea.

Well, maybe your sniffer is what verifies that.

Yeah, that's right. Not a network sniffer, just regular sniffer.

Oh, speaking of this notion of verification, right, you know, people say trust but verify.

Доворей, но проवरей. I learned how to make it rhyme.

What's that?

You can make that rhyme if you say it in Russian.

Oh yes, it rhymes in Russian. That's the original proverb in Russian does rhyme. Yes.

Okay, that that's do that for me right now, please dance.

You want the Russian version?

Yeah.

Да вериай, но про veriay.

That's fascinating.

That means exactly that trust but verify. That's kind of like it, but it rhymes.

So if I were to turn that around, and I like to say verify then trust, which is what many products built on zero trust principles do this. So like the ZTNA market.

Mm-hmm.

You know, in normal remote access, there's a VPN concentrator sitting behind a firewall with an open port, so you can throw all kinds of traffic you want at that VPN concentrator. You never have to authenticate yourself, but you might be able to force that thing to malfunction in some way. Look at the way the ZTNA market works now. It's cloud-based services. You have to authenticate first, and then you can interact. So we've flipped that connection model around. We're hiding things you don't know exist. So concealment actually is a good part of an overall security strategy. But if I say verify then trust, it means I'm going to know who my principals are first, and only after I know them and their environment can I extend a certain amount of trust. So Anton, what would verify then trust be in Russian?

Verify then trust? Yeah, uh, but it would make kind of no sense. It would be the opposite. It would be Превиряй.

That's the point.

Превиряй и довиряй. It would be verify and trust, literally.

Okay, so there's no then that represents a sequence?

I'm just okay. It's fine.

So now I'm like Anton's been stateside too long, listeners. He can't even remember his Russian.

Yeah, now I'm like it wouldn't rhyme. Yeah, it doesn't rhyme. It would be like then later it would be like. Verify and then later trust, right? But that's not the same theme.

All right, Anton, you've got another question you want to pick out here. Why don't we do that? Okay.

Yes. So—

Okay. That's fine.

I mean, I bet now I'm like, yeah, now I need to think about it a little bit.

No, think about the questions.

Oh, back to the questions. Yes.

So, we did cover zero trust, and I think it actually is fascinating, and that discussion was actually a lot more lucid than some discussions I've seen. But zero trust and ZTNA specifically gave birth to these weird, somewhat agglomeration of things like SASE, and then later a smaller thing called SSE. I think— I'm sorry, I missed the SSE creation time. I left Gartner by then, but I'm still befuddled by that. And I think, Steve, you may be one of the best people probably on the planet to explain SASE versus SSE and what it all means for clients. What does it improve? Probably focusing on the later creation, namely SSE.

Yeah. Well, so, but we have to start with SASE because there's an origin story there. SASE was an important effort by Gartner to begin bringing folks thinking about how InfoSec and I&O should be cooperating more than not, right? I mean, these are security folks and infrastructure folks. For most of the existence of these disciplines, they've gone to great efforts to avoid each other professionally and socially.

Mm-hmm.

And maybe that was fine when everything was on-premises, but as We move from one data center to many centers of data. Every cloud is a center of data. As people move from being on the corpnet to everywhere else, but not on the corpnet, InfoSec and infrastructure, they can no longer remain isolated. So almost by kind of forcing folks to think about the collaboration of these two by creating this interesting market where the products have already been brought together, It's accomplishing a critical goal for modernizing IT departments. Now, in the original days, there was a bunch of networking on the left side of that diagram, you know, WAN op and routing and switching and, you know, even SD-WAN was there, right? And then there was a bunch of security stuff on the right side, CASBs and SWGs and VPNs and ZTNA and all that stuff. Now, over time, What happened, the left side kind of collapsed into just SD-WAN. And I can remember a summit presentation one year from an analyst who showed only SD-WAN on the left side because SD-WAN kind of subsumed all those other functions. But the security stuff was still like this giant menu of acronyms. Well, so there's that. Now park that in your brain for a moment. Craig Lawson and I started the CASB MQ in 2017. And the SWIG MQ had been around since, you know what, again, 1885. 1885, probably, yes.

Yeah, Jim, we just mentioned 80s and you missed it.

Sorry, guys.

One thing that several of us authors noticed sort of around 2020 was that the SWIG and the Caspi markers were beginning to converge. Vendors in one were offering capabilities in another, and we just saw more and more overlap. So after the 2020 iteration of the MQs, we started talking about what's this going to look like? These individual markets are going to be features of something bigger. And so the decision was to intentionally retire both Magic Quadrants for the distinct markets and come up with a new Magic Quadrant, a new critical capabilities for the combined market. Now, everybody agreed to that before I left, and I was happy to see that, but there was still some discussion about what they were going to call the market. If SASE is Secure Access Service Edge, SSE is Secure Service Edge or Security Service Edge. It does feel like SSE is SASE without the A, without having the A.

Yes, exactly.

That's a little wrong because SSE is actually all about mediating and governing access to SaaS apps, the general web, and private apps, right, through ZTNA.

So what gets better when you deploy C? This is a question Tim invented a few episodes back. And we've been testing it on vendors. And I think at this point, I apologize, Steve, I'll treat you as a vendor. But what gets better when you deploy SRE? Like, what gets better in your life? What gets better once you deploy SRE? Like, what improves?

Oh, well, you go from 3 or 5 consoles to 1 console.

OK.

You reduce the number of arguments that people have over who gets to sit at which console because there's only 1. Of course, though, with proper role-based access, you can maybe divide that up if necessary. But we don't want people to do that anymore. You've got a single policy engine for all traffic and maybe even a single agent. You know, this is what people often ask, hey, what do you do at Netskope? And there's the like corporate answer, right? But here's mine. Our value proposition is send us all your traffic. Doesn't matter— SaaS, web, private apps— send it all to us. We will make sure the right traffic goes to the right places based on the rules you create in our console. And those rules you create can apply to all of the destinations. That's what we do. I don't want to have duplicate DLP policies just because some traffic is web and some traffic is SaaS. I want one policy, one policy engine, one evaluation.

This actually makes sense. I think this is the first SSE explanation that would stuck in my brain because before that, people would explain it and it would just like wash off. And maybe it just means I'm stupid. It's very possible.

It's certainly the first one you haven't made fun of.

Ah, yes, that's true. That is the first SaaS definition I did not make fun of. Thank you for the reminder.

Well, geez, I'm honored.

Big day for you, Stu. All right. So on that positive note, I'm afraid I'm going to have to ask our traditional closing questions. First, I suppose in all of this, do you have a recommendation for how people can use cloud and SaaS more securely? And 2, do you have recommended reading?

How to use it more securely? Uh, so I want to go back to this.

Yeah, like one weird tip.

Yeah, I want to go back to the distinction, right, between IaaS and SaaS. Acknowledge that there are different starting points from these styles of cloud and adjust where you want to go based on those different starting points. You cannot assume that their origins are identical. But whatever you do, I think it's always important, and I said this earlier and I'm going to say it again, is to strike the right balance between staying secure and getting work done. You know, there's 3 kinds of vulnerabilities: code, you know, bugs that we think of, right, that are security problems in code. There are configuration vulnerabilities, which are actually far more popular than code vulnerabilities. But there's also circumvention vulnerabilities. You have a control that is so onerous People will seek ways to get around it. And these are the controls that should automatically be rejected as security departments look to modernize themselves and strike that balance. We don't want to be the department of no anymore. We want to be the department of yes, you can, but with conditions, getting back to the Zero Trust principles we mentioned earlier.

Oh, that's a great answer. And Steve, do you have any recommended reading? It can be anything from Mary Oliver to The Art of War.

To Netscope blog. I mean, we'll put it on the list anyway, so don't say Netscope blog.

I will warn you, if you say Anton's blog, you have to put a dollar in the swear jar.

Just one?

Just one.

Okay. There are 2 gentlemen who have been roundly influential in shaping my thinking of the InfoSec space: Bruce Schneier and Marcus Ranum. So I would encourage listeners and viewers to Check out their stuff. It isn't going to be always cloud-specific, but I can't imagine 2 better sources of ideas where you can learn to strike that balance that I've mentioned earlier in wherever it is that you work.

Awesome. Well, Steve, I really appreciate that.

You're welcome.

Thanks for joining us. And listeners, thanks for tuning in and joining us live. With that, thank you.

Thanks, everybody. See y'all later.

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 @_timpeacock. 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.

Thank you, Roni.