EP61 Anniversary Episode - What Did We Learn So Far on Cloud Security Podcast?

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and esteemed member of the cloud security team here at Google. You can find and subscribe to this podcast wherever podcasts are available, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button. Finally, you can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Now listeners, you may have noticed that we've been doing the show for over a year now, and if you noticed that, you're doing better than we did because we straight up didn't notice. But we thought we would finally take the time to do an anniversary episode and indulge in a little bit of self-reflection. So today's episode, no guests, just me and Anton talking about things we've learned from a year of doing a cloud security podcast. So Anton, I guess that's really the softball question of why did we do this? Why did we make a cloud security podcast? And when we think about our name and our topic, why cloud security? What are we doing here?

So there's actually a story there, and I don't think we can share all the details, but keep in mind that the cloud security is both our topic and our name for a podcast.

Mm-hmm.

So the reason why I think we started it is because to me, a lot of people are kind of fascinated by cloud security. They're fascinated by cloud. They're fascinated by security, and they're kind of confused/puzzled by how these overlap.

Mm-hmm.

Think about shared responsibility model. Think about the role of the hyperscaler. cloud service providers. A lot of things in how security is done in the cloud are actually quite alien. And to me, one of the themes— I'm jumping a little bit ahead, we'll get to the themes— were that some things in the cloud are just completely different, and cloud is not just somebody else's computer. Or maybe I should emphasize it like this: cloud is not just somebody else's computer. So to me, the fascination with the topic is what made us pick the topic. And of course, we were sort of handed a name on a platter.

Well, when naming things at Google, the overriding principles are that they're descriptive and accurate. And I would say Cloud Security Podcast by Google is both descriptive and accurate. So I agree. I find it also a fascinating topic, and I guess our listeners must if they keep listening. So we get a lot of questions, and one of the things that Google has used in our messaging for a long time is, Security for the cloud, in the cloud, from the cloud. What does all that mean?

So I think the origin of this term actually predates us.

It does.

And I recall seeing it in the CSA, Cloud Security Alliance materials, a good number of years ago. But the challenge with that is I think that the meaning kind of floats and evolves sometimes. So to me, security from the cloud is something that's the easiest to explain, right? If I have laptop or a server and I want something very mundane, like, I don't know, antivirus.

Uh-huh.

I can pick a tool that beckons to the cloud. So it would sort of be security from the cloud, but I may be securing my laptop. I may be securing my on-premise data centers, but some of the value of this would come from the cloud. So it's not really cloud security from that point of view. It's kind of a security for wherever you are delivered from the cloud. So that's sort of the easiest one, right? Mm-hmm. Mm-hmm. Now, to be really honest, and I may kind of embarrass myself by saying this, but I've always confused security for the cloud and security in the cloud. One of them applies to the platform security of the cloud. Actually, wait a second. Did we mention security for the cloud, in the cloud, from the cloud, and off the cloud?

Oh, there's a 4th. Brutal.

Yeah, I think so. Because like platform stuff.

So things like how we harden KMS, things like our Titan chips.

Correct.

Things like how we do employee access control and credentialing.

Yes. And security of the cloud is actually another one that's easy to explain. We are super proud. I'm probably talking for all of us here. We are super proud about how much attention we pay to security in Google Cloud.

Yes.

So security of the cloud is very dear to our hearts. But to move to other, possibly more puzzling terms, imagine you're a customer, and you show up in our cloud with your applications. Who is securing all that? Of course, we talk a lot about the shared fate and some other terms that we plan to explain clearly at some point. there's security of things that aren't part of the platform. It's security for whatever customers bring to the cloud. So it's kind of security in the cloud, but it's not of the cloud. Are you puzzled already?

No, I think there's a distinction that's absolutely as clear as mud there. I think that's great.

But it's a useful distinction.

Yes, we agree it's a useful distinction, even if the line is hard to draw very clearly. So that's one of the fun things I think about about this podcast for me has been things that seem clear internally almost never seem clear externally. And too often Google, I find, thinks something is going to make sense where it really doesn't. And so doing this podcast has given me a lot of user empathy for things that are way more confusing than they ought to be. It's been fascinating, really.

So wait a second. So, you know, the next question was supposed to be, what is one thing you learned from doing a podcast? And I guess you just answered this question, or you want to use another one?

