EP137 Next 2023 Special: Conference Recap - AI, Cloud, Security, Magical Hallway Conversations

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, argue with us and the rest of our Cloud Security Podcast listeners all on LinkedIn. Anton, this is a fun episode today because we're talking and recording about stuff that's happening right now.

Yes, we are doing it. I can't say we're doing it live from Google Cloud Next conference because we are actually doing it from a Google office 4 blocks away. 4 blocks away, exactly. I wanted to say next to next because it'd be funnier, but like, sorry for the 4 blocks thing.

It was next to next, and this is airing next week.

Yes, correct. It's airing next week right after next.

Got it. That's a mouthful. Listeners, this is fun though, because Anton and I happen to be in the same room today, which we very rarely do. This is cool. So what did you see at Next that you thought was interesting?

As you know, I kind of hate general broad questions. Hey, what are the trends? So—

It's true, listeners. He told me this Monday, actually.

Yeah, but I think that one thought that came to me, I was observing the expo floor in Moscone and watching the presentations. Obviously, I got this intense RSA vibe, even though I realized that not every vendor is a security vendor in the next show floor. But it's interesting that I found our own booth for Google Cloud Security. So I thought, hey, we are finally a security vendor. And of course, that statement is probably like years overdue. But it sort of dawned on me when I was wandering the expo floor that we are now a bona fide real security vendor that delivers stuff to secure not just our cloud, but other clouds, other devices.

Not just our browser, every browser. Yeah, we're a real security company.

And this is like somehow dawned on me. And I guess maybe it's more of a personal observation rather than a fact or new launch. But I kind of felt it very intensely that we are a security vendor. We are the real thing.

It was funny, the RSA comparison you bring up, because listeners, the event happens in the same place as RSA happens every year. When you walk the show floor at RSA, everybody's a security vendor. At this event, there were vendors of all kinds of stuff, and it was kind of like, you know, I'm bi, so I hang out in both gay and straight spaces. It's kind of like when you're at a gay bar, almost everybody's gay. But this time it was as if my usual gay bar was full of straight people. Not everybody was a security vendor. It was very strange. I didn't know what was going on. Felt so out of place. But it was nice to realize that, yeah, we're a real security vendor. We sell, we make, we secure a meaningful portion of the world now. It's really cool. So you have a presentation. I had a presentation. What other presentations did you think was cool? And then I want to talk about some of the stuff in my presentation.

Yeah, I guess, yeah, it's the self-serving bit. It's a little self-serving. And I think that—

So rarely are we self-serving.

We are very rarely self-serving. But I think that I kind of want to have a meta idea on this first before I go into the presentation I did. So one other thing that I observed, we observed when we were walking the vendor expo, is that a lot of security we see in the expo floor, is sold to security people. Obviously RSA, back to the traditional security show, security is meant to be sold to security teams, security leaders, but some cloud security is actually sold to cloud people, and it's used by cloud people, not security people.

Yes.

So my presentation is kind of about the encounter between these 2 worlds. It's a story about a more traditional security operations center, or SOC, that suddenly encounters cloud. So, I'm taking the view that I'm talking to security people who met cloud for the first time, and they maybe their encounters weren't very friendly in the beginning. But I'm also realizing that at this conference, it's more normal to have cloud people encountering security for the first time. So, it gives me kind of a weird vibe in my brain.

You know what's fun? My talk is about security people helping cloud people learn about security. So, in my talk with 2 speakers from Uber, they describe how as security professionals, They've integrated my product with the rest of Uber, and they use that to help the rest of Uber's cloud people understand security and respond to security, which is really great.

Yeah.

Listeners, we say in cloud, you really, because of the scale, because of the distributed responsibility, back to the Sunil Yu episode, security teams can't do it on their own. And we were talking about this earlier in the week too, of how do we, as people move to the cloud, how do we abandon the traditional no mindset and gatekeeper mindset of security, and instead have our security organizations become enablers of engineering and business teams to move quickly and safely.

