Cloud Security Talks Summarized: A Recap Episode

Hi there, welcome to the Cloud Security Podcast. Thanks for joining us today. Your hosts here are Tim Peacock, the product manager for threat detection here at Cloud, and me, Anton Chuvakin, a reformed analyst— reformed, I'm going to stress that— and member of cloud security team here at Google. You can find this podcast wherever podcasts are distributed and on our website whenever we finally launch it. You can also follow us on Twitter as well, twitter.com/cloudsegpodcast. Today we have no guests actually, we're just going to talk about a recent event that Google Cloud has run. It's Q1 2021 Cloud Security Talks, a lot of very fun presentations on many topics, including some of the things that I feel would be pretty groundbreaking like Trusted Cloud. What do you think, Tim?

I think it was a fantastic day of interesting talks, and I'm excited to do a recap of it with you today. So let's talk about Trusted Cloud.

I mean, to be honest, when I first heard of the concept and how we're gonna present it, I had some doubts, frankly. But to be honest, when the story came out, I loved it. The fact that we have elements unique to Google Cloud— we have, of course, Zero Trust. We are kind of the original home of Zero Trust. at least of Zero Trust working in real life. We have focused a lot on transparency, explaining how to do things, putting out detailed white papers and writing about how things are done inside Google Cloud so people can trust us. And of course, now we created this whole concept of shared fate, which we'll discuss later in the episode. I kind of liked it. I think I'd buy that. I think the Trusted Cloud vision worked well.

I think there's a ton of cool stuff happening in this space. So listeners, one of our previous episodes was about Zero Trust, and there was a lengthy discussion about what you actually do trust in Zero Trust. But the access transparency portion and transparency in general for cloud, I actually think is a fascinating area. Google does a lot of really cool things that, again, are an externalization of some of the great stuff that we do internally. Google's entire business relies on trust, and whether it's consumers trusting us to be respectful of their data or enterprises trusting us to be respectful of their data, there's a lot of process and technology in place behind the scenes that not only govern Googler access to data, But when Googlers do need to access data, making sure that we have immutable logging, which is rapidly exposed to customers that explain not just what was accessed, but the justification for the access as well. I think the access transparency area is actually a fascinating thing, both in terms of technology design, organizational design, but also user-centric design and thinking, how do we expose the right bits to users so that they can understand what was going on?

And to me, it's also a very direct trust-building machinery, if I can call it that, because to me, if people know what we do, with their data, their systems, and we have clear technical proof of that, to me, this is probably the best trust building. It's better than any kind of contractual legal paperwork. I mean, I'm not a lawyer, of course, so I shouldn't give legal advice. But the point is, I'd rather see bits and bytes and math as proof, not necessarily legal paperwork.

You prefer public certificates, private keys, and that sort of thing over pinky promises.

Yeah, I shouldn't offend the lawyers by saying that what they do is pinky promises. But to me, technical proof sort of trumps the paper proof. And to me, the most fascinating aspect of the whole trusted cloud story is, of course, the whole concept of shared fate. We will probably eventually invite people who are responsible for building that to the podcast. But again, this is another vision where I can have initial questions. So my first take on the shared fate logic was this. Wait a second. You cannot possibly use insurance and shared fate synonymously, because if my house burns down, insurance pays me money. Their house didn't burn down. The fate is separate. And I've hit Matt, and I've hit a few people with that example. And later they told me, wait a second, no. Yeah, that's one interpretation, but really it comes back to the operational roots where people who own the systems and people who operate the systems collaborate in a way that isn't just about money changing hands. And so to me, shared fate really clicked in my head. I kind of realized that the shared fate is a way to fix some of the challenges with who is responsible for cloud security problems, clients or providers.

Right.

To me, shared fate is muting this question and saying, let's transcend this and go from shared responsibility, your fault, my fault, your fault, my fault, to shared fate when this question makes no sense. To me, this is awesome.

