Threat Detection at Google Cloud Security Summit

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and member of the cloud security team here at Google. You can find this podcast and subscribe to it wherever podcasts are sold, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content, you can hit that subscribe button on your podcasting app of choice or on Twitter, twitter.com/cloudsecpodcast. Anton, we've got a fun episode today. We are talking about the Security Summit, and I think we'll start off with talking about Sunil's keynote. A couple of interesting things in there. What did you think about it?

Well, first thing is, we are recording this episode in July, and it should air one day before the summit. So please, please come join us at the Google Cloud Security Summit tomorrow, July 20th. This is probably the most important bit. Like, I want to make sure people show up and see all the videos and experience the whole thing. Yes, I know it's a virtual event, but it's a very fun virtual event with a lot of new things about our products, our thinking, and other things. The event would start with a keynote that is called Making Invisible Security a Reality with Google. So to me, I've looked at a lot of materials we built in this theme, and there are a lot of things I see that I like. For example, we do know security for a lot of organizations feels like friction, feels like many layers, feels like a lot of bolt-on stuff, feels like stuff to buy on top of what they bought already. So I really appreciate the fact that we want to push security into an area where it's sort of there and it delivers, but it isn't necessarily in your face. I would be the first to know that it's probably not possible with every security control. And the keynote definitely covers some of that. So it's a fun keynote to watch.

Is this the multi-decades-long vision of security built in, not bolted on?

Well, I mean, it's tricky. I don't think it's as simple as built in and bolt on because sometimes security, as the book we mentioned pretty much every episode mentions, Security is an emergent property of the system. In that sense, neither built-in nor bolt-on. You can build the security in, but then you can build the system in such a way that it would be insecure, right? So I'd be careful with an old built-in, bolt-on story simply because there's more to security. There's more complexity in our field, in our chosen field of endeavor, cyber, right?

Cyber. There is a lot of complexity there. So speaking of complexity, you and I are both presenters at the summit that's happening— for listeners who are listening to this, on the day it's released tomorrow. What are our 2 topics about and what do we have to say for the world?

So the fun part is I like the fact that we are talking about sort of parallel-ish products. Like, yeah, my presentation is about Chronicle and solutions around Chronicle, and yours is about the Security Command Center, right?

That's right. Mine's about Security Command Center and what it can do for you. And for listeners who aren't familiar with those 2 products, how would you describe Chronicle? I'll take a pass at describing SCC, but you go first on what is Chronicle.

Ah, you really put me on the spot here because funny enough, Chronicle is a lot harder to describe than some other tools. For example, if I meet somebody for the first time or if you wake me up at 3:00 AM and say, hey, Anton, what's Chronicle? I would probably start my explanation by starting with a SIEM or security analytics, log analysis, threat detection platform. So I wouldn't necessarily say Chronicle is a complete SIEM today because we have enough features, we cover enough use cases, but we also have some gaps between, say, Gartner's view of a SIEM. But we do cover a lot of modern SIEM use cases with the tool. And of course, it does mean on-premise as well, not only in GCP. That's very important.

Mm-hmm. If I were to answer the question of what is Security Command Center, I would say in Gartner lingo, it's CWPP and CSPM. It is your one-stop shop within Google Cloud for native posture and workload protection in Google Cloud. I think I said Google Cloud a lot of times in there, but you get the idea. And so then speaking specifically about our presentations, I had some questions I wanted to ask you about it. So why don't we dive in on that? When I look at your presentation and I look at your slides, there's a lot of problems we're trying to solve with it. You've got more than 10 listed on one of the slides. What are the most important one or two things that Chronicle is trying to address today for an enterprise security shop?

So this is a question that has been kind of going through my mind a lot in the last 2 years. Again, to use my 3:00 AM test, if somebody wakes me up at 3:00 AM and says, Anton, what are the absolute key magical advantages of Chronicle? I would probably go with speed and scale.

Mm-hmm.

Of course, every vendor now highlights scale, but there is scale as in your tool can scale, and there is a scale in terms of you can afford the tool to scale. Because sometimes when you pay per gigabyte, the tool would scale, but your wallet will not. So Chronicle is meant to scale both from the performance point of view, Flat query speed, just like Google, but also from the cost point of view, because we don't use the volume-based or log source-based pricing model, we can give you predictable economic scaling, not just, well, the tool can scale, but your wallet would crash way before the tool does.