And I think there are also, there are other notable presentations, but I've noticed one by the team from Mandiant about cloud threats, which felt almost like a perfect prequel for my presentation because I talk about how SOC that just landed in the cloud need to be aware of cloud threats. And their preso is a very solid view of what's real in the cloud. what's happening. And it's not just all crypto miners. There's actually fun stuff going on, not just crypto miners. Crypto miners, Tim would say these are solved, right?

Well, I did talk about my million-dollar protection program against undetected crypto mining attacks, but did you see Kevin's slide during the keynote?

No, I have not.

Ah, so Kevin had a slide during the keynote and I haven't actually seen it. I've just had it described to me. So this is thirdhand description now, but in that slide he talked about the number of critical vulnerabilities in public cloud providers that have been publicly disclosed over the past couple of years.

Yeah, no, this is a bit biased against us, meaning like we don't have enough.

Well, so what was interesting is that our graph was labeled and there were 2 other unlabeled data points. And so listeners, I encourage you to go check it out. You can find it online if you search for Next 2023 keynote. on your favorite search engine, whatever that might be.

I've seen that visual before. I mean, it's a— yeah, so for me, it was a little spoilered a little bit before. And I know that there are some really staggering numbers. And so let's— yeah.

Yeah, so I guess one funny thing is, if you go watch my talk, you can see me fail at a demo. I love giving demos. And I will confess, I gave a live demo yesterday that did not work.

Isn't it a rite of passage for a PM that you'd have to have a demo fail on stage in front of ideally millions of people, but we'll take thousands?

In this case. Merely hundreds.

Hundreds.

Okay.

That's— yeah, well, junior league, I'm sure.

Yes, yes, yes. But still intensely painful psychologically. I will have nightmares about this the rest of my life. A little bit like when you think you show up to school naked, I will now forever nightmare about the time that my demo failed live on stage. So let's talk about some launches. We've seen a lot of AI.

We've seen a lot of AI. And I think that's the first time when we exposed the whole Duet AI for security. And I think SCC got a Duet, or maybe will play as a Duet. I don't know. What's the proper term of referring to it?

So I asked about that yesterday and I got a mixed answer. But actually, Connie, who joined us on the show for the RSA recap, explained to me how I should talk about this. And it's a feature of SCC powered by Duet AI. And what we're doing there is 2 things. One, we're using the generative AI to contextualize findings. So when a user, either a security user or an engineering user, looks at a finding, That finding comes with an English language generated, easy to understand explanation of what this finding means, how it was detected, why it's a problem, and what you should do about it.

English language, but also correct, right?

Yes, correct English language. That's even more important.

I've seen LLMs produce very, I mean, perfect language, better than mine, frankly, but not correct.

In this case, it's correct. We've spent a lot of time tuning it, training it, teaching it to really understand cloud. And then we also use that same Duet AI generative capability to explain attack paths. And so one of the things we made a lot of conversations about at the show, one of my demos that did work was my attack path explanation demo. And listeners, go check that out as well. We'll explain attack paths using AI. So an attack path in cloud can be hard to understand.

Can you explain attack paths without using AI, but like right now? Because remember when we walked around the vendor expo, we've seen a whole bunch of vendors That actually couldn't stop talking about attack paths. So how about you use your English language and no AI to explain attack paths?

So attack paths generally is the concept that maybe we could prioritize vulnerabilities, misconfigurations, exposures, things we want to fix to reduce our risk based on the actual risk that that particular issue or set of issues expose in an environment. And so to do that, you need to understand the environment. You need to understand the issues, and you need to understand how an adversary particularized to that environment would use those issues. Now, I saw a wide range of things that all had the label attack paths. I saw some cases where attack paths were—I don't know—a three-node diagram with internet issue and resource, and it was. I think maybe a visual trick more than an actual mechanism for prioritization. I saw other cases where attack paths were 2 or more issues bundled together, and I'll give that vendor credit for understanding the relationship between issues, but it wasn't clear to me that they were using it for true ranking of the problems in the environment.

Mm-hmm.