Yeah, I think in addition to the, like, economic alignment, there's again cool technology things happening here. The technology that underpins a lot of the underwriting APIs where insurers get insights about users' cloud posture are actually some of the same APIs that we are developing over in Security Command Center. So there's really interesting technical work going on behind the scenes to make better cyber risk underwriting possible. In buildings, we've had Not a lot of technology changes, like the fundamental risks to buildings— fire, flood, earthquake, tornadoes— those have been around for 100 years or more, and we've got actuarial tables going back longer than my arm. Cloud is moving as quickly as a tornado. In many cases, I think CISOs feel similarly to cloud migrations and tornadoes. But what's fun about this is we actually have now the ability to standardize and get out of paper-based questionnaires. about security practices and give a live real-time update of how an organization is actually doing in keeping themselves safe. So unlike a building where you install sprinklers and they stay in the ceiling for 30 years until you tear the building down, you can have firewalls come and go in cloud, not hanging out in a bucket in the blink of a Terraform change. It's a whole new world. And I'm super stoked about what we're exploring and making possible there.

And I think the tricky part is not really about, hey, we now have insurance in the cloud. It's really not that. It's kind of a perfect marriage of the risk manager, with the technology Tim just described, and the insurance as a backstop for challenges that are not handled by technology. So to me, this is actually going to work. I bet it's going to work. I think that's actually the paradigm-changing— I don't use the words loosely— approach to cloud security.

It's things like that that attracted me to working at Google on this problem space in the first time, is with cloud, and when it comes to thinking with cloud and security, it is literally paradigm-changing for what we're able to deliver. I find it exciting. I'm not laughing at the paradigm shift in common at all. So changing gears slightly, and again, something very cloud-oriented, we had a session by Nellie Porter, the guest from our first episode ever, talking about confidential compute and what's going on there. I don't want to spend too much time on it because we did have a whole episode on it and we had Nellie on the show, but I thought it was really great to see the partner ecosystem coming along in that area as well.

Yeah, and I noticed, for example, the person from Tails at that panel described how they provide this for some of the top security requirements, for some of the environments where security really matters more than anything. So to me, it was kind of interesting that it's not about, hey, let's make things more secure, but it's more about if you really solved most of the security problems and you only have the tippy tip of the pyramid to solve, you really push hard to solve that sort of like residual risk with some of these things. To me, that was kind of impressive. Sometimes when you deal with mainstream clients and they go and say, hey, do you guys do encryption? And you say yes, and they say, okay, great, that's all they need.

This is okay. I mean, we do do encryption.

There's default encryption. It's awesome. Google has it. Others, you know, may not. But to me, it's kind of when you push this threat model to the extreme, like you crank it all the way to 11, you then realize, wait a second, what if somebody is stealing memory contents from this neighboring VM? And then you start thinking, wait a second, how do you solve that?

One of the things that Thales, the thing that that guy said that I thought was really interesting was there's no demo for encryption. And I've been thinking about that. Like, how do you demo encryption in a way that is exciting and gives users that pin-drop moment of, oh yeah, this thing's really secure?

Well, the Cloud EKM, it was not the subject of the presentation, but actually when you use Cloud EKM, there is a decent demo story when you do configuration, you set up the external key manager, and then you try going to BigQuery and you cannot. The demo is that stuff breaks, but it breaks the way it should because you revoked the key. So when you own the key and you revoke it, stuff stops working. And the demo shows stuff works, stuff doesn't work. That's the demo. Very impressive.

That is a great demo. The other External Key Manager demo component I love is the key access justifications that come with that. Tying things back to the transparency thing is External Key Manager. When Google asks for a key, we tell you why we're asking for it.

And you can, based on our key access justification, provide the key.

Or not.

You can make policy decisions, you can write policy, you can write automated policy based on the metadata that shows up. Like if they say we want this, you say no. I mean, I can see how it can become part of operational reality at some companies.

Very cool feature.

Yeah, absolutely. So you did the presentation as well on container security. I'm pretty sure you're excited to talk about that, right?