No, I think that's actually a really good one for me. One of the things I've learned from this podcast is that I already knew that cloud security was different. It's its own thing. I talk about this in every talk I give publicly about why it's different, but the degree to which it's different, I think after 4 years of doing this, has gotten a little bit blurry to me. But doing the podcast has really refreshed for me just how different it is. We have people come on the show and talk about firewalls and putting them out into buckets. We have people who explain identity, like Dylan a couple weeks ago explaining identity more lucidly than I'd heard a Googler explain it. And to have that perspective of how hard these things are to wrap your mind around, to even be able to explain to somebody else, it's eye-opening. So that's one thing I've learned from the show. What have you learned from doing the podcast? And you can't reuse that answer.

You know, yeah, I know that, but I'm known sort of for giving a dark answer sometimes. Maybe this is the non-reformed part of my analyst. But I'll give you a slightly dark answer. So, to me, one learning— actually, let me step back a few years. So, when I joined Gartner many years ago, and then I left Gartner after about almost 8 years, the one learning from Gartner was that a lot of people are doing IT using the 1990s approaches and technologies and kind of thinking. So, a lot of this, like, inertia is the most powerful force in IT.

Yeah.

That was one of the realizations that I've gathered after being an analyst. And I'm going to use an extended version of that here as well. Doing the podcast taught me that a lot of people come to the cloud, use cloud technologies, but their minds, their brains are on-premise. They're kind of the opposite of cloud natives. Sometimes I joke that they're cloud tourists, but frankly, they're not cloud tourists. They read fairy tales about the cloud. They're not tourists. Tourists visit the place. They're kind of like a fairy tale about cloud as operational guidance. So this is a little bit dark, but the point is that it's our job to teach on-premise people cloud so that they can benefit.

That's right.

One of the jobs, I guess. I have lots of jobs here.

We have lots of jobs.

But this is one of my jobs, is to teach people cloud so they do cloud the cloudy way and they don't do cloud like a data center circa 1994.

I mean, this is very much like the conversation we had with Anna not too long ago, where people go to containers, but keep running their stuff the way they ran it before. Is cloud also the tropical vacation for a struggling couple? Like, one of the things I've concluded after a decade of doing stuff in the security industry is a lot of companies don't need another product. They need a couple's counselor.

Yeah.

They don't need a new detection tool. They need somebody to sit them down with business, And this was actually one of the things I loved about Miller when she was on the show, was how much she understood with her BISO title, the importance of the relationship between security and business, not just security exists out there doing security stuff.

Yes, very much so. And to me, this has been very much part of the journey. But if we wanted to do one learning—

One learning.

There are many learnings, of course. Yes. So this is a good one. But of course, we use our podcast sometimes to— wait a second. I need to make a dramatic pause here to mention and maybe even, dare I say, promote Google products. We don't do a lot of it, but we do do some. And Tim, being a non-reformed product manager, lately has been super excited about VMTD, of course.

Yes. What is VMTD? Have I infected you with the knowledge of what it is?

Well, I know what the term stands for, and I know that I had people who are upset that it kills their crypto miners.

But So VMTD, I'm so excited about this because I came to Google, I was sold this job on the premise of come build threat detection. And don't just build threat detection, come to this place where we are helping people with a generational transformation of how they think about compute. When we talk about application modernization, it seems so sterile, but the cloud thing that's happening, it's a generational change. It's as big a change as Mainframes to minis, or hardware to virtualization. It's a real honest-to-God, once-in-a-lifetime transformation in how people think about compute. And when I was sold this job, I was told, you also have that once-in-a-generation opportunity to think about how people secure their compute. And so when I look at my arc of my career at Google, I started out doing threat detection on logs, and we've been doing threat detection on logs since, well, forever. What's the original story of threat detection? It's Cliff Stoll, Looking at logs to figure out where the 8 cents got stolen by the KGB. So that's old school. We've done that. Well, then I did containers, and containers are new, but the way we're securing them isn't all that special. It's cool. It's great. I'll tell you all the benefits. But again, it's agents, it's endpoint instrumentation. We've done this before. But with VMTD, I'm so excited because we're not relying on agents. We're doing it totally differently. We're using the hypervisor to give us a stream of bits, and then from a stream of bits, We're figuring out what's going on inside of a Linux kernel. How cool is that? Like, that to me is the generational change that, you know, cloud and Google's kind of innovation makes possible. So yeah, I'll say that for my product listeners. That's the kind of excitement I have about where we're going with threat detection inside a command center these days.