I saw yet another vendor that was using AI also to explain their issues. But what I thought was interesting there, there's a third-party vendor that you would choose to use to protect your cloud environments. They were taking that exposure data, vulnerability information about your cloud environment, and they had first moved it to their fabric. So they had stepped away from your environment with security risks, and then they were exposing that security risk onto another third party to do the generative AI explanation.

Oh, it's a little bit chained, a lot of Sort of risk going on, right?

Yeah. So think about that for a second. You've gone from, I've got issues in my environment that I trust, to a third party, to another third party. And so now we've moved security data from where it lives all the way over here. And listeners, I'm, I'm putting my arm on the other side of the room. How do you as a security team think through the legal controls, jurisdictional controls, technical controls of moving your threat data and vulnerability data around like that? And so one of the things I'm delighted about our AI capabilities and our security capabilities is not only are our security capabilities already delivered from the same fabric where the issue exists, so are the AI generations.

Yeah, no, but I mean, it's almost like an unfair advantage. Well, it's a fair advantage.

It's a fair advantage because we built it, and that's one of the inherent upsides of working with the cloud provider who understands their cloud best. So on the attack path thing, just to recap, there's a spectrum of of capability here from diagrams and eye candy to grouping all the way up to what we do, which is honest-to-goodness simulations of adversaries and how they might move through a cloud environment particularized to that cloud environment. And so when you look at our demo, you'll see how we understand the locations of identities, the ability of adversaries to assume identities and the permissions that those identities have that would allow them not only to do direct access, but actually to take fairly subtle steps in order to elevate their privileges or modify the environment that make further access to resources possible.

Yes. I think I liked it. I think it would make some of the crazy complex issues that especially the non-cloud people don't fully understand. And to me, that's part of the magic that we are delivering here. It wasn't just all AI. And I think that a lot of people on social media are joking how it's all AI. And I think there was a lot of AI, but there are some other interesting things. We've finally broadened the scope of what we used to call Cloud DLP to sensitive data protection. So there's this new data security. stuff being launched. I think there are updates to confidential computing, assured workloads. Yes, you can say they're less exciting than AI, but they're very useful. I mean, even the Chronicle Hunt with Mandiant is a fun thing.

What's that?

Oh, it's where we use actual humans, not AI—

Humans?

—to hunt for some of the— and not just humans, not just like actual humans, actually very, very skilled humans from Mandiant to look for some of the top-shelf threat actors and other things in Chronicle data. We call it Mandiant Hunt for Chronicle, and it's the way to approach some of the detections that are powered by experienced threat hunters on your Chronicle data.

So wait, wait, wait. Let me make sure I got this right. You're telling me that there's now an offering for Chronicle customers where they can get Mandiant's hunters to hunt for threats in their environments using Chronicle and Mandiant?

That's exactly correct. And I think that it is really awesome. But the point is that we have fun stuff that's not about AI.

Oh, that's literally the opposite of AI because it's human beings.

Well, they probably use AI too.

Okay, fine. They probably do. But it's human intelligence, not artificial intelligence, that's the core of the offering, where we're taking these experienced people who know how to do hunting really well and bring them to you.

That's correct. That's exactly right. I think that's part of the fun, and it's part of the fun that's solid, valuable, interesting for security, and it's not about AI.

At all?

At all.

Yeah, no, that's great. I think that's really quite a powerful capability. We had a couple of other hallway conversations that I thought were pretty interesting. We're at the point now where I think we're asking, will the real slim CNAPP please stand up?

Oh, yes. This was interesting. And I feel like, to me, it switched my brain off from asking that question. These conversations in the vendor expo and the hallway made me think that I should stop asking, please, the real CNAPP stand up, because I feel like there's a CNAPP with an application DNA and there's a CNAPP with platform DNA, and both of them have legitimate claims to being The real CNAPP. If you have the CNAPP that started largely around CSPM. By the way, people hate us for speaking acronyms without explaining them.

Oh, yeah.