I am. It had a cool demo, in my humble opinion. With security products, it's actually a little bit more fun to do demos in the threat detection world, I think, than the encryption world. And what we did a demo of, and I think this is a pretty cool demo, is I actually deployed a container, attacked a vulnerability in Drupal, not to pick on Drupal, everybody's got different vulnerabilities you could abuse. We could have just as easily done WordPress or Jenkins or a million other things, but we chose Drupal and got some code execution on the container and then showed in Security Command Center the real-time detection of the code execution in that GKE container. And so what we're doing with container threat detection is solving one piece of the container security lifecycle. There's a million things that Google is doing upstream and infrastructure security, supply chain security. We're going to have GKE guests on the show in a couple of weeks. But one of the things we're doing with KTD is solving the runtime threat detection problem.

You know, I'm going to ask about the threat model because you say threat detection and I usually think, well, wait a second, what threats? Like in your example, you had an exploitation of a classic vulnerability, like a known vulnerability. What sort of threat model assumptions you're making when you did the presentation?

So what's really fun is we didn't actually detect exploitation of a vulnerability. what we detected was execution of a binary that was not part of the container when it was built. And so one of the fundamental assumptions in our threat model for containerized workloads is that what comes out of your build system is what should run in production. And if we see things getting added to the ephemeral file system and then executed, that's probably an indication of compromise regardless of where that added binary came from. Now, there are of course exceptions. I alluded to Jenkins. Everybody's build system creates binaries and executes them. So there are, of course, cases where this theory of defense falls down, but it's a really elegant generic way of detecting compromise of a container, as opposed to a virtual machine type environment where adding binaries is just a thing that happens. We're taking advantage of what containers are.

Maybe I'm dating myself, but I think of it as kind of a modern spin on whitelisting, right? When nothing except for this whitelist can run. And obviously, if anything does, then you freak out, all hands on deck, right?

I would hope that my users are more nuanced than freak out, all hands on deck. But yeah, essentially, if something runs that was not part of what came out of your build system, it's a good sign you've got an issue.

Okay, so the issue is not that you have this system to detect exploitation. The challenge is that if exploitation leads to execution of stuff that you didn't put there, then you do all hands on deck or block things.

There's a number of other detection capabilities within the product, and, you know, we're able to do this kind of detection because not only are we a user space component, We're also a kernel space component that can watch file writes regardless of which container they're happening in, as well as process execution regardless of what container they're happening. So we got really nice kernel level visibility with KTD coupled with a user space agent that makes us container aware. It's an elegant solution to the container security runtime problem. Now you also had something relevant to what you primarily work on at the container talks, although it wasn't you talking. Mike was talking about Chronicle. What are the highlights there?

Of course, because I used to deal a lot more with Chronicle than now. I mean, I still help with the team, of course. I would say that to me it was more of a traditional presentation. However, there were a few highlights that Mike, the product manager, had made. I would say that when we present Chronicle story today, we kind of make assumptions that we know, like it runs on Google infrastructure and stuff like that. But we also need to highlight some things that are just dead obvious here at Google and are not obvious at all to clients. Like, for example, that we don't charge money Right. It wasn't necessarily in the presentation, but there were other things that are first well-known and obvious at Google, but are just esoteric knowledge outside. So, for example, Chronicle does have the sense-making advanced search. I can call it that using the outside term and the enrichment that we call aliasing to really make sure that the data that shows up in front of an analyst is reliable, useful, clear. And to me, You can do it elsewhere, but it's a lot of work. To me, some of the Chronicle advantage that Mike highlighted is that we do correlate a lot of datasets together, from IPs to names to users to processes to assets to hashes. And then as a result, you can do magical things like you can search a log that has no DNS name for a name. The log would have an IP, IP gets resolved to DNS name, and it would show up in your search. To me, this is magic. And it works really well because as an analyst, I don't always know, do I try an IP? Do I try DNS name if resolution changed over time? There's a lot of funny stuff and not always fun stuff that I need to do. And in case of Chronicle, the data is clear, logical, timestamp connected, and this is kind of a big deal. And I liked how Mike presented this in the presentation. He also made a great point about some of the modern data sources. Of course, we have a lot of EDR data. When I say EDR, I keep thinking how I invented the term back in my Gartner days, and I don't want to boast, but the point is— You are responsible for inventing Yeah, I'm responsible for EDR, correct.