So I used to be a big Elastic customer way back in the day, and we would joke that, you know, with Splunk, you would have a coffee cup query. You would make a query, go away, get your cup of coffee, and come back. With Elastic, you also had a coffee cup query. You would make a query and it would cost you a whole cup of coffee just to answer that one question.

Yeah. If somebody charges you per query, that's not unlikely, but there's also somebody somewhere paying for hardware, you know, for both of these tools. Yeah.

Yes. We were managing it ourselves and that was what our AWS bills worked out to. So I'll put, you know, a dollar in the swear jar here for mentioning your blog, which usually you do, but you had a blog recently that said more or less, and I'll summarize for the audience, TI matching isn't a detection approach unless you hate your SOC. A lot of what I see in Chronicle is TI matching. What's the special thing in there going on that makes Chronicle TI matching not harmful to people's SOC?

The blog post you have in mind on my Medium blog talks about how people naively get threat intel feeds from public sources, like from free feeds or low-cost feeds, and they just throw those feeds into their SIEM and match them to logs. And then they naively expect that the intel matches to logs are great detections. They're not.

They're not.

Because they're not really good. And I've seen environments where this approach delivers 97% false positives, which is kind of incredible. You'd never think that's possible, but it is.

I'm surprised it delivers 3% true positives. That seems high.

There is that, yes. But so the challenge isn't that TI is bad for detection or you must hate your SOC to use it. The challenge is that people do it naively by applying poor quality, kind of like context-quality threat intel to all logs instead of applying highly curated feeds to specific logs. You know, think about it. You have logs from your web server, connections hitting your DMZ, in the old parlance, connections hitting your publicly exposed cloud resources. Are you going to match it to bad IP lists? Guess what? A bad IP tried to connect to your website. That sounds horrible, right?

Oh, no.

Wake people up at 3:00 AM. But the stuff like that, I've seen people actually do, and it's It's kind of dumb.

Yeah.

And it destroys value, right?

Totally.

But when we mesh TI, we think of TI as kind of for heavily curated feeds. You can do detections. You can do retroactive detections. So you can have maybe intel showing up today, but logs showing up last month. And that's really useful, and it's much harder to do in other tools. We do do detections of fresh logs to fresh intel. But to really wake people up at 3:00 AM, I would rely on a heavily curated feed. I would rely on maybe human-curated feed by our team, Uppercase, Or I would use other matches as my either hunting clues or as hints to pursue or as something that then gets fed into rules. So to me, TI is useful for detection, but naive TI matching to logs, especially to all logs, is a recipe for failure.

I would buy that story completely, especially the idea of matching TI to your web server logs. That's just bonkers. The last thing I really wanted to pick at here, and it gets back to some of the Sunil content as well, is What does autonomic mean? Is this just like— and listeners, I'm doing jazz hands, but you can't see it. Is it just a fancy way of saying automatic, or does it mean something more beyond fancy automatic?

So here's the thing. We are airing this episode the day before the summit. So technically, people would have to wait for one more day before they know the truth behind this.

No, but this is a teaser question.

We'll give them a glimpse today. When I think about the autonomic approaches, I don't think about automated or about the degree of automation because frankly, automatic SOC is a crazy idea and it's a bad idea, frankly. If you've seen my blogs and blogs from other analysts, such as my former sort of colleagues at Forrester, the SOC without people is kind of a bad idea and it's a bad idea for the foreseeable future. It's also an unworkable idea.

Mm-hmm.

So, autonomic does not mean fire the SOC personnel. However, it does mean that we have to apply automation to SOC in a somewhat different manner, not only as a force multiplier, not only in the more traditional way to solve routine tasks, but we have to sort of hyperscale the people. We will have the SOC team, but we have to scale the people's resources at a different model, different approach, different scale. I'm being a bit vague. You will have to wait one more day to see the details. But that's why to me, autonomic is not synonymous with automatic.

Okay.

It's kind of automated in a particularly smart manner, but absolutely not looking for getting rid of the people. That's impossible.

Yeah, I agree that getting rid of the people is impossible. If it were at all possible, we would've figured out how to do that at least in part by now. Everything we see instead is all about the workforce gap in cyber and what a lucrative career it is for all of us to go into.

So let's switch roles and then I get to interview you about your presentation. That sounds like fun.

Please.

I'm going to latch onto the point that we really like to hate on our podcast specifically. So it's the point that you chose to elevate to a title heading on one of the slides.

Yeah.