But it's also a little bit of an IQ test because like CNAPP is this one of those acronyms that my former colleagues have coined and it's 5 letters, not 4. And not everybody knows what it stands for.

Cloud Native Application Protection Platform.

You're exactly right. Yes. I think you paid your Gartner tax with remembering this.

Goodness gracious. So listeners, CNAPP, Cloud Native Application Protection Platform. If you hear me spell out that acronym and still have no idea what it means, not my fault, Anton's former colleague's fault. What is a CNAPP? And explain it without saying it's a CSPM plus a CWPP.

No, because there are other components. I left Gartner in 2019, and I think that CNAPP was just being cooked. It was kind of still, you know, I can smell them cooking them in the kitchen, so I know what it was. I felt like CNAPP has grown to be the platform for securing customers' cloud experience. And customer cloud experience isn't the same as cloud platform plus apps. It's actually all of the above. It's cloud usage, it's apps, it's data in the cloud, it's infrastructure.

It's your upstream IDP.

It's your upstream stuff. It's to an extent whatever the cloud provider exposes, say APIs. So while in security we have a long history of trying to go for the platform and never succeeding, Duh, going back to, I don't know, '90s. I think CNAPP is this type of a bundle stack of things you need in the cloud to have a secure cloud experience.

And what are the other 2 components that I mentioned? What are those and how do they fit into it? What do those stand for, CSPM and CWPP?

CSPM is Cloud Security Posture Management.

What gets better if you use a CSPM?

Well, the dreadful cloud security issue everybody keeps talking about for 10 years is misconfiguring something. So CSPM is purported humanity's answer to cloud misconfigurations, and they've been trying to give that answer for 10 years, and it's been kind of tricky.

If that's the answer for 10 years, how come we still have misconfigurations?

Let's focus a separate episode on this very question. I don't think I have like a deep—

Okay. It's a good question for an episode.

It's a really good question. I have a blog somewhere, and I think you told me not to mention my blog more than 5 times an episode.

Well, now we're at 1. So that CSPM has helped us with posture. What about CWPP?

CWPP is actually—

What does that stand for?

Cloud Workload Protection Platform. And please don't laugh, but Cloud Workload Protection Platform is kind of an older acronym, and it's the previous attempt to create the platform. But CWPP is workload-centric, not cloud infrastructure or cloud-centric. It's centered on the workload. So, if you have like VMs in the cloud or some other transition tech, not cloud-born, cloud-native, You probably would be focused on CWPP, but people think this acronym is so 2000— probably 2010 even. I don't have the— CWPP is quite old.

That's quite old.

Yeah, it's quite old.

I'm not sure we had clouds back then.

I think we just started, and it was mostly VMs, and that's why CWPP was seen as the— but it's a history lesson. At this point, almost nobody cares about CWPP, but clearly everybody starts to care about CNAPP, and you should care about CSPM because if you don't, you're going to suffer.

But it also sounds like if you do care about CSPM, you're still going to suffer.

We decided to shelve this question and do it next episode.

Okay. Okay. Okay. Okay. So anyway, listeners, the debate we were having about CNAPP with all of that background is whether you were a more legit CNAPP having approached the problem from roots on the CSPM side, focusing on getting posture right, or whether you were a real CNAPP because you started from the workload side and then came back to do the posture side.

And the answer is yes.

The answer is yes.

The answer is yes.

I think it's a bit like the story of John Henry where they're digging from both sides of the mountain and they meet in the middle. I don't know which side is going to be John Henry though. Is it going to be the workload providers of the world that fall over dead? Is it going to be the posture providers of the world that fall over and say, wow, this team shovel really is great?

I think it doesn't matter, but it does matter that you do shovel from both sides. Because I think that if you only shovel from one side and you try to make your CSPM better without gaining any application visibility, you're not going to lead to customers having secure experience in the cloud.

I agree with that. Yeah, this is our second digging-related metaphor recently, and I'm glad we didn't dig down to hell this time or have an argument from the shovel lobby.