I didn't know you invented that term.

Yeah, I can send you a Gartner blog post from 2013 where I say, I finally named it.

I've always wondered, what's the difference between EDR and AV?

There's actually a blog post from 2014 where I tried to explain that. So funny enough, we're kind of derailing from our story. But to me, when I thought about EDR first, I thought of detection and response that happens primarily on the endpoint. I did not think prevention. I did not think malware. In fact, my very first name that almost made it was ETDR, Endpoint Threat Detection Response. And I used the T to shove away malware as an example and say, no, this is not really about malware like AV. This is about threats. If it's a human attacker, some other issue, but not malware, ETDR, which is now called EDR, should detect it. And I like how EDR became one of the critical data sources in the Chronicle. We have a lot of clients who have EDR data in very large volumes, maybe not petabytes, but definitely high terabytes flowing in there, and we don't charge for it. The data just shows up.

I really like that split of adding threat to distinguish from malware because one of my other products, event threat detection, we really don't do a lot for malware. And I think I have a lot of users that wish we would do more, but they're not thinking with cloud. when they ask for malware detection. So this is a case of something old that's new again for me, where threat is really beyond malware, you know, Mad Max beyond Malware Dome sort of situation.

Yep.

And that's, again, is an exciting bit. Sometimes we hear things about like attackers living off the land, using PowerShell, using other technologies. And to me, this is not really new, but the attention we now pay for it is kind of elevated for sure. And our threat analysts would talk, you know, ad infinitum about how attackers may not even bring malware. They may use legitimate tools. So to me, you have to look for it. And to me, antivirus is obviously not the answer because there's no virus, no malware. But EDR is supposed to watch activities from legitimate applications, new processes, old processes, connectivity. And that data is hugely useful, especially when correlated with logs. To me, Chronicle is a really good answer for that, whether you're running in the cloud or not. At this point, I'm going to become a Chronicle evangelist, which was my original job here. So maybe I should stop and go back to videos.

Let's pivot from Chronicle, since I know Chronicle enables analyst pivots, and talk about ML. We had a fun session from 2 of my favorite PM colleagues, Peter and Emil, talking about ML and network security. And I have made some— whatever the opposite of a friend is, I've made some of those here at Google with my ML for security skepticism hat. Nobody likes this hat when I put it on, but I think it's an important hat to wear. And I think you also wear the ML skeptic hat. Is that true?

Sort of. I'll kind of share my position on this a little bit later, but my absolute last paper I wrote at Gartner in 2019 was assessing the impact of machine learning on security. It published in May 2019. So this was my literally last contribution to the world of the analyst job, but I am a reformed analyst, so I shouldn't push it too far.

What's your take on ML for security? And we'll talk about what they shared with us in their session.

Over the years, I've kind of realized that there's only one true statement, one true position that one should have on this. And I'm not trying to tell you, you must adopt my view or you're wrong. But I kind of came to that view over time. I think that the sane view is that you become a long-term optimist and a short-term skeptic. Will machine learning make a big contribution to security within the next 10, 20 years? Absolutely. Do you think today's tools are magical and would deliver security when you push the button?

No.

Hell no. So I am definitely a short-term skeptic and a long-term optimist.

I think that's super reasonable. Are we allowed to say hell on the internet? Can you curse on the internet? I'm not sure.

We're not cursing. We are just referring to hell.

I see.

Okay.