Right. But honestly, if you guys— and I refer to the entire audience by this, I guess— if you have any feedback to whether we should do more products, less products, you know where to find us on social media or in comments. So we are still looking for that balance. We invite Googlers, we invite non-Googlers, we invite customers, we invite partners, we invite people we know in the industry. So it's not really about products, as you figured out by now, but we are happy to cover more products if you're excited. Like, I have some— of course, there's Chronicle, there is some fun data security stuff. This sovereignty stuff, we plan to cover it, and it involves products. So to me, there are a fairly large number of fun things to cover. As far as Google products are concerned. So let's shift to a somewhat more safe topic.

Yeah.

So can we think of maybe a favorite cloud security trend that we encountered on the podcast? Like, this is a fuzzy question. I get that. But I'm thinking of one. Hopefully, Tim can think of one too.

Okay. I think the one we're thinking of is actually the same one under the covers, but it goes around with 2 very different masks on. So I'm curious, You go first, and then I'll share mine, and then I'll tell you why I think they are the same thing.

Hmm. Well, I was actually trying not to say that it's shift left because shift left sounds like a cliché. But ultimately, the reason why I'm still going to go there is because the shift left thinking isn't about, in this case, isn't about code and development. To me, the shift left is doing security early. And frankly, in the cloud, we do see a lot more reasons for doing it, a lot more opportunity for doing it, and kind of a lot more harm if you don't do it.

Yes.

So, we published stuff about shift-left thinking for compliance. We've done stuff focused on security as code, detection as code, and something else as code. These are all angles, and these are all facets of the same line of thinking. That does come from development, but it's ultimately not about writing code.

Okay. So mine is zero trust.

Oh no, this is so predictable.

I knew that you were going to do shift left, but I think ultimately what they have in common is that they're both about changing where we put trust. We've had a lot of debate on this show, including an episode yet to be released about what zero trust means. But at the end of the day, it's about changing where your root of trust comes from, whether it comes from network access, Or identity that's provisioned in a particular way. And when you look at how Google does these things internally, they're very related, our beyond corp concept, our beyond prod concept. And so much of the shift left thinking comes out of the beyond prod concept where you can't deploy code to production without it having roots of trust deep backwards in the Google build stack. And so, as you do shift left, you have a very similar journey you get to go on as a security organization of, Where does trust come from and how do we track that on the journey from developers developing to production producing? And that's, to me, very similar to the zero trust journey of how do we go from a person has joined our company to they can access the information applications they need to access and tracking that trust through that chain.

That's fair, even though zero trust does imply a degree of monitoring of the end result.

And so does shift left. If you're doing it right with, you know, say, BinAuthZ and monitoring on the alerts that it produces, absolutely should have monitoring.

Yes, if you're doing it right. Because if you're doing it wrong, I've seen people who basically go left and forget right, and then nothing is monitored and the whole thing is a disaster. So, okay, fine. Let's go to a more positive theme here. But yes, I agree. You convinced me that zero trust and shift left are connected. Yes.

I convinced Anton of something. Listeners, this is always a fun day when I get to do that.

So another question is also kind of easy, but maybe tough.

Okay.

Can you name one favorite episode? And you are looking at the notes and you know mine, so don't steal it. So what's your one favorite episode so far?

I bet you can't guess what my favorite episode is.

I bet I cannot.

My favorite episode is with Seth.

Threat models. I can't.

Because it gave us the security garlic versus security onion. Yeah. And I think that threat modeling, I mean, obviously I'm the threats guy, but I think that threat modeling is so critical to building a correct security posture that you neglect it at your peril. If you're not doing something out of a sake of threat modeling, you're just cargo culting.

Yes. You know what? I agree. I almost regret not picking this one, but my favorite is actually the one about securing AI with DeepMind.

Well, that one's really cool. Why do you like that one?

That was really cool. Yeah, because the reason I like it is because it's a bridge episode for things that are real today to things that are almost certainly to be real in the future.

Yes.

I'm reading a book that actually Eric Schmidt, right, former CEO of Google, has written on AI with other people. And the book also reminds me about this bridge between AI today and the future state of AI. So to me, the DeepMind episode reminded me of this because there are some Threat models that are real today and the threat models that are coming for that. And I loved how the episode connected the reality today with the likely, very likely reality of the near future.

Yes. And I think that that field of AI security and securing AI and understanding the threats against AI, super fascinating. A couple of summers ago, I actually think this was at the event where you and I met for the first time. Listeners, the way I met Anton, we were standing in line to get coffee, or he He was standing, I was hunched over on a set of canes at the time. And I say, oh, hey, I'm Tim, what's your name? He says, oh, I'm Anton, blah, blah, blah. And I look at him and I'm like, oh, you're that Anton. So our relationship has improved from there. But at that security strategy offsite, a dear friend and respected colleague proposed actually a product suite around AI security. And I think her ideas were, Maybe premature or maybe not appreciated by everybody in the audience, but it's certainly an area that has for years been fascinating. And I think you're absolutely right that it's a bridge to an area that's going to be fascinating for a long time to come. So one of the things I love about doing the podcast, like I said, is learning and all this user empathy. We've had a lot of people come on to talk about migrations, whether it's practitioners like Elliot, whether it's high-level leaders like Brandy and Allison. What have you learned from organizations migrating to the cloud? Like what are, what are some of the surprising lessons maybe? about cloud migrations that you've run into?

So I don't want to use the same line I've used before about how many people come to the cloud with on-premise thinking. But to me, the— I'm going to use a derivative from that, maybe a more useful derivative. I feel like what we do need in many regards is kind of a mental model translator. And this is needed for the CISOs, for leaders, And it's needed for practitioners. So, it's not just a tool for CISOs and CIOs, but it's also not a tool for engineers. It needs to have a version for both. And to me, the learning is that a lot of organizations are not cloud natives, and it's a fact of life. They're coming to the cloud from, well, not cloud. So, before we tell them, do what cloud natives do, or use these tools, or shift left, or do threat modeling right, what we need to tell them is, Before that, here is the mental model translator. Here's what's in your head most likely, DMZ, firewalls, secure endpoints, OS hardening. Here is the tool that makes these concepts translate to the cloud realities.

Mm-hmm.

And here's how you use it. So, I almost feel like there's this mythical/metaphorical machine that translates on-premise mental models to cloud.

You want the cloud Babelfish. You want like the object we drop in somebody's ear and all of a sudden everything they know about on-prem translates or doesn't to cloud.

Correct. That's exactly right. Yeah, that's the idea.

Because there's no DMZ in cloud. Some things just straight up don't translate.

Yes, but in this case, I want the tool to be smart. Probably should use AI. And it should translate. It should go back to reasons why DMZ exists and then come back with a cloudy implementation of the same reason.

Hmm.

So like for physical security, it may not map.

That's like one of the most interesting things I think, as you see not just, you know, security teams moving to cloud, but compliance teams moving to cloud. You know, you have well-intentioned members of organizations who are trying to translate compliance standards that maybe haven't kept up as the cloud has come. And you have people literally having to figure out what a DMZ means in the cloud, oft because somebody with a paper checklist is going to show up and say, Do you have a DMZ in the cloud? How do you even answer that question for those people and how do we help them? That was one of the most interesting things I think from the episode with Zeal, which I ended up enjoying that episode way more than I thought I would because it was such a thoughtful approach to understanding, well, what does compliance in the cloud mean?

Yes, correct.

And of course compliance in the cloud isn't just taking the old stuff and translating to cloud. It's also in the upcoming episode adjusting the reality of cloud to the old way of thinking about things. And so as we think about what sovereignty means in the cloud and how countries as part of national security policy think about securely retaining these compute bases in the event of God knows what could happen, which has become all too real now, it's a really interesting case where not only do we have compliance translating to cloud, we also have cloud getting translated back to more physical meatspace thinking. It's fascinating.

Right.

Really?

Yes. And I mean, to me, this mythical tool should translate the compliance concept as well, because it may be that they need a quarterly audit. But as I was joking back in my Gartner days, how do you mix daily code changes with quarterly audits?

Right.

Like, that makes no sense, but it needs to make sense, right?

Right.

It better make sense.

It has to make sense. We have to figure out how to make this make sense to people for a lot of reasons. One, because it'll change their security outcome, and two, because they're not going to adopt Google Cloud as quickly as they would otherwise. If we don't make this easy. I think about the value that my teams generate. A lot of it is helping people move more quickly and more securely. You can move faster when you feel safe. It's like if I'm skiing down a mountain and I see that there's a nice runout, I'm going to take more risk than if there's trees everywhere. So we got to keep that in mind as we're building these things too.

So at this point, we should ask each other our favorite closing questions that we use on all guests, right? And these are, of course, as most of you know by now, reading materials and one tip Or maybe one trick on how to improve cloud security. So with reading materials, Tim, any answers?

You know, it's funny. I actually think given how much of the time we spend trying to get people to think with cloud, I would say you should go read the write-up on the Capital One breach on AWS. Because if you read that, you will see what a breach in cloud looks like as opposed to a breach on-prem. and appreciate why they are so markedly different and where we as security professionals have both new opportunity but also new exposure. So that would be my one reading suggestion if I only get one. I would have a list as long as, well, as long as our episode list if I could go point to all the interesting things our guests have mentioned, but I don't think that one's gotten mentioned yet. And so I'm excited about that one. What would you recommend? And it can't be your blog. You have a swear jar for that.

I have a swear jar and I would not read the full URL of my blog, my Twitter, my LinkedIn, and of course our podcast because this would be too much time. I want to highlight a resource that actually some of the Googlers who were on the show highlighted as well. Of course, we have a collection of several books written by SREs, and these are hugely useful. I kind of call them SRE books. There's a security SRE book. But there's also one book. I don't think it's counted as an official SRE book, but it's a cloud migration book. It is available for free, and we'll put the URL in the notes. But there's a cloud migration book with a lot of wisdom.

Mm-hmm.

from our field team, from other people, and it does address some of the same topics we're addressing. It's not a security resource, but it's a cloud migration resource.

Fascinating. That's a really good resource because so much of our time is spent thinking about migration. So I'll close then. What's your one weird tip to improve your cloud security?

You know, I'm going to be really nasty in this case, and I will actually kind of steal yours, frankly. And the reason is we're probably just going to use the same tip, and it's about threat models. My version of it would be slightly more Antonized version, I guess. Okay. I'm going to start from saying that a lot of people are actually genuinely confused about what threats are real in the cloud.

Yes.

So, to me, threat modeling is very difficult. I'm looking back to my Threat Horizons, to our Threat Horizons report we published last year and then had another one this year. A lot of things in the report read like on-premise threats, but some of them don't. So it's interesting that we actually don't have all that much data to deduce what threats are real for your environment in the cloud. There's data, but there's no canonical source. And there's some published resources, but some of them are frankly fairly silly, or they're not based on reality. But the reality-based ranking of threats to my environment is actually really difficult.

Hmm. Yes.

And I want people to invest time and energy into finding this for your environment.

That's a, that's a really good one.

Threat model where you are.

Yeah, look at that. Well, having stolen my tip, I guess I will go with a seemingly very generic piece of advice, which is people should make sure that all of their sessions auth with YubiKeys. And of course, you should use Security Command Center Premium, but You know, that's for down the road. Get the basics right first.

It's a little self-serving, Tim, though. It's a little, a little.

It's a lot self-serving. It's a lot self-serving. But, you know, you get the posture side, you get the threat side, you get the reporting side. Very powerful capability. You can say use Chronicle if you want.

Okay. Use Chronicle. Yeah, there it is. I will say so. Use Chronicle and Simplify while you're at it. And now we are at time.

This was actually more fun than I expected, even though, no guess, Anton, are you saying you didn't expect 20 minutes of hanging out and shooting the shit to not be fun? I'm hurt.

Oh, well, yes, I did. So to continue with our traditional closing, you can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us on 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_Chuvakinen_. Everybody probably knows your underscore at this point.

_TimPeacock.

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, or perhaps see you at the next anniversary episode next year. Hopefully, you'll listen for more than that. Secure running.

Secure running.