And this is the point, the cloud, it is not somebody else's computer. Because to me, the fear and the risk of people naively thinking that cloud is somebody else's computer is that they automatically apply all their knowledge from on-prem, all their playbooks, all their approaches to the cloud.

Mm-hmm.

Because, hey, it's just somebody else's computer. I can use all of my thinking going back to 1978 when you got into IT. Maybe not me. Yeah. You don't see that, but Tim made this sad, sad face. And then they try to apply this thinking to the cloud. And the result is extreme lift and shift, a lot of bad value. But sometimes people just flip too much the other way and they think cloud is completely different. You have to have a brain implant to use cloud, or you have to fire all the people and hire the cloud-native people. Not true. So help me understand, how do you think about cloud is not somebody else's computer in the context of threat detection?

Yeah, I think of it as an opportunity for people to, as I think it was Alyssa who said, update your playbooks. The needs of information security professionals don't really change in cloud. We still have to keep our data private. We have to keep our systems secure. We got to ensure uptime and reliability, but the terrain that we're defending has shifted. Sure, we still have compute instances. We still have the need to do detection on endpoints, but that's just one piece of the puzzle now. And just like with the Seth episode where we talked about onions versus garlic, I think in cloud, the model I'm starting to land on is really a 5 or 6 layer model of, I Identity protections, API protections, cloud-native and managed service protections. Host is one layer in here. Network is one layer in here. And that's where traditional security approaches live. This is where you'll find your EDR in cloud or your cloud IPS. And then on top of all of that is a whole new world of Kubernetes and distributed containerized workload protection. And that takes on all kinds of different flavors. given the nature of those workloads as compared to traditional approaches of installing applications on VMs or on physical machines. To me, the cloud is not just someone else's computer means sure, there's computers, but there's a whole lot more as a defender you need to think about, which give you both new opportunities, but also new places where you can lose if you're not looking for threats there.

Correct, correct. So to me, maybe the consensus position is cloud is not just somebody else's computer, But absolutely, cloud involves computers, in our case, owned by Google. There is that. But it's the just that really destroys your line of thinking, and it just sends your train down the wrong path into the lift and shift and crazy expenses and, you know, bad on-prem stuff deployed in the cloud and then ruined.

Totally.

So let's go talk about like slightly more detailed version of this, and your presentation focuses on threat detection. I don't think you say directly cloud native in this case, but What makes SCC or the ETD threat detections cloud native? Like, why are they born in the cloud, and what does it mean for threat detection?

Yeah, we actually had Julian on a couple of weeks ago. He leads the detection and response efforts here at Google for Google's use of Google Cloud. A lot of ETD's capabilities today are co-developed with that team. So to the extent that from the beginning of our concepts of what we wanted to detect, it's really focused on cloud. Even from the stage of writing a PRD or a design doc, it's cloud native. In terms of what we're looking for with ETD as compared to, say, KTD or some of the other stuff I'm working on, ETD, event threat detection, is really focused on detecting threats at the identity, API, and cloud managed services layers rather than, say, the host and network layers. And so it's super complementary to the kinds of detection that security teams already know and love from their on-prem days. I don't know about the love part, but what we're doing with ETD is really looking for the threats that target your cloud as a cloud, whether that's bad guys gaining persistence through anomalous IAM grants, whether that's account takeover that we can detect with UEBA now, things like that where they're really cloud-specific threats that we're looking for in cloud-specific ways.

Specific to containers, you had some really interesting ways to observe containers, like do introspection, do telemetry from containers, which don't have any on-premise equivalents, at least in my mind, they are truly cloud native because there's nothing of that sort on-prem, right?

Yeah, absolutely. We're really excited about what's going on there. And in about 6 months, we're going to have this conversation again about a really even much more cloud native thing that I wish I could talk about today, but we'll talk about really, really soon.

Well, there is that, like cloud native, I guess, has a scale, but for sure SCC isn't a backport of an on-premise product. Like some of our competitors in the market basically push products that were born on-prem into the cloud. And so to me, they may be good products, they may work well, but they're certainly not cloud native because where they were born? On-premise.

That's right.

So they're not cloud native, right? Like they may be cloud ported, but not cloud native. So let's go and touch about a little fun part of your product. And I hear that SCC now has a little embedded user and entity behavior analytics. So in my analyst days, I would call it a mini Yuba or even a baby Yuba. It's kind of embedded Yuba module inside another product. Do you think clients would use your sort of embedded UBA over a dedicated UBA tool or maybe a SIEM tool? And what kind of ML magic does your baby UBA use?