We should have some episode that mentioned dwarves and mines and stuff like that. I think it'll be kind of cool.

I think that has a good ring to it. I'll think about how we can do that.

Good ring to it indeed.

Yeah. All right, so I think we're getting up on time, and I'm not sure we have a ton more to say about the conference. Do you have final closing thoughts here on what we should take away from all this?

So I have 2. One of them is, actually, I had a few very fun hallway conversations and—

Magical hallway conversations?

One of them was maybe, yes, was quite magical.

Wow.

So I was going around and asking people how they help customers with cloud migration, security during cloud migration, how do they get people to transition from the lift and shift mindset and the 1990s data center mentality to more cloud native. And there was somebody who really sparked some kind of inspiration/depression in my mind that actually—

Oh, no.

They kind of said, well, people who carry a lot of their 1990s-style infrastructure and copy it to the cloud are kind of multiplying technical debt, and then they plan to pay it off in the future as they slowly become cloud native. And it's a very difficult journey for a lot of people, and it's— you can give them advice. But this person who I was talking to said, actually, Their take was, don't pay technical debt. Default on technical debt.

Ah, yes.

Leave the old stuff to be old, but put most of your energy into making sure that all the new stuff is done in a new way.

Is this very Michael Scott, I declare bankruptcy?

It's— that's probably a little bit too depressive a take. But the interesting point is that if people burn out trying to turn 1990s stuff into the cloud one VM at a time, And then they kind of die trying in some cases. Instead, what they should do according to this person is to make sure that all the new stuff is done in a new way, that you don't start with VMs in 2023.

You start with serverless in 2023.

You start with serverless and you start with modern services.

Well, that's interesting.

So it struck something in my mind. I'm now kind of obsessed with this take a little bit.

But how do you bridge that gap?

That conversation did not get to that point. But it was interesting how making sure that new stuff is done in a new way, rather than making sure all the old stuff is converted, is an interesting focus or refocus for them. And that's one, and it's kind of, again, if I have one big idea after a conference, that's a good idea.

That's great.

And the second point I wanted to make is the one I started making about cloud security being sometimes built for cloud people or for security people. And sometimes you see a tool that has vulnerability assessment in the cloud. Some of the cloud-native organizations are building technologies to do vulnerability assessment. But of course, there was a very active market going back to the '90s, if not '80s, of doing vulnerability scanning. Maybe late '80s. I think the first tool was written in the very first beginning of the '90s. Not the point. The point is that many, many years of evolution of vulnerability assessment, and now suddenly there's a bit of a rebirth of that in the cloud. So we have security tools written for security people, and we have Security tools written for cloud people. And adoption is really interesting. I've seen people adopt— deep in my heart, I think of them as still kind of inferior tools that were built by cloud people for cloud people. Was there an argument about some cloud security vendor building exploitability metric in their scan? And I thought, but wait a second, the classic vulnerability assessment vendors have built it. And I found the press release in 2009.

Wow.

Literally, they had exploitability metrics since 2009, and it's seen as new by cloud people who haven't seen that evidence. Well, of course it is.

If they never saw it, of course they think it's new.

Yes. And so this to me is freaking me out a little bit, but I think that the actual meta thought here is that there are cloud security tools built by security people for security people that then suffer adoption hurdles. And there are cloud security tools built by cloud people for cloud people that are easily adopted. But they are sometimes inferior in functionality.

Interesting.

So how do you make them have a happy— give me the metaphor, Tim.

Well, I think the real question is, how do we put the right value judgment on this? Because if a tool gets adopted and causes outcomes to be improved, even if it doesn't know that security stuff from 2009, it might still be the better tool if more people are using it and more people are improving outcomes thanks to it.

Yes. The tool that gets used is always the better tool.

Yes.

Yes, fine. That's a very good conclusion to have.

Okay. I will take a good conclusion. And with that, listeners, thank you so much for joining us this week. You can find this show where you find the show always. You can find Cloud Next on YouTube, as well as at the Cloud Next website.

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

Bye-bye. Secure running.

Secure running.