Well, so I think I largely agree with that position. But I will say, and in the context of WAF and DDoS mitigation and bot detection, in a past life, I was never an analyst, but I did work at Shape Security. And one of the things that we really did succeed at there, believe it or not, is using ML to discern the patterns of automated activity in a sea of activity against websites and mobile apps. I've seen ML used, but in some ways, what I'm describing is not a traditional security problem, it's more of an abuse problem. The other place is, of course, in fraud detection. There's this interesting spectrum in my mind from fraud to abuse to real security problems. I don't know if security has done itself favors by trying to push fraud and abuse out of our cool kids club. But there's definitely a distinction going on between those 3 fields, not just in who practices them, who owns the bag, but also how applicable ML is.

I would say that there are definitely use cases where it works well. And to me, your example of the bot and fraud detection reminds me of a lot of the beaconing detection use cases where people responded to, say, malware C&C, command and control, talking to the mothership. from similar activities, say, by human users, browsers, applications. So to me, that type of automation detection was some of the, like, baby's first ML use cases together with DGA detection. Then for DoS, DoS is the problem that just begs to be ML'd, right? You don't want to write complicated rules for DoS, but you also need to learn the baselines and then kind of make deductions from the activity patterns. Like, is this an end-of-the-quarter rush or is it an attack? To me, this is very MLable.

Right.

And I'm happy that we are doing more of that. And WAF, I think that WAF is an interesting space where the rules would still survive. I think that the fully ML-based WAF that has no rules of any kind ever is a bad idea.

I would agree with that. I can't imagine a WAF with no rules, but a WAF that has a core rule set that then adapts to your application, I think that's plausible and probably not too far off. There's a couple of interesting places where we use ML internally for security, and I don't think I'm allowed to speak too specifically about them, but they They take the form of classification problems and classification problems again, where we have fairly large datasets to work with. But what's interesting about where we've successfully applied it internally is they are cases of smaller true positive sets than you might imagine, and where there's fewer opportunities for true positives in training sets than you might imagine.

Yep.

We're making some progress internally, and I'll allude to the fact that at least one of the teams I look after is going to later this year launch multiple ML-powered detectors that I can't wait to talk about.

Funny enough, same with Chronicle. Chronicle is close to building a couple of ML-based detectors. I'm going to leave it at that. I don't want to reveal— steal the thunder from the team. But the point is that to me, a quick thing that attracted me to Chronicle in the first place back in 2019 was that we want to get the data first. We want to get good data first, and then we can build ML that works. If you're a startup, you may want to market ML day one, but if you are attached to Alphabet and now part of Google, it's much more logical, much more sane to build the datasets, collect the data, have the data in one place, clear it, and then have ML have at it.

So we're getting close to time. I want to mention 2 other sessions that we didn't have time to go over today. We had a great session on information governance in Google Workspace from 2 of the folks over there, and there's a really interesting session that we didn't have time to talk about today About how we're building security capabilities into the Chrome browser for use in a zero-trust environment. And so there's a lot of other great talks. You can find them all online. They're now available on demand. A lot of great work went into putting these together. Recommend that people check them out. Really fantastic sessions. I want to call out one Googler. I'm sure his face is going to turn red for me thanking him so publicly, but I really want to give a big old shout out to Sam Lugani, who puts these sessions together. Sam is a wonderful colleague, a great friend, really appreciate his work. He's also the host for the confidential session, so you can check him out when you get to that. And so with that, we're at time today. Links to all the videos are going to be available on our website and in the podcast metadata. You can find this podcast, all of our previous episodes, and our future episodes at Google Podcasts or wherever podcasts are sold. You can follow our podcast account on Twitter. twitter.com/cloudsecpodcast. You can follow my co-host Anton @Anton_Chuvakin, and you can follow me @TimPeacock. Please do tweet at us, email with us, argue with us, and if we like or hate what we hear, we can invite you onto a future episode and you can have all of the fun arguing with us in person, which is, I promise, more fun than arguing with people on Twitter. So with that, I will see you on the next Cloud Security Podcast episode. Bye.