I get basically 2 reactions when I talk about UEBA with users. I get users that have never seen it in practice and they're really excited about it. And I get users that have seen it in practice and they roll their eyes and say, oh my God, that's going to be so noisy, please go away. And what I say to both of those users is, look, We really care about the quality of life for your analysts when it comes to turning this stuff on. We monitor the heck out of these rules before we release them. And just last week I was having a conversation with the engineering team on a new rule we're developing in that ballpark where we're not ready to release it yet because we still haven't gotten the noise out of the system for a group of users. So what we're doing is we're profiling the geographies of access as well as the client libraries or user agents used by service accounts and IAM accounts and detecting major deviation from established patterns. So it's really straightforward UEBA for now, but it's a stake in the ground about where we're headed with this team. And in terms of engineering development, there's a lot of good work that went into making this possible, but not just this one, the future ones as well. So it's both powerful detection today as well as a stake in the ground for where the team is headed over the next 12 to 18 months.

Yeah, exactly, because people expect us, Google, deliver on the ML for security because, frankly, When I think about it, I think of Google as number one company on this planet in terms of ML and AI knowledge. Like, there's no exaggeration. We are number one on this planet. That's fair.

I think a lot of people would agree with you on that one. My other team, KTD, has a couple of other super exciting ML things in flight as well that I can't quite talk about. But I will hint that in running something in evaluation mode last week, we had sort of the first set of data through this detector. And we had a couple of things that looked like reasonable false positives from the data we collected, but also something that looked like a really good true positive within our first week of running this new ML-powered detection capability. I'm just super stoked about that.

I mean, you probably don't plan to squeeze out all false positives out of the system, hopefully, because that's how you get your false negatives ratio up in most cases. So I think that many of the maybe less mature organizations don't appreciate this when I say it like this. Squeezing out FPs completely is bad advice.

Yes.

Because if you squeeze out all FPs, you would end up with losing some of the subtle clues, most likely.

That's right.

Let's get to the other fun part, namely the last question I wanted to ask is kind of about something we covered in episode 2, namely about automated remediation. I think your slide deck and your speech kind of mentions automated remediation. And I know that as we discussed in episode 2, a lot of people are triggered by that and not always positively. So what's our current stance on automated remediation as it's implemented in SCC?

Well, my stance on automated remediation is first to say we should really be talking about automated response. Remediation is a very high bar to achieve with the robots, but you can automatically respond and do a lot of good before you get talented humans involved in the non-toilsome, deeply insightful work. And so I think that's, you know, really where we see automation throughout the world being useful is in the toilsome parts and letting humans do the, you know, creative work. So with SCC today, there's not a lot built in, but we are working on it. And for people that do want to do automated response to SCC findings, SCC was built from day one to put our findings onto Pub/Sub topics, make them really easy to get out and operate against with things like Cloud Functions. I've had multiple users pull some example code that we posted on GitHub in what we're calling Security Response Automation, develop it for their specific use cases, and then another user actually published a blog post about what they achieved there when it comes to closing public buckets that SCC detects when they're made public. Cloud Function picks up that finding, automatically closes the bucket. And so it's not quite built in, but it's the next best thing to it and allows security teams to go from having to be in this toilsome process of responding to this finding over and over to just automatically smacking that and then having the security team free to go talk to that user and educate them and be the partner in security outcomes rather than the hamster on the wheel closing the bucket.

So if you'd use more crisp fact-based assessment, or a term for it would be like automated enablement for remediation, like you enable automation down the pipe.

Yeah.

Some people assume that naively that means the product fixes security problems by magic, just like that. But you sort of enable automated workflows elsewhere in the system, which to me is a realistic and valuable goal. It just doesn't sound as glamorous as, oh yeah, we auto-fixed the problem. It's done.

It's maybe less glamorous, but it also strikes me as a lot less scary and a lot more achievable in the near term.

So this is our second ever episode with no guests, and let us know how we fared this time. We are close to our 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 you get your podcasts. You can also find us at our website, and we are no longer joking about our website because we have a website, cloud.withgoogle.com/cloudsecurity/podcast. That's a real website. We have 21 episodes, and with this, it would be even more. Please subscribe so that you don't miss episodes. You can also follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter. It's @anton_chuvakin and @teampeacock. 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. And of course, attend the event tomorrow.

Bye.

Security.

